Writing Test Cases From SRS Document 

Just to repeat what we have been doing up to this point – we are functioning as we would prefer through the Product Testing Preparing small scale seminar on a live venture OrangeHRM.

In this free online QA training series so far, we are done with: 

  1. SRS review,
  2. Test Scenario/Test Scope identification and
  3. Documented the Test Plan.

Now, we have reached the part that is the real deal, the test cases.

As demonstrated in the article before this: Experiments are archived by the QA group while the Code period of the SDLC is going on. All in all, while the Dev group fabricates the product framework, the testing group prepares with the experiments that would assist us with testing the framework once it is prepared, for example toward the finish of the code stage.

Thus, in the present article, we will deal with understanding what experiments are, the means by which to make them and compose a couple of test experiments for our live undertaking.

Let us get to it right away.

Table of Contents: [Show]

Basics Of Writing Test Cases

1) In the event that Test Situations were about, “What we will test” on the AUT – the experiments are about “How we will test a prerequisite”.

For Instance, assuming that the test situation is “Approve the Administrator login usefulness” – This would yield in 3 experiments (or conditions) – Login (effective), Login-fruitless when the mistaken username is placed, Login-ineffective when the wrong secret word is placed. Each experiment would, thusly, have moves toward address how we can check a specific test condition is fulfilled or not.

2) The contribution to make an experiment report is FRD, Test situations made in the prior step and some other reference records if present.

3) The experiment documentation is a significant deliverable by the QA group and is imparted to BA, PM and different groups when accomplished for their criticism.

4) Work is split between the colleagues and every part will be liable for making experiments for a specific module or a piece of a specific module.

5) Very much like with the test situations, before we start Experiment documentation, a typical format must be settled upon. Basically anything can be utilized to make experiments. The 2 most frequently utilized decisions are MS Succeed and MS word.

6) The MS word format looks something like this:

#7) The Excel template could look like the following:

#8) From the above two templates, it can be observed that the fields (or the components) that make up for a test case are the same, the only difference is the way in which they are organized.

So, as long as there is a field for each of the types of information to be included in a test, the format of the template does not matter. However, my personal favorite happens to be the excel sheet, because it is easy to expand, collapse, sort, etc. But again, choose any format that works best for you.

Fields In Test Cases

Let us take a moment, to observe the fields that are part of a test case.

Test case Id and Test case description are the generic ones.

The other fields can be explained as follows:

  • Precondition: State of the AUT (the state in which the AUT needs to be for us to get started).
  • Input: Data entry steps. For these steps, it is important to note what kind of input info is required – Test data.
  • Validation point/trigger/action: What is causing the validation to happen? (Click of a button or toggle or the link access. Make sure there is at least one validation point to a test case- otherwise it is all going to be data entry with nothing to look for. Also to ensure that we have enough modularity, try not to combine too many validation points into one test case. 1 per test case is optimum.)
  • Output: Expected result.
  • Postcondition: This is additional information that is provided for the benefit of the tester, just to make the test case more insightful and informative. This includes an explanation of what happens or what can be expected of the AUT once all the test case steps are done.

See Also => Sample Test Case Template

Live Project Sample Test Cases (Download)

Now that we have enough background information to get started on the test case creation process, let us get going and create few test cases for our Live Project.

Based on the process mentioned above we have created some sample test cases for the OrangeHRM account module.  These should give you an exact test case format and idea on how to approach writing test cases.

=> Download Sample Test Cases Document for our Live Project here.

Note: There are few images referred to sample test cases XLS document. If you are viewing this on the older MS Office version, you may face compatibility issues.

We have listed those images below as per their names in the XLS files:

Test Cases Writing/Optimization Methods

Now, imagine a situation where a certain page has a few 10’s of fields on it or has a complex business logic that is implemented in there. To make sure that we optimize the test case creation process in situations like that, we testers have certain Test case optimization methods.

Enlisted below are the links that are provided for more information on these methods.

Using the above techniques and following the general test case creation process, we create a set of test cases that would effectively test the application on hand.

Few Important Points To Be Noted

  • The test cases we create are not only the point of reference for the QA phase but also to the UAT.
  • Internally test cases are Peer-reviewed within the team.
  • When a certain situation is not addressed by a test case – the rule of thumb is, it is not going to get tested. So, this is a good place to check whether the test suite we created achieves the 100% test coverage goal or not. To do so, a traceability matrix can be created. Check out all there is to know about the Traceability matrix here.
  • Tools – Test management tools like QCqTest help us with the test case creation activity. For an example of how test cases can be dealt with using Quality Center, check out this Quality Center tutorial.
  • Automation tools can be used to create test cases- in which case, they are referred to as, Test scripts.

Pro Tip: Please perform a spell and grammar check on each and every document we create. We are the quality representatives for IT projects – and it doesn’t reflect positively on us if our deliverables themselves are of inferior quality.

That brings us to the finish of another interesting segment.

Conclusion

The end of the test creation process/test design phase (STLC) and the end of the Code phase (SDLC) will generally mark the end of the test preparation phase and the beginning of the Test execution phase.

Next tutorial in this Software Testing Course – In the coming article, we will talk about what Test Execution is, what it includes and what are the expectations from the QA team during this phase.

YOU MAY BE INTERESTED IN

The Art of Software Testing: Beyond the Basics

Automation testing course in Pune

Automation testing in selenium

Mastering Software Testing: A Comprehensive Syllabus

Scroll to Top