Testing is any activity aimed at proving the software does not do what it is supposed to do. Each bug uncovered is a victory — it means the end-user won't see that failure.
Testing is not a phase that begins after coding is complete. It should start as early as the Discovery phase, before design and development. By specifying test cases upfront, you embed measurable quality requirements into your product — clear-cut acceptance criteria that define when the software is acceptable.
The testing process includes three broad types:
- White-box tests: Technical tests of the software’s internal components and architecture.
- Requirements-based tests: Black-box tests that verify if the software behaves as specified by the requirements.
- System tests: Tests that check whether the software performs well enough on non-functional criteria like performance, security, and usability.
Your actual job as a PM is to support testing. What that looks like depends on your organization. Some companies have dedicated QA teams; others expect PMs to be deeply involved in specifying and sometimes even running tests. Many organizations have PMs whose primary role is managing testing.
Testing begins in Discovery — not after development
The Discovery phase is where you spend most of your time as a PM. The objective is to discover and document all necessary requirements completely, correctly, and unambiguously. The product requirements document (PRD) is the contract between business and developers. If a requirement is missing from the PRD, it is not part of the contract.
Testing activities start here because early testing means early detection of errors. The sooner bugs are found, the cheaper and easier they are to fix.
Testing is broader than running the software. It includes verification activities such as reviewing use-case descriptions with stakeholders. These are testing activities even if no code exists yet.
A bug is any variance between what the system is supposed to do and what it actually does. Some bugs come from coding errors. Many others originate earlier — from ambiguous, inaccurate, or missing requirements you wrote. Your job is to eliminate as many of these as possible.
The PM’s role in different types of testing
Testing includes three main categories:
| Test Type | What it is | Who does it | PM role |
|---|---|---|---|
| White-box testing | Technical tests based on knowledge of the code and architecture | Developers | Specify required coverage levels, review test evidence/reports |
| Requirements-based testing | Black-box tests verifying the software meets the PRD | QA team or PM | Design and write test cases, especially for requirements and usability |
| System testing | Tests of non-functional requirements like performance, security, usability | QA or specialized teams | Plan tests, verify completion, understand results |
In practice, most of your time as a PM will go into requirements-based testing. If your company lacks dedicated usability testers, you may also specify and run usability tests yourself.
White-box and system tests require technical expertise and are mostly carried out by developers and QA engineers. But you must understand enough to specify the required tests and interpret their results.
Designing effective test cases: general guidelines
Ivar Jacobson, a founder of object-oriented (OO) methods, advises deriving test cases from your system use cases:
- Test scenarios covering the basic flow of each use case.
- Test scenarios covering alternate and exception flows.
- Tests for line-item requirements in the PRD traced to use cases.
- Tests for features in user documentation traced to use cases.
These guidelines ensure your tests cover not only the happy path but also variations and failure modes.
Structured testing, pioneered by Glenford Myers in 1976, provides a disciplined approach. It uses standardized techniques to locate bugs introduced during business analysis, design, and programming.
Structured walkthroughs: testing without code execution
Testing is not just running software. Structured walkthroughs are manual, collaborative reviews of system aspects before any code is written.
The PM leads or participates in walkthroughs with stakeholders, developers, and testers. You walk through use cases, design documents, or decision tables together to find inconsistencies, ambiguities, or missing information.
Walkthroughs find causes of problems, not just symptoms. For example, a test might find that credit is being approved incorrectly. A walkthrough might uncover that the decision table for credit evaluation was documented incorrectly.
Walkthroughs enable early error detection — the earlier you find errors, the cheaper to fix them.
Requirements-based (Black-box) testing: verifying the contract
Requirements-based testing aims to find variances between the software and the PRD.
Because testers do not need to know the code internals, these are called black-box tests. The PRD is the reference.
Limitations: For full coverage, you’d have to test every possible input and condition — an impossible task.
Instead, use techniques to design test cases that uncover the greatest number of bugs in limited time.
Use-case scenario testing
Use cases are naturally suited for testing. Each use case has:
- Basic flow: The normal path through the system.
- Alternate flows: Rare or variant paths.
- Exception flows: Error conditions causing the use case to abort.
Design test scenarios for each flow. For example, test the basic flow once, then test each alternate and exception flow.
You may also want to combine alternate flows in certain tests to uncover interactions that cause failures.
Decision tables
When input conditions are interrelated, test all combinations of inputs.
A decision table summarizes these combinations and expected system responses.
Each column represents a test scenario, but you must specify the exact steps and data for each.
Decision tables help organize complex input combinations, especially for business rules.
Boundary-value analysis
Bugs often occur at the edges of input ranges.
Boundary-value analysis targets test data near these edges:
- For a valid range, test minimum and maximum values (positive tests).
- Test just outside the valid range (negative tests).
- For multiple valid ranges, test boundaries of each.
- For sets of discrete values, test each valid value and invalid ones.
- Combine positive tests where possible, but keep negative tests separate.
Example: If valid input is 2 to 10 parties, test 2 and 10 (positive), and 1 and 11 (negative).
Boundary-value analysis is a powerful way to find bugs efficiently.
White-box testing: technical tests of the code
White-box testing requires knowledge of the internal code structure.
Developers usually perform these tests.
They include:
- Code coverage tests ensuring all statements or paths are executed.
- Unit tests of individual functions, classes, or modules.
- Integration tests verifying components work together.
Limitations: Testing all possible execution paths is usually impossible due to combinatorial explosion. For example, a loop with nested conditionals can have trillions of paths.
Sequencing white-box tests
Software is developed in units — subroutines in structured programming or classes in OO.
Unit testing involves planning and executing tests of these units and their integration.
Approaches include:
-
Big Bang: Test all units individually, then integrate and test all at once. Easy to manage but hard to diagnose integration bugs.
-
Incremental: Add and test units one by one.
- Top-down: Start testing from top-level modules downwards, using stubs for missing lower units.
- Bottom-up: Test lower-level units first, using drivers for higher-level calls.
In OO environments, units collaborate at the same level. Testing follows the development of system use cases iteratively.
The PM should consult developers on unit testing plans and schedules.
System tests: verifying non-functional requirements
After black-box tests, system tests check if the product meets service-level requirements (SLRs), such as:
- Response time
- Throughput
- Security
- Usability
- Reliability
- Compatibility
Glenford Myers defined system testing as showing that the product is inconsistent with its original objectives.
Common system tests include:
-
Regression testing: Ensures new releases don’t break existing features.
-
Volume testing: Verifies the system handles large data volumes.
-
Stress testing: Subjects the system to heavy loads in a short time.
-
Usability testing: Checks if the system is user-friendly.
Questions include:
- Is the UI appropriate for users’ education level?
- Are system messages clear and helpful?
- Are error messages actionable?
- Are UI elements consistent?
- Does the system support the natural workflow?
-
Security testing: Attempts to find vulnerabilities.
-
Performance testing: Measures response time, CPU usage, throughput.
-
Configuration testing: Tests combinations of hardware/software.
-
Compatibility/conversion testing: Checks if new software matches old outputs and converts data correctly.
-
Reliability testing: Verifies the system meets reliability metrics like mean time to failure.
-
Recovery testing: Tests backup and recovery procedures.
User acceptance testing (UAT)
UAT is the final phase before users sign off.
It may be:
- Formal: Users and developers sign an agreement on test terms. Successful tests lead to acceptance.
- Informal: Users experiment freely to ensure the system supports their work, including unexpected workflows.
The PM may perform or facilitate UAT, depending on organization.
Beta and parallel testing
- Beta testing: After alpha testing by developers, the system is tested by a wider user group representing target configurations and needs. Bugs found are fixed before production release.
- Parallel testing: The new system runs alongside the old system. Outputs are compared to ensure equivalence. This reduces risks by enabling rollback if problems arise.
Installation testing
Performed after software installation to verify:
- All files installed correctly.
- File contents are accurate.
- Installation procedures work as expected.
Field exercise: Design test cases for your product
Take a product or feature you are currently working on. Spend 15 minutes:
- Identify the key system use cases.
- For each use case, draft test scenarios covering:
- Basic flow
- Alternate flows
- Exception flows
- Create a decision table for any complex input conditions.
- Identify boundary values for numeric or range inputs.
- Outline at least one usability test case.
This exercise grounds you in test design early, saving time and rework later.
Test yourself: Prioritizing testing in your first 30 days
You are a new PM at a Series A fintech startup in Bangalore. The product team has just completed Discovery for a new payments feature. Engineering is ready to start development next week. The CEO expects a demo in 8 weeks.
The call: How do you plan and prioritize testing activities starting now? What test types do you focus on, and how do you coordinate with engineering and QA?
Your reasoning:
Where to go next
- Learn how to write clear requirements: Writing Effective PRDs
- Master use-case modeling: Use Cases and User Stories
- Understand agile testing practices: Agile Testing and QA
- Explore product quality metrics: Measuring Product Quality
- Develop stakeholder communication skills: Stakeholder Management