Test Analysis and Basis in Testing
Thomas Hamilton
⚡ Smart Summary
Test Analysis, also called Test Basis, is the structured review of requirements, design documents, and other artifacts used to derive testable conditions. This article explains the sources, the step-by-step workflow, and the V-Model placement of test analysis.
Test Analysis — also known as Test Basis — sits at the very start of the testing life cycle. Every test condition and test case ultimately traces back to it. The sections below define the term, explain its sources, walk through the analysis workflow, and place it in the V-Model.
What is Test Analysis?
Test Analysis in software testing is the process of reviewing the inputs used to derive test conditions and test cases. These inputs — specifications, requirements, design documents, user stories, and similar deliverables — are collectively called test artifacts. The goal of test analysis is to extract test objectives clear enough that each one can be turned into an unambiguous test condition. Because the analyzed material forms the foundation from which all tests are derived, it is also called the Test Basis.
Typical sources from which testers derive test information include:
- SRS — Software Requirements Specification
- BRS — Business Requirements Specification
- Functional Design Documents
- User stories, acceptance criteria, and wireframes
Testers can also generate test conditions by exploring the Application Under Test directly or by drawing on past experience, but most test cases are derived from test artifacts to maintain traceability.
👉 Enroll for Free Live Software Testing Project
Why is Test Basis important?
Test Basis is the single biggest determinant of whether a test suite catches real defects or chases phantom ones. Treating it as optional is the most common cause of escaped bugs reaching production. Solid test analysis delivers four concrete benefits:
- Traceability: Every test case can be linked back to a specific requirement, which makes change-impact analysis fast and audit reviews painless.
- Coverage clarity: Reviewing the basis surfaces gaps — unspecified error states, missing edge cases, undefined non-functional thresholds — before they become production incidents.
- Stakeholder alignment: When the testing team derives conditions from the same documents the development team builds against, both sides hold a shared definition of “done.”
- Early defect detection: Many requirement defects (ambiguity, contradictions, missing acceptance criteria) are caught during test analysis itself, well before any code is written — by far the cheapest place to fix them.
Common Sources of Test Basis
Different artifacts feed different testing levels. Use the table below as a quick reference when deciding which document to consult while writing test cases.
| Source Artifact | Best Suited For | What You Extract |
|---|---|---|
| Business Requirements Specification (BRS) | Acceptance and system testing | End-to-end business rules, regulatory constraints, success criteria |
| Software Requirements Specification (SRS) | System testing | Functional and non-functional requirements with measurable thresholds |
| Functional / Technical Design Documents | Integration testing | Module interfaces, data flow, error-handling specifications |
| User stories & acceptance criteria | Agile sprint testing | Behavioral expectations in “Given–When–Then” form |
| Wireframes & UI mockups | UI / usability testing | Layout, navigation, input validation rules |
| Application Under Test (exploratory) | Exploratory and regression testing | Undocumented behavior, real-world workflows, edge cases |
How to Perform Test Analysis Step-by-Step
Effective test analysis follows a repeatable five-step workflow regardless of project size or methodology.
- Gather and inventory the test basis. Collect every artifact that describes intended behavior — SRS, BRS, design docs, user stories, mockups. Note which document owns each requirement so traceability stays intact.
- Review for testability. Read each artifact with three questions in mind: Is this statement measurable? Is it unambiguous? Is it complete? Flag any requirement that fails one of those checks and raise it back to the author before writing tests against it.
- Identify test conditions. For every testable statement, list the conditions that need verification (positive paths, negative paths, boundary values, error handling, security, performance). A test condition is the abstract “what” — for example, “system rejects orders with zero quantity” — distinct from the concrete “how” of a test case.
- Prioritize and group conditions. Classify each condition by risk and frequency of use. High-risk, high-frequency conditions earn detailed coverage; low-risk conditions can be combined or sampled. This is also where you decide which conditions are automation candidates.
- Convert conditions to test cases. Each prioritized condition becomes one or more test cases with preconditions, steps, test data, and expected results. Maintain a requirements traceability matrix linking every test case to its originating requirement.
Following this sequence avoids the most common test-analysis mistakes: writing test cases without a clear basis, missing negative scenarios, and producing tests that cannot be linked back to a requirement during defect triage.
Test Analysis in the V-Model
The V-Model pairs every development activity with a corresponding testing activity. Test analysis happens at each level using whichever document is available at that point in the life cycle.
Figure 1: Test Analysis across the phases of the V-Model.
Case Study: Deriving Test Cases from a Client Requirement
Consider a scenario in which the client sends the following one-line requirement.
Client requirement: Add search functionality to an eCommerce Store
Even though the application has not yet been built, a tester can already derive several test conditions by analyzing what the requirement implies — both happy-path behavior and the failure modes the client did not state explicitly. A few examples include:
- Verify the search result when no keyword is entered.
- Verify the search result when no matching product exists for the entered keyword.
- Verify the search result when several matching products exist for the keyword.
- Verify behavior with special characters, leading/trailing spaces, and very long inputs.
- Verify case-sensitivity and partial-match behavior.
- Verify search response time under expected user load.
The tester takes the client requirement (the test basis), analyzes it, and converts it into test conditions. This pattern repeats at each phase of the V-Model — test plans and test cases are created using whichever document is available at that point in the life cycle.
Video: Test Analysis Explained
If the video does not load, view it directly on YouTube.
