QA: BRD, SRS, and Test Plan

BRD, SRS, and Test Plan

BRD

The Business Requirements Document

This document outlines the Business needs that justify the development of a product, the features required to meet those needs, and how those features should look to end users. This document is not necessarily concerned with HOW to achieve the feature, only that a functionality is required.

SRS

The System Requirements Specification relates back to the BRD and provides the technical details on how to accomplish each BRD requirement.

If the BRD includes an 'Account Deletion' feature, the SRS would typically describe the Account Deletion form fields, authentication rules, and visual elements such as buttons. Authentication architecture might be described elsewhere in the SRS and only referenced in that specific section.

I've seen in recent Agile environments such as TFS for the SRS/Specification documents to be quite inadequate and lacking meaningful information. This might not be a terrible thing if the team has little turnover or the product is not overly complex. For QA teams, this can prove frustrating as 'Expected Results' are hard to obtain and there is little to go on for CYA if things change in the product that break Regression tests or create defects that make it to the final release. I'd venture to assert that the worse condition the BRD and the Specifications are, the more important a quality Test Plan becomes.

Developer peer review of the Test Plan or Test Suites will not only solve misunderstandings early on, but can give part ownership to the development team on tests and their expected results.

 

Test Plan

The Test Plan is the QA's documentation that enumerates all the various tests required to ensure the features in the SRS are bug-free. My approach is to implement a multi-tiered architecture with the following

  1. Test Group - A collection of Test Suites, categorized by either Function or test type(performance/load/feature).
  2. Test Suite - A collection of Test Sets. Collections could be based on feature or test type.
  3. Test Sets - A collection of Tests that target a specific requirement or a group of closely related requirements.
  4. Test Cases - Specific steps to tests at least one function. Data driven tests allow for the same test to iterate through many sets of data - in effect, performing many tests. Data driven tests will sacrifice simplicity with power. Unless serialization of the test data exists in the data store, reporting can be impacted ( a test will fail even if only 1of 10 iterations fail ) with data driven testing,

Test Group/Suite

The Test Group normally encompasses an entire release ( in waterfall methodology ) and a sprint ( in Agile methodology ). It ideally should tie back to a top-level SRS number. Some workflows don't have room for this extra level and it is far from required. It does, however, simplify testing by allowing Test Sets to be reused for targeted testing.

Test Set

The Test Set carves out one peice of functionality - or a single feature - and contains all the individual tests that must occur to have adequate coverage. For example, a Test Set could be titled: Taxing: BreakPoint Table: Taxable Department: Verify that the low, high, and each breakpoint implement the proper tax rate/amount.

Test Case

The Test Case is ONE set of steps to test ONE pathway in the Test Set feature. Test cases can be parameterized an thus, would represent identical steps with many values. Problems can occur with a one-to-many accociation of Test Case to Parameters as if ONE parameterized instance of the test case fails, there is no way to indicate this without additional test framework and reporting framework. For example, if a Test case of 100 parameters addresses a Taxing Feature for BreakPoint tables ( NY and much of the New England area use these tables in lieu of flat-rate percentages ) if one parameter fails the effect on reporting is the same as if ALL 100 tests failed. In many cases, this isn't an issue, particularly in automation, as the effort and time required to re-test is minimal. But in manual testing, if the test iteration is logged will the tester have to go through all 100 parameters? If not, how do they show that only one parameter was re-tested in the test reporting tool.

Document Size/Length and Detail

Typically the BRD will be much  more concise than the SRS as the technical details to achieve features can be quite complex depsite the deceptively simple BRD line item. The Test Plan is usually a massive document as for each feature, there could be litterally thousands of permutations and paths that could have logic or error checking errors. As one progresses from the BRD to the SRS, Test Plan, Test Group, Test Set and Test Cases there should be an exponential growth occuring indicating the level of detail is growing with each phase of defining the deliverables in the SDLC. When properly executed, Traceability Matrices will be easy to create, maintain and review, allowing for efficient - if not automatic - reporting on projects progress, outstanding work ( technical debt ) and efforts pending to compelte a sprint or test iteration.

Example

BRD

1.            User Account Forms

1.1.         Account Representatives must be able to create accounts with customer SSN, First Name, Last Name, Checking Account Number, and Savings Account Number.

1.2.         Account Representatives must be able to update user accounts

1.3.         Account Representatives must be able to delete user accounts

 

SRS

1.            User Account Forms

1.1.         Create User Account Form

1.1.1.     A CREATE User Account Form must exist with text fields for User Name, SSN, First Name, Last Name, Checking and Savings account numbers.

1.1.2.     The form must have a SAVE button for posting new user data to the Database.UserAccounts table.

1.1.3.     The form must have a CANCEL button for aborting a new user entry/submission

1.1.4.     An email must be generated to the User Account Manager for final approval before additional edits are allowed on the user account.

1.2.         Update User Account Form

1.2.1.     An UPDATE User Account Form must exist with User Name, SSN, First Name, Last Name, Checking and Savings account numbers

1.2.2.     The form should pull a users's information from the database and populate associated text fields.

1.2.3.     The Account Form must allow any text field to be edited and have an UPDATE button to POST the data to the Database.UserAccounts table.

1.2.4.     The form must have a SAVE button for posting new user data to the Database.UserAccounts table.

1.2.5.     The form must have a CANCEL button for aborting a new user entry/submission

1.2.6.     Upon an UPDATE request, form validation must occur to ensure the SSN is fully completed and is numeric only.

1.3.         Delete User Account Form

1.3.1.     A DELETE User Account Form must exist with User Name, SSN, First Name, Last Name, Checking and Savings account numbers

1.3.2.     The form should pull a users's information from the database and populate associated text fields.

1.3.3.     The form must have a DELETE button for deleting the user data from the Database.UserAccounts table.

1.3.4.     The form must have a CANCEL button for aborting a new user entry/submission

1.3.5.     An email must be generated to the User Account Manager for final approval before additional user account is removed from the database

TEST PLAN

1.            User Account Forms

1.1.         Create User Account Form

1.1.1.     A CREATE User Account Form must exist with text fields for User Name, SSN, First Name, Last Name, Checking and Savings account numbers.

1.1.1.1. Test Case 1

1.1.1.1.1.              Parameters?

1.1.1.2. Test Case 2

1.1.1.2.1.              Parameters?

1.1.1.3. Test Case 3

1.1.1.3.1.              Parameters?

1.1.2.     The form must have a SAVE button for posting new user data to the Database.UserAccounts table.

1.1.2.1. Test Case 1

1.1.2.2. Test Case 2

1.1.2.3. Test Case 3

1.1.3.     The form must have a CANCEL button for aborting a new user entry/submission

1.1.3.1. Test Case 1

1.1.3.2. Test Case 2

1.1.3.3. Test Case 3

1.1.4.     An email must be generated to the User Account Manager for final approval before additional edits are allowed on the user account.

1.1.4.1. Test Case 1

1.1.4.2. Test Case 2

1.1.4.3. Test Case 3

1.2.         Update User Account Form

1.2.1.     An UPDATE User Account Form must exist with User Name, SSN, First Name, Last Name, Checking and Savings account numbers

1.2.1.1. Test Case 1

1.2.1.2. Test Case 2

1.2.1.3. Test Case 3

1.2.2.     The form should pull a users's information from the database and populate associated text fields.

1.2.2.1. Test Case 1

1.2.2.2. Test Case 2

1.2.2.3. Test Case 3

1.2.3.     The Account Form must allow any text field to be edited and have an UPDATE button to POST the data to the Database.UserAccounts table.

1.2.3.1. Test Case 1

1.2.3.2. Test Case 2

1.2.3.3. Test Case 3

1.2.4.     The form must have a SAVE button for posting new user data to the Database.UserAccounts table.

1.2.4.1. Test Case 1

1.2.4.2. Test Case 2

1.2.4.3. Test Case 3

1.2.5.     The form must have a CANCEL button for aborting a new user entry/submission

1.2.5.1. Test Case 1

1.2.5.2. Test Case 2

1.2.5.3. Test Case 3

1.2.6.     Upon an UPDATE request, form validation must occur to ensure the SSN is fully completed and is numeric only.

1.2.6.1. Test Case 1

1.2.6.2. Test Case 2

1.2.6.3. Test Case 3

1.3.         Delete User Account Form A DELETE User Account Form must exist with User Name, SSN, First Name, Last Name, Checking and Savings account numbers

1.3.1.     The form should pull a users's information from the database and populate associated text fields.

1.3.1.1. Test Case 1

1.3.1.2. Test Case 2

1.3.1.3. Test Case 3

1.3.2.     The form must have a DELETE button for deleting the user data from the Database.UserAccounts table.

1.3.2.1. Test Case 1

1.3.2.2. Test Case 2

1.3.2.3. Test Case 3

1.3.3.     The form must have a CANCEL button for aborting a new user entry/submission

1.3.3.1. Test Case 1

1.3.3.2. Test Case 2

1.3.3.3. Test Case 3

1.3.4.     An email must be generated to the User Account Manager for final approval before additional user account is removed from the database

1.3.4.1. Test Case 1

1.3.4.2. Test Case 2

1.3.4.3. Test Case 3

 

 

Tags