StatusNeo

Quality Assurance for Dummies

What is Quality?

Before diving deep into the definition of the concept of QA (Quality Assurance), let’s try to establish our understanding of the definition of ‘quality’.

The word quality in industry terms would generally mean – ‘The degree of conformance of a product or service to its implicit and explicit requirements and expectations i.e. higher the quality, more the requirements/expectations are met/exceeded.’ You can think from an everyday perspective like take the example of a chair. What makes a high-quality chair? Before deciding that, you implicitly think of why the chair exists in the first place or why did you buy it? Your explicit requirements/expectations out of a chair for example can be:-

1. Ergonomic? Comfort simply for you can be are you able to game on this chair for long hours together without a backache?
2. Should look good. Good for you can mean its fabric should match with your curtains.
3. It should be durable. You might be specifically expecting it to withstand your kicks when the crypto market crashes.
4. Justified price tag. Whether the price tag is justified w.r.t. the market.
5. Feel of the chair. Use of premium materials for example.

All these requirements if met or exceeded have the potential of achieving high customer satisfaction which ultimately is the goal of a product or a service.

It is very important for a producer of a good or service to first gather the requirements and try to document them as specifically as possible down to the inch of dimensions of a product or the time of availability of service down to the seconds. This is the first crucial step of quality assurance even when it comes to software.

Even if the requirements are not obvious especially if it is a new invention, the process of brainstorming on implicit requirements of a product along with continuous feedback and surveys to enhance them can be a promising approach.

The next step generally is to test on the producer’s end –the degree of conformance of the product to its requirements. This is usually done by executing a set of test cases by a team of people, manually or with the help of a machine (automation). This is the part that is called testing and is often confused to be the same as a more holistic process i.e. quality assurance. It is the same as comparing apples to……. apple trees.

Once the test cases pass, the product or service is good to go to its intended consumer, but what if a test case fails? The cost associated in that case turns out to be huge since catching a defect is one thing but going back and fixing it is all the more a huge problem in itself. The stage where a defect can be found can range from the first set of testing to the actual consumer reporting them back to the producer. The cost of a defect increases as we move down the stages of a product or service with it being the highest when it is caught and reported back by the consumer. The costs associated can be reputation damage, the cost of recalling the product, reimbursing/compensating the customer, loss of time, etc.

An ideal process should be designed with the ultimate goal to capture potential issues as close to the inception stage as possible due to the associated cost of fixing any issue increasing as we move down the further stages of development. Abraham Lincoln once said,

“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”

So now we know testing is just a drop in the sea of quality assurance since QA is something that ideally should be omnipresent throughout the cycles a product or service goes through.

In this blog, I will talk more about Software Quality Assurance in particular, although a good portion of it is applicable to all the products/services that exist across industries.

Software Quality Assurance

Let’s talk about what an ideal QA process looks like in an agile model of software development.

• Brainstorm, define and document rigid requirements– The first step for a business to achieve high quality is gathering the requirements which evolve through a collaborative effort between the product owner along with the QA team and the business. This step is a crucial first step since requirements are what will dictate the quality of the product or service in the long run. The focus should be on capturing all of the functional and non-functional requirements. It doesn’t mean the requirements are supposed to be rigid and immutable in the big picture since it is an agile method, though it has to be unambiguous and clear (i.e. there are no conflicts or loopholes) in the respective iteration before being handed over to the QA or the developers who will actually implement them. A high-quality user story would have clear and concise requirements well defined as explicitly as possible usually created by the ‘business’.
• Create and validate acceptance criteria for user stories – The next logical step should be creating acceptance criteria for those user stories. Acceptance criteria generally mean the definition of done of a user story i.e. when will the story be considered complete. This is very important since this is what will decide how well the test cases cover the requirements. The acceptance criteria need to be validated by the QA team and the business since it is the business that gave the requirements in the first place and the QA team will be the ones making sure they are met.
• Create test cases that cover 100% of the acceptance criteria – Test cases should be created in such a manner that the entire acceptance criteria are covered. A good practice of writing the test cases is thinking from the end user’s perspective and prioritizing the most important use cases first followed by the exploratory test cases which generally involve out-of-the-box thinking. These exploratory test cases are the ones that usually help the product or service exceed the user’s expectations since they cover the ‘good to have specifications’.
• Risk analysis during the Design phase – A certain kind of risk analysis is a must, best done during the design phase itself. Since potential error conditions, bottlenecks, and deadlocks identified in this relatively early designing phase can save a lot of re-development effort later on. Design should be thoroughly reviewed and brainstormed in iterations if needed, amongst the stakeholders till it reaches its final acceptable stage where it can be fed into the development pipeline. More time should be spent here in choosing a development strategy/approach if there are multiple options that need to be evaluated, rather than a ‘hit and trial’ later on during the development phase. A good example can be ‘a tattoo’, good luck figuring it out later.

