Growing trees, today

It was May 25th 2015 and I was angry, frustrated and felt disconnected from the software industry. I made frequent remarks on preferring to work at McDonald's. I remember, because emotional resonance outlasts the specific detail of any interaction, and the overwhelming interaction on that day at XP2015 conference was the death of testing as I knew it.

In hindsight, the feelings of that time were my personal driver to reposition myself in testing. I learned unit testing, particularly exploratory unit testing, shifted a lot of my test automation considerations down the stack and started working with developers rather than testers on quality.

Ten years later, I claim I made right choices for my career in testing. I found impacts I could not have made without the developer collaboration aspect. I learned things I was convinced I did not want to or need to learn, on the side of doing things in teams that I felt strongly about.

Testing is far too wide and versatile to be dying, and it may be that was not what people said. I heard that because the message was not one I was welcoming or expecting, and news even if true can cause us to reject them.

I learned to frame things differently. I learned that the future is already here, it is just not equally divided and that sources of inspirations for experiments that grow both me and the project I contribute in are plentiful. Themed microlearning on the job allowed me to change the frame in which I worked, and learn about the past fears that had prevented me from embracing the developer I had become in my teenage years.

I remembered that feeling and that day, because today I have been the person making others feel like I did on that day. I told people that industry has already changes so that:

• More architecture-aware approaches to testing are required. You may not know what your UI tech is, but you can start today, ask and learn what are the typical technology-specific risks to it.

• You get to manage your own work, not expect someone else to be the manager pointing you to your work. The siloed roles within testing are breaking down.

• You can't remain an expert of a single system, you are expected to be able to compare, contrast and reuse in domain, and across domains.

• You need to tell about the value of your work. No, being modest and not explaining the dynamics of value unique to testing just don't cut it.

• Programming in testing, particularly with AI in the picture, is here and you won't make it ten years to retirement avoiding it. You should find your touchpoint to it.

My message of today about the dead ends and steering away from those isn't late for people who did not hear it or find constructive ways of microlearning back when I did. Consultancies, in particular, tend to make their money from having people who are in demand, and not having people would be bad business.

Yet you should, probably, think about this with the famous idea of when would you plant a tree to grow it. Prefererably 10 years ago if you need the tree today. But the second best option is today.

30 minutes of reflection on how you can be better tomorrow on the work you do now, identifying the variables you can tweak and doing on the job microlearning on a theme you choose for a period of time can take you a lot further than expecting a full training day at some point.

I forgot who made me feel bad in 2015, I only remember the feeling. And I can wish the same to be true for the people who had to hear the harsh messages today, that the industry has been giving this heads up on what is needed for quite some time, and we need to work on that future that is more equally distributed, because the clients at large want to see their value, impact and productivity evolve to the potential (and beyond).

More work for the same salary

I prerecorded a talk for BrowserStack Breakpoint, and showed up for the chat while the talk was playing. I understand online conference organizers automating as much of the delivery timing as they can, but miss the actual live part. So I'm live. For possible discussions. And while I talked from prerecorded talk on how testing stops splitting in two (manual and automated separately) and even gets task expansion with AI, someone made a remark:

"More work for the same salary."

(edited: the actual quote should be "contribute more, get payed less")

My first instict response was to make a remark on the fact that I have not noticed that the personal experience I am speaking from on the stage would have resulted in more work for the same salary but I've rather had a steady increase in my salary. I then spend a day thinking about it, and to deemed it relevant enough for a longer discussion. (edited: my response: "I get paid more so I would not know)

I've worked in testing for 30 years, and one thing remains constant: the amount of work I do. While with my fuzzy boundaries of work and life I could never cut to a clear 7.5 hrs work day, that with my kind of interpretation of the boundaries has remained a constant. I don't work more in terms of hours, but the value those hours is different by both my abilities and my choices of what the work is.

I think of my abilities and knowledge as a platform that I have invested in. Today that platform in hiring conversations comes with remarks like "I've been asked to keynote 51 times" or "Most testers in Finland have learned from me" or "Hiring me you get 20+ agents that I know how to operate" or "Everyone says they learn well, but I learn in a way that gives me consistently the feedback of knowing more of my products in two weeks than people know after years".

