So, we should first decide what we’re talking about: we’re not talking about how QA engineers do their job. We are talking about why Quality Assurance is an essential part of software development and the way we operate at Django Stars.
Let’s start with some definitions.
Quality Assurance engineers aim to help create quality products. It’s not about finding bugs, not about simple testing. The main function of a QA engineer is to prevent defects, and therefore ensure the quality of the development process and its results. This is a broad statement, so in this article, I will try to cover a few specifics to help you understand the business value of QA.
Defect aka bug is a flawed piece of code that causes the system to fail to perform its required function. It doesn’t always mean that something doesn’t work. It may just work incorrectly.
So what do QA engineers do? They:
- identify weaknesses and inconsistencies in the product at all project stages;
- help define project requirements;
- provide comprehensive information about the level of quality of a product;
- test the product during all phases of the software development lifecycle (SDLC).
It’s important to note that QAs are interested in making any product user-friendly, be it functionality or design. For this, QAs closely communicate with all team members and constantly refer to the given requirements.
Now, let’s study all the stages in which QAs are involved, their roles in those stages, and the business value their work brings.
When do you need QA?
In this part, I will describe what QAs do and when they do it. The stages I’ll describe are common (and generalized) parts of the software testing life cycle (STLC).
Stage 1 – Requirements Gathering
This is the most important stage, in my opinion. During the first meeting, clients describe in general what they want. They outline the functionality of the desired app or service and what features it should include, but rarely the technologies they want it to include.
In many companies, the examination of functional requirements is the job of business analysts (BAs). However, they can’t guarantee the compatibility of the technical components. That’s why BAs share this stage with other experts, including QAs. The tasks of the latter include: (1) analyzing and deciding whether the requirements can be integrated within a single system; (2) which solutions will work and which ones won’t; (3) planning the required testing techniques (more on that below).
Validation is the process of evaluating a product before the development starts to find out whether the product will meet the users’ expectations, and if the idea is worth putting effort into.
During this stage, QAs collaborate with BAs to research the degree to which a software product can satisfy users’ needs. Basically, they check whether product makes sense to the users and the market. It’s critical to gather feedback from users to see what’s missing or what can be improved (design, features, etc.) to provide a better user experience.
Unless this validation occurs, the product may never reach its audience, even though it may be great from a technical point of view. This stage also ensures that the product will deliver profit to the client. Otherwise, why bother in the first place?
Stage 2 – Test Planning
During this stage, QAs define the testing strategy. By defining strategy, I mean making time and effort estimates for the entire project (= software product). After the requirements analysis, QAs create a document known as the Test Plan. It includes the project’s deliverables, its scope and objective, responsible roles, and defines the testing environment.
If not for this stage, the testing process would be full of unexpected obstacles and contingencies. To ensure further stages follow a strict sequence of action, the QA’s job is to make up and document the plan of action. Otherwise, the process itself might be clumsy.
Stage 3 – Test Development
Now that we have a Test Plan, we set up a test environment and create test cases. A test case is a set of steps we need to take to validate whether the software product is bug-free and works according to the specified requirements. After this, we think of the Acceptance Criteria – that is, the technical standard that a software product should meet to be considered successful.
Stage 4 – Test Execution
This is the stage that many consider as the QA’s only job – the execution of all test cases, based on the plan. If some part of a system works well, we mark it as Passed. In this way, we can ensure that we are not missing any details and the product is a quality one.
If a test case fails, it means there’s a defect in code, and the QAs send a report back to developers so they can check out what’s going on.
Stage 5 – Test Reporting
After the product is tested, it’s time to discuss what was OK and what went wrong to improve further testing cycles. To ensure fast bug fixes without any misunderstandings from developers’ side, every detected issue must be well documented. I will tell you later about the most common techniques QAs use to test products from different perspectives.
What is a testing cycle? It’s the frequency with which we conduct these five test stages – that is, each sprint.
Specifics of a QA’s job
Most software companies, Django Stars included, work in sprints – two weeks with a set list of tasks to be done. During each sprint, we implement some parts of the product requirements and complete all five stages of testing. It’s important that you understand that testing is not just trying every possible way to engage with a product. Surely, it’s that too, but usually there’s only so much you can do with a system.
Unless QAs are involved in the development process, it may later appear that the development team made something that works, and works really well, but not what was originally intended. It also helps reduce the time needed to devise new test cases, because the earlier we understand what we’re going check and how, the easier it is to conduct such testing. It’s crucial for the development and QA teams to work together, otherwise it may turn into a who-can-find-more-bugs fight. This rarely leads to quality results.
Now that I’ve told you about the Software Testing Life Cycle, I want to summarize why every team needs a QA:
- Secure business. You have a payment system, and it works just fine. A user pays for a service and gets it. However, you didn’t check certain cases and the money goes not to you, but to a random bank account. This is big, and fatal, especially if we’re talking about thousands of dollars.
- Save money. The diagram below clearly shows the correlation between life-cycle stages and costs. It’s more expensive to fix a bug than to prevent it. Fixing one bug may create another one, soo problems can escalate quickly.
- Protect your reputation. If you launch a buggy product and a user has a bad experience with it, it will be very difficult to persuade them that the problem is gone and they can use the product again. Rule of thumb: first impressions are hard to change.
- Ensure the product’s quality. If it is not tested inside out, the product may not work properly or not work at all. Testing stuff requires theoretical knowledge, so it’s difficult to assure quality if you’re not a professional.
- Monitor the process. Unless the development process is being controlled to align with the specified requirements, the final product may be different from the one planned.
You’ll notice that I use the word testing a lot. That’s because there’s a separate discipline known as Quality Control (QC). In the next part, which I call The QA’s Work, I will tell you the difference between QA and QC, the correlation between SDLC and STLC, and give a detailed description of some of the testing techniques that QA engineers use.
The QA
Quality Assurance and Quality Control
Quality Control encompasses all activities that ensure that a product is of good quality and meets specific requirements. QC engineers focus on identifying defects in the developed products before they are released. We can say that Quality Assurance encompasses Quality Control.
There are some cases when a product doesn’t require QA, but only QC. For example, if a team gets a product developed by somebody else and is asked to check whether the code meets the requirements, we have a case when only QC is required.
In some development teams, QA and QC are combined with other engineering roles. Sometimes, developers try to verify their own code. However, it’s not good in regards to quality, because it’s much more difficult to find bugs in your own code than in somebody else’s.
Software Development and Testing Life Cycle
It’s a simple message I want to convey: development and testing must always be synchronous. At Django Stars, we don’t divide the testing stages without accounting for what developers are doing at that moment. The team, as a single unit, is responsible for the product. Unless development and testing are done simultaneously, there can be delays and inconsistencies, and thus low-quality products.
I hope I have managed to convince you about the importance of both processes – SDLC and STLC – being conducted together. Now we’ll move on to some popular test design techniques that QA engineers use to assure the quality of a software product.
Test Design Techniques
Test case (or simply test) is a step-by-step approach to testing the functionality of a software product. Basically, it’s what and how we’re going to test.
Test design technique is a process for selecting tests that will validate that a software product meets the specifications before its release.
There are various test design techniques, and each of them identifies defects of a certain type. That’s why the choice for the required techniques depends on (1) the type of a product, (2) its status, and (3) requirements.
The picture below shows the most common test design techniques.
Let’s take a closer look at each of techniques and cases where we need them.
Static. This technique tests the source code, functional and requirement specifications before the code is executed (goes live). This technique identifies structural defects. It’s not a one-time thing, so we try to start conducting it at earlier stages of the development process.
Structure-based. We use structure-based techniques when we have full access to the code. To put it simply, these techniques deal with the internal logic and structure of the code. These tests help identify wrong or missing logic and typos in the code.
Specification-based. Also known as Black-box testing, this is a testing technique that examines the functionality of a software product without studying the code. Based on the requirements, we select appropriate test design techniques that help us derive test cases.
Experience-based. More of an auxiliary technique, this allows QAs to test the software based on their previous experience with similar systems.
I believe that you now see the theoretical basis one must have to be able to conduct quality testing. The number of required hard skills make it close to impossible for a non-QA person to assure the quality of a software product.
Bottom Line
No matter how simple a product may seem, there’s a ton of work under the hood of quality software. As Don Norman points out, “Good design is actually a lot harder to notice than poor design.” In most cases, QA engineers make it possible for people to enjoy good products by checking to see if everything works well.
Quality Assurance includes lots of activities, from testing to reviewing the results. Most software products need QA engineers to (1) set a mature development process, (2) ensure the quality of the released software, and (3) prevent errors in the system before users find them. QAs use various techniques to check whether a system meets all the specified requirements and operates as it ‘should’.
It’s not easy to test a system without special skills, and even an experienced developer is unlike to succeed in it. That’s why the best teams have QAs and developers working together; they can combine their skills in the pursuit of quality software.
The article is written by Irina Meshchankina. Article about quality assurance is originally published in Django Stars blog.
You can also visit our content platform Product Tribe created by professionals for those involved in a product development and growth processes.
You are always welcome to ask questions and share topics you want to read about!
Top comments (0)