User doesn’t need to know about defects

As said above, testing reduces the number of defects delivered to customer. In reality, defects in software are inevitable. And we must not be scared of it. It is well-known that something can’t be done right from the first time, especially if “something” is a complex system. Let’s take the car as an example. Multiple tens of people for multiple months shape the model before the first mass instance of the car is alight from the production line. At this stage the car has a lot of defects, which are being removed, to bring flawless car to customer. Nevertheless, defects are found even in new cars.

Admittedly, number of defects in car on market is incomparable with number of defects in car on design stage. It is reasonable that software product is getting its shape before it is shown to customer.

What system would you choose: one that contains 652 potential defects or one that contains 1307 potential defects? The answer is evident: one that contains the lower number of defects.

By what the number of defects can be reduced? Testing is one of the most effective methods.

On the other hand, software often is a unique system with no second instance, and this brings additional difficulties concerned with the fact that you can’t produce “pilot lot”. However, this is not the reason to deliver “as is” the system with all its defects (they are always there despite of conditions). This problem can be solved, for example, by using of beta-testing, based on product testing by end user. Turning back to automotive industry, we can see such example when new defects are disclosed after the car is out on the market. There are defects that can’t be found on testing stage by objective reasons. But you will never know about the problems (especially if they are resolved) if you are not an employee of the production company. The same for the software systems. Most defects must be fixed before user starts using of system. It is clear that after you get program where one defects goes for the other one, your desire of using this program will reduce. That is why user must get product without defects. Ideal situation, but we must rush to it (in the end the number of defects is a finite quantity). You may reduce the number of defects by testing of product. The other aspect is “how” and “under which conditions”. But you have to test.

Testing helps to prevent errors in the future

Nowadays iterative and spiral development models are widely used. They assume gradual buildup and improvement of system. Such models most precisely represent the reality. It is always useful to hold on and analyze previous step before starting the next. The same in the software development. Developer should consider the experience of the previous runs. In the strict sense, after the developer has learned some programming technology and learned how to use it, he/she uses the same code constructions in different combination and with different content. If it is not remembered that one or another sequence or construction of code ineffective or risky, then we’ll be all in bumps stepping on the same rakes. It is not easy to notice our own mistakes. That is why independent testing is considered as one of the most effective way to increase the quality. It is easier for exterior person to find errors and defects. That is the human nature – to notice mostly negative. With the rational approach defects of the previous versions become advantage of the next versions. Almost everyone has to go through the errors because one profits by own mistakes.

System in time or qualitative system?

What is more important: to manage in time or to meet customer’s wishes? Often these two targets are incompatible, and in most cases the second depends on the first. If you don’t manage the project in time – the customer is dissatisfied. Circumstances change so fast that the customer needs the system here and now, in the future this system can be simply useless. However, reaching the first target is not a sufficient condition to reach the second one. Customer requires (beside the time constraints): completeness of functions implementation, compliance with non-functional characteristics (performance, reliability, usability, etc.) and even what wasn’t stated in specifications – namely customer’s own subjective expectations on product. The last constituent is hardly managed. But as regards specified requirements and common standards and rules, they are managed and are to be managed.

Management can be represented by two parts: monitoring and control action. Testing is the tool for monitoring of quality level (that’s what about we were talking in the start of the article). Therefore it is the tool for monitoring of requirements implementation and standard validity.

But how all this may influence on customer’s satisfaction? Easy! First of all, testing reduced the risk of incorrect implementation of the product, i.e. chances that customer gets exactly what he/she wanted. In the second place, testing saves product from defects, which will annoy users and customers. However, often testing doesn’t get proper attention or it starts too late, when fixing of all obtained defects doesn’t let the project manage in time.

There are two solutions: either not fixing all defects (and resign yourself with customer’s temper) or try to convince of shifting deadlines for finished project. In the second case you can guarantee higher quality maybe even by your expense. So what is more important? It’s up to concrete manager in a concrete project depending on many conditions. By not reaching one these targets, you are at risk of losing customer. By not reaching high quality, you cannot expect more customers in the future. You have to show only the best to the world, the worst must stay at “workshop”. Exactly this testing allows doing.