Friday, February 23, 2018

Assignments in Intent

We're testing a scenario across two teams where two major areas of features get integrated. In a meeting to discuss testing some of this in end to end manner where end to end is larger, we agreed the need to set up a bunch of environments.

"Our team sets up 16 windows computers in the start state" seemed like an assignment we could agree on.

Two days later, I check on progress. I personally installed 3 computers on top of what we agreed to be what my team would do, and was ready to move on to using the computers as part of the scenario. The response I get is excited confirmation of having the rest of them available too.

The scenario we go through has a portal view into the computers installed, and checking if the numbers and details add up, I quickly learn that they don't. Ones I set up are fine. All others are not fine. We identify the problem ("I forgot a step in preparing the environment" and "It did not occur to me that I would need to verify on system level that they are fine") and agree on correcting them.

Two days later, I check again. It has not been corrected. So I ask where we are, to hear that we are ready, which we are not. Containing the mild steam coming out of my ears, I ask if they checked the list in which they could see things are fine from a system perspective and I get explanations ("I don't have access", "I did not know I have access").

Another day passes by and I realize there's a holiday season coming up, so I check again. They are not fine, but "they should be". I ask for a list of the computers, to learn there isn't one. And I spend a few days tracking the relationship of the IP (given by DHCP, changes over time) as the only info given, matching them to image names and actual statuses of getting things to work.

The assignment was made in intent. No clarifying questions were asked. Given solutions, instructions were being dismissed. Learning did not show up in the process with repeating patterns. And finally, there was no consideration for the handoff that was evident for the planned vacation.

This is the different between a trainee and a senior. Seniors see things and track things others don't.

Today I'm enjoying the results of this prep, finding some really cool bugs having guessed some places where it would be likely to break. Having these issues now and having them soon vanish, knowing that my mention of them here is all I have to show is deeply satisfying.

Wednesday, February 21, 2018

Conferences as a change tool

European Testing Conference 2018 is now behind us, except for the closing activities. And it was the best of three we’ve done so far. We closed the 2018 edition saying thank you and guiding people forward. Forward in this case was a call for action to look into TestBash Netherlands, which is in just two months in Utrecht. I will personally attend as a speaker, and having been to various TestBashes, I’m excited about the opportunity to share and learn with fellow test enthusiasts. 

This promotion of other conferences is yet another thing where we are different. We don’t promote the other conferences because they ask us to. We don’t promote them because they pay us to. We promote them because we’ve learned something before we started organizing our own conference: we all do better when we all do better. 

In TestBash New York, Helena Jeret-Mae delivered a brilliant talk about career growth, with one powerful and sticky message: in her career, while she stayed in the office and focused on excellence at work, nothing special happened. But when she went for conferences, met people and networked, things started happening. She summed it up as “Nothing happens when nothing happens”. There’s side effects to growing yourself in conferences, learning and networking, that create a network impact of making a change relevant in advancing your personal career. This resonated. 

At European Testing Conference 2018, there was a group of people in different roles in a company. There was the manager, and there was the person the manager would manage. Telling the person to do something differently had not resulted in a change. Sending the person to a place where people enthusiastically talked about doing the thing differently made the person come to manager with a great idea: there’s this thing I’m not doing now, I want to do more of it. Ownership shifted. A change started. The threshold of thinking “all cool kids are doing this” was exceeded. Power of the crowds made a difference. 

While we would love to see you at European Testing Conference 2019, the software industry is growing at a pace where we are realistically seeing that the need of awesome testing and programming education (tech excellence) is needed. We need to grow as professional ourselves, but also make sure our colleagues get to grow. We all do better when we all do better. We suggest you find a local meetup, learn and network. Go to any conferences, go to great conferences. Go and be inspired. The talks can give you nudges with ideas, the skills you acquire by practice. Sample over time, always look for new ideas. 

The short list of conferences I pay attention to mentioning are ones I recognize for being inclusive and welcoming, and treating the speakers right (paying their expenses and including new voices amongst seasoned ones). I want to share my love and appreciation for TestBashes (all of them, they are all around), Agile Testing Days (in USA and Germany), CAST (USA, since latest editions)  and Nordic Testing Days. The last one is a fairly recent addition to my list now that they’ve grown into a solid success that can treat the speakers right. 

I enjoy most of the conferences I’ve been to, and would recommend you to go to any of them. I have a list of my speaking engagements in and the places I’ve experienced is growing. 

What’s the conference you will be at this year? Make sure there is one. Nothing happens when nothing happens. Make things happen for you. 

Introducing intentional vs. accidental bugs

There was an observation I made on the psychology of how people function in a previous job that has kept my mind occupied over time.

