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.
There are so many different IT projects out there – that assuming every IT project is about source code is quite a blind spot. Projects that deal with commercial standard systems or outsourced software might have source code underneath – but many teams does not have access to the source. Additionally, many legacy systems from the 90’es and older does not have the same automation capabilities as we have now.
Not all software projects are about consumer facing native apps and websites. While they are numerous there’s still plenty of systems out there for internal and business-to-business use. While the trends from CI/CD are picking up for B2B and internal systems, things doesn’t move so fast.
This post is my current take on using Robot Process Automation (RPA) tools for automation in testing. RPA tools comes in different shapes, some are better at some things than others. Similarly it has to do with the tool stack of the system under test.
First some definitions/terms.
RPA/RDAdefiniton: I use the original Horses for Sources definitions: “increase productivity, support human operators in completing tasks and activities” (RDA) and “increase process efficiency, reduce manual labor by automating transaction intensive activities” (RPA). In more practical terms RDA is across the desktop while RPA is more about background processing – a poor man integration between systems.
System under Test: There is more to a system under test than a web page with backends or an app for a smart phone. Explore the notion of System under Test. You might not have access to the source code – as the test pyramid assumes.
The enterprise challenge: Large businesses and organizations unfortunately struggle, as their IT stack is much more that web only. They want the benefits of continuous testing to their whole technology stack. Existing automation best practices doesn’t seem to address testing on top of IT systems that are older than SAFe, agile and Test-Driven Development.
Automation in Testing: See the AiT definition and namespace: “using automation to support their testing outside of automated checks“. Use tools and automation to handle all the tedious tasks of your active testing activity. Use automated checks to cover the binary requirement confirmations.
Hence, the sweet spot for using RPA tools is a as an execution muscle for mainframe solutions, commercial standard applications and legacy systems with inactive or unavailable codebases. The test management system is still key in providing an overview over all testing activities across CI/CD pipelines, RPA and tests based on human evaluation.
If your system under test is web only, you can follow the modern testing principles and build in Observability in (https://charity.wtf/) and a lot of the things in the code. Plenty of best practices around ci/cd for web systems. Obviously it depends on how well the knowledge about the system is codified – but you can work on that within your org/team too. It’s more tricky of the source code of your web SUT is not available to you and render new locators every time you deploy or refresh. … for that consider to move up the stack and use Cypress or Testim.
In my current and primary projects the testing is not done by software testing professionals – and it’s probably for the better too! It is in contexts like these:
A Microsoft Dynamics “D365O” implementation of health registration forms. Tested by public service clerks partly comparing to the previous solution, partly testing the new system platform.
Moving 700+ servers running 50+ applications from one data center to another while keeping everything from mainframe to SaaS integrations live. Tested by the application staff that have maintained the system since for ever (10+ years).
Implement at standard commercial off-the-shelf tool for 2000+ IT savvy users. To most users this tool is their primary work tracking system, so they get to test it too.
In contexts like these the act of testing done by subject matter experts of the field – infrastructure specialists, public service clerks, support staff, application developers and the like. These persons qualify as the “customer” in the Modern Testing Principle that “the customer is the only one capable to judge and evaluate the quality of our product“. They might have a testing /role/ during the project, but that is because of their high domain knowledge, but at the end of the project they continue with their “real business job” of using the system to produce stuff for the business.
It’s not their job to know ISTQB from “MT Principles” and “RST methodology“. That is up to me, as the manager of the testing. My role is more and more about the guidelines for the testing and the facilitation of the people doing the testing. My reach goes so far as to ask them to think about how the product fails and succeeds. But I cannot expect them to know checking from testing.
Long gone are the days of managing testers that put all their skill into the niches of the testing craft. There are less software testing professionals doing the testing in projects like the above. Part of it is, that the describing the whole system explicitly is simply to expensive in time and money. This makes the requirements inherently fuzzy and undefined. And part of it is that learning the skills simply takes to long. Some technical tests require skills of a certified VMware specialist, others having an eye for every unwritten tacit business rule.
Another angle is that the skills that the usual software testing specialist brings to the table is handled on a lower level. Testing is done by the organisation (like Microsoft) that builds the standard solutions and commercial off the self systems (SAP, D365O etc). Another is that the test techniques of the software testing field simply no longer applies. I mean how does boundary value analysis add value to enterprise data center transition executions, when the system under test it not even software?
The better tester is neither the software developer nor the software testing specialist. It’s the person who ponders:
How could this go wrong…
I wonder if…
For this to work, we need to do…
Come to think of it, everyone in the project does that! Some do it more explicitly, some do it more experimental. Everyone evaluates how their actions add value to the people that matter (at some time).
Complexity is a Matter of Perspective 
You must be logged in to post a comment.