App Dev Manager Julio Madeira considers the importance of quality assurance in the software development lifecycle.

In recent years the search for software quality has grown considerably worldwide. Previously, quality culture was practiced only by software factories. Now it has also been adopted by companies using technology in their internal products.

Software quality goes against the jargon “always exceeding customer expectations”. This discipline even seeks this, but at the right time, that is, only during the Sprint Planning and depending on the Velocity of the Team in charge of delivering it. During the Sprint, it is necessary to be faithful to the initial Sprint Plan, that is, deliver exactly what was planned.

The project should not be risked due to opportunities and improvements that may come along the way. This is one of the precepts of software quality. Scope changes are inevitable, but must be planned for a another sprint, unless there is an urgent need on the part of the customer. The software architecture must adhere to the specified requirements. It can be innovative, lasting and still try to solve, not only the predicted problems, but also the unforeseen ones. It is at this point that the development team must glimpse what is really needed and not just what was asked for. One of the biggest causes of failure in software projects is lack of scope. In the eagerness to start work soon, the scope definition phase is reduced to the extreme. The result of this is a large number of corrections made during a sprint for a feature that was not properly planned.

Figure 1 Azure Test Plans

The size of the Sprint Planning is inversely proportional to that of the correction phase. The better the Sprint Planning phase is defined, the less time is spent on unnecessary discussions in the final phase of the project. This problem currently occurs in 25% of cases, according to the Gartner Group. Other problems that occur in most projects are customer dissatisfaction, the low adoption rate of the product, excessive rework, poor adherence to the solution and, worse, the image of the impaired company.

This last item is very difficult to measure, but bad comments about a product and its implementation tarnish the reputation of a large-scale company. In the software development process, Test Plans typically come together with the delivery of requirements and user stories to the development team. When software is rated as good because of the few defects it has, developers say it is because of them. The testing team says it is due to their performance. In reality, what defines the quality of the software is precisely the combination of these two factors. It is from the conflict of views between the development and testing teams that the quality of the software arises. It is precisely at that moment that you have different solutions to the same problem and discuss which is the best in relation to the client’s business.

The quality process can be supported by automation tools that save the testing team from performing repetitive activities so that they can engage in activities with higher added value, such as business rules and real use cases. Some of these tools are fully integrated into all stages of the project, from design to launch, integrating all teams on the same platform. The longer it takes to detect an error in software, the more expensive it becomes. This cost can be up to 80% higher if detected in the client, since it involves displacements and the company’s image.

Whether it’s a software lab or an in-house department that creates its own applications, its reputation can be made or destroyed whenever a product is launched. Therefore, the concern with software quality becomes increasingly essential for any company that wants to stand out in the market.