Testing is any activity aimed at proving that the software system does not do what it is supposed to. Each bug you find early saves your users from frustration later.
The Discovery phase takes up most of a Product Manager’s time. Its objective is to discover and document the requirements of the proposed system thoroughly. The Product Requirements Document (PRD) you complete here serves as a contract between business and developers. If a requirement is missing or ambiguous, it will cause bugs downstream.
Your job is to ensure all necessary requirements are documented clearly and completely. On waterfall projects, this phase happens before development starts. On iterative projects, requirements analysis continues alongside development in cycles.
Testing is not just a Development phase activity. It starts here, during Discovery. By specifying test cases upfront, you add measurable quality requirements — clear acceptance criteria for the software. This sets expectations and reduces costly rework later.
The actual job: Support testing with effective test case design
Testing is any activity aimed at proving the software does not do what it is supposed to. This negative framing is intentional — every bug uncovered means a problem avoided for users. Testing includes:
- Technical tests of components and architecture (white-box tests)
- Tests that check if the software works as advertised (requirements-based or black-box tests)
- Tests that verify the software meets non-functional objectives like usability, performance, and security (system tests)
Your responsibility as PM is to support testing. Depending on your organization, some have dedicated QA teams; others expect PMs to be hands-on with testing. Many PMs spend most of their testing time on requirements-based tests and sometimes usability tests.
You do not need to be a coding expert to contribute. But you must understand the types of tests, know how to design effective tests, and be able to interpret results.
A bug is any variance between what the system is supposed to do and what it actually does. Bugs can be introduced by developers but also by ambiguous or missing requirements you wrote. It is your job to eliminate as many bugs as possible by specifying clear requirements and test cases.
Black-box testing: The PM’s core area of testing involvement
Black-box testing, also called requirements-based testing, verifies that the software meets the documented requirements without needing to know the internal code.
The PRD acts as the reference for these tests. The tester focuses on inputs and expected outputs, designing test scenarios from system use cases.
The challenge: full coverage requires testing every possible input combination — impossible in practice. So you use techniques to prioritize tests that uncover the most bugs efficiently.
Use-case scenario testing
System use cases are organized into:
- Basic flows: the normal path through the system
- Alternate flows: rare or exceptional but valid variations
- Exception flows: error conditions or unrecoverable failures
You design test scenarios to cover each of these flows at least once. For example, a stock trading app might test “non-standard lot size” and “partial order fill” individually and combined.
One effective way is to derive test cases directly from the steps in the use case descriptions, mapping “The user does X” to test action and “The system responds Y” to expected result.
Test template for requirements-based testing
A test template standardizes how you document each test scenario, including:
- Test objective
- System use case and flow
- Preconditions
- Actions and expected results step-by-step
- Pass/fail criteria and severity
- Sign-offs
This traceability ensures every requirement has corresponding tests and that test results are auditable.
Decision tables for complex condition combinations
When multiple input conditions interact, decision tables help ensure you test all relevant combinations.
For example, a decision table might list conditions like “Code of Good Practice Followed,” “Procedures Followed,” and “Number of Committee Members” with corresponding actions like “Mark as Payable” or “Not Payable.”
Each column defines a test scenario covering a unique combination of inputs.
Because sequencing is not specified in decision tables, you must supplement them with detailed test templates.
Boundary-value analysis: Targeting error-prone inputs
Boundary-value analysis focuses on testing inputs at the edges of valid ranges, where bugs are most likely.
For example, if a field accepts values 1–100, you test inputs at 1, 100 (positive tests), and just outside at 0, 101 (negative tests).
This technique applies to ranges, sets of options, and conditions that must be true or false.
Boundary-value analysis helps reduce the number of tests while maintaining coverage of critical cases.
White-box testing: Developer-led but PM-aware
White-box testing requires knowledge of the internal code structure.
Developers perform these tests, such as statement coverage, decision coverage, and condition coverage.
Your role is to specify the level of white-box testing required before you accept the software.
You may also review reports from automated tools that confirm coverage levels.
Full white-box testing is practically impossible because of the exponential number of execution paths.
Understanding the limits and coverage levels helps you ask the right questions and set realistic expectations.
System testing: Verifying non-functional requirements
System tests check whether the software meets objectives beyond functionality, like:
- Regression testing to ensure new changes don’t break existing features
- Volume and stress testing for performance under load
- Usability testing to verify user-friendliness
- Security, compatibility, reliability, and recovery testing
You may be involved in planning these tests and verifying execution but typically do not run them yourself.
Structured walkthroughs: Early, non-technical testing to find root causes
Structured walkthroughs are manual reviews of requirements, use cases, or designs with stakeholders and developers.
They can be done before code exists, catching errors early when they are cheaper to fix.
Unlike automated tests, walkthroughs find causes of problems, not just symptoms.
For example, a walkthrough might uncover a poorly documented decision table that caused credit to be wrongly advanced to unqualified applicants.
When is testing performed?
Testing activities occur throughout the project phases:
- Discovery: Design test cases; implement architectural proofs of concept
- Construction: Developers run unit tests and requirements-based black-box tests as use cases are implemented
- Closeout: Users perform User Acceptance Testing (UAT)
On iterative projects, these activities cycle repeatedly with each iteration.
Specifying the implementation plan: Planning for success beyond code
Your PRD must include an implementation plan covering:
- Training: Who needs training, how it will be done, and what resources are required
- Conversion: Data migration strategies, scheduling batch jobs, report distribution, and user privilege management
- Rollout: Communicating promotion dates to affected users
- End-user procedures: Documentation detailing new workflows and processes for impacted departments
User Acceptance Testing (UAT)
UAT is the final test before users sign off. It can be formal, with predefined test cases and sign-off documents, or informal, allowing users to explore and experiment.
Formal UAT clarifies acceptance criteria and reduces disputes.
Informal UAT provides flexibility but may be more subjective.
Beta Testing
Beta testing follows alpha testing and involves releasing the system to a wider user group representing target configurations and use cases.
Errors found in beta are fixed prior to production release.
Parallel Testing
Parallel testing runs the new system alongside the old one, comparing outputs to minimize risk.
If issues arise, users can revert to the old system quickly.
Installation Testing
After installation, checks ensure files are correctly installed and contents are accurate.
The PM’s role during Development and Construction
Once development starts, your active participation may taper on waterfall projects.
On iterative projects, you continue gathering requirements and clarifying use cases for upcoming iterations.
You must be available to answer developer questions promptly to reduce blockers.
Sprint planning meeting in a mid-sized product company
Developer: “Can you clarify how the edge cases for the payment flow should behave? The use case isn't clear on partial refunds.”
You (PM): “Good catch. Let's update the use case to include partial refunds and specify expected system responses.”
QA Lead: “We’ll design black-box tests based on the updated use cases to cover these scenarios.”
You (PM): “Also, I’ve scheduled a structured walkthrough with stakeholders next week to catch any ambiguous requirements early.”
This collaboration reduces bugs and accelerates development.
Clarity in requirements and early testing prevent costly rework later.
- Choose a key feature from your current or past product.
- List its primary use cases, including basic, alternate, and exception flows.
- For each flow, draft at least one test scenario describing the user action and expected system response.
- Identify any complex input conditions and create a simple decision table covering combinations.
- Apply boundary-value analysis to critical input fields.
- Outline how you would organize structured walkthroughs and user acceptance testing for this feature.
Prepare to share your test plan outline with your team or mentor for feedback.
You are a PM at a Series A SaaS startup based in Bangalore. The engineering team reports that the payment gateway integration frequently fails for a subset of users. The QA team has run unit tests and black-box tests but cannot reproduce the failure. You have access to the PRD and use case documentation.
The call: How do you investigate and support testing to resolve this issue?
Your reasoning:
You are a PM at a Series A SaaS startup based in Bangalore. The engineering team reports that the payment gateway integration frequently fails for a subset of users. The QA team has run unit tests and black-box tests but cannot reproduce the failure. You have access to the PRD and use case documentation.
Your task: How do you investigate and support testing to resolve this issue?
your reasoning:
Where to go next
- If you want to deepen your skills in user research and requirements gathering: User Research Methods
- If you want to master product strategy and vision: Product Vision and Strategy
- If you want to understand agile delivery and sprint planning: Agile Delivery Fundamentals
- If you want to improve your stakeholder communication: Effective Stakeholder Management