Future of testing
Hello there, long time no see :)
Nothing better to end the year than to write a blog entry about “the future of testing”, but to understand the future we must look at the past. How has this testing area started? Let’s see the past evolutions to try to identify how the future of the area may look like.
Past
Quality was always a necessity, even when we looked into how it was baked into the assembly lines in factories way back in the past, manually validating the product at the end of the assembly line to make sure it had the expected standards. People were doing manual validations of a series of parameters that were expected to be found in each product hoping for the seal of approval. In the past, quality was owned by testers and they were the soul keeper of quality.
Although quality was important, the tester work was always viewed as less important than, for example, the assemblers/builders in the chain. The idea was that anyone can test but building will require skills, so the ones that could not be built will be redirected to testing, starting this trend of seeing testing as a lesser job.
As we wanted to have quality software delivery also, we brought those practices into our world, unfortunately we were too literal and ended up having a separate team waiting for the finalized product (release) to perform validations. So development teams handed over the release to the testers team to be tested, hoping to have the quality approval.
We were the gatekeepers of quality, lonely quality fighters that would approve or not a release, sole keepers of quality that were blamed if some errors/issues reach production. We were not involved since the beginning but the expectations were that we need to understand it all. In these dark ages we were fighting alone, seen as the ones that were always blocking a release.
Thankfully the development process and the testing process have evolved, the market recognizes and demands that quality must be owned by everyone and in all steps of the process.
Present
The development and testing processes have changed to align with new necessities of fast releases and feedback. Teams felt the necessity to change things in order to have more frequent releases (demanded by more exigent clients) but with a high level of quality.
Team composition and responsibilities changed, we started to have mixed teams, with different roles that complement each other with the goal to make those teams independent. More independence means that we will spend less time waiting for other teams as we are only dependent on ourselves (or at least we hoped).
This gave birth to the automation rush, not only of testing but of everything, all of the sudden everyone that did not know automation was looked at as someone that would not contribute as much. Automation was seen as the silver bullet to solve all the testing issues that we may have in our process, everything will be faster, better if you automate tests.
Although I’m a big defender of automation, this view that test automation will solve all our problems has done more harm than good. We suddenly were focusing on solving automation issues and forgetting all the other improvements we need to do to even consider jumping into automation. The testing area started to see a division between the ones that know how to code and the others. Pressure on learning how to code was high because it seemed that if you did master this new indispensable art of coding tests you were doomed in the testing area.
Roles in testing started to be redefined and new roles started to appear, for example when SDET came along I was really happy to finally have a role definition that recognizes the technical ability of testers… but I was wrong, instead it was seen as the guys that code tests only :(
Testing was defined by automation only and we lost the focus of what testing was. Fortunately hard lessons come from this assumption and we shifted towards changing the mentality of what a team is and should do.
Quality is now a responsibility of everyone and the team members are helping and learning from each other.
We all know that we cannot automate everything, accessibility is hard to automate, exploratory testing cannot be automated, so we will continue to have space for assisted testing. What do I mean by assisted testing? I think that testers will benefit from new tools and ways of doing things and use those to enhance the way we test our products/systems assisted by those tools loaded with AI/ML, making the most of it.
New ways of delivering software appear: DevOps, DevQAOps or DevSecOps, that should address all the challenges of having frequent releases with high quality.
Future
We are on the verge of a new change with the appearance of Machine Learning and Artificial Intelligence, these new areas appear with the necessity to process all the data the systems are producing and extract valuable data to continue to enhance the systems in ways that will benefit the end user.
Every tool/product is trying to ride the AI/ML wave and advertise some kind of AI/ML implementation, most of them with very poor usages. We start to see some tools that use AI/ML to choose tests or to analyze test executions but every usage we see appearing is still far from the capabilities of AI/ML. I think we are still early in the stages of taking advantage of AI/ML for testing, so stay tuned as things move fast in our field.
More than ever testers should focus on the things that testers do best, questioning, bringing that critical thinking to the table and the know-how acquired from their experience. Testers will be in the first line regarding AI/ML products because guess what? They will need to be tested :)
While being part of those teams that are shaping what AI/ML tools will do, we have the chance to influence the output, and since we may be the ones training them and using them most, we will secure our place in the AI/ML world.
We will need to have an understanding of AI/ML, much like we need to have some technical knowledge to be able to take advantage of that knowledge in our testing. These tools are becoming advanced, in fact if they are built right, their usage should be transparent to the user, to the point where they are easier to use.
Artificial Intelligence will need to be regulated and this need will, for sure, generate a great demand of people with a testing mindset. If we reach a time when all products will have AI/ML embedded, testing software will shift towards validating AI/ML software, making sure bad things don’t happen.
I’m a believer that AI/ML will change the way we produce and test software, but as testers will be part of this change we will be very well positioned to use AI/ML based systems and leverage them to accelerate their testing.
Conclusion
The world of testing and overall software development is changing, new practices, new technologies, and we need to be able to cope with each of those changes and adapt the way we do things to these new realities.
Will that mean that we all need to become automators? Or AI/ML experts? I do not think so, it definitely helps to have a basic understanding of how things work but a full fledged developer in tests or python developer is definitely not the way to go.
The way things are evolving I see tools and frameworks become easier to use and the focus is on the mentality and on the capacity to have an understanding on how everything interacts.
For me, testers are in a unique position to continue to be valuable in the future, they will be the ones that, assisted by AI/ML tools, will help bring quality into complex systems.
See you in my next article ;)