When I joined, our software was infested with bugs, but the users of the product were generally satisfied and happy. It appeared as if the existence of bugs wasn’t an issue externally. It was an issue internally - we could not make any sense of schedules for new features, because the developers got continuously interrupted with firefighting for a bug fix. 

Over time working together, we changed the narrative. The number of bugs went down. The developers could focus better on new features. But the customer experience with our product suffered. They were not as happy with us as they had been. And this was puzzling. 

Looking into the dynamic, we grew to understand that for the product, there was a product and a service component. And while the product was great, the service was awesome. And there was less of the service when there was no “natural” flow of customer contacts. If a customer called in to report a problem and we delivered a fix in 30 minutes, they were just happy. Much happier than without the need they had for our service. 

This past experience came about as we were organizing European Testing Conference 2018. Simon Peter Schrijver (@simonsaysnomore) was awesome as a local contact, focusing on a good experience for the venue in making things clear and planned in advance. As a result, things flowed more smoothly than ever before. There were “changes” as we went on setting up sessions on when we’re reorganize rooms, and those changes required the conference venue to accommodate some unscheduled work. While we felt we can do this ourselves, this venue had a superb standard of service (highly recommending the Amsterdam Arena conference center) and would not leave us without their support. 

Interestingly, some of us organizers felt less needed and necessary when there was less of firefighting, bringing back the memories of the service component from the past. Would there be a way of knowing if people were happier with our past years quick problems resolution (we were on it, so promptly) or this years feel of everything just flowing? Whose perception of quality mattered? Interestingly, in retrospect we identified one problem that we had both earlier years and this year. Earlier years we fixed it on the fly. This year we did not fix it, even we should have had equal (if not better) financial resources to act on it. I personally experienced the problem with the microphones, and failed to realize that I had the power to fix it. I can speculate on the feeling of “executing a plan” vs. “emergent excellence”, but I can’t know the real causes to the effects. 

This brings me to the interesting question of introducing intentional vs. accidental bugs. If the problems while they exist make things better as long as we can react on them quickly, would moving from accidental to intentional be a good move? Here the idea of opportunity cost comes to play: are there any other, less risky ways to focus on the pull of service, than creating the need of the service with bugs? 

With the software product, we needed to invest more in sales and customer contacts to compensate for the natural pull of the bugs for the customer to be in contact and nurture our mutual relationship. Meeting people on content can happen ore in a conference with less issues to resolve. Did we take full advantage of the new opportunity? Not this time. But we can learn for future. 

Friday, February 16, 2018

Things the Frog Did Not Notice Before It Was Late

Looking at my quarter of a decade in the software testing industry, I can look back at what I am now and what I've been earlier, to realize I've gone through some major learning experiences. Having gone through those learnings, they all now seem evident and obvious. But I've made myself a favor over the years, clarifying my stances in writing, allowing myself to see how my views change. At first I worried about sharing anything I thought was true because none of it might be, but writing more helped me deal with the concern and just embrace the positive. 

Many of the foundational changes are things I did not see coming before, they sunk in slowly over longer periods of time. They are foundational in hindsight, and could easily be things I thought I always knew. Here's four that I think are ones that caused my whole belief system to pivot to find new possibilities. 

1. Test Cases aren't What Good Testing is About

Early in my career, I taught testing at university. The course had 120 students a year while it was part of a major, and I reached a substantial amount of local young minds. Part of the course was four-phase hands-on lab where the students would write a test plan, test cases, execute test cases and report their testing as well as automate a subset of their tests. 

A few years passed, and some of my students taught me my first foundational lesson. We met in a real world testing project, where I guided them into exploratory testing and cautioned against premature documentation of test cases at times when we know the least, and opportunity cost of the documentation work in relation to time we could spend actually testing the products. My students reminded me of my teachings early on with words I've come to cherish: "Great to hear you're doing this in a smart way, not the way you taught us it must be done at the university course". 

I used to believe test cases were what good testing is about. But good testing is about finding relevant information with a limited budget, with consideration of best for today and for the future. Test cases have little to do with best for either time. 

2. Continuous Integration and Delivery Wins Over Change Management

I grew up with testing in mostly waterfall projects. By the time we were testing, many moons had passed without us seeing the software, hearing only rumors through requirements documents. We tested in phases, with a huge scope and a fixed schedule. And when it finally reached us, we needed to be careful with change management. Every fix would take us back to testing again, and we only wanted fixes that were absolutely mandatory. And we did not want them to come to us whenever they were available, after all we were approving a build, not making sure that the end system was the best possible for the users by enabling change. Because change was a risk, that usually realized as something even worse.

I remember the person who first tried to talk me into the idea that continuous integration was a good thing, and how fiercely I resisted. Later, living through continuous integration and delivery, I can't imagine wanting to control change in the way we used to. Small changes with small impacts, and lots of them over time makes life much simpler. 

