How to Review SRS Document and Create Test Scenarios – Software Testing Training on a Live Project – Day 2

By Vijay

By Vijay

I'm Vijay, and I've been working on this blog for the past 20+ years! I’ve been in the IT industry for more than 20 years now. I completed my graduation in B.E. Computer Science from a reputed Pune university and then started my career in…

Learn about our editorial policies.
Updated March 10, 2024

This is the second tutorial in our ‘free online Software Testing training on a live project’ series. If you are new here please check the first introduction tutorial: End to End Software Testing Training on a Live Project.

Let us now get into a detailed analysis of how an SRS walkthrough happens, what is it that we need to identify from this step, what pre-steps we need to take before we begin, what are the challenges we could face, etc. in a detailed manner.

How to Review SRS Document and Create Test Scenarios_

SDLC’s Design Phase:

The next phase of the SDLC is “Design”- this is where the functional requirements are translated into the technical details. The dev, design, environment, and data teams are involved in this step. The outcome of this step is typically a Technical Design Document- TDD.

The input is the SRS document both for the creation of the TDD and for the QA team to start working on the QA aspect of the project- which is to review the SRS and identify the test objective.

What Is An SRS Review?

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.

The formal format and a sample were shared with you all in the previous article. It does not necessarily mean that all SRSs are going to be documented that way exactly. Always, the form is secondary to the content.

Some teams will just choose to write a bulleted list, some teams will include use cases, some teams will include sample screenshots (like the document we had) and some just describe the details in paragraphs.

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?

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.

Team leads often ask- What kind of inputs? Wouldn’t it be better to assign a certain module to someone interested in it than to a team member who is not? Wouldn’t it be nice to decide on the target date based on the team’s opinion than thrust a decision on them? Also, for the success of a project, templates are important.

As a general rule, templates have a higher rate of efficiency when they are tailored to the specific team’s convenience and comfort. It should, therefore, be noted that team leads more than anything are team members. Getting your team onboard on the day-to-day decisions is crucial for the smooth running of the project.

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. However, software projects are not ‘one-man’ shows. They involve teamwork.

Imagine a team of 4- if each one of them decides to review one module of the software requirements specification each. Team member A has made a list on a sheet of paper. Team member 2 used an excel sheet. Team member 3 used a notepad. Team member 4 used a word doc. How do we consolidate all the work done for the project at the end of the day?

Also, how can we decide which one is the standard and how can we say what is right and what’s not if we did not create the rules, to begin with?

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:

test scenarios template

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)

test scenarios template

=> 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.

QA Training Day 3: How to write an SRS document from scratch.

Please keep your questions and comments coming. We appreciate your readership a ton!

Was this helpful?

Thanks for your feedback!

Recommended Reading

