This is going to sound pretty unusual for someone who has for a large part of his software development career had the world "Test" in his title, but I actually dislike the phrase ‘testing’ when it comes to the software development. It is certainly well-intentioned and used to be an accurate depiction of the role many traditional testers played in the development process. However, I think development methods have evolved and so too should the terminology we use to describe the process of quality assurance in the software development space.
The reason why I don’t like the idea of testing as a phrase or terminology is because it is very reactive. Testing is something you do to verify something works as intentioned. While it sounds about right to what most people do on a daily basis, the truth is that quality is best designed into the code rather than after it. Yes, there will always be an aspect of confirmation "testing" in the job, but it should form a smaller aspect of the role. In a more technical world, quality control should be proactive and something that we think about in the designs of what we write ad less after it.
Consider a typical construction site. When you design a building or house, you don’t only test when a structure is complete, but already when it’s still in its conceptual design phase, using structural simulation models to ensure the design and structure will work as intended. It's just too expensive to start building and realise later that the design actually won't work at the site. However, in the construction space this isn't called testing, but rather engineering and is more akin to what we should be doing on the software development space.
Software developers and quality engineers shouldn’t be waiting for pieces of code to be completed before testing, but should be getting involved in every aspect of design to ensure it will meet the necessary specifications, testability and be of the right quality. This is done before a line of code is ever written and the tests can already be formulated and scripted during development and actually be a major aspect of the development process. Essentially we are engineering quality into the software and not testing it.
The approach to software quality has definitely evolved, but should we really still be pedantic around terminology used for the whole process? Yes, largely because the phrase software testing still implies a non-technical or reactive process where testing is either done manually or automated post code in a formal test environment. Using the phrase ‘testing’ fosters this kind of mind-set and being someone who has spent many hours in interviews looking for the right people for a role – I find it often attracts the wrong type of person.
Rather we should be focusing on the word software quality engineering which not only sounds more appealing, but is actually more representative of how we should be testing and describes who we are looking for. "Testers" these days need to actually have a strong understanding of software development principles, be able to write code and identify ways of writing better code and building better automated solutions closer to the code. Engineering sounds a lot more like what we should be doing than "testing".
And while I’m not someone who gets particularly hung-up around titles or is unaware of the difficult implications that a company will need to phase to change a job title, I do think that even if it’s not a formal title change, but simply the way that we refer to the process, it will help to change our thinking. Stop referring to the process as testing, but rather look at quality as something you need to engineer and you start to foster the right mind-set in your team. Not just those responsible for the quality aspects, but the entire team because after all quality is the responsibility of the entire team.
So think twice the next time you are planning your project and looking to add the word testing into various phases of it and rather focus on better and proper design, testing closer to the code and rather integrate these engineering processes into your development phase of the cycle.
Comentarios