Why Quality Assurance Is Not Just Testing?

In my professional life I have often observed a misconception where quality assurance (QA) and testing are perceived as the same. In case if you’re looking for a QA specialist or you want to become one, you may want to understand what set of skills you’re looking for. Even though the procedures for QA were seeded long before humanity shifted its focus to digitalization, the term was defined only in the 21st century. It was added to the Oxford dictionary in 2002 and states, “The practice of managing the way goods are produced or services are provided to make sure they are kept at a high standard”. This is what QAs have done before and have pledged to continue to do in the future. The goal has not changed but the ways to get there have multiplied significantly. How to navigate through them?

There is no equal sign between quality assurance and testing

Testing is only one part of the whole software QA process (in the image below). QA engineers can carry out necessary testing for the project, but a tester won’t be able to provide you with the necessary skills for the quality assurance of your project. At this point, some might ask, what is QA in software engineering if not testing?

QA does not just tell you if the product is being developed according to the specification but if proper processes are being enforced to reach the quality of development on multiple levels. For QA’s the scope of the daily task list is not only to find bugs but prevent them to enter the system, whether it would be the keeping an eye on proper code management or communication channels, because “quality assurance is concerned with the proper execution of the entire process”. QA engineer will always keep an eye on the whole process end to end.

Besides testing, a daily task list may involve risk analysis, striving for innovations to improve the testing process, analyzing product features in the scope of the whole system, analyzing feature consistency, developing new testing procedures etc. For example, if testing is being done by a QA on a feature that updates your product’s aspects to privacy consent, a QA engineer would be inclined not only to ensure that the feature works, but also if it is in line with legal regulations of the region of business. A QA engineer has always his/her eye on a bigger picture not only on the execution steps in front of her/him.

As you can see from the image above, testing is the phase where quality control is being enforced. It is done by applying various testing techniques to validate software, detect and report bugs. After corrections in the software or documentation have been made, and after validation passes, testing reaches its final stage. So, if you already have very detailed documentation of your software’s development process (testing included), and all you need, is to verify that your product has been developed as it has been described in your documentation, then testing might be all you need. The success of this approach will mostly depend on the quality of your documentation.

Origination of misconception through Waterfall

So, why there continue to be a misapprehension of testing and QA? I believe it is because the first software development life cycle (SDLC) that incorporated testing into software development was the Waterfall model. It was first described in detail (even without coining the term “Waterfall”) in 1970 by Dr. Winston W. Royce. In the paper “Managing the Development of Large Software Systems” W.W. Royce defined six main phases (in the image below) of the software development process, where testing had its own phase because he wanted to separate the testing process from the coding. For this phase, W.W. Royce encouraged employing “specialists in software product assurance” who could do a better job in testing but only “with a good documentation”. When each mistake would be documented, the one who made the mistake should analyze it because “he is the only man who understands the program area”.

Even though W.W. Royce uses the term “specialists in software product assurance”, at that time (as it becomes clear from the original paper) what he actually meant were “testers”. As we already looked above, nowadays software testing is only a part of QA, and it is often forgotten that knowledge these specialists bring to the table is more than that.

Misconceptions for assessing execution capacity below management level

It is easy to forget that testing has grown into a full QA process because of the mindset Waterfall SDLC brought to software development with it. This mindset formed in  manufacturing about a century ago and was carried to the digital world. We don’t even need to make a scientific research to determine that, because management theories emerged in the setting of factory systems during the late industrial revolution (some call it the second industrial revolution) at the beginning of 20th century.

Those were times when there was a shortage of skillful workers due to limited access to knowledge. Education was mainly available to upper classes, who therefore leveraged management positions while workers under management level were viewed as uneducated and unskilled therefore should be guided, controlled, and educated in the factory setting to reach necessary production results. This setting is not true anymore in most parts of the world, but the mindset is still occasionally leering back at us.

For that we can thank scientific management, also known as Taylorism, after its creator, Winslow Frederic Taylor, whose principles were first published in 1911 and could be summarized in 4 points:

• Task execution should be based on a standardized (“scientifically studied”) process instead of just common sense or observation.
• Tasks should be assigned to workers based on their motivation and skills and then trained to advance those skills.
• The output of each worker should be monitored and analyzed to ensure the most efficient output is reached. If necessary, additional training and a set of instructions should be provided.
• There should be a clear line between management and workmen so that everyone could focus on the work of their level.

According to F.W. Taylor those who were assigned leading roles should focus on planning, management, and providing training, while those who were employed to execute manual tasks should focus on those. These principles lead to a hierarchical structure of organizations, centralization of training and compromising output over the outcome that resulted in rational organizational structure. Hate it or love it, this is how the organizational structures were viewed for a very long time and on some levels, it still is, especially when we talk about Waterfall, where each phase emphasizes a different set of specialists. This way of thinking is almost in our blood even when we try to transform our processes to an agile way of thinking.

A quality assurance engineer or a tester?

Because of the assumption that testing and QA is the same, I have observed that there are a lot of testers who (some knowingly, some – not) extend their job title to QA engineer even if they do not possess all the necessary skills to carry it. Business owners who, wanting to employ the former, end up with testers whose knowledge pool is less than they bargained for as a result they end up losing trust in QA processes even though they [unwillingly] have employed a specialist who originally even didn’t possess the knowledge advertised. At the same time, when businesses employ QA engineers and box them in the testing phase, they cut themselves off a broad spectrum of knowledge that QA engineers could bring to the table.

Present-day QA engineers often have at least a bachelor’s degree in one of the sub-disciplines of software engineering – computer science, software development, software design etc. In addition, they often have one or multiple certifications to support their additional knowledge of software testing, its procedures and software development processes involved. And even without a wide range of credentials to prove it, additional learning possibilities are countless – from academic settings to online classes. They are accumulating their own experience on multiple projects and inspiring themselves from the experience of experts in the field to guide your product development in the best direction.

When Robert C. Martin (some might refer to as “Uncle Bob”) went back to review Agile practices in the light of the 21st century and published a book “Clean Agile: Back to Basics” in 2019, he also talked about the role of QA engineers. In our day software development processes he encouraged moving QA specialists at the very beginning of the development to work alongside business analysts, “QA’s role is to write the unhappy paths. There are a lot more of them than there are of the former. QA folks are hired for their ability to figure out how to break the system. They are deeply technical people who can foresee all the strange and bizarre things that users are going to do to the system. They also know the minds of programmers how to probe all their lazy streaks. And, of course, the developers work with QA and business analysts to ensure that the tests make sense from a technical point of view.” This allows business analysts to stay focused on positive scenarios while QA specialists use their technical knowledge to prevent negative cases and edge cases from even coming to life, thus applying their preventive role rather than corrective.

This approach exceptionally pays off if you’re a business owner who has no knowledge of creating technical documentation, or you don’t have a team that represents a spectrum of technical people to arrive at faultless documentation (if even such exists) – business analysts, technical business analysts, technical architects, who translates your ideas into software requirement documentation, which again developers translates into fully functioning product.

Therefore, what you should choose, a tester or a QA engineer, depends on the depth of documentation needed, how thorough testing is needed, and how inevitable falling into the diffusion of responsibility is. Read our blog post to find some good tips on how to choose the experts that would be most suited for testing your product.

Honestly speaking, since Agile was brought into the software development world, there has been a lot of discussions about whether trusting in your documentation and process standardization isn’t too archaic, because a shift into the aeon of “trust-your-people-first” is inevitably coming.

This shift in thinking is no more regarding people as a source of labor but as personalities who steers to the common goal by their own free will via their creative cognitive abilities; acknowledging that they can acquire the necessary skill set very well on their own with incentive rather than a mandate. This also brings more pressure (in a positive way) on QA engineers, to be always up to date with all the necessary information in the industry to provide the best services of the trade, which never ends with just executing tests.