3. Test Managers Can Make Testing Worse

With a some years into testing, someone decided I could lead testing efforts and made me a test manager. I created strategies and plans, discussed with the testers I was working with on how we'd follow through those plans and coached people into being better testers. I sat through meetings, building a great holistic picture of what was expected of us. And I tested some, usually something less time critical because my attention could be taken elsewhere. Then agile hit us. External managers trying to manage small self-organized teams did not make so much sense anymore.

I stepped down from my "career path" and became a tester again. The testers I used to manage became better because they did not leave "my work" for me to do, but found better ways of doing it all. They became better testers when part of their work wasn't expected from "manager". When I knew things others didn't, I could contribute just as much if not more as a colleague. 

4. Test Automation is a Core Part of Testing

I've spent years honing the thinking part of testing. I've learned to work with software and hear what it tells me, combining all sorts of information while using the software to test as my external imagination. The thinking part and the manual execution part supported each other, and automation in testing was something that helped me reach things I wouldn't be able to do manually. But a lot of the automation was throwaway code. I had colleagues with a different focus in testing, creating test automation scripts that could run reliably over time, detecting unwanted changes. And I thought of those as separate things - the artifact creation and the performance.

Then I learned to do the part I used to look at others doing, and it changed the way I looked at it. It made me realize my previous company would have been better off investing three years into me if they got both the great exploratory testing results and a piece of automation that documents, in an executable format, some of my lessons that the team could use to hold their stuff together. 

I realized the only reason for me to hire someone who does not do both exploratory testing and test automation and intertwine them is that people have not yet learned the other. And we have lots of test automation specialists who are bad at testing, we even have lots of test automation specialists who are bad at coding. But they leave behind, in long term, something that could help when they are not around. Those who don't automate make their impact in the quality as we see it NOW.

There's the story of a frog not noticing when it is boiling, moving to a different purpose as food. The frog story might be a fable without a foundation in empiricism, but as fable it describes the feeling of how things change. Many of the things that changed my views are like that. I did not notice them while I was in middle of the process. But where I started and where I ended up are very different states. 

Saturday, February 10, 2018

Test Automation Legacy Code

10 years ago I left an organization, that was top-notch in exploratory testing but had no test automation. With exploratory testing alone, I helped introduce the foundation for what would become more aimed for continuous delivery, introducing continuously delivering (with a lot of manual steps) to a beta program. The technology preview concepts and ideas still are easily recognizable, a decade later, without memories of history: it's just a way things are and have been.

While I was away, test automation got a foothold. Looking at it in hindsight, I'm happy I wasn't there to mess it up: great testers favoring the thinking part of testing and speaking up a lot about it are one of the most relevant blockers useful automation has, stopping automation being born while it's still learning its place and form. Lesson learned: give room for things to grow you don't believe in, and they may grow into things you do believe in.

Now that I'm back, and I look at the test automation generated and feel joy on the accomplishment of introducing that there. I did not do it. Or maybe I did, by stepping away and leaving the battle of opinions unbalanced, for the automation side to win. But it is there, it is doing real testing and while it has many many problems, it is a cornerstone of the way we build and release products.

In the 10 years, I've changed. I've come to remember that I was 12 when I wrote my first program. I've come to appreciate internal code quality, and recognize when its lacking. I've stopped looking at testing testers do, and started to look at programming productivity to produce the right quality.  I've trained with Llewellyn Falco, a legacy code expert, and re-learned programming legacy code first, test-driven development second and always driven by hands-on work over reading about it.

This week brought me new appreciation in the role of legacy code in what I do now for our test automation system. I'm helping us clean up the mess, without removing the value so that we can add more value. I draw from lessons on legacy code, lessons on (test) product ownership, and intertwine those so that the automation we have would better serve a product line.

I look at this as lifecycle. There's someone to select (or create) the framework. There's someone to use that framework, adding tests to the best abilities they have, doing real useful work. And still, there's the time when the code running the test automation is legacy, still living and breathing, and needing attention to not block us from our future enhancement aspirations.

We're inclined towards a rewrite, while refactor is a better option. When the existing structure emerges from the mess of duplicated details, changing pieces becomes timely. Mending the systems, not making them.

Friday, February 9, 2018

The War of Ownership

Agency. It's the fancy new word introduced to coin an insight in a war I don't want to be fighting. The idea that it's referred to as war is the first hint that what this says has little to do with the collaborative non-violent software development we aspire to.

This is a war to say that in the kinder, collaborative way, testers don't feel safe to believe their existence is founded. They're struggling for their life as they know it. I don't feel like I want to join that war, I want the war to stop. And the way to stop war isn't my specialty, but I suspect it has something to do with finding options and making working agreements. And when the party in war isn't willing to make any agreements, the stronger wins. Newsflash: tester profession isn't winning in this war. It is taking steps further into alienating itself from the tables where decisions of future of software are made.

