Define Your Process

Learning Objectives

After completing this unit, you’ll be able to:

• Define the stages of the Software Testing Lifecycle.
  
• Explain the process and features of test management.
  

This module was produced in collaboration with Provar. Learn more about partner content on Trailhead.

The Software Testing Lifecycle

By now, you’ve learned about the Software Development Lifecycle (SDLC), but now it’s time to discuss the Software Testing Life Cycle (STLC). The STLC is a sequence of testing activities designed to make the testing process more effective. Unlike the SDLC, where the entire team (development, business, and operations) is involved, the STLC is primarily led by the testing team. It has six stages: Requirements, Test Plan, Test Design, Environments, Test Execution, and Data Analysis

Watch the video to learn more about each stage.

Test Management

Test management is the process of managing the stages of the STLC with the goals of increasing visibility and reducing risk. This process is often informed by how the team approaches development. While the STLC can be used in various models for software development, the two main models are waterfall and agile.

For the purposes of test management, the differences between waterfall and agile come down to documentation and speed. Waterfall emphasizes documentation with detailed planning and a test strategy for the entire testing process that places test execution at the end. Agile, on the other hand, forgoes heavy documentation to prioritize speed. It focuses on shorter chunks of development (called sprints) to test and release.

In both waterfall and agile, the STLC and test management are important. Although teams have trended more toward agile development, each team must consider their own context to determine the right balance of documentation and speed.

Quality Metrics

Regardless of a team’s approach to test management, there is one critical question for everyone to answer: How do we measure quality? Every project and team is different, but there are a few universal factors to consider.

The answers to these questions will organize testing efforts in a way that is both impactful and attainable. They will also guide the team as they determine their metrics for quality.

One common metric is test coverage, which measures what percentage of an item is covered by tests. These include code coverage, feature coverage, requirements coverage, risk coverage, and metadata coverage. Once a team sets a goal for that metric, they can routinely measure it to track their progress toward it. For example, one team might identify a goal of 70% code coverage. This would mean that they are aiming for 70% of their code to be tested. Sometimes test coverage goals are set by the application you’re using. For instance, Salesforce sets the goal for unit testing coverage at 75% as seen in this help article.

Why create test coverage goals? Teams can use test coverage data to identify gaps, determine if those gaps need to be filled, and if so, how they can fill them. This data can also help teams determine if they need to apply more time or resources and estimate future work. Note, though, that test coverage is just one metric. It can tell you how much of something you’re testing, but it cannot tell you about the quality of your tests. It is best used in conjunction with other test types.

For example, teams need to track bugs, too. With this data, they can identify where issues do and do not arise and better understand where to shift their efforts. Defect-related metrics might include the number of bugs, number of bugs in production, or bug escape (the ratio of bugs between production and nonproduction environments) ratio.

In the end, meaningful data analysis relies on comprehensive data. If you’re only using one metric, you’re really only getting information about your testing from one angle. By using a combination of metrics, teams get a more complete picture of their testing.

Test Plans

As teams are tackling key questions, they often use test plans to document their decisions. There are various elements that may be included in a test plan, but let’s look at a few found in most of them:

• Objectives: Use objectives to stay focused on your goals. To identify your objectives, consider all the software features to test and the goal of the test based on those features.
  
• Scope: Scope covers the degree of testing. This includes defining what is both in and out of scope. It is important to define scope because this can quickly slip beyond the reach of what is attainable for the team, a situation defined as scope creep.
  
• Risks: Risk identification and mitigation are important factors to consider when determining what to test. Identify the risks, their probability, and their potential impacts on the project.
  
• Assumptions: Identify any assumptions in the test plan to ensure all team members have a shared understanding of the work.
  
• Approach: Define the types of tests, their frequency, and the overall methodology of the testing.
  

As you can see, test management takes a lot of collaboration and decisions. On top of that, it occurs not just in one place but across all six stages of the STLC. In the next module, we look at test management tools teams use to coordinate and communicate these efforts.