When disaster knocks on your door – the importance of Quality Assurance | 3030

In my previous articles, I answered the question: ‘Why Is Quality Assurance Important in Software Development’. This time, I’ll use my own experience to describe two case studies. In both of them, Quality Assurance (QA) teams have contributed to avoiding issues and potential disasters related to delivering low-quality software.

  1. A story of an efficiency
  2. Action plan
  3. Testing strategy
  4. Conclusion

In my twelve years of testing, I’ve encountered several high-risk projects. I’m confident that having the devoted quality programming professionals on board has always allowed us to avoid at least some problems or, in other circumstances, drastically reduce their influence on the projects. I’m talking to both the legal and financial concerns as well as how the client is perceived outside of the company, or when the product falls short of consumers’ expectations or dissatisfies them.

a narrative on efficiency

Initial Case

In the instance of this project, a client who already had a system in place contacted us. Therefore, we started by learning about the demands of that specific consumer. Therefore, we were ability to specify the project’s goal, which is to use the resources at hand to achieve the desired outcome in a predetermined amount of time.

The system in use by the customer was related to financial options. It has been built over many years by several teams using obsolete technology. It had also been handed over repeatedly from one contractor to another, each of whom had a completely different approach to quality assurance. As a result, the code had very poor quality and, among other things, lacked appropriate project templates. As a result, the whole system’s quality declined, making it difficult to accomplish business goals effectively.

The processing time for some data points, for instance, was measured in days. That led to substantial issues with utilizing the program as well, which in turn seriously hurt the client’s reputation among their end customers. Therefore, increasing system efficiency as a whole became our top focus. We would be able to accomplish the project’s primary business goal if it were implemented successfully. That goal also included a timetable for accomplishing the efficiency improvement that was sought for.

Additionally, we had to be clear about the resources that were accessible in the context of the team and the tools in order to get the required outcome in the allotted time. A few seasoned engineers and QA personnel made up the crew. Their responsibility was to guarantee the process’ and the solution’s supplied quality. would constantly be upheld. The tools were selected depending on the technology that the entire system was built around. It was associated with the actual project. Verifying the code for the tests was one of the jobs in addition to the code for the main application. The tests were designed to catch mistakes when new functions were being implemented.

Unfortunately, they were almost nonexistent in the case of this specific endeavor. Up until that moment, all manual checks and validations had been made. That made everything incredibly expensive and time-consuming, and we couldn’t afford to waste any more time given the impending deadlines. Therefore, the following tasks were assigned to our QA team:

creating a test strategy for older systems,

establishing system quality indicators to keep track of the system’s health and effectiveness,

creating and executing tests to confirm attaining the intended project goal, such as increasing efficiency,

creating a CI/CD strategy that places a focus on testing,

To reassure stakeholders of the absence of regression in all areas, such as financial computations, stakeholders should create and perform automatic regression testing.

action program

In the initial weeks, we created an action plan. The establishment of a comprehensive framework for automatic testing was hampered by a lack of funding, and manual testing was not commercially feasible. Since time, money, and resources are limited, we concentrated on the Rich Based Testing technique. As a result, we identified the project, technical, and business risks. We developed the action plan in light of everything said above.

After that, we created a series of tests that were very original and convinced us that the changes to the program itself wouldn’t affect financial computations. We thoroughly examined the ROI of automating all the remaining process elements when developing the solution.

We were able to complete some operations in a fraction of the time—from several hours to just a few minutes—while still making sure that the code itself did not undergo any degradation. That was made achievable by the test harness’s right conception and application. In the end, we completed the task within the allotted time. The result was on time delivery of the upgraded product to the customers and end users.

The committed team of QA professionals made certain that:

Risks and hazards were clearly identified, then they were reduced or eliminated.

Potential risks were found early on thanks to continual monitoring of the process.

efficiency increased without worrying about regression,

Future enhancements’ tests to cut down on mistakes were created and put into practice.

Integrity is crucial.

Third Case

In the second case study, I joined a team that was already in place and working on a transportation-related project. Its goal was to enhance transportation by implementing a cutting-edge system to administer payments, access points, and permits.

The idea was built on the integration of outside providers and micro-services. Many needs for the project had already been established, and it was already at an advanced level of development. Additionally, certain microservices were prepared for deployment. The absence of a dedicated QA team from the beginning of the process was a significant issue. Due to this, the current procedure lacked the following elements:

a strategy for testing at various project phases;

procedures for testing each release;

excellent techniques for automated testing;

identifying hazards and taking measures to reduce them.

testing approach

After familiarizing ourselves with the project’s goal, supporting documentation, and current code, we moved on to creating a testing strategy and overall testing methodology.

Delivering the initial software version in time for the meeting with stakeholders was the first crucial deadline (and concurrent aim). It was crucial to get it correctly because the funding for the entire project depended on the success of that event. We selected automated testing as one of our options and chose to invest a lot of money on it. The purpose of the tests was to validate our presumptions that each module satisfied the requirements of the customer and that the integration was reliable. At the same time, we made the decision to grow the QA staff so that manual tests could be performed on the already-built components.

It was discovered during testing that several services returned integration flaws, which had a detrimental effect on the overall payment computations. The customer was spared the expense of addressing those problems later on because to this early fault discovery during the testing process. If the program had already been released to the clients and users, it would have unquestionably been considerably more expensive. However, if the QA team had been included in the early project phases, when the testing specifications and documentation were being developed, that cost may have been further minimized.

As a result, we were able to move on to the following phases of implementation and continue to build the application.

We were able to be successful in the following areas thanks to the establishment of a committed QA team:

putting together a plan and testing procedure for the project, including testing new functionality, automation, regression testing, and application quality reports;

creating an early mistake detection method as opposed to discovering faults during manufacturing, which might have resulted in lesser trust in the product and greater repair costs;

incorporating QA into the creation of requirements to identify possible mistakes more quickly;

putting up a mechanism for automated testing that can handle both individual modules and the interaction of microservices with other systems;

incorporating testing into the CI/CD process phase, which provided us with immediate feedback on the current application status;

producing high-quality software in a timely way, first as a presentation for the stakeholder and afterwards for the end customers.


The case studies presented above show that any team of QA professionals may greatly increase the quality of the given software solution. While this is a general statement, here are some concrete benefits of hiring QA for your next project:

enhanced program end-user happiness, time and cost savings in terms of potential issue patches if found early enough,

safeguarding the client’s reputation who collaborates with the team on the final output,

preventing missed deadlines and expenses brought on by possible delays,

removing problems that affect the effectiveness and security of the system,

Identifying hazards and taking the necessary steps to either reduce or eliminate them.

In conclusion, any software development team has to have professionals that can guarantee the greatest level of quality for the finished product.

Leave a Comment