This is the second tutorial in the “Free Online Software Testing Training on a Live Project” series. If you are new here, please go to the first introduction tutorial: End to End Software Testing Training on a Live Project.
Let us now take a detailed look at how an SRS walkthrough works, what we need to identify from this phase, what pre-steps we need to take before we begin, what obstacles we may face, and so on.
SDLC’s Design Phase:
- The “Design” phase of the SDLC is when the functional requirements are transformed into technical specifics.
- This process involves the development, design, environmental, and data teams.
- This process often produces a Technical Design Document (TDD).
The SRS document serves as both an input for the TDD and a starting point for the QA team to work on the project’s QA part, which is to examine the SRS and determine the test objectives.
http://www.elearningsolutionstesting.inTable of Contents: [Show]
What Is An SRS Review?
SRS is a record that is made by the improvement group in a joint effort with Business Experts and climate/information groups. Regularly, this record once concluded will be imparted to the QA group through a gathering where a definite walkthrough is organized.
At times, for a generally existing application, we probably won’t require a proper gathering and somebody directing us through this record. We could have the important data to do this without anyone else.
SRS survey is only going through the utilitarian necessities particular archive and attempting to comprehend what the objective application will be like.
The proper organization and an example were imparted to you all in the past article. It doesn’t be guaranteed to imply that all SRSs will be archived that way precisely. Continuously, the structure is optional to the substance.
A few groups will simply decide to compose a bulleted show, a few groups will incorporate use cases, a few groups will incorporate example screen captures (like the report we had) and some portray the subtleties in sections.
Pre-Steps To Software Requirements Specification Review
Step #1) Documents go through multiple revisions, so make sure we have the right version of the referenced document, the SRS.
Step #2) Establish guidelines on what is expected at the end of the review from each team member. In other words, decide on what deliverables are expected from this step – typically, the output of this step is to identify the test scenarios. Test scenarios are nothing but one line pointers of ‘what to test’ for certain functionality.
Step #3) Also establish guidelines on how this deliverable is to be presented- I mean, the template.
Step #4) Decide on whether each member of the team is going to work on the entire document or divide it among themselves. It is highly recommended that everyone reads everything because that will prevent knowledge concentration with certain team members.
But in case of a huge project, with the SRS documents running close to 1000 pages, the approach of breaking up the document module wise and assigning to individual team members is most practical.
Step #5) SRS review also helps in better understanding if there are any specific prerequisites required for the testing of the software.
Step #6) As a byproduct, a list of queries where some functionality is difficult to understand or if more information needs to be incorporated into functional requirements or if mistakes are made in SRS are identified.
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?
Group leads are for the most part answerable for giving every one of the things recorded in the segment above. Notwithstanding, colleagues’ bits of feedbacks are generally significant for the outcome of this whole undertaking.
Group leads frequently ask-What sort of sources of info? Couldn’t it be smarter to relegate a specific module to somebody intrigued by it than to a not? colleague? Couldn’t it be good to settle on the deadline in view of the group’s perspective than push a choice on them? Likewise, for the outcome of an undertaking, layouts are significant.
When in doubt, layouts have a higher pace of proficiency when they are custom-made to the particular group’s accommodation and solace. It ought to, thusly, be noticed that group leads more than anything are colleagues. Getting your group locally available on the everyday choices is urgent for the smooth running of the task.
Is Template Required For Test Scenarios?
Why a template for test scenarios – isn’t it enough if we just make a list?
It sure is. Nonetheless, programming projects are not ‘one-man’ shows. They include cooperation.
Envision a group of 4-in the event that every last one of them chooses to survey one module of the product prerequisites determination each. Colleague A has made a rundown on a piece of paper. 2 utilized a succeed sheet. Colleague 3 utilized a notebook. Colleague 4 utilized a word doc. How would we solidify practically everything accomplished for the task by the day’s end?
Likewise, how might we conclude which one is the norm and how might we get out whatever is correct and what’s not on the off chance that we didn’t make the guidelines, regardless?
That is what template is: A set of guidelines and an agreed format for uniformity and concurrence for the entire team.
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 header of this template contains the space required to capture basic information about the project, the current document, and the referenced document.
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.
Let us now review our Orange HRM SRS Document and create the Test Scenarios
Pro Tip: check out the table of contents in the SRS sample we provided in 1st tutorials to get a good idea of how any document is going to flow and how much of work it might involve.
Section 1 is the purpose of the document. No testable requirements there.
Section 2.1: Project Overview- Audience- no testable requirements there either.
Section 2.2: Hardware and Hosting- This section is talking about how the Orange HRM site is going to be hosted. Now, is this information important to us testers? The answer is Yes and No. Yes, because when we test we need to have an environment that is similar to the real-time environment.
This gives us an idea of how it needs to be. No, because, it is not a testable requirement- a kind of prerequisite for the testing to happen.
Section 3: There is a login screen here and the details of the type of account we need to have to enter the site. This is a testable requirement. So it needs to be a part of our Test scenarios.
Please see the test scenarios document where test scenarios for a few sections of the SRS have been added. For practice, please add the rest of the scenarios in a similar manner. However, I am going right to section 4 of the document.
Section 4: Aesthetic/HTML Requirements and Guidelines- This section best explains how some requirements might not make sense to the test team at the time of the SRS review, but the team should make a note of them as testable requirements all the same.
How to test them and if we need specific set up/any team’s help to validate it are details we might not know at this point in time. But making them a part of our testing scope is the first step to ensure that we do not miss them.
Sample Test Scenarios for OrangeHRM Application: (click to enlarge image)
=> Please refer and download the Test Scenarios document for more information.
Some Important Observations Regarding SRS Review
#1) No information is to be left uncovered.
#2) Perform feasibility analysis on whether a certain requirement is correct or not and also if it can be tested or not.
#3) Unless a separate performance/security or any other form of test teams exist- it is our job to make sure that all nonfunctional requirements have to be taken into consideration.
#4) Not all information is targeted at the testers, so it is important to understand what to note and what not.
#5) The importance and no. of test cases for a test scenario need not be accurate and can be filled in with an approximate value or can be left empty.
To sum up, SRS review results in:
- Test Scenarios list
- Review Results – Documentation/Requirement errors found by statically going through/verifying the SRS document
- A list of Questions for better understanding- in case of any
- The preliminary idea of how the test environment is supposed to be like
- Test scope identification and a rough idea on how many test cases we might end up having- so how much time we need for documentation and eventually execution.
Important points to note:
#1) Test scenarios are not external deliverables (not shared with Business Analysts or Dev teams) but are important for internal QA consumption. They are our first step towards a 100% test coverage goal. Test scenarios once complete undergo a peer review and once that is done, they are all consolidated.
For more details on how QA documents are reviewed, check out the article: How to Perform Test Documentation Reviews in 6 Simple Steps.
#2) We could use a test management tool like HP ALM or qTest to create the test scenarios. However, the Test scenarios creation in real-time is a manual activity. In my opinion, it is more convenient manually. Since it is step 1 we do not need to bring out the big guns yet. Simple excel sheets are the best way to go about it.
The next step to this series is that – we will work on creating test cases and get further into the test designing phase. Before that, we will also get into – What test planning is? Where it fits into the entire QA project? As always, work with us for the best results.
YOU MAY BE INTERESTED IN
The Art of Software Testing: Beyond the Basics
Automation testing course in Pune