81 thoughts on “How to Review SRS Document and Create Test Scenarios – Software Testing Training on a Live Project – Day 2”

  1. Hi, I have 2+ year experience in manual testing…i planned to do automation testing tool course…so let me know which institute is good in bangalore..

    Reply
  2. @ivan: I missed answering your question- “Why do we need to version control the documents during the peer review” – The answer is, if it does not make sense for you to do that for your project, you dont absolutely have to. But in my opinion, all documents have to be track able, so that if a newer version proves to be unsatisfactory, we have a previous version to fall back on. It is just a precautionary measure.

    Reply
  3. Hi,

    It’s very useful. On Test-scenario file, I see the number of test cases of “TS_MI_MIM_01” is 20. How do you can know it ? Please explain.

    Thanks,
    Hung.

    Reply
  4. thanks for this information, really helpful. being a fresher in this industry without hands on experience its difficult.

    much appreciated.

    Reply
  5. Hi
    you are giving free live project “orange HRM” login credentials are invalid because when i given user name admin and pwd is admin is opened to the “orange HRM” web site but ur giving username is”Admin” (capital A is given you) but i am giving small Alphabetical username “admin”. so plz modify that issue….

    thanks for the live free project

    Reply
  6. At the end of the article there is link-

    QA Training Day 3: How to write SRS document from scratch.

    instead it should be

    QA Training Day 3: How to write Test Plan document from scratch.
    Thanks

    Reply
  7. Hi STH Team,You are doing a wonderful work in helping people learn about Software Testing.One Small Suggestion though(if you are not already implementing it).Please provide more examples for every concept you cover.We can make this website different from others,by providing more examples of the concepts that are being covered than others.I have visited other sites,similar to this one,but I find this site more appealing since it covers examples for the concepts explained.My only point is… Please take One Simple Example(for freshers to understand) and One Complex Example(again for freshers and experienced QAs) for every concept and explain them in detail.Also if you can provide more videos(in YouTube) and also Transcripts(in your website or in blogs or in YouTube),it would be Great.Thanks Again and ALL THE BEST.MAY GOD BLESS YOU ALL… 🙂

    Reply
  8. why didnt you used RTM after writting test scenario. we can create RTM after writting test scenarios rite ?

    Reply
  9. hello, I really do not understand reviewing all the lessons I still do not see the usefulness of the scenario test because in other templates of another tutorial they place it and from there the test cases start but in their test cases they do not use the scenario tests, In the same way, in the scenario tests and following the live tutorial, they state that TS_MI_01 has 3 cases of tests and when it goes to the test cases there are only 2.

    what he does is great and it helps a lot for those of us who want to enter the QA world but there are many confusing things, I think we have to follow an order of logic, here we are in “how to review the srs and create test scenarios “and the next one is like starting a srs from scratch and there one loses the sequence to my point of view maybe I’m wrong should be” how to create test cases, maybe with an explanation of “unit tests” and “integration tests” afterwards the execution of the cases of tests with the cases of integration then “the tests of the system” more or less so I think that the model goes in V

    Excuse me if you do not like my message, I just try to do the tutorial and I do not know how to start being new in this.

    regards

    gustavoamaza@hotmail.com

    Reply
  10. An excellent article. I have a question on test scenario topic # After completion of writing test scenario for a particular module and test cases are also created for that module, if there are some minor changes were been made in SRS document in future on that module how do we modify our excel sheet according to the changes ?

    say for example # a new sub function is added to a main function how do we add this sub function in the excel ?

    Reply
    • Simply, you will refer to the SRS version in “requirements, reference documentation” field or whatever its name according to your company. Then, you write a suitable test scenario.

      Reply
    • Hi Sandy,

      You will need to create versions. For example version 1.0 will include test scenarios that do not include the new tab.

      Version 2.0 will have a test scenario for the new tab functionality.

      Also your project manager will need to ensure if testing the new tab is out of scope.or not

      Reply
  11. se que esto sonara raro pero no entiendo, el escenario de prueba es lo mismo que los casos de prueba? luego de hacer los escenarios de pruebas tengo que hacer los casos de prueba? tenia entendido que escenarios de prueba es una variante de las pruebas de software donde se utilizan los escenarios para las pruebas. Los escenarios ayudan de una manera más fácil de probar los sistemas más complicados ejemplo
    Check the Login Functionality esto es un escenario de prueba y

    estos los casos de pruebas
    1. Check system behavior when valid email id and password is entered.
    2. Check system behavior when invalid email id and valid password is entered.
    3. Check system behavior when valid email id and invalid password is entered.

    escenario de prueba
    Check the Search Functionality
    casos de prueba
    check system behavior when field search is empty

    si me puede explicar se lo agradeceria

    Reply
  12. softwaretestinghelp.com/free-online-software-testing-qa-training-course/

    Is this kind of mini level project ???? or
    industrial level project ( a project in any of the software company) ?????

    Reply
  13. Hi, STH Team
    You guys are rocking.
    This article is really a big help for me.
    Keep doing this great work.
    Looking forward to you for some important QA articals.

    Reply
  14. Dear Swati & STH Team,

    This is an awesome way of explaining concepts.It is really helpful as you associate it with the real time scenarios and that is what makes STH stand out unique among other similar websites. Thank you Swati, Vijay and all STH Team 🙂

    Reply
  15. why do we need to have version controlling when a peer reviews… will test scenario goes through different versions until we make the correct changes. please validate.. some organizations dont have srs, we only have brd , what can be done when its difficult to capture the function requirments since brd is a descriptive non technical document. how we can approach such tough documents as a fresher. thank u so much for ur explanation swati, I was not sure how to start testing from the documents and after this class i got the perfect answer.. god bless u

    Reply
  16. Correct the following mistake..

    It should be ‘How to Write A Software Test Plan Document From Scratch’,

    Not ‘ How to write an SRS document from scratch. ‘

    Reply
  17. Hi Swati/STH Team
    This article is very useful for me .I have a doubt and wanted to know if the Test Scenario document is same as Requirement Traceability Matrix(RTM).Please clarify this

    Reply
  18. @ivan: sure, it is a challenge to create tests based on BRD, but in cases where documentation is limited or non-existent, talking to developers/BAs might be a good idea.

    Reply
  19. Hello,
    Can any1 help me write a test scenario on flight + hotel booking confirmation email using the 1st template. Ex. customer has made a booking, made the payment and click on Book now. Then received an email confirmation…’

    Thanks

    Reply
  20. I agree with venkatakrishna . “Awesome information, Thanks a lot. I have a question, How do we decide on no. of test cases required( In above Test scenarios doc, you have mentioned 20 test cases for validating edit field.) Can you explain. Thank you in advance.”

    Reply
  21. @AMV: a use case is created by the developers to describe the flow of the application – the actors, the normal flow, the alternate flow are all explained in detail in a use case.

    A test scenario is created and used by the QA team-testers. Test scenarios are merely one line pointers on “What” to test.

    Reply
  22. At the end of the Day 2 training the line that mentions what is next as Day 3 training the title mentioned is ‘QA Training Day 3: How to write SRS document from scratch.’. This should be ‘How to write Test Plan document from scratch.’

    Reply
  23. I am a fresher,Completed Manual testing course and now learning selinium,so can any one help me what are the most important things that i have to learn now,and what type of questions will be asked if i go to interviews.

    Please if any one knows tell me and help.

    Reply
  24. Hi, Thanks for the live QA project training!! I have a small doubt. I came across this term called”Use cases”. Can you tell me the difference between a Use Case and Test scenario?

    Reply
  25. Awesome information, Thanks a lot

    I have a question, How do we decide on no. of test cases required( In above Test scenarios doc, you have mentioned 20 test cases for validating edit field.) Can you explain.

    Thank you in advance.

    Reply
  26. Great work Swati, The explanations are clear and informative. No confusions in understanding the things. thanks. Awaiting for the next tutorial.

    Reply
  27. Hi Swati/STH Team,
    Really a great work out. This is really a great help for the starting people.
    Keep helping people like this and more, God will give the reward for the nice work and great help to the people.
    Also as mentioned by Madiraju, please add more examples.
    Thanks,
    Sunil

    Reply
  28. Great work STH and esp Swati.
    My question is what to write in the PASS/FAIL column for a test scenario. Some test cases may pass and some may fail.
    Thanks.

    Reply
  29. Hi, I really appreciate your effort.I think i am in love with testing now.Your articles made me a continuous reader of your website.
    Gr8 Work…
    God Bless u all…

    Reply
  30. I really love this site. Full of inspiring and information about software testing. Keep up the good work. One of your fan of this site. Cheers! 🙂

    Reply
  31. Hello,

    I want to know in Section 3.1.1 of test scenario it is given number of cases 20. I want to know it will be 20 cases? Please help.

    Regards
    Mahvish Fatima

    Reply
  32. Thanks! A great source for QA and amazing training! You’ve got a new and loyal fan! Keep up the great work! Thank you a ton!

    Reply
  33. I can’t download the documents from given URL. Please help me to get these documents ASAP. Because this is really important to my QA knowledge.

    Reply
  34. Great stuff! This article will help so many persons who are hunting for Testing Jobs in the industry.Thanks for your creative stuff.

    Reply
  35. The label of the link in this page should be changed from
    “A Training Day 3: How to write SRS document from scratch.”
    to
    “A Training Day 3: How to write testplan document from scratch”

    Reply
  36. @All: the most common question seems to be “How can we tell how many test cases a particular scenario will result in”- This depends on how many components on a screen we have -take personal info- there are many fields on the screen- each field has a set of valid/invalid values- so an approximation of nearly 20 Test cases is the closest we can get to.

    An important point is that: There is no reason to be accurate at this stage. Try to get to as close an estimation as we can.

    Reply

Leave a Comment