Here are some good questions / matters to consider before you define your strategy to test a product / software.
- What are the risks of hazards and safety measurements / limits
- What are the available resources and skills. Also consider human and time capitals.
- What is your test objective and is it clear enough for the test team.
- What are the regulatory aspects and does they change in any condition?
- What is the nature of the product and business? It also brings the questions of who is the product users?
Let’s explore the software test strategies according to ISTQB Foundation, using examples and analogies to make them easier to understand.
Analytical Test Strategy
This strategy is based on analyzing risks or specifications to design tests.
Analogy: Home Security System
Think of this strategy as designing a home security system. You analyze potential risks (weak points in your home’s security) and specifications (valuable items to protect) to determine where to place cameras and sensors.
Examples:
- Risk-based testing: Focusing more tests on high-risk areas of the software
- Requirements-based testing: Deriving tests directly from documented requirements
Model-Based Test Strategy
This approach uses defined models as the basis for testing.
Analogy: Building with Lego
Imagine you have a Lego model instruction booklet. The model in the booklet serves as your guide for building, just as a defined model guides your testing process.
Example:
Testing data uploads against a predefined mathematical model that specifies how data should be structured and processed1.
Methodical Test Strategy
This strategy follows a systematic, pre-planned approach based on prior experience.
Analogy: Cooking from a Recipe
Like following a tried-and-true recipe, this strategy uses established checklists or procedures developed from previous testing experiences.
Example:
Using a checklist of common areas to test for a mature product that undergoes regular updates1.
Process or Standard Compliant Test Strategy
This approach adheres to external standards or processes.
Analogy: Building Code Compliance
Just as constructing a building must comply with local building codes, this strategy ensures testing follows industry-recognized standards.
Examples:
- Following IEEE 829 standard for test documentation
- Adhering to agile methodology principles in testing1
Dynamic Test Strategy
This strategy uses lightweight guidelines to find as many defects as possible.
Analogy: Treasure Hunt
Think of this as a treasure hunt where you’re given a basic map and told to find as many hidden items as possible within a time limit.
Example:
Exploratory testing, where testers actively learn about the system while testing it, adjusting their approach based on what they discover1.
Consultative or Directed Test Strategy
This approach relies on guidance from experts to direct testing efforts.
Analogy: Guided Museum Tour
Imagine exploring a museum with an expert guide who points out the most important exhibits and explains their significance.
Example:
Having developers or domain experts guide testers on which areas of the software to focus on and how to test specific features1.
Regression Averse Test Strategy
This strategy focuses on automating tests to catch regression defects.
Analogy: Home Alarm System
Think of this as setting up an automated alarm system in your home. Once installed, it continuously monitors for any unexpected changes or intrusions.
Example:
Creating an extensive suite of automated tests that run after each code change to ensure existing functionality hasn’t been broken1.
Factors for Selecting Test Strategies
- Risk: For established, slowly evolving software, a regression averse strategy might be best. For new software, a risk-based approach could be more suitable1.
- Skills: The team’s expertise influences strategy choice. For instance, regression averse strategies require automation skills1.
- Objectives: Stakeholder needs guide strategy selection. If finding many defects is the goal, a dynamic strategy might be preferred1.
- Regulations: In regulated industries, a methodical strategy that satisfies compliance requirements may be necessary1.
- Product Documentation: Extensive documentation favors a requirements-based analytical strategy1.
- Business Considerations: If an existing system can model a new one, a model-based approach might be appropriate1.
By considering these factors and understanding the different strategies, testers can choose the most effective approach for their specific project needs. Remember, these strategies aren’t mutually exclusive – often, a combination of approaches yields the best results.