When I discuss testing not splitting in two or task expansion with AI, I am suggesting you should care about building your platform. You should realize your career is too important to be left on the whims of your manager. Your current manager at your current job might find themselves in a place where they can let you use your platform but not raise your salary, but your options aren't just there.

The other part we need to address is the your salary is monthly. You are already, with your current level, getting more salary for more work. You may not be happy with the level your compensation monthly is, but your growth is also required for the future months of that very same salary.

Quoting Ginny Rometty, former CEO of IBM:

"AI will not replace humans, but those who use AI will replace those who don't."

My today's me replaced the past me. Your future you will replace the past you. And while I don't want to say AI must be a part of the future you, your take on AI will be. Specializing in what it can't do is not a bad specialization.

Remaining in the mindset of someone suggesting there could be different ways for you to do work being responded to with "more work for the same salary" makes you a victim of circumstances that the person speaking was trying to get you to avoid.

I hope for you all more work for salary. And I am really worried that in the group of testers, this may not be the case with current trends of how many testers are looking for their next opportunity.

Lessons Learned from AI for Testers Coaching

When I try to teach, I find myself learning a lot. Sometimes I feel like I learn more by teaching than what people I try to teach learn from me. Other times, the balance is fine. Today I taught a small group of tester where the balance was not fine, and I have been thinking about it since.

What I came to realize in hindsight is that the group of today, while small, was also particularly versatile in two relevant dimensions:

• Their client project had limitations to using AI that made testing with AI particularly challenging
• Their background as system expert meant that the ideas of where I wanted them to be on their AI in testing journey caught me by surprise.

The client project limitations lead me to identify that there are six essential dimensions in which we need to discuss our allowances of AI:

1. What AI features are allowed? After choosing a tool like Github Copilot, clients still block many features: models by origin or purpose, CLI-use (unsupervised commands with shell access), and MCPs to name the most popular ones. These may not completely stop you from agentic testing, but they require you to be architecture-aware.

2. What data can be in the system tested? If the system tested has production-like data too close to production, the data is probably something to be excluded. Should you give access to playwright CLI or MCP to look at the application, it sees the data. Eyes on the the UI may be blocked for data.

3. Can the system be seen by AI? While early access competition reasons keep features secret, some platforms have license agreements that explicitly forbid using AI other than the platform built-in. This agreement based blocking is becoming more widespread, it seems, with notable examples being Guidewire and Salesforce.

4. Where to keep credentials and PII data? Well, learning to keep secrets separate is about time, but the practice is different. In addition to not including these in repos and ensuring that with commit hooks, you can't keep your own local secrets where AI has access. Or you might have an acceptable risk policy with credential rotation.

5. Code, including test code as a secret? Not all code is secret. A lot of code is in fact public. And we have cases where test code is used to make AI reverse engineer and implement entire complete libraries.

6. Examples, requirements, and other documentation could be secret? Not all but some of it. Knowing what is and isn't can sometimes pose a challenge.

The other lesson today was on the journey. What I was teaching with Github Copilot and agents was too much of a step today. It was too much because I did not split it to smaller steps like I did because I was not thinking about it just before the session. But it was also a lot because the starting point of expecting visual studio code and playwright from a test case based manual tester is a lot. Sprinkle in random bits of version control without a previous sighting, and a VPN that blocks your tool access, overwhelm is guaranteed.

The picture I drew was to illustrate the idea that I tried placing people on the crossroads of the journey towards building validate steps for dark factories. And they had barely made it to realize what the uses of AI as external imagination or opportunities or limitations of generating artifacts would be. And they might just as well be better off on the route to better creation of artifacts.

Making teams awesome - or getting hurt trying it?

28 years a tester. Sure, I have held all kinds of fancy monikers on top of that,  but that is what I find myself to be at a core. I learned testers break illusions, not software. I learned that I could still hold the idea of being a tester when the illusions I break go beyond the product, to ways of working, to people, and even patience of people. I mean to say I test patience with a lighthearted smile, but it holds a piece of truth. Testers aren't always easy people. I have been many things, but easy is not one of those. Persistent. Reflective. Endlessly curious. For a long time, I believed the value I brought in as a tester was founded on two things: 

