 Testing documents are prepared at different stages :

1. Before Testing:

 Since testing begins with the generation of the test cases. The following documents are required for reference –

 SRS document – Functional Requirements document.

 Test Policy document – It means the product must be tested far before release.
 Test Strategy document – It mentions detailed aspects of test the team, responsibility matrix, and rights/responsibilities of
the test manager and test engineer.
 Traceability Matrix document – This is SDLC document, that is related to the requirements-gathering process. As new
requirements come, they are added to this matrix. They can be traced forward and backward. These matrices help testers
know the source of the requirement.

2. During Testing:
 While testing is started and is being done, the following documents may be required.

 Test Case document – It contains the list of to-be tests. It includes various testing like Unit test plan, Integration test plan,
System test plan and Acceptance test plan.
 Test description – It is a detailed description of all test cases and procedures for executing them.
 Test case report – It contains a test case report resulting from the test.
 Test logs – It contains test logs for every test case report.
3. After Testing:
 After testing, only the test summary remains which is a collective analysis of all test reports and logs. The software is released
under the version control system if it is ready to launch.
 It summarizes and concludes whether the software is ready to launch.
 How to write Test Cases – Software Testing :
 Software testing is known as a process for validating and verifying the working of a software/application.
 It makes sure that the software is working without any errors, bugs, or any other issues and gives the expected output to the user.
 The software testing process isn’t limited to finding faults in the present software but also finding measures to upgrade the software in various factors such
as efficiency, usability, and accuracy.
 So, to test software the software testing provides a particular format called a Test Case.

 Table of Content :

 What is a Test Case?

 Test Case vs Test Scenario
 When do we Write Test Cases?
 Why Write Test Cases?
 Test Case Template
 Best Practice for Writing Test Case
 Test Case Management Tools
 Types of Test Cases
 What is a Test Case?
 A test case is a defined format for software testing required to check if a particular application/software is working or not.
 A test case consists of a certain set of conditions that need to be checked to test an application or software i.e. in more simple terms when conditions
are checked it checks if the resultant output meets with the expected output or not.
 A test case consists of various parameters such as ID, condition, steps, input, expected result, result, status, and remarks.

 Parameters of a Test Case:

 Module Name: Subject or title that defines the functionality of the test.
 Test Case Id: A unique identifier assigned to every single condition in a test case.
 Tester Name: The name of the person who would be carrying out the test.
 Test scenario: The test scenario provides a brief description to the tester, as in providing a small overview to know about what needs to be performed
and the small features, and components of the test.
 Test Case Description: The condition required to be checked for a given software. for eg. Check if only numbers validation is working or not for an age
input box.
 Test Steps: Steps to be performed for the checking of the condition.
 Prerequisite: The conditions required to be fulfilled before the start of the test process.
 Test Priority: As the name suggests gives priority to the test cases that had to be performed first, or are more important and that could be performed
later.
 Test Data: The inputs to be taken while checking for the conditions.
 Test Expected Result: The output which should be expected at the end of the test.
 Test parameters: Parameters assigned to a particular test case.
 Actual Result: The output that is displayed at the end.
 Environment Information: The environment in which the test is being performed, such as the operating system, security information, the software name,
software version, etc.
 Status: The status of tests such as pass, fail, NA, etc.
 Comments: Remarks on the test regarding the test for the betterment of the software.
Test Case vs Test Scenario :
• Below are some of the points of difference between a test case and a test scenario:

Parameter Test Case Test Scenario

A test case is a defined format for software testing required to The test Scenario provides a small description of what needs to
Definition check if a particular application/software/module is working or be performed based on the use case.
not. Here we check for different conditions regarding the same.

Level of detailing Test cases are more detailed with several parameters. Test Scenario provides a small description, mostly one-line
statements.

Action Level Test cases are low-level actions. Test scenarios are high-level actions.

Derived from Test cases are mostly derived from test scenarios. Test scenarios are derived from documents like BRS, SRS, etc.

Objective It focuses on “What to test” and “How to test”. It focuses more on ‘What to test”.

