Differences in QA approach for product life cycle phases
Nowadays, it’s hardly a cutting-edge statement that quality assurance is ‘baked in’ to agile and lean iterative development approaches. But it’s important to mention that the quality-related activities differ according to the phases of the product life cycle. Why is that? Basically, the reason for a diversified QA approach lies in the needs and goals that originate in each phase’s purpose. If your team’s approach to quality and testing is the same regardless of the maturity of the product, you can be sure that something is not quite right.
The main goal of a QA strategy is to design a set of activities and processes that directly respond to current business needs. And those are of course different, depending on the product’s current place in its life cycle: the MVP (minimum viable product) phase focuses on validated learning about the users, so extended testing activities are usually not required; however in the product-market fit stage, the quality assurance process gets more intense and structured; while for scaling products, the quality efforts focus mostly on improvements and maintaining the status quo. Let’s have a closer look at each phase and explore the possibilities.
Table of contents
What is the QA approach for the MVP phase of the product life cycle?
The MVP phase is mainly about validating the product idea, learning about the customers, checking if the product scope is of interest to the end users, and the value proposition responds to their underserved needs. With that in mind, we can consider time and user experience as the focal points of the test strategy.
Our mission is to deliver a product that allows users to comfortably complete certain designed business flows, in order to actually check if our assumptions about user behavior and product interactions are correct. And the product team expects to get feedback about the product as soon as possible, to be able to adjust and retest the flows and ideas. That’s why preparing a heavily-loaded QA strategy will definitely not align with the team’s focus.
From a quality perspective, to accurately respond to the team’s goal, QA specialists usually aim at less structured tests and may give more space to exploratory tests. Exploratory tests are well-suited for MVPs as they combine constant learning about the product with simultaneous test design and execution. A QA specialist has the chance to play around with the product, checking positive paths, looking for alternatives or risks, and trying to impersonate the end user. A set of predefined scripts is not required here, and allowing more freedom can result in some interesting discoveries.
With MVPs, it may be more effective to work with high level test scenarios, mind maps that mention areas of interest, or behavior-driven development (BDD, a behavior change and outcome-focused approach to testing and development) with Given/When/Then scenarios mentioned directly in the user story as acceptance criteria. Investing in detailed test cases that cover every possible path and edge case or complex test management tools would not bring much value to this rather explorative phase.
In this step, we may consider investing in manual functional tests, as time and a rapid feedback loop is of essence. The tester attempts to act similarly to a user and checks if the designed flows work as expected, sharing comments about some obvious defects, inconsistencies or negative scenarios. Bug fixing is usually also a fast process within the sprint (sometimes even a full defect report is not necessary, and a short note about the issue on Slack, a Trello board or Jira ticket is enough).
Regression testing is usually not a big topic for MVPs, and to some extent can be done manually. It is usually sufficient from a quality perspective, considering that the number of devices and platforms is limited for an MVP. However, if we are confident that the development will continue to the next phase, it’s a good moment to consider an approach for automated regression and maybe set up some basis for it.
An MVP is also probably not the best stagevfor a heavy set of load tests - we’re validating business ideas here and not delivering full-scale products.
What does Quality Assurance look like in the product-market fit phase?
Here we are after a set of experiments and adjustments to the initial concept as the product gets more and more users who are actually willing to pay for the service. At this point the product team will focus on garnering more profit, usually by adding new functionalities, improving the current flows based on user tests and feedback, as well as focusing on standing out compared to the competition.
Looking at this step from a quality perspective, growth is aing here, so the focus of the testing activities also shifts a bit in that direction. Likewise, the need to secure a stable environment for a larger number of users has a higher priority now.
Automated regression at this point is a must. The frequency of production deployments increases, the product gets more complex, so there’s no longer a possibility to effectively secure regression testing manually. Checking even the most important business flows may take hours and that is definitely not an option if we want to be able to deploy to production often and quickly.
This is especially true when there’s a need for a fast reaction to a production issue that directly affects customers. It’s good to establish a plan on how the team should react and handle production issues - where we’d like to communicate these types of issues, who sets the priority and severity, what actions should be taken for the issues triaged for immediate fix.
Product-market fit is a phase that strengthens a team’s efforts and cooperation in favor of product quality. For example, the scrum team may want to introduce more complex QA strategies, focus on testing integrations or speed up the automation of regression scenarios. An important aspect is also monitoring uptime and observing some crucial health check metrics, to ensure that the product is constantly available for end users.
Moreover, in the product-market fit phase the quality assurance tasks in a sprint get more structured. Usually, the test cases are prepared, so that they can be automated. I strongly advocate for incorporation of behavioral methods, like the previously-mentioned BDD, where the focus is on the value that a feature brings to the users and that in general also speeds up automated regression.
More consideration is also given to defect management. As the product gets more complex and the intensity of the testing activities increases the probability of finding bugs and new challenges also gets higher. All of this results in the need to triage the findings, planning according to their severity and priority in the sprints.
It’s also not unusual that in the product-market fit phase, a business will expect to offer the product to a wider range of browsers and devices, so cross-browser and cross-device testing becomes more important here, as does supporting these activities with automated tests.
Additionally, more detailed design checks may become necessary as well as user tests focused on testing not ideas but the user experience as it relates to selected functionalities and business flows. This is a great opportunity for QA specialists to understand the product better, mainly by observing the user tests and analysis of the data from metrics set up, for example, in Google Analytics or a database.
How to adjust the QA strategy to the scaling phase?
Scaling is a phase that has at its heart further development, adjusting to the market, adding product improvements, and optimization - regarding both the user flows and technical aspects.
In terms of quality, scaling does not differ much from the product-market fit phase, but is a great time to revisit the QA strategy in search of new areas of interest. It is highly possible that most of the testing goals and activities are still important as only a limited number of issues are expected and teams want to be confident about the production deployments and top-notch service for customers.
But what was being actively built in the previous phase of the product life cycle should now be a regular, solid daily routine. The technical and regression testing may now be fully automated, all browsers and devices are included in the test runs. There are definitely fewer manual testing activities relating to new functionalities. However exploratory tests may play a great part in this phase - the features and processes are advanced and complex, large numbers of customers on various platforms are supported, and so the area for quality discoveries also evolves.
To benefit the product’s development, the team can invest in aspects that have not so far been present in the QA strategy or were deprioritized. For some products, the performance and load tests may gain importance in order to ensure business stability and enable the product to handle more users or new markets. If it was not a top priority in the previous phase, it may now be necessary to expand standard security checks. Also, this phase is a great opportunity to focus more on the technical quality of the product - e.g. set new thresholds for unit or integration tests or start a completely new type of test.
Quality Assurance Life Cycle - Key takeaways
If I were asked for two top tips regarding the QA approach throughout the different phases of the product’s life cycle, I would definitely emphasize the following:
- Every product is different and requires its own quality approach which must directly respond to the current business needs. In the course of this text, I’ve suggested a few possible activities but it is highly likely that your product may require a different set of tasks and techniques.
- The QA strategy and ongoing testing activities must be reviewed regularly, especially when a product moves into a new life cycle phase. Each phase has its own focus, and business goals and user needs also vary depending on the different levels of a product’s maturity. An outdated QA approach might keep the team occupied with a wide range of testing tasks, but it may not efficiently support the business strategy.
Share this article:
