Quality assurance always plays an important role in achieving the objectives of an IT project. Not only in terms of the functionality of the systems, but also in terms of the cost and time. Yet too often contract negotiations in delivery projects are conducted without the supervising eye of a quality assurance professional and as a result, contracts for quality assurance and testing often include vague promises of ‘quality testing’. When the word ‘quality’ is not defined in any form, the parties’ perceptions are often not matched by the mention of quality in the contract. As a result, the supplier and the customer run the risk of conflict as the delivery project progresses.

Ideally, the test manager should be involved as early as possible in the delivery project to gain an adequate understanding of the customer’s business and critical business needs. The choice of the approach to be used in the project should not be a decision for the project management alone. The project management should choose the approach to the project democratically with the quality assurance professional, and thus build a coherent whole that can create the conditions to minimise risk while safeguarding the overall project cost and schedule. Testing and quality assurance often take up about 2/3 of the time in a delivery project, so the mirrors of the chosen project approach are significant in terms of quality assurance.

Creating a quality assurance strategy for a delivery project in a timely manner is in the mutual interest of the customer and the supplier

In a delivery project, the goal should always be a joint, efficient and high-quality delivery that best serves and supports the customer’s business needs.

Unfortunately, in supply projects, we often encounter situations in which the supplier’s sales strategy includes quality assurance as a positive mirror for the supplier, but the customers forget to react in a strategically relevant way during contract negotiations.

It is good to remember that functional testing of software is only one part of successful quality assurance in a project!

The waterfall model should not be underestimated

The next steps in the quality assurance process will depend on whether the project is implemented using the waterfall model or the agile development model, which is widely used today. Agile is currently the dominant trend, but I believe that the waterfall model is still better suited to projects in large, stable business organisations.

In my opinion, the agile model is suitable for businesses where the business also involves rapid response and new operating models, services, etc. Core systems in banking and insurance, healthcare systems and devices, systems for lending services are good examples of projects where the waterfall model has proven to work very well. In addition, the choice of model should take into account whether the development work is done in-house or whether it is a delivery project, or perhaps a mixture of both.

In a waterfall model delivery project, it is easy to build quality gates and also record them in the contract. For example, in a delivery project, the supplier’s payment invoices can be linked to specific quality records. This way, both parties have a clear picture of the project’s stages and progress from the beginning. In the waterfall model, testing pressure has traditionally been seen as being applied towards the end of the project, but with the right design and identification of the right quality gates, pressure can be correctly and evenly applied throughout the project. It is not uncommon for IT projects to be taken through an agile development model, but when major problems arise, the tools of the waterfall model are used in a corrective motion to get the project back on the “right track”.

We humans have a need to control and a tendency to compartmentalise, which is positive for project work in terms of structuring and anticipation. But in testing methodologies, it sometimes also makes sense to use a hybrid model, where a waterfall model and agile activities are extracted to find the most appropriate approaches for the project in question. A good test manager will have a keen eye for detail and be able to respond to changes during the project in an agile way in the waterfall model, and in an agile way in the waterfall model, using the tools from the waterfall model as needed.

A positive test can bring negative results

Unfortunately, in many IT projects, only the so-called happy scenarios end up in functional testing. Personally, I consider it a rule of thumb that for every 10 positive test cases there should be at least 3 negative test cases. As long as systems are used by humans, errors will occur. Errors can be prevented by testing things at an angle where the user makes conscious errors. If the system does not allow errors to be made, then errors cannot be generated either. Thus, business processes and systems will not be subject to user-induced problems.

A good Test Manager encourages a certain kind of disobedience from his team – divide and conquer. Business lifecycles are never overlooked, but missteps in the lifecycle often are. The test manager needs to make the team understand that every flaw found is a win, not a loss. Errors can be generated in documents, processes, applications, systems and users. An effective testing team can create a negative image of itself in the eyes of others on the project, but then it should remind others that nothing in testing is right and working until it is verified. Scepticism, that professional disease of testers for which the only cure is controlled and well-managed testing!