I'm selecting a few points on twitter to emphasize my takes, words by Michael Bolton.
"Testing doesn't make your code better. Testing doesn't make your code testable either. YOU make your code better, and YOU make it more testable, and those are fine things.
Testing isn't an abstract thing that happens. There's someone who does it. And there's two clear choices of who that someone might be in the jobs we have in the industry. It could be a tester. It could be a programmer.

The programmer is YOU in the clipping above. The programmer makes the code better., the programmer makes it more testable. And the programmer tests. The programmer makes makes the code better. And in my experience, programmers who don't test rarely create good software.

There's the other option of why it might be. The tester. It is in the tester's interest to create a clear line and separation. But the trend is to remove that clear line. Many organizations report great results blurring the lines. They aren't making everyone the same, but they are stopping man-made absolutes of lines between who does and what. They are saying everyone does what their skills allow them. Everyone learns. And that everyone learns also about testing and ways to build software that makes users awesome.
"...make explicit a central theme of our Rapid Software Testing classes and consulting work: agency. We want to help empower people; shine light on what they do; help to liberate them."
What I read in this statement is that people = testers. Testers that fit the Rapid Software Testing methodology requirements. I've been told in the past I'm not a tester (as per the RST terms at least). Yet, that is exactly the position I hold, and have been holding, hands on working with products for the last 25 years.

Empowering people by creating a clear distinction on roles that are job functions and don't need as much clear distinction in the world of collaboration would include allowing them to see world their way, and mediating. But that is not the world RST seems to serve. It serves the world that I don't see as a practitioner in the companies I work with.

I recognize I'm selective. I choose product companies. I choose agile methodologies. I choose ones that believe in empowering and listening to all their experts.
"I don't think there's enough salt"
I can notice lack of salt, and add it. I don't remove myself as an actor when the salt needs adding if (and when) I know what is the appropriate amount. I don't need to remove myself as an actor on fixing as someone hired as a tester.

When we talk of the concerns about limited time and choices that we make on splitting to roles to ensure different concerns get covered, we are using concepts from time before continuous delivery. The world has changed. Quoting Necromancer from memory: "The future is already here. It's just not evenly distributed.". We don't need and can't have one true way anymore.

Software development is a process of transforming ideas into code. Which of the ideas are labeled what isn't as relevant as we think they are for reasons other than having the profession we love. What could be the ways to add meaning to this conversation that is stuck on violence and war? Isn't there a more constructive way to build a profession that draw the lines around testing for the purpose of understanding the tester?

Note added later: I did not need to read JBs article to pick up words from the title. This is not a response to his article. This is a response to the tone MB runs on twitter. 

Thursday, February 8, 2018

It's just semantics

I work with product development, building and testing a product. The product is a Software-as-a-Service type product extending beyond the idea of renting an app from the cloud. Some parts of the product change as much as 20 times a day introducing new functionality to provide the service the product provides. When I test, I don't test only the software components, but the whole customer journey and experience dealing with our product. And with some millions of customers, long-term commitment with them, striving for better for them is a fun area to work with. There's no projects. There's the product that lives on. 

So I wrote a piece of my mind talking about test automation as a product. It too has users, long-term commitment with them and is intertwined in appropriate ways with the way we develop. And an ex-colleague decides to comment on twitter:

My first reaction is to to say "it's just semantics" - "wordplay". Semantics is meaning of words, and surely meaning of words matter? In this case, I don't care of the difference between "product" and "ecosystem". I don't care for the focus in a single word, when I've just used many to explain a lot more than just that word. 

To say "it's just semantics" is to say that in this conversation, I'm done. The way you approach the discussion with me just turned sour, and I'm  not committed in continuing. You're derailing me. 

I read a wonderful book called Crucial Conversations, that talks about these types of dynamics in conversations that matter. And conversations around the nature of testing matter a lot to us testers. The book introduces the ideas of two ways of closing the flow of meaning to a pool: violence and silence. Correcting words is a form of violence. My default reaction is silence, keeping the violence option of "it's just semantics" hidden in the back of my mind. 

As we would want to add meaning to the pool when discussing, closing communication isn't a good thing. We can choose to stop and ponder on our reactions, and work back towards a place of trust. We can learn more, add more meaning to the pool, if we just keep at it.

I know Valera as an ex-colleague I have utmost respect for, and explaining myself other possible meanings of his corrective statement isn't hard. He means well, just playing on my triggers. I've needed the same reminder for myself on good intentions a lot with men who explain things to me, without me knowing them or them knowing me.