Author Marko Krstic
What is quality assurance in software engineering?
Building custom software solutions consist of many parts and processes necessary to produce an expected outcome. One of the processes that are mainly invisible to us clients, people who are not much into software engineering, is the assurance of software quality.
Since it's a hidden process, companies decide to implement it as they want or think it's the best without explaining what it is and how it works. Very often, we are not even aware of that process. We have just an initial assumption that they will deliver the solution we need.
Quality assurance in software engineering
Quality assurance in software engineering is a methodology for software development companies to ensure adequate confidence that a product complies with defined standards.
Development companies must rely on and stick to standard processes and activities in the industry to meet quality expectations. It is not a process to perform once and forget but consists of many different parts throughout the development cycle.
There are some of the criteria that a software solution needs to meet to satisfy the high-quality standard. Let's look at the most necessary aspects of quality assurance and how software development companies apply them:
- To do what it is supposed to do
- To do it correctly
- Usability
- Performance
- Security
- Monitoring
To do what it is supposed to do
One of the essential criteria software needs to meet is to do what it is supposed to. That means we need software that will exactly do what the documentation describes. Otherwise, our software will be completely useless.
Let's look at a trivial example: we need a custom software solution that sums two different digits. For example, if we enter two values, 4 and 3 or 5 and 6, we expect the result to be 7 or 11. That means our software does what it should do: sums numbers.
That was a very trivial example; in reality, the software solutions are way more complex than this. They might have dozens of features tailored to some specific business problem.
How do we ensure that the software solutions do what they should do?
The first step, and the most important one, is to transfer the domain knowledge of our business to the development team. We need to teach the people responsible for developing our software solution everything we know about our company, what we are doing, what we need, where we are stuck, etc.
If they don't understand our business processes, we will most likely get a solution we don't need or a solution that does what it is not supposed to do.
The best way which shows that we are on the same page and that they understood us correctly is to have some documentation in written form. Experience said that the most reliable way of accurately creating documentation would be if our development team made it and gave us so we could check it and approve it.
Letting the development team write documentation and requirements guarantees they understood each aspect of our business. Also, they can see the problem from a different angle which is always desired and could only lead to higher software quality.
Having described features in the documentation that both parties agree on (we and our development team) ensures that we will get the solution that does what it is supposed to do.
Another approach to writing documentation would be if we, as a client, write a full specification & documentation of potential software and give it to the development company to build it. Even though this is quite a popular approach, mostly, it's the wrong way and might produce many problems.
There are several reasons for that. First, we are domain experts and understand our business, but we are not developers and don't understand software engineering. Having that in mind, we could then define some requirements that are against engineering standards which might make our solution not good enough.
Also, software engineers have a lot of experience building complex solutions and might come up with better ideas for solving some problems than we do. They might propose a better / faster / more performant approach than we can since they know how to build the software.
Suppose we define requirements and the development team only builds it knowing nothing about our business. In that case, due to the lack of knowledge, they might pick the wrong technology, architecture, approach, etc., which might lead to additional problems.
So the most crucial step is educating the development team about our business so they can suggest the solution and make it with high-quality standards.
To do it correctly
It's not enough if the software does what it should; it also needs to do it correctly. Let's take the same example about summing the numbers.
If we what software to sum 4 and 3 or 5 and 6, and we get as a result 7 and 10, that means it doesn't do it correctly. It adds 5 and 6 incorrectly. So our software does what it is supposed to do, summing numbers, but not accurately.
Responsibility for this step is on a development team. Developers should use engineering techniques to ensure that our software is bug-free and less error-prone.
The way to ensure it is to write automated tests. Tests are specific pieces of code that test our software and its functionality. They check if our software produces an expected and desired outcome.
Developers write them and then periodically execute them to ensure our software solution works as expected. Writing automated tests takes time, almost the same amount of time as writing our software solution, but it is a guarantee of software quality and part of quality assurance.
Tests are entirely invisible to us clients; we cannot even notice if they exist. That's why many development companies don't write them, wanting to save time and deliver the product faster. But in almost all cases, it leads to low-quality software with many errors. Usually, the trade-off to save time by not writing automated tests turns into a disaster.
A simple example: our software has three features X, Y, and Z. We want to build a new one. By accident, developers can easily break any of these three existing features by creating a new one. If we don't have automated tests to execute against X, Y, and Z and check if they are still working correctly, they will ship and deliver it to us with new errors. That's how we get buggy software. And again, fixing that error might lead to introducing a new one somewhere else. The more features we have, the higher odds the new bugs creep in. It was just one example of the benefits of having automated tests; there are many more.
Usability
Another aspect of quality assurance in software engineering is software usability. We might have software that does what it should and does it correctly, but if it's not easy to use, it might significantly reduce its quality.
Usability defines how easily we can use our software to achieve our goals. Or, to put it in other words, the more user-friendly our software is, the higher its usability is.
User experience is essential but not the only part of usability. Efficiency plays a vital role as well. Efficiency shows the ability to use the software at the appropriate speed. If we could achieve the same task with fewer steps or clicks, it makes better our software usability.
The development team should initially provide and test software usability. They should check whether it's easy to use, efficient and if it is a user-friendly solution. But we also need to be included in the process. When they present the solution to us, we should check, test it out and propose the changes if we think there is an easier or more efficient way to use it. It's an ongoing process that requires fine-tuning since each problem is specific.
Performance
Performance might play a vital role in quality assurance, depending on the software type and its purpose. It is especially true for the software solutions that are used under high load.
The more users our software has, or the more intensive tasks our software performs, the higher load is, and the performance is more critical. But this is not the case with all software. Many custom-developed software solutions for internal business purposes don't have such a problem.
The development team or company is responsible for predicting if the software will be under a high load and writing and executing particular tests. That process is called performance testing.
The performance testing aims to show us where the bottlenecks are, what part of the software is under high pressure, and the cause of not performing well. When the software development team finds the reason, they are responsible for changing that part of the software with a new, more performant code to ensure our solution works smoothly without problems.
Security
One of the central aspects of software quality assurance is security. Different software solutions require different levels of security, but almost all software solutions require a basic concept of security.
The development team is responsible for implementing all necessary layers of security for our software solutions. They should predict, identify and prevent each dangerous activity and keep our software safe.
Since we will be the users, developers need to educate us about particular security policies related to our software. The part of the responsibility is on us, too, to use it according to the policy and not perform any suspicious actions.
Monitoring
Monitoring is a process where the development team continuously watches and supervises the health of our software. Developers use special tools for that purpose to early detect all possible problems.
Some errors & bugs are essential to be detected early since some could cause significant damage and problems. Monitoring is a good practice to prevent and fix issues. Prevention is always better than a cure.
Also, monitoring is supposed to show us other things about our software, different statistics, bottlenecks, load, CPU and Memory usage, etc. All in all, it is a good and necessary practice that is a part of software quality assurance.