The Role of a Software Test Strategy in a Strong Quality Assurance Plan

3 min read

Quality assurance (QA), substantiated by a strong software test strategy, is often underestimated in many IT projects. We consider the QA strategy vital for the healthcare project we worked on. Our team worked to ensure alignment with the requirements of patients, healthcare professionals, and the organization involved. A robust QA strategy aids in early problem detection and prevention, ultimately leading to time and cost savings and potentially saving lives.

This article will delve into the core components of an effective QA strategy and share some valuable insights from our extensive experience in a long-running healthcare project.

About the project:

The project’s main objectives were:

  1. Assist users in understanding their health insurance coverage.
  2. Facilitate the booking of appointments with healthcare providers or clinics for users.
  3. Aid users in resolving disputes related to insurance payments.
  4. Support our users’ employers in reducing insurance expenses.

The role of software test strategy in the QA process

A software test strategy is an instructive document that outlines the approach for testing a software product during its development process. This document includes various facets of testing, such as methods, procedures, goals, resources, and more. A well-crafted test strategy is a structured blueprint for evaluating the software’s functionality, performance, security, and other aspects.

The specific details of a software test strategy often hinge on the scale and scope of the project. Based on the project’s progress and the attainment or non-attainment of its objectives, it can be adapted or modified over time.

Crafting a practical test strategy demands that you, as the author, to:

  1. Begin by clearly defining the project’s goals, focusing solely on measurable and attainable results that align with your team and the client’s expectations.
  2. Identify and catalog the resources, including their team, testing environments, time constraints, and other relevant assets.
  3. Evaluate the feasibility of achieving each goal by considering the available resources. Based on resource availability, determine the relative importance of each goal.
  4. Once you’ve established what can be accomplished, prioritize the goals accordingly. Some objectives may take precedence over others as you discover their relative importance.
  5. Conduct a thorough risk assessment and document potential risks that could directly impact the quality of the project. This step ensures you’re prepared to address and mitigate potential issues.

Following these steps, you will create a robust test strategy that aligns with your project’s objectives, optimizes resource utilization, and minimizes risks. It was our theoretical base for creating a test strategy. 

Implementing a QA/AQA strategy pursues several central benefits:

  1. Clarity for the QA team: The QA team understands what, how, and why tests will be conducted. This clarity facilitates a streamlined onboarding process and prevents team members from being sidetracked by irrelevant tasks.
  2. Engagement of the development team: The development team becomes more actively involved in the quality assurance process, fostering a collaborative environment that emphasizes the importance of quality from the outset.
  3. Visibility for project management: The project manager (PM) can see the success criteria established in agreement with the customer, enabling a transparent tracking of progress against these benchmarks.
  4. Increased customer satisfaction: The customer gains a deeper insight into the quality and reliability of the product. This builds trust and provides a clear understanding of the development and testing processes, contributing to overall customer satisfaction.

The development of the test strategy for this project experienced three consistent iterations:

1) The first strategy was created when only six people were involved in the project. The main objective for QA engineers was just to keep the app stable. The customer never specified their requests; their primary concern was for the app to function correctly. 

Therefore, our QA team limited their testing to unit tests, considering other tests unnecessary. The release cycle was also notably brief, lasting just a week.

Yet the team had to deal with the following problems: frequent release failures, lack of requirements, tons of hotfixes, and not keeping up with QA documentation. 

2) The second step in the strategy development occurred when approximately thirty people were engaged in the project. Despite the increased involvement, the core goals remained consistent with the initial strategy: to enhance the app, eradicate bugs, and maintain stability.

Two product owners were added to the team and began documenting requirements. However, the QA team received this documentation only after developers released updates on the staging environment. Meanwhile, the customer started to appreciate the advantages of automated testing more, leading the team to implement these tests.

The release cycle was prolonged to two weeks, eliminating the problem of exceeding the implementation deadline. Although things started to look better in general, we faced new problems:

  • Due to security concerns, the team lost production
  • Release delays since the QA team didn’t have enough time to test the functionality
  • Lack of communication between the Product Owners had led to inconsistent requirements
  • There are tons of other hotfixes.

3) At this stage, the need for a new strategy became urgent, so we proceeded with its third version. The customer came up with more precise goals, and as the project team grew to fifty people, we finalized the objectives and the results we aimed for, with a new focus on quality assurance. Our goal was to improve the app’s quality without raising costs.

Four additional Product Owners helped streamline communication, making requirements more transparent. The QA team ramped up automated testing while keeping the release cycle at two weeks, which everyone was comfortable with. With the growing demand for testing, minimizing manual testing became essential to adhere to deadlines. Bug elimination became a key focus, especially with more frequent third-party audits, guiding us to establish specific objectives:

  • Checking if the software standards comply with the stated requirements.
  • Bringing the number of production bugs from high and critical levels to zero.
  • Moving from “technical” sprints with regression testing to sprints with partial regression testing.
  • UAT automation: reducing testing time from two days to one. Setting up regular auto-test runs to monitor the system performance

Our QA team analyzed the pros and cons of all types of testing we could use within the project and summarized its view in the following infographics:

software test strategy
software test strategy

After conducting the analysis, we settled on the following software test strategy:02 Building a Strong Quality Assurance Plan img2 development

Instead of conclusion: the new strategy provided excellent intermediate results:

  1. Comprehensive documentation testing was initiated, utilizing dedicated boards within the organization.
  2. We introduced concepts like defect classification to intercept bugs before they reached pre-production. Defects were categorized based on issues with requirements, integration problems with third-party systems, and failures to meet direct requirements.
  3. Although we’ve moved beyond the technical sprint phase, we’re still in the process of partial regression. We focus on elevating auto testing, integration, and e2e to meet the necessary standards.
  4. Regarding User Acceptance Testing (UAT) automation, we’ve achieved a day’s worth of efficiency gains, continuous updates to test lists, and a significant enhancement in test integration, jumping from 0 to 35%.

software test strategy

Editor's Choice

Post Image
8 min read

The Secret to Top-Notch Software Development: Our HR Management Platform

Software development is knowledge-driven and labor-intensive, meaning our most valuable assets are our employees. We must hire and retain the best teams to…

Post Image
7 min read

Overcoming IT product & business management challenges

Nowadays, more companies outside the IT sector are considering digital transformation and creating proprietary IT solutions. Yet they run into unexpected challenges, recognizing…

Post Image
6 min read

Save your information and nerves. Everything you need to know about the concept of Observability in Ruby.

  Engineering teams focus on observability.   Companies are increasingly adapting to diverse tech stacks, integrating observability in Ruby and other languages to…

Get the best content once a month!

Once a month you will receive the most important information on implementing your ideas, evaluating opportunities, and choosing the best solutions! Subscribe

Contact us

By submitting request you agree to our Privacy Policy