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.