Changing profile of testers

🙋 Questions
,
1

I am curious on how you all frame the job role of a ‘tester’ these days?

I used to have a principal test engineer role where I could see a lot of different projects in a single larger company, hands-on. That gave me a few ideas about myself:

  • Hands-on is where change is made: doing, modeling, coaching is what is needed more from someone supposedly senior
  • Sampling a bit everything is great: got to do functional testing of web, windows, embedded, IT systems (platform+data+integrations), AI on video, but also performance, security, usability, value, accessibility, reliability, compliance, interoperability across various browsers and OSs and hardware, and change architectures so that testing would be possible.

Now I have been in consulting for 9 months and variety of organizations I face is larger. But at the same time, I think I am seeing a change in what is expected.

They used to ask separately someone to do analyst, someone to do automator and someone to do lead work in testing. Now they ask all in one. Amount of programming languages is also quite significant.

And they ask the full dimension of what I sampled over the previous job on types of testing.

What shapes of responsibilities have you managed to carve out, and is there something you expect that must stay so that you consider that role still ‘tester’?

4 Likes
2

I think however you package up QA or Tester roles, it comes with a huge heap of “it depends”.
I’ve worked in software now for 30 years and there are a few things I’ve learned about people in roles:
I’ve never met or worked with a “tester” who was a brilliant analyst AND automator AND performance tester AND Manager AND developer etc. People have strengths, weaknesses, skills they want to develop, skills they don’t.

So to this day, everyone in the teams I’ve managed or contributed to has been a “specialist” that needed other “specialists” to work with. From my experience, automators love working with analysts. They’re all over “WHAT” should be tested, the automators are all over “HOW”. I don’t think there is anything wrong with that, but it doesn’t stop companies looking for a silver bullet solution.

So currently, my team is split between “Tech Test Specialists” (HOW) and “UX Test Specialists” (WHAT). From all the teams I’ve managed, this has been the most productive, collaborative and self improving set-up I’ve had. My role is simply to help them all grow.

7 Likes
3

Nowadays companies expect testers to have multiple skills, and the role of testers within the organization has expanded significantly. In service-based companies, different clients demand various tools and frameworks, making the tester’s responsibilities even broader, especially when working on multiple projects. The traditional separation of roles analyst, automator, and lead is fading, with testers now expected to handle everything.

Even with automation and AI tools that claim to cover E2E testing, I believe exploratory testing should remain essential. Real testing happens when testers engage with the application visualizing user flows, entering inputs, tapping through interfaces, and observing behaviors. This approach brings creativity into testing, something tools alone cannot achieve. Without it, testing will be completely technical managed by some scripts or ai tools.

2 Likes
4

Love this.

I’ve been a big fan of job crafting - making any job you have the job you want. Supporting that, and the options sounds just perfect.

3 Likes
5

Yes, @maaret
Nowadays, companies expect one person to have multiple skills to handle all aspects of testing activities.
In my opinion, relying on a single person is not ideal for delivering a bug-free application.

Happy testing :rocket:
Ramanan

1 Like
6

Organisation profile in my view also has a big impact.

Way back I was in main stream financials, tester team based with a bit of a bias towards scripted testing that’s moved strongly toward automation roles.

Smaller companies attempted this but could not get the same value, many now have developers taking on more automation and solo testers combining that exploratory element alongside various other specialisations. Perhaps rough ratio’s of dev to testers could be an indication of company profile and in turn tester profile.

I’ve been in the latter for a decade but interestingly even with a few testers our skillsets and specialisations are different.

All exploratory specialists, all technical to a decent level, all capable of automation, I’d put those three as core skills these days but then between four of us also have security, performance, accessibility, framework architecture and even a level of systems support etc covered.

Then on top of that the bigger picture of quality planning, team coaching and training.

I’m both an advocate of solo embedded tester but also a team model support to make sure that solo tester has a call a friend option to cover the broad range of testing skills required.

I remain wary of the total drift towards all testers being coding experts, its in demand but the more it drifts the higher chance of those involved not being aware of what they are missing out on from the other skills. Elements of “good enough” may also be a factor.

Ai is also being used but again the testing model is likely a big factor, if your testing leans to machine strengths it will likely be used for that, if the model leans to human strengths then its more likely to be another great tool in your box.

In hiring, the core is almost mandatory plus at least one specialisation maybe more. I suspect really hard for those new to the field these days.

2 Likes
7

We’re doing some research of job titles and there’s definitely been a shift toward ‘quality engineers’ that take a more shift left / continuous quality / holistic / coaching / generalist type focus.

I’ve felt for a while that recruiters want automation skills, but the reality it that people need to support in many non-automation ways, maybe we over emphasize the need for automation/coding. I’m not saying it’s not important, but perhaps giving more space to learn on the job, relevant to the task at hand would be a more practical way to focus on getting what needs to get done, done.

PS. Help us with job title research by updating your MoT Profile with your job title. :pray:

2 Likes
8

I’m not sure that I completely understand the question but I’ll try :sweat_smile:

You can define any role/title in any way you like but it doesn’t mean that your definition and the list of skills will fit in one role in QA/testing that a company has. There is a list of requirements (that might be unique for each company). Yes, lately it’s like all in one (strong programming/automation skills in several programming languages (like Go/Python/C++ and at the same time JS/TS), security/penetration testing, performance testing, leading and managerial experience, and willingness to perform up to 90% of manual testing “when needed” and of course strong DevOps, CI/CD pipelines skills. The problem is that some companies have unrealistic requirements and expectations and use inappropriate titles because they want and can.

So my point is that my experience in my companies is highly likely to be irrelevant to your organization. Use your context and existing in your company/team QA/testing roles and tasks, etc. Of course, in some short period, the structure and requirements may be changed in your company and you’ll need to start over :slight_smile: so I don’t even see the point spending time on it :slight_smile:

2 Likes
9

When I look at my MoT Profile, it says “Director, Consulting” - which is my title. Did I miss where I should put this? Or maybe this was encouragement for everyone, which would be a good idea all in all.

Titles feel to me like they are less relevant nowadays. Around me in Finland, I see about 150 people with test titles; the amount of people whose job is primarily testing is multiple to this. Product owners are most often test managers. Developers are doubling as test automators. Test automator seems to mean “Robot Framework programmer” here.

10

Love the phrasing of vision here:

solo embedded tester with a call a friend option

I have teams with that vision. And then I have teams with a vision of having a testing team separately. I have been going between distributing and centralizing, and making that ‘call friend option’ real requires some fairly exceptional network / internal community building, in my experience at least.

I have friends I call but since 10 years ago when I went solo tester without friends in the company, my friends tend to be in community at large.

1 Like
11

I am clearly processing the question (so it is less direct than what I assume a question should be), and I realize I am working with visions that frame testing.

image
image1406×956 89.6 KB

The older “team of testers” is increasingly unlikely to come my way, even if I have customer organizations with those. Those are heavily shifting into formats where testers are remote in commoditized development centers, and a lead is left locally.

The call a friend option is difficult when there is hour-based invoicing structures and named people that a lot of orgs ask for, meaning majority of what I observe is solo embedded testers.

I am sure there are other visions too.

2 Likes