Testing is boring. It’s just about clicking around and it doesn’t bring any real value. It only makes projects longer and raises the development cost. Quality assurance for sure isn’t a hot topic. So why do we still need testers? Can’t developers just double check their work?
Just kidding.
Quality assurance is quite underrated. Though bringing indisputable benefits to any application, it is still seen as a whimsy rather than necessity. In this article, we’re explaining what QA actually is and how it’s advantageous in the software development process.
A long, long time ago…
Software testing is as old as software development itself. By definition, the purpose of testing is to find errors in a program so that it functions in accordance with the end user’s requirements.
In the beginning, testing was a negligible process, but things began to change dynamically in the 1990s and 2000s, along with the introduction of IBM’s PC (and many clones it spawned). PCs were not identical of course, and the specification of their software and hardware varied widely. This fact made it necessary to prepare software that worked the same way on every machine.
Another factor that added up to the importance of tests was the commercialization of software and business demanding more frequent releases to keep clients happy with updated products on a regular basis. The same reason made the industry abandon the waterfall approach and work out more flexible ways for continuous software development management. The answer was Agile.
Tests are an integral part of SDLC (Software Development Life Cycle) and help developers find malfunctions as early as possible. Elimination of bugs can be directly translated into quality improvement. Thanks to that, the final product is as close to the initial blueprints as possible.
To test or not to test
Every tester book begins with examples of undetected defects in software and the dreadful consequences. You can easily find examples of Mariner I or Mars Climate Orbiter space probes that were some of the greatest failures in NASA history. Defects of Therac-25 and Cobalt 60 medical radiotherapy devices are also examples that affected the health and life of many people. The examples mentioned above may be very graphic, but what do they have to do with regular development of web applications? If you don’t plan to send an artificial satellite to the Earth orbit or experiment with radioactive elements, why bother? Will profits overmatch expenses?
Find out why Poland is the best place to outsource software development
Is it worth it?
Testing is the aspect that delays product release with every bug that is found.
Testing is another cost that needs to be taken into account in the development process.
Testing is ‘’the last part’’ of the process, so you can give it up easily.
Only it’s not.
Some may think that testing is an unnecessary addition to the development process. Can’t the developers check whether the app is fine or not? Is it really that hard to find bugs? As much as we appreciate neat programming, even the neatest programmers won’t be able to find all the bugs by themselves, and that’s for a couple of reasons. The developer’s job is to work on the code: when a developer works on a functionality, he is far from being objective in that matter. It wouldn’t be reasonable to expect the creator of functionality X to take a few steps back and look at said functionality ‘’from a different perspective’’ in order to find malfunctions. There are some things that the developer will not even think of: being the technical party, he may sometimes overlook some UX (user experience) matters. That’s just natural. A quality assurance engineer, however, is trained to find bugs in the application. He or she is rather impartial in the process, which definitely makes it easier to find bugs. What’s more, a QA engineer is allowed to focus solely on the issues there are in an app. Nothing is going to be too small to even bother. But when you’re heavily involved in the project (because you’re coding it), you can easily go like: OK, no biggie. That’s a small thing, we’ll fix that later.
Additionally, as it is commonly known that time is money, clients can often put pressure on the manufacturer to accelerate the process of product delivery. If testing is seen as an ‘’addition’’ rather than a standard part of product development process, it is the field that seems to be the easiest to resign from for the client, at least at first glance. We cannot eliminate all the defects anyway, right?
Well, the answer to this question is not that simple. Can we eliminate ALL the defects? In brief, the principles of testing say that it is impossible to find all the bugs during the development process no matter how much time is spent on the task. But there is a set of practices that help to eliminate the vast majority of defects, and that’s already a lot. The problem is that if there is a bug in the application and nobody finds it, there is a risk of a user stumbling upon it. And while in some cases the malfunction will not have any deadly consequences, any problem with the application translates into a loss of money. How so? It is estimated that finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase. What’s more, current software projects spend about 40 to 50 percent of their effort on avoidable rework. Let’s now have a look at even bigger numbers. According to a report on software fails, in 2017, software failures cost the economy $1.7 trillion in financial losses. In total, software failures at 314 companies affected 3.6 billion people and caused more than 268 years in downtime. A more tangible example may be Amazon. In March 2016, Amazon experienced a service disruption and for a period of 20 minutes, its users were presented with a message saying “We’re sorry! An error occurred when we tried to process your request”. 20 minutes doesn’t seem like a lot of time, does it? But it was enough to make Amazon lose $3.75 million.
It is also statistically proven that costs of correcting defects rise as product development advances.
Testing vs. Quality Assurance
In Agile methodologies, testing has a much wider spectrum and can be called “quality assurance”. The difference is as follows: back in the day when waterfall was still prevalent, testing was the last stage of the development cycle. In Agile methodologies, however, iterative system of work makes it easier to act upon existing defects sooner than last seconds before delivery. This translates into more flexibility and shorter time of reaction, so the changes and corrections can be made on the spot.
Though testing and quality assurance have some overlap in duties, they are not exactly the same. While testing is generally made to demonstrate that the application functions the way it is supposed to and focuses on finding bugs and having them fixed, quality assurance is a systematic way of assessing the quality of the product so that it meets the client’s expectations. QA is not only testing, but also measuring the quality of processes, improving processes, and preventing defects.
Ideally, quality assurance should be implemented into the development cycle as soon as possible, just like in extreme programming. Extreme programming (XP) is an intense, disciplined and agile software development methodology that focuses on coding within each SDLC stage. XP is based on five values: communication, simplicity, feedback, courage, and respect. XP provides an interconnected set of software development practices, such as pair programming, informative workspace, stories, weekly cycles (iterations), Continuous Integration, test-first programming, and incremental design.
Test-first programming sounds interesting, doesn’t it?
Testing in XP is quite unusual. XP is the only methodology where tests are written before the work on the code even begins. While the normal path is:
develop code – write tests – run tests,
XP does it in a totally different way:
write failing automated test – run failing test – develop code to make test pass – run test – repeat.
This strategy allows the developers to write the code in accordance with test requirements. This way, the process of bug detection is highly effective. Test-first programming reduces the feedback cycle and helps developers identify problems and solve them faster.
As more and more clients understand the role of quality assurance in their product development, the role of the tester is also changing. QA can be beneficial at every SDLC stage, starting with defining the requirements when a QA engineer may find functionalities that are at risk of malfunction and also make sure that all the requirements are precise and well-understood by the whole development team. QA is also of help during defining user stories, and later, the tests happen: it’s not only about the end-product tests, but also testing the functionalities before production and UX-oriented testing.
Why test?
Quality assurance is more than checking the code for bugs. It helps to make sure that the client gets a product of high quality and all of their requirements are met. Though initially it may be seen as an additional expense, it quickly proves to be a necessary part of the development process that can actually save money in the long run as detecting defects early in the process prevents your app from malfunctioning in maintenance. It is crucial that every functionality gets double-checked before the product can be released. QA invests effort into verifying whether the product is defect-free by pointing out the bugs that occur during the development stages. Simply put: QA watches over product quality, making sure that there won’t be any (expensive) failures in later stages of development. An undetected defect may lead to serious business losses, so double-checking the software is crucial.
To sum up: what are some benefits of quality assurance?
- Quality
Testing allows for identifying and fixing bugs before the software becomes operational. When bugs are found in the early development process, the cost of corrections is much lower, while the risk of failure later on is considerably lower. And delivering a quality product translates into further benefits for the manufacturer. - Savings
Not testing your software is only an illusive saving. In fact, testing can help you avoid expenses that you’d have if your software failed e.g., in maintenance. - User experience
UX is something that really matters in any application, but some UX-related issues may still be accidentally overlooked by the developers. Testing is there to make sure that the app is simple, intuitive, and, of course, free of errors. - Customer satisfaction
The product owner is happy when their customers are happy. Having defect-free software helps to gain customer satisfaction as the product is valuable and reliable. - Organization and efficiency
QA promotes organization and efficiency. Working with QA since the beginning of the software development process, you can test your software as it gets created. This will help you avoid many problems, including faulty software and hasty fixes.
The primary goal of the development is to release a product that brings profit, and, at first glance, quality assurance seems to be something that doesn’t contribute to it. But again: it only seems not to contribute. In reality, QA is a significant part of the software development process that brings great value to every product.