• Proper code review process and unit test cases – Once the design is finalized and the underlying code/configuration change is done, there should be a well-defined process of peer-review of the code written to implement the change. This usually can be done by at least 2 other developers of the team who can be the engineering lead in the team, the project members, or anyone in the organization as long as enough context is given. It is important that everyone is merging code with non-breaking logic, adhering to coding standards, and agreeable styling. Linters can be used to enforce styling, but for validating logic, an additional pair of eyes are required. If PR review is done carefully, the possibility of bugs creeping into production becomes significantly low. This is usually the last and strongest line of defense against bugs in a production environment. It is important to have unit tests although it doesn’t guarantee 100% coverage of the corner cases. Minor or low priority errors can still be missed by the QA team which have the potential to later snowball into larger defects. For example, usage of Math.round vs Math.floor.

• Automated deployment process to minimize human errors – Manual deployments are inherently slow and error-prone. A proper well-defined automated deployment process will minimize deployment-related errors by building a set of pre-requisite criteria that the code has to fulfill before it can be deployed to an environment that can range anywhere from a leak detection (Gitleaks) to a basic code quality check(SonarQube). The goal here is to fasten and optimize the deployment process which is crucial, especially in an agile mode of development where a continuous integration/continuous deployment (CI/CD) pipeline is a must-have.
• Execute test cases as per the test steps – The test cases need to be executed properly as per the test steps and the test data. The goal here is to cover all the high-priority test cases first, followed by some exploratory test cases which can be random and should aim at catching the defects or areas that can be improved. It can be used to discover features that can be put in the ‘Good to have’ category just to give that extra premium feel to the user. These are usually low priority but have the potential of a huge impact on the user’s perception of your product/service’s quality.
• Automate the cases if feasible in the order of priority – The process of executing the test cases can be manual or automated depending on the feasibility or the Return on Investment (ROI). The ROI for automation is good if the estimated cost (man-hours) is less than that for manual testing. The benefit of automating the test cases is that it frees up the QA team’s bandwidth for exploratory testing since repetitive checkers every release(Regression testing) are best left to machines. If you don’t have to test it again or you don’t execute the test case too often, don’t spend time and money automating it. Since 100% automation is never achievable as you would always need a human mind to maintain, interpret or cross-check in case of failures or special cases just like the example of an airport security setup, you can have all the fancy high tech machines to scan commuters which definitely fastens up the process simply by its mere sophistication and speed in detecting threats. But you never see airport security without officers especially when the stakes are high.

Who is responsible?

As you can see, QA is just not limited to testing contrary to what an average engineer thinks. It is a shared responsibility between the client, the product owners, the designers, developers, the QA team, and the SREs.

Conclusion

The goal of a business aiming at assuring quality should be to move away from a catching bugs mentality to a preventing bugs mentality. More time should be spent on improving processes to foresee and prevent issues to minimize their occurrences at the end stages. Albert Einstein once famously said –

“Intellectuals solve problems, geniuses prevent them.”

Testing is just a part of the Quality Assurance process since QA is the process of improving and optimizing all the phases of the software lifecycle for it to produce high-quality products or services. A high-quality process will produce high-quality products. Ensuring high-quality batteries for example can avoid the scenario of exploding phones in the hands of consumers which can be costly and hazardous to a company’s reputation and can spoil any prospect of future engagement.

Everything starts from understanding, refining, and documenting the requirements in the best and the most explicit way possible to minimize the scope of assumptions/loopholes. Rest, everything needs to be put in place just to make sure, that whatever the requirements are when fed to the system, can be planned, designed, reviewed, implemented, tested, and released to the end-user as fast as possible while not sacrificing quality. This can be done in iterations if needed especially when it is an agile mode of development.

The ultimate goal is to focus on customer satisfaction which will involve understanding their requirements properly and feeding those requirements into a high-quality pipeline of product development that has the potential to produce high-quality products/services speedily and iteratively.

References- Internet