• serendipity: "The more I practice, the luckier I get."
• perseverance: "It's not that I'm so smart, I just stick with the problems longer."

I would get to travel the world to deliver talks with titles such as "Making teams awesome". I would observe roles of catalyst, conscience, cheerleader and critical thinker in my work with the teams. 

Today, I write this post wondering if the world changed, if I changed, or if the context changed. I received a fairly substantial piece of feedback that exemplifies something I did to help as something that breaks the team. We need to talk about failures, and we can't talk about failures of others. So I talk about my failures, in spirit of truly believing in blamelessness through seeing things in systemic context. 

I worked with a particular team, set up for a short period of time. My title: test automation engineer. The task: planning. The framing: agile with named roles. 

Reflecting on what happened, I went for a generated illustration. While my intent may be to help in making the team awesome, when that did not succeed within constraints available, I became a canary in the coal mine. Powerless to fix, destined to get hurt while being trapped on a purpose I could not escape. 

The experience of feedback that threatens professional integrity is still raw and recent, yet I appreciate the learning experience. I am not yet sure if my conclusion would be to 

1. Invest differently in preparation as I see canary mode activated
2. Walk away for greater good as I see canary mode activated
3. Learn to block canary mode even when it feels necessary for a greater cause

I will continue working on finding better ways of interacting in teams, as a tester. Or as me. The feedback would have been very different for same behavior in the team if they did not frame me as test automation engineer. Authenticity is confrontational to a world built on masks, but for this team, in this context, I really needed a mask. 

The fascinating lessons work has to offer are many fold. This was definitely the most strenuous job interview I have ever been at, let alone failed at. Failed together, for systemic reasons, but failed none the less. An experience richer. 

I'm sure I am not the only tester in the world that balances the feedback and actions that would lead to quality, enough to become nominated as the reason for lack of quality. 

Seeing systems in people's choices

LinkedIn as a platform annoyed me enough to break my let people be wrong on the internet -principle, on some smaller company leaders trash talking people on other companies payroll. Stories like this are popular fodder for a lot of toxicity: 

The leadership of a big consulting firm had gone to visit a major client to “sell” an AI transformation. The only problem was that the firm’s own consultants had spent the past year refusing to adopt AI tools, even though the client had been offering them training and tools 😂 A friend of mine at that company just said: “We already bought this a long time ago—go sell it to your own people so we can actually start using it.”

I felt like offering a perspective of experience: 

1. I have been on the receiving end of a client manager boastfully telling me this. Thanks, I can see the prep you did on delivering that line of insult. 
2. I have seen that the same client's organization expects a lot of uninvoiced work on planning future major changes. They consider it part of our sales work. I consider it some of our best people doing a lot of work from promise of future profits. 
3. I have seen that the same client's organization brings hourly rate down by competition, to a level where I cannot work a single hour without losing money for my company. And no, I am not that expensive. Their hourly rates are that poor. We have a blended rate so me losing money on every hour does not matter any more than the uninvoiced sales and management work. 
4. These are expected disproportionately from larger organizations. 

Coming to the conversation of offering them training and tools often misses the idea of making space to learn these things. Even when we pay for the training time, none of the other commitments that are paid are flexible. We are probably already on a tight delivery project. We are probably already accommodating growing understanding as scope does not creep that just creates more work. 

Expecting everything AND a change at the same time without making space for people just does not work. 

It might be "why can't you spend two weeks trying out Browserstack" or "why can't you just start using AI", usually from people who neither work regular hours (me!), nor on regular speed (again, me!), within contractually micromanaged responsibilities (sometimes me!). 

There is this Knoster change management model: 

❌ No vision → People don’t understand why → Wrong or chaotic change

❌ No motivation/incentives → People don’t care → Slow change

❌ No skills → People feel incapable → Anxiety

❌ No resources → People want to change but can’t → Frustration

I had a picture of that too, but someone has decided even linking images already uploaded online to my blog on this computer is unacceptable to protect the large numbers of clients I care for. 

