High Level Documents in QA
SRS document: SRS is the high level document, created by BA or tech lead, describes about the software product, which we have to develop. It also describe about the business flow, user need, and project proposal.
Sample Requirements:
Requirement ID | Requirement Definition |
FR-01 | User registration. |
FR-02 | Request new password |
Detail documents:
Priority: | Essential |
Effort: | Days |
Risk: | Safe |
Functional area(s): | Administration |
Use case(s): | |
Description: | Visitors can come to the site and register themselves. They must provide the following information: · username · email address (twice to catch typos) · real name Precise Details: · username must be unique (not equal to any other existing user name) · username must be of the form [a-zA-Z0-9]{2,16} and is not case sensitive · email address must be of the form [-a-zA-Z0-9_.]{2,16}@[-a-zA-Z0-9_.]{6,64} · both entries of the email address must match · email address will be verified by sending the user's initial password there · real name must not be empty · leading and trailing spaces are stripped from all fields |
Notes and Questions: | · NOTE · QUESTION |
Revision History
Requirement ID | Date | Author | Changes Details | Version |
FR-01 | 5/6/2011 | Nsingh | Add another field for contact number | 1.1 |
Use Case:
A use case in software engineering and systems engineering, is a description of steps or actions between a user (or "actor") and a software system which leads the user towards something useful.
UC-01: Register as a new user
Summary: | Users need to register themselves in this web application. |
Priority: | Essential |
Use Frequency: | Once per user |
Main Success Scenario: |
|
Alternative Scenario Extensions: | · If the username is taken, then the system will suggest an available username based on the user's email address and/or real name. |
Notes and Questions | · NOTE · QUESTION |
UC-02: Request new password
Summary: | If a user forgets their password, they can request a new one be emailed to them. |
Priority: | Expected |
Use Frequency: | Rarely |
Main Success Scenario: |
|
Alternative Scenario Extensions: | · User puts invalid username, user puts non registered user id |
Notes and Questions | · Alternatively, we could use password hints. |
Test Case:
Test Case | Summary | Steps | Expected Results |
Registration_ValidData | Validate the registration of user, if he puts all valid information in registration page. | 1. Visit log-in page 2. Click on the new user registration link 3. Puts all valid information in given fields 4. Submit the form 5. Check the mail 6. Sign in | 1. User successfully signs in. 2. Welcome – XYZ should appear on top left of the Home screen. |
RTM format:
- Requirement ID
- Description
- Created/Updated date
- Is testable?
- Priority
- Test Objective (Test-suits)
- Test Case IDs
- Number of Test cases
- Status
- Comments
This document has been approved as the official Business Requirements Document for the [name of project] project, and accurately reflects the current understanding of business requirements. Following approval of this document, requirements changes will be governed by the project’s change management process, including impact analysis, appropriate reviews and approvals, under the general control of the Project Plan and according to company policy.
Nature of Signoff | Person | Signature | Date | Role |
Author | Narayan Singh | nsingh | Dec 5, 2011 | Sr QA |
Reviewers | XYZ | xyz | Dec 20, 2011 | QA Manager |
No comments:
Post a Comment