Trends for the Tester Role

YMWV – this is a model for reflection not to a 1:1 scale of everything in the universe. It might be useful.

The space for the testing professional is under pressure – for my own role and even more for the “traditional” testing professional. At least since 2017 there has been a shift and ongoing disruption. I finally have a form to visualize some of the trends that puts the role of the tester under pressure:

• SIT / UAT debate
• Low-code trend
• Modern Testing
• Quality Engineering and whole team approach

I still see two key areas (stars below) for the classic tester to move into: exploratory testing based on weak signals and supporting the end-users low-code activities (test tool smith). For the more managerial and coordinating role I will have to get back to you in a future blog post.

Here’s my (Wardley map inspired) model of the whole thing:

SIT / UAT Schism

We used to discuss strongly the schism between UAT and SIT – who did what and why. Sometimes the end-user in a small or medium sized business would do all the formal and informal testing of changes to ERP. Sometimes outsourcing companies would do all the testing (as a service) on behalf of the customer. I have been involved in both – it happens.

Usually, what would go in the SIT would be the repetitive and rule-based confirmations of features and functionality. While the UAT would focus on the more business visible and more intricate activities. In case there is UAT at all – but for large public and enterprise deliveries (B2B) there sure still is plenty UAT around.

Sometimes the business users, subject matter experts doesn’t take it lightly for someone to test on their behalf – and the tools are emerging that allows automation for other roles too.

Low-code trend

The low-code, no-code, RPA and the Citizen developer trend has provided the end user organisations with the tools to automate on their own (to a certain degree). Not only in test automation but in general – for instance with the automation tools of Microsoft Power Automate.

Even Alan Page of Unity / Modern Testing talks about the benefits of low-code for most web problems (as I have):

I talked about this briefly in Episode 135 of the AB Testing Podcast (https://t.co/GslXJVxOd0), but putting it in twitter for feedback.

There was a time in my career where record and playback test tools were nothing but crap over-emphasized by snake-oil sales people/

1/x

— b-alan-cé (@alanpage) March 27, 2021

Modern Testing, Quality Engineering and the Whole Team Approach

Another significant and persistent trend in the testing space is the Modern Testing principles. They are really hard to imagine for many testing professionals – yet the foothold for the principles are strong. (Is it then a best practise?)

Especially two of the MT principles challenges the status quo for the tester, and pushes the testing activity partly up towards more business visible activities and partly to the right as a team embedded/pervasive activity.

5. We believe that the customer is the only one capable to judge and evaluate the quality of our product

7. We expand testing abilities and knowhow across the team; understanding that this may reduce (or eliminate) the need for a dedicated testing specialist.

Modern Testing Principles 5 and 7

Lastly the topics and principles of Quality Engineering and the “whole team approach to quality” drives much of the less visible testing activities to be handled by the team as a whole. Developers and others involved on a technical level can test both exploratively for weak signals and unknown-unknowns in the stack – and automate all the boring and repetitive tasks and checks with explicit outcomes. This btw includes visual tests in the UI.

This independent of the system under test being a custom built web page or a commercial SaaS solution. It’s a better solution if more “lower” testing can be performed by the application specialist configuring a commercial standard application.

Spaces for the Tester role

Some testing based on weak signals can be handled by the team of system specialists. Some exploration of the unknown is best handled by the business representatives. Though, as the maps shows there could be a space (the star to on the left of the map) between these two – for the skilled exploratory tester with a technical mindset, who can use relevant test tools to pick the solution apart and explore for issues and findings.

IT systems exists for both rail tunnels and containerships – where it could be relevant to explore the solution before it gets into “actual use” on ships on the oceans and where you just can’t easily recover from a crashed cargo train in the tunnel. The system under test matters – as does the culture of the organisation.

Lastly, there could be a space for the testing tool smith on the very right of the map between the business visible low-code activities and the technology-facing automation practices. Depending on the low-code platform (Visual Tests are Still Code), the system under test and the testing we want to perform.

If the capabilities of the low-code test automation approach requires you to tinker and fiddle a lot, it could be a sign that either the tool is a bad fit or the system under test is not as stable utility as you would have liked. Example the old pitfall of management saying that the COTS solution is 80% standard, yet the implementation project ends up with 20% custom.

Lastly

It’s a general map, so it’s probably missing some trends and weak signals I have yet to spot. The map is not specific for a certain delivery team, but it seems to me that it would be valuable to map in detail using Team Topologies or Wardley maps with a team – to visualize the test strategy.

It’s a model to help my thinking about the patterns and trends in a changing world. I do not want to throw all testers under the bus – but observe and spot the trends. But I also know that by observing I affect the outcome ;).