I suspect more than one of these are missing, and the lack of empathy on the system you have contributed in creating and are maintaining on social media might be at play with your results. 

People have reasons, and ideology is a relevant one, too. 

Stop with the prompting, be clear on your intent

I sat at a table with a group of developers, somewhere in California a decade ago. We were all keenly watching a piece of java code we had just collegially written into a test to describe inputs and outputs to a function we were planning to implement for training purposes. The length of the conversation of the design we could see just from the method signature is something I remember. We could design all this before implementing any of it.

It took a while and a lot of opportunities to reflect for me to eventually get to the idea of unit testing and test-driven development. There is a lot of power in expressing your intent, and reviewing it before taking steps further. 

What made intentional programming really click for me was teaching kids in this style. If you could express yourself on what you want (what you really really want - could not resist) in your local language, translate to English and translate to code, it created a flow that made sense. So I spent some time teaching kids and women over forty, back when that felt like a cause I would dedicate time on. 

From intentional programming, I combined this with exploratory testing, and taught exploring with intent and shared notes on learning about navigating with intent - location - details hierarchy for ensemble testing. I learned to speak a little better with the intent I had with self-forced repetition of clearly needing some practice. 

Ensemble testing made me really great at exploratory testing. I got to learn from hundreds of people on how they actually do things, not just on how they say they would do things. I failed a lot, succeeded a lot, and learned even more. 

When I sat at that table in California, I had no idea that expressing intent would soon be called "prompting", and the whole world would be obsessed on finding a ways of clearly expressing intent in average language that, when enriched, would produce increments of code that fits to the expression of intent. 

We may call it "zero-shot prompting" when we don't give an example to illustrate our intent, and "one-shot prompting" when we give an example, but we should already remember how we people discuss things: an example would be helpful, right about here. 

Express your intent. If that is best done by saying "As an expert exploratory tester...", do so. Paying attention to your use and average use of language feels relevant now. Don't search for prompt engineering techniques, that is what we have been building into AI tools for last years - overriding your attempts of prompt engineering to give you things you did not know to ask for. We may call that context engineering but it still feels like a bigger prompt, just not one you can fully control. 

Express what you want with intent, and you may just get something in that neighborhood. And what you get may be good enough, or a good starting point. Sometimes getting recognizably bad things is just the external imagination you need to get your real intent out.  

Why would I even want to generate test cases with AI?

There is a conversation I keep having on use of AI, where people ask me about generating test cases with AI and I explain them that test cases was never the thing we wanted in the first place. Puzzled? You might not be yet aware of what exploratory testing really is if you are, and if you were, you would be better equipped for the AI transformation in testing we are currently in. 

Testing is not about executing test cases. It is about finding information - some of what others may not know that is of relevance. Test cases are not ideas of what to test, but ideas turned into step by step instructions. 

Let's not confuse automated test cases to test cases through. Automated test cases are captured programmatic steps that enable repeating the steps as executable documentation. Unlike test cases, automated test cases are not just repeating the same steps, but also a foundation for extending with new data, mixing step orders and thus discovering ways of not stepping instructions to miss bugs. And their design shifts testing down to a faster cycle of feedback. 

We need testing to find information, but we don't need test cases. This is what we see with AI. Ask for bugs, and you get bugs. Why would you ask test cases when you wanted to know what information at least could use addressing? Ask for bugs many different ways, and all the layers might give a good level of testing done. 

When we need documentation for future, we capture that as output. And we treat automation as a first class citizen as creating that asset for documentation the texts are generated from - not the other way around. 

When I joined CGI Finland as Director of AI-Assisted Application Testing nearly two years ago, I had a hunch that the transformation expected included reframing testing, and supporting it with new kinds of approaches. Turns out that some of the better outcomes are founded on ideas of contemporary exploratory testing. When packaged, we call it Test Intelligence Mesh. Fancy names aside, this is new rules on how testing is done, AI assisted, with packaged skills of great exploratory testing. One experiment at a time, collecting and sharing our toolbox that we can leave behind and scale. 

I don't generate test cases, I generate valuable results of testing. And I would be a fool doing that without AI-support that helps me scale.