Resources required Test cases require more resources for documentation and Fewer resources are required to write test scenarios.
execution.

Inputs It includes all positive and negative inputs, expected results, They are one-liner statements.
navigation steps, etc.

Time requirement It requires more time compared to test scenarios. Test scenarios require less time.

Maintenance They are hard to maintain. They require less time to maintain.
 When do we Write Test Cases?
 Test cases are written in different situations:
 Before development: Test cases could be written before the actual coding as that would help to identify the requirement of
the product/software and carry out the test later when the product/software gets developed.
 After development: Test cases are also written directly after coming up with a product/software or after developing the
feature but before the launching of a product/software as needed to test the working of that particular feature.
 During development: Test cases are sometimes written during the development time, parallelly. so whenever a part of the
module/software gets developed it gets tested as well.
 Why Write Test Cases?
 Test cases are one of the most important aspects of software engineering, as they define how the testing would be carried
out. Test cases are carried out for a very simple reason, to check if the software works or not.
 There are many advantages of writing test cases:
 To check whether the software meets customer expectations: Test cases help to check if a particular module/software is
meeting the specified requirement or not.
 To check software consistency with conditions: Test cases determine if a particular module/software works with a given set
of conditions.
 Narrow down software updates: Test cases help to narrow down the software needs and required updates.
 Better test coverage: Test cases help to make sure that all possible scenarios are covered and documented.
 For consistency in test execution: Test cases help to maintain consistency in test execution. A well-documented test case
helps the tester to just have a look at the test case and start testing the application.
 Helpful during maintenance: Test cases are detailed which makes them helpful during the maintenance phase.
 Test Case Template :
 Let’s look at a basic test case template for the login functionality.
 The Test case template contains the header section which has a set of parameters that provide information about the test
case such as the tester’s name, test case description, Prerequisite, etc.
 The body section contains the actual test case content, such as test ID, test steps, test input, expected result, etc.
 Below is the table that shows the basic template of a test case:
Fields Description

Test Case ID Each test case should have a unique ID.

Each test case should have a proper description to let testers know what the test
Test Case Description
case is about.

Pre-Conditions Conditions that are required to be satisfied before executing the test case.

Mention all test steps in detail and to be executed from the end-user’s
Test Steps
perspective.

Test Data Test data could be used as input for the test cases.

Expected Result The result is expected after executing the test cases.

Post Condition Conditions need to be fulfilled when the test cases are successfully executed.

Actual Result The result that which system shows once the test case is executed.

Status Set the status as Pass or Fail on the expected result against the actual result.
 Project Name Name of the project to which the test case belongs.

Module Name Name of the module to which the test case belongs.

Reference Document Mention the path of the reference document.

Created By Name of the tester who created the test cases.

Date of Creation Date of creation of test cases.

Reviewed By Name of the tester who reviews the test case.

Date of Review When the test cases were reviewed.

Executed By Name of the tester who executed the test case.

Date of Execution Date when the test cases were executed.

Comments Include comments which help the team to understand the test cases.
 Best Practice for Writing Test Case :
 There are certain practices that one could follow while writing the test cases that would be considered beneficial.
 Simple and clear: Test cases need to be very concise, clear, and transparent. They should be easy and simple to understand not only for oneself
but for others as well.
 Maintaining the client/customer/end-user requirements must be unique: While writing the test cases, it’s necessary to make sure that they
aren’t being written over and over again and that each case is different from the others.
 Zero Assumptions: Test cases should not contain assumed data, and don’t come up with features/modules that don’t exist.
 Traceability: Test cases should be traceable for future reference, so while writing it’s important to keep that in mind,
 Different input data: While writing test cases, all types of data must be taken into consideration.
 Strong module name: The module name should be self-explanatory while writing the test case.
 Minimal Description: The description of a test case should be small, one or two lines are normally considered good practice, but it should give
the basic overview properly.
 Maximum conditions: All kinds of conditions should be taken into consideration while writing a test, increasing the effectiveness.
 Meeting requirements: While writing the test case the client/customer/end-user requirements must be met.
 Repetitive Results: The test case must be written in such a way that it should provide the same result.
 Different Techniques: Sometimes testing all conditions might not be possible but using different testing with different test cases could help to
check every aspect of a software.
 Create test cases with the end user’s perspective: Create test cases by keeping end-user in mind and the test cases must meet customer
requirements.
 Use unique Test Case ID: It is considered a good practice to use a unique Test Case ID for the test cases following a naming convention for
better understanding.
 Add proper preconditions and postconditions: Preconditions and postconditions for the test cases must be mentioned properly and clearly.
 Test cases should be reusable: There are times when the developer updates the code, then the testers need to update the test cases to meet
the changing requirements.
 Specify the exact expected outcome: Include the exact expected result, which tells us what will be result of a particular test step.
 Test Case Management Tools :
 Test management tools help to manage the test cases.
 These tools are automated tools that decrease the time and effort of a tester as compared to the traditional way.
 Some test case management tools include advanced dashboards, easier bug, and progress tracking as well as
management, custom test case templates, integration of test cases, inviting guest testers, managing team requirements
and plans, and much more.
 Below are some of the test case management tools:
 Testpad: Testpad is a simple tool that makes test case management easier. The software’s main motto says that it aims to
find a bug that matters. A few features of Testpad include manual testing, reports of the test cases and software, dragging
and dropping to make testing easier, inviting guest testers by email, building custom templates, and much more.
 TestCaseLab: TestCaseLab is easily manageable for the test cases and could swiftly integrate them with bug trackers. The
features of TestCaseLab include Custom test cases, Test Runs, Integrations of test cases, Test Plans, tags and priority for
test cases, search by name of test cases, description, tags, etc.
 TestRail: TestRail is another platform that aims to make test case management easier, it streamlines the software testing
processes and along with more visibility into QA. The basic features of TestRail include management for test cases, plans,
and runs, more test coverage, real-time insights into the QA progress, etc.
 TestLodge: TestLodge is a test case management tool that helps the entire team manage their requirements, test plans,
test cases, and test runs all in one single place and with no user limit. The basic features of TestLodge include Test Plans,
Test Runs, a Dashboard, a Test Suite, and many more.
 Formal and Informal Test Case :
 Formal Test Cases: Formal test cases are test cases that follow the basic test case format. It contains the test case parameters such as conditions, ID, Module
name, etc. Formal Test cases have set input data and expected results, they are performed as per the given order of steps.
 Informal Test Cases: Informal test cases are test cases that don’t follow the basic test case format. In these, as the tests are performed the test cases are
written in real-time then pre-writing them, and the input and expected results are not predefined as well.

 Types of Test Cases :

 Functionality Test Case: The functionality test case is to determine if the interface of the software works smoothly with the rest of the system and its users
or not. Black box testing is used while checking for this test case, as we check everything externally and not internally for this test case.
 Unit Test Case: In unit test case is where the individual part or a single unit of the software is tested. Here each unit/ individual part is tested, and we create
a different test case for each unit.
 User Interface Test Case: The UI test or user interface test is when every component of the UI that the user would come in contact with is tested. It is to test
if the UI components requirement made by the user are fulfilled or not.
 Integration Test Case: Integration testing is when all the units of the software are combined and then they are tested. It is to check that each component
and its units work together without any issues.
 Performance Test Case: The performance test case helps to determine response time as well as the overall effectiveness of the system/software. It’s to see
if the application will handle real-world expectations.
 Database Test Case: Also known as back-end testing or data testing checks that everything works fine concerning the database. Testing cases for tables,
schema, triggers, etc. are done.
 Security Test Case: The security test case helps to determine that the application restricts actions as well as permissions wherever necessary. Encryption and
authentication are considered as main objectives of the security test case. The security test case is done to protect and safeguard the data of the software.
 Usability Test Case: Also known as a user experience test case, it checks how user-friendly or easy to approach a software would be. Usability test cases are
designed by the User experience team and performed by the testing team.
 User Acceptance Test Case: The user acceptance case is prepared by the testing team but the user/client does the testing and review if they work in the
real-world environment.