Are you in charge of software projects at your company and facing problems with your software? Do you want to improve the quality and have no idea where to start? Then this article will help you to start implementing QA processes!
QA stands for Quality Assurance and is a very important subject in the complex world of software development. We observe our software and find that it has discrepancies with customer expectations. A discrepancy in software is called a bug. If we remove the bug from the software, it does not automatically mean that it now works flawlessly. A requirement is the term for customer expectations for a system and it could be that the bug hides there as well. Sounds difficult, right? That is why we need dedicated QA engineers!
Let’s start with the assurance part in QA. Spoiler: Nobody in the industry can assure that your software is flawless. Every software application has at least one bug, the question is: Do we know what it is, where it is and do we want that others (end-users, competitors, hackers) find it? Now that we accept that, we can move on. How can we ensure that we know about all the relevant bugs in our software? We test the software! We can also test all kinds of documents, design and code. Testers have a comprehensive toolbox on how to collect information about the system in test.
After some time of testing you will notice that there is a pattern of some kind (testers are really good in discovering hidden patterns) on how bugs appear or reappear. When you discover that pattern, one thing you might want to do is to reduce the number of known bugs or bug types from your product in the future. We can divide this process into two steps:
Why and how did a defect find a way into the software? Possible questions to ask: Is our system architecture too complex? Bad (or no) technical documentation? Vague or contradictory requirements? Do our people have the necessary skills to design/implement/test the software?
A typical approach might be: define a set of guidelines and standards to prevent this type of failure in the future, improve the quality of requirements by creating a checklist of what good requirements should cover, or use a specific tool to help us.
To summarize, with the help of analytical techniques we collect information about the software, with the help of constructive software quality assurance methods we prevent reappearance of bugs from a known source.
Quality Assurance requires processes and structure in order to analyze and improve software quality.
Now we need to talk about the quality part of QA. To better understand the topic let’s use the analogy of a chair. If we need new chairs for our dining room, we go to the store, see 20-30 different types of chairs and feel lost. How to find the right model? Which chair can we describe as having good quality? Different people mention different things. For me, it is important that the chairs fit with the rest of the interior decor, and that they are stable and easy to clean (because of my kids). For my son, it is important that he can swing on it without the fear of falling backwards. The best way to address these needs, is to create a list of requirements. Do we need armrests? Should they be stackable? What kind of material/style/colour?
We do the same with software. We create a list of requirements and measure the degree of compliance. The biggest problem is that software development is a very complex process and many customers lack an understanding of it. Customer requirements influence up to 50 % of project success. That is why we talk about quality attributes. One way to classify quality attributes and metrics is the standard ISO/IEC 25010:2011.
Image by Kristīne Corbus
Like testing, quality aspects can be applied to all kind of sources: software, subsystems, documents, single requirements, design and code. When starting a project, consider which quality aspects you will cover and what you will use as measurement. Choose it wisely, because what you measure, you will improve.
To illustrate the idea of quality, I used an example of finding a set of chairs, but software is a very complex system, more like a house. Quite often in development teams we hear customers saying: “We do not have the final set of requirements, but you can start and implement what we have so far.” This is wrong for many reasons, but I will mention just two of them.
Firstly, a requirement baseline is part of the contract between customer and service provider and should be synchronised with a SLA (service level agreement). Secondly, imagine building a house and, when your constructors are halfway done, you have the idea to put a swimming pool in the basement. Will it work? No. It is the same with software. If you cannot read the source code and see software architecture yourself, it does not mean that it does not exist. Your software has a structure and developing it requires you to follow certain rules.
Conclusion
Software development is a complex process which involves specialists from different domains. Quality Assurance is a discipline which shadows SD starting with the gathering of requirements and ending with testing rollback scenarios, with the aim of finding errors as soon as possible, analyze them and improve the process to reduce or eliminate those types of bugs.
Image by Kristīne Corbus
Why do we do all this? Because prevention and reduction of errors as early as possible cost less than the rework involved in fixing the bug. In this case we can talk about build-in quality. It is a smart business decision to invest in effective software quality assurance.
trendig
