Wireless and Digital Services
Testers have struggled for years with the perception that their role is largely unskilled, marked by repetitive, dull, negative activities; a role that is the nemesis of the software engineer; a role that is a stepping stone to other careers. As the industry shifts towards continuous delivery and deployment, the very role of the tester comes into question. Where does it fit?
I’d like to explore what testing really is, why the perception of testers is often wrong, show the value that testers can provide to a project, and ask whether testers are relevant in a continuous delivery environment.
The traditional definition of testing
Testing has normally been defined as the process of validating and verifying (V&V) that a product (software and/or hardware) meets the business and technical requirements that guided its design and that it works as expected.
Testing in this context is typically performed during the latter stages of the project when there is something tangible to ‘test’. The product will be handed over to test, defects raised and passed back to development. This process repeats until the product is deemed to have sufficient quality, requirement compliance is met and the product is signed off.
The role of the tester in this V&V environment is to plan and perform this testing, and to provide a level of confidence in the quality of the product. The testing during this phase ranges from the functional to the non-functional, mostly running to a pre-designed set of tests in the form of a test plan and test cases. The primary purpose of these testing activities is to make sure the product meets all of the defined and agreed requirements.
Testing == Quality Assurance?
Quality is often seen as the responsibility of testers, with the term Quality Assurance (QA) used as a synonym for testing. Just take a look at job adverts for testers and you will see roles such as Test Engineer, QA Engineer, Test Analyst, Tester, QA consultant; all of these roles mean more or less the same thing. But is quality assurance something that testers should be doing? By testing the product, can testers really assure its quality?
Quality is subjective and there are many varying definitions of the term, but essentially, what constitutes quality to one person may not match that of another.
The question then becomes “who is responsible for quality?” It’s clear that testers can’t assure the quality of a product for all stakeholders. So the answer has to be everyone!
As soon as a development organisation, whether that be a team or the wider company, realises this fact then significant improvements in quality are often made.
William Edwards Deming (Out of the crisis 1982): “We cannot rely on mass inspection to improve quality, though there are times when 100 per cent inspection is necessary. As Harold S. Dodge said many years ago, ‘You cannot inspect quality into a product.’ The quality is there or it isn’t by the time it’s inspected”.
Replace ‘inspect’ with ‘test’ and you have a statement that defines a principle that all development teams should live by.
However, it’s not just as simple as ‘write better code’. A good quality product is often thought of as one that has very few bugs; one that passes all the tests. However, the developers could have written the best, most maintainable, testable and tested code in the world, but if the product they created is the wrong thing, then the quality of the product will not meet the expectations of the client as it will not fulfill their needs.
Many product quality issues stem from unclear, ambiguous or misinterpreted requirements which follow through into planning, design and ultimately into a built product. So in reality, everybody involved with a project has a responsibility for quality and the best place to have an impact on quality is at the requirements capturing, designing and analysis stage. Do the engineers or indeed the testers have any input into this part of the process? Often not, and I suspect this is either due to the perception of the capabilities of the testers, or more likely is that they are just not considered at this stage.
At Cambridge Consultants, we’ve recognised the importance of involving all disciplines from the very early stages of a project. The second part of this article will explore how this benefits our projects and how testers in particular can provide significant value throughout all stages of a project.