What Is The Value Brought By Quality Assurance To Your Software Product?

So you have a dream team of developers to work on your new software project. You have UI/UX experts, a professional project manager, and proven best practices of offshore software development. You fully realize the value they bring to your project. But there is one more essential activity—Quality Assurance—its value is less than obvious and more than crucial at the same time.

To understand the importance of QA and the value it brings to a software product, let’s start with defining the goal of testing and busting some myths about it.

Some people believe that the goal of testing is to find each and every bug in software. But that’s just impossible. Modern software is so complex, it often consists of lots of 3d-party frameworks, plugins, APIs that are used as they are. Moreover, the work of software is also influenced by environment (such as hardware, OS, browser). It would take eternity to test all combinations of inputs.

Another popular definition is “to create a high-quality product.” But if you look at QA engineers work, you’ll understand that they actually don’t create anything. They don’t draw UI wireframes, they don’t code (well, except code for automated testing, but that’s a different story).

Yet another myth is that the goal of testing is to assure quality of software. But one person cannot be responsible for quality of teamwork. It’s a shared responsibility.

So how can we define the actual goal of testing? For our company it is: “To provide information about current product status to those, whose opinion matters.” It means to those, who can make decisions whether to allocate resources for fixing the found issue, or whether it can be postponed as a low-priority issue.

This is what a QA engineer aims to do at work. And this is how we can describe what skills a good QA should have. In my opinion, among lots of technical and soft skills there are only two that really matter: ability to ask questions and think critically.

Why these? Because to achieve the goal of finding problems and letting concerned people know about them, testing should be performed as exploring, not checking.

Let me explain the difference. Imagine that we have a software piece ready for testing. Let it be a Login Screen with Email and Password fields, as well as a Login Button.

There are certain questions asked by a QA engineer, and each of them defines a new test:

• What is the functionality of this screen?
• Should I be logged in the app if I use the correct email and password?
• And what if I use an invalid email, without “at” sign? Should it show me an error alert? Should it highlight the input field with red? Should it give me a hint about a valid email format?
• And what if I try to login with a valid but unregistered email? Should it say “User not found”? Or should it say “Incorrect password”? Are there two different alerts for unregistered email and registered email with an incorrect password?
• And what if I forgot my password? How do I restore it?

Answers to these questions can be found in product documentation, and they give expected results to test.

This is an exploration of software, where the real value of a professional QA engineer shows. If something goes wrong during this exploration, it may mean a problem. An issue is logged in the bug tracker, and the bug is fixed. And now QA needs to check whether the fix is correct and hasn’t broken any already tested functionality. It is necessary to re-run the same checks again. And later, after fixing new issues, after adding new functionality – to check once more that everything still works. This almost matches Albert Einstein’s definition of insanity: doing the same thing over and over again and expecting different results.

One more crucial detail: if you have a small project that can be developed within 6 months, QA engineers won’t get buried under a massive scope of regression checking. There will be enough time for exploring. But what if you have a large project—such as our example of long-term ERP system development—the sooner you start thinking about test automation, the more time will be saved in the future.

The next question: when a QA engineer should join the project? The answer is simple: the sooner, the better. Let’s see what a QA engineer does at each stage of the project and what value these activities bring.

Analysis

This is the stage where requirements are gathered and defined. QA tests them to make sure that they are clear and specific with no uncertainty—that they are measurable in terms of specific values—that they are testable with evaluation criteria for each requirement—and that they are complete, without any contradictions.

Design

As soon as any wireframes are available, it’s time for the QA engineer to test them. They do not evaluate usability or color palette—that’s designer’s work. Instead, they are looking for any missed requirements, lost functionality, mistypes, etc.

Development

When the requirements and design are approved, but still there is no app to test, QA engineers start planning. The main goal of this stage is to prepare a minimum number of tests that will cover the most possible cases in the app. Different test design techniques, like equivalence partitioning or pairwise testing, are used. All these tests are written down as checklists (or test cases, depending on project needs). Checklists prevent missing any critical check in the future and during regression testing.

Moreover, all the work at every stage is preventive. Once a QA engineer thinks of some tricky unobvious flow of actions (and let’s be honest, during early stages of development almost any flow except the happy path is unobvious), developers will consider this during their work.

Every prevented issue is a huge amount of saved time. Every time a QA stumbles upon a bug in the app, it takes some time to investigate it, create a bug report. Then it takes the developer’s time to read a bug report and fix it. Then again, QA verifies the fix and makes sure that it didn’t break anything previously working. And if something is wrong, the whole circle with reporting an issue and fixing it starts again…

There’s another vital activity. QA helps the team to prioritize issues by defining their severity. When there’s a lot of issues in the project, it’s crucial to concentrate work on fixing urgent things and not wasting time on low-priority issues.

Yet another responsibility of QA is to analyze user feedback and statistics—after the first release or during an open beta test. Defining the exact steps to reproduce from obscure user’s feedback like “It’s not working!” speeds up the fixing. And knowing the user statistics helps to update the test environment and concentrate testing efforts only on what really matters.

Conclusion

As a conclusion, let’s summarize everything that we learned about QA engineers:

• Their goal is to provide the team with information about project status. Take note, we are speaking not about some weekly or monthly reports, but about the continuous communication process.
• The greatest benefit brought by QA is that defects can be prevented before they are implemented. It takes way less time to edit the specification or to include a solution in the code than rewriting it, trying to fix something.

In other words, QA helps to correct mistakes and save your time and money from the very beginning of the project on idea stage, during development and even after product release.