In my 12 years of testing experience, I’ve come across high-risk projects many times. I’m convinced that we have always been able to steer clear of at least some issues or – in other cases – significantly mitigate their impact on the projects because of having the dedicated quality programming specialists onboard. I’m referring to both the legal and financial issues, as well as the client’s image perception externally, i.e. when the product doesn’t meet the users’ expectations or leaves them disappointed.

A story of an efficiency

First Case

In the case of this project, we were approached by a client who already had an existing system in place. So the first step we took was getting to know that particular customer’s needs. That way, we were able to define the project’s objective: achieving the desired result within a given timeframe using available resources.

The client’s existing system was associated with financial solutions. It had been created based on older technologies and developed for many years by various teams. Additionally, it had been passed on numerous times from one contractor to another, who all approached Quality Assurance very differently. As a result, the code’s quality was very low, and it lacked suitable project templates, among other things. Consequently, the quality of the whole system suffered, rendering it an obstacle to the effective implementation of business objectives.

For example, the processing of some data points was measured in days. That also caused serious problems with using the software, which – in turn – significantly damaged the client’s reputation in the eyes of their end-users. Hence, improving the overall system efficiency became our highest priority. Its successful implementation would allow us to achieve the project’s main business objective. The timeframe for achieving the desired result – improving the efficiency – was also a part of that objective.

Additionally, to achieve the desired result within the given timeframe, we needed to clarify available resources in the context of the team and the tools. The team comprised a few experienced developers and QA representatives. Their task was to ensure that the quality of the process and the delivered solution would be maintained at all times. The tools were chosen according to the technology the whole system was based on. It was related to the project itself. Apart from the main application’s code, verifying the tests’ code was also one of the tasks. The tests were supposed to detect errors in the early stages of the implementation of new functionalities.

Unfortunately, in the case of this particular project, they were practically non-existent. All verifications and validations up until that point had been carried out manually. That made everything very costly and time-consuming, and, keeping in mind the strict upcoming deadlines, we couldn’t afford to lose more time. Therefore, our QA team was tasked with the following:

• developing a test approach for legacy type systems,
• defining system quality indicators to monitor the state of the system and its quality,
• designing and implementing tests to verify achieving the desired project result – improving the efficiency,
• devising a CI/CD process with emphasis on the tests,
• designing and implementing automatic regression tests to assure stakeholders of the lack of regression in all areas, i.e. in terms of financial calculations.

Action plan

We spent the first few weeks drafting an action plan. Manual testing was not financially viable, and establishing a full framework for automatic testing was impeded by insufficient resources. Therefore, we focused on the Rich Based Testing methodology, recommended when time, budget, and resources are limited. Thus, we defined the business, technical and project risks. Based on all that, we were able to determine the action plan.

Next, we designed a fairly unique set of tests which convinced us that the modifications in the application itself wouldn’t impact financial calculations. While creating the solution, we also carefully considered the ROI associated with the automation of all the remaining process elements.

We were able to reduce the time needed to process some operations from a few hours to a few minutes, while also being certain that no regression was introduced to the code itself. That was possible due to the properly designed and implemented test harness. Ultimately, we reached the objective within the designated timeframe. As a result, the improved product was delivered to the clients and end-users on time.

The dedicated QA specialists team ensured that:

• risks and dangers were well-defined, and then mitigated or eliminated,
• the process was constantly monitored, and potential dangers were detected in the early stages,
• efficiency was improved without the fear of regression,
• tests to reduce the number of errors in future improvements were designed and implemented.
• Integration is key

Second Case

In the second case study, I joined an already existing team working on a project in the transport sector. Its objective was transport improvement by introducing an innovative system to manage, analyse, and distribute permits, access points, and payments.

The concept was based on micro-services and the integration with external suppliers. The project was already in the advanced stages of development with many requirements set in stone. And some micro-services were ready to be deployed. A dedicated QA team was not involved in the process from the start, and that situation posed a real challenge. Because of it, the existing process didn’t include the following features:

• an approach to testing at different project stages;
• testing processes for each release;
• best practices for test automations;
• defining risks and taking actions to mitigate them.

Testing strategy

After getting acquainted with the project’s objective, documentation, and existing code, we proceeded to establish a testing strategy and general approach to testing.

The first essential deadline (and goal at the same time) was delivering the first version of the software for the meeting with the stakeholders. It was important to get it right – the success of that event would determine the funding for the whole project. One of the decisions we made was to invest heavily in automatic testing. The tests’ role was to confirm our assumptions that every module met the client’s needs and that the integration worked properly. At the same time, we decided to expand the QA team to run manual tests on the already existing components.

While testing, it turned out that some services returned integration defects, which negatively impacted the general payment calculations. This early error detection during the testing phase spared the client the cost of fixing those issues at later stages. It would have surely been much more expensive if the software had been already delivered to the clients and users. However, that cost could have also been reduced further had the QA team participated in the initial project phases when the testing requirements and documentation were being established.

Consequently, we were able to pass to the next implementation phases and develop the application further.

Having established a dedicated QA team, we were able to succeed in the following areas:

• devising a strategy and testing process for the project – from testing new functionalities and automation to regression tests and application quality reports;
• designing an early error detection process that prevented potentially lower confidence in the product and higher costs of fixes as opposed to spotting errors in the production phase;
• implementing QA in the requirement definition process to detect potential errors much quicker;
• devising an automatic testing solution to cover both individual modules and the integration between micro-services and external systems;
• introducing testing in the CI/CD process phase, thanks to which we were provided with quick feedback on the current application status;
• delivering high-quality software in a timely manner, both as a presentation for the stakeholder and later for the end customers.

Conclusion

The above case studies demonstrate that any team composed of QA experts can significantly improve the quality of the delivered software solution. While it is a fairly broad statement, here are some tangible advantages of having QA onboard your next project:

• improved satisfaction from the application’s end-users, time and costs savings in terms of potential bug fixes if they are detected early enough,
• protecting the reputation of the client who is co-operating with the team on the final product,
• avoiding missed deadlines and costs generated by potential delays,
• eliminating issues related to the system’s efficiency and security,
• identifying risks and taking appropriate actions to either mitigate or completely eliminate them.

To summarise, every software development team should always include experts who will ensure the highest possible quality of the final product.

Deliver high quality software solutions

Work with us and turn your idea into a great software solution for your company’s needs.

Let’s join forces