Training Day #3- How to write a Test Plan Document from Scratch and Writing Test Cases from SRS Document

What Is A Test Plan?

Test Plan is a dynamic document. The success of a testing project depends upon a well-written Test Plan document that is current at all times. Test Plan is more or less like a blueprint of how the testing activity is going to take place in a project.

Given below are a few pointers on a Test Plan:

#1) Test Plan is a document that acts as a point of reference and is only based on that testing is carried out within the QA team.

#2) It is also a document that we share with the Business Analysts, Project Managers, Dev team, and the other teams. This helps to enhance the level of transparency of the QA team’s work to the external teams.

#3) It is documented by the QA manager/QA lead based on the inputs from the QA team members.

#4) Test Planning is typically allocated with 1/3^rd of the time that takes for the entire QA engagement.  The other 1/3^rd is for Test Designing and the rest is for Test Execution.

#5) This plan is not static and is updated on an on-demand basis.

#6) The more detailed and comprehensive the plan is, the more successful will be the testing activity.

Components Of A Plan Document

Items in a Test Plan Template	What do they contain?
Scope =>	Test Scenarios/Test objectives that will be validated.
Out of scope =>	Enhanced clarity on what we are not going to cover
Assumptions =>	All the conditions that need to hold true for us to be able to proceed successfully
Schedules =>	Test Scenario prep Test Documentation- test cases/test data/setting up environment Test Execution Test Cycle- how many cycles Start and End date for cycles
Roles and Responsibilities =>	Team members are listed Who is to do what module owners are listed and their contact info
Deliverables =>	What documents(test artifacts) are going to produce at what time frames? What can be expected from each document?
Environment =>	What kind of environmental requirements exists? Who is going to be in charge? What to do in case of problems?
Tools =>	For Example, JIRA for bug tracking Login How to use JIRA?
Defect Management =>	Risks are listed Risks are analyzed- likelihood and impact is documented Risk mitigation plans are drawn
Exit criteria =>	When to stop testing?

How to write the Test Cases from the SRS document?

Basics Of Writing Test Cases

#1) If Test Scenarios were all about, “What we are going to test” on the AUT – the test cases are all about “How we are going to test a requirement”.

For Example, if the test scenario is “Validate the Admin login functionality” – This would yield in 3 test cases (or conditions) – Login (successful), Login-unsuccessful when the incorrect username is entered, Login-unsuccessful when the incorrect password is entered. Each test case would, in turn, have steps to address how we can check a particular test condition is satisfied or not.

#2) The input to create a test case document is FRD, Test scenarios created in the earlier step and any other reference documents if present.

#3) The test case documentation is an important deliverable by the QA team and is shared with BA, PM, and other teams when done for their feedback.

#4) Work is divided among the team members and each member is going to be responsible for creating test cases for a certain module or a part of a certain module.

#5) Just like with the test scenarios, before we begin Test case documentation, a common template has to be agreed upon. Practically anything can be used to create test cases. The most often used choice is MS Excel or any test case writing tool

Standard Fields of a Sample Test Case Template

There are certain standard fields that need to be considered while preparing a Test case template.

Several standard fields for a sample Test Case template are listed below.

Test case ID: Unique ID is required for each test case. Follow some conventions to indicate the types of the test. For Example, ‘TC_UI_1’ indicates ‘user interface test case #1’.

Test priority (Low/Medium/High): This is very useful during test execution. Test priorities for business rules and functional test cases can be medium or higher, whereas minor user interface cases can be of a low priority. Testing priorities should always be set by the reviewer.

Module Name: Mention the name of the main module or the sub-module.

Test Designed By Name of the Tester.

Test Designed Date: Date when it was written.

Test Executed By Name of the Tester who executed this test. To be filled only after test execution.

Test Execution Date: Date when the test was executed.

Test Title/Name: Test case title. For example, verify the login page with a valid username and password.

Test Summary/Description: Describe the test objective in brief.

Pre-conditions: Any prerequisite that must be fulfilled before the execution of this test case. List all the pre-conditions in order to execute this test case successfully.

Dependencies: Mention any dependencies on other test cases or test requirements.

Test Steps: List all the test execution steps in detail. Write test steps in the order in which they should be executed. Make sure to provide as many details as you can.

Test Data: Use of test data as an input for this test case. You can provide different data sets with exact values to be used as input.

Expected Result:  What should be the system output after test execution? Describe the expected result in detail including the message/error that should be displayed on the screen.

Actual result: The actual test result should be filled after test execution. Describe the system behavior after test execution.

Status (Pass/Fail): If the actual result is not as per the expected result, then mark this test as failed. Otherwise, update it as passed.

Notes/Comments/Questions: If there are any special conditions to support the above fields, which can’t be described above, or if there are any questions related to expected or actual results then mention them here.

Test Type/Keywords: This field can be used to classify tests based on test types. For Example, functional, usability, business rules, etc.

Requirements: Requirements for which this test case is being written. Preferably the exact section number in the requirement doc.

Attachments/References: This field is useful for complex test scenarios in order to explain the test steps or expected results using a Visio diagram as a reference. Provide a link or location to the actual path of the diagram or document.

Automation? (Yes/No): Whether this test case is automated or not. It is useful to track automation status when test cases are automated.