Training Day #2- Review of SRS Document and Create Test Scenarios
SRS is a document that is created by the development team in collaboration with Business Analysts and environment/data teams. Typically, this document once finalized will be shared with the QA team via a meeting where a detailed walkthrough is arranged.
Sometimes, for an already existing application, we might not need a formal meeting and someone guiding us through this document. We might have the necessary information to do this by ourselves.
SRS review is nothing but going through the functional requirements specification document and trying to understand what the target application is going to be like.
It does not necessarily mean that all SRSs are going to be documented that way exactly. Always, the form is secondary to the content.
A sample SRS document is attached to this post to give you an idea on how this document looks like, the format in which it is written, what kind of information it contains, etc. In the next article, we will get into how this document is consumed by the QA team to proceed further in our testing projects.
What do we need to get started?
- The correct version of the SRS document
- Clear instructions on who is going to work on what and how much time have they got.
- A template to create Test Scenarios.
- Other information on- who to contact in case of a question or who to report in case of a documentation inconsistency
Who would provide this information?
Team leads are generally responsible for providing all the items listed in the section above. However, team members’ inputs are always important for the success of this entire endeavor.
How to create a template for QA Test Scenarios?
Templates don’t have to be complicated or inflexible.
All they need to be are an efficient mechanism to create a useful testing artifact. Something simple like the one we see below:
The table below will let us create Test Scenarios. The columns included are:
Column #1) Test Scenario ID
Every entity in our testing process has to be uniquely identifiable. So, every test scenario has to be assigned an ID. The rules to follow while assigning this ID have to be defined.
For the sake of this article we are going to follow the naming convention as TS(prefix that stands for Test Scenario) followed by ‘_’, module name MI(My Info module of the Orange HRM project) followed by ‘_’ and then the subsection (For Example, MIM for My Info Module, P for photograph and so on)followed by a serial number. An example would be: “TS_MI_MIM_01”.
Column #2) Requirement
It helps that when we create a test scenario we should be able to map it back to the section of the SRS document where we picked it from. If the requirements have IDs we could use that. If not section numbers or even page numbers of the SRS document from where we identified a testable requirement will do.
Column #3) Test Scenario description
A one-liner specifying ‘what to test’. We would also refer to it as the test objective.
Column #4) Importance
This is to give an idea about how important certain functionality is for the AUT. Values like high, medium and low can be assigned to this field. You could also choose a point system, like 1-5, 5 being most important, 1 being less important. Whatever the value this field can take, it has to be pre-decided.
Column #5) No. of Test cases
A rough estimate on how many individual test cases we might end up writing that one test scenario. For Example, To test the login- we include these situations: Correct username and password. Correct username and wrong password. Correct password and wrong username. So, validating the login functionality will result in 3 test cases.
Note: You can expand this template or remove the fields as you see fit.
For example, you can add “Reviewed by” in the header or remove the date of creation, etc. Also in the table, you can include a field “Created by” to designate the tester responsible for a certain test scenario or remove the “No. of Test cases” column. The choice is yours. Go with what works best for the entire team.
Sample Test Scenarios for OrangeHRM Application:
0 Comments