Create a Test Report in Software Testing
What is Test Case Report?
It is documentation that contains a complete test summary for a particular project component or complete project.
Test case report depends on the scenario and type of testing that will be performed application.
Test Case Report Provide complete details of the Testing operation by the QA team to the client and development team both.
Test case reports will be created using two different parts.
1) Design Test Case Report:-
Test Case Report Designed by SR Tester, they will prepare Test case Step, Test Case Description, Expected Result, etc.
They will prefer requirements details by FRS(Functional Requirement Specification) or SRS(Software Requirement Specification) documents.
2) Execute Test Case Report:-
The test case report designing part will be executed under the developed project and it will decide the test cases will pass or fail.
The client and developer both will review Test Report and view the Test LOG to monitor the bug.
The developer will open the bug then confirm the bug and again forward it to the testing team for Re-testing.
How to Create a Test Report?
We can create a Test Report using MS Excel, google docs, CRM Tools, or JIRA Software tools to represent a testing process.
We can create a Test Report using MS Excel, google docs, CRM Tools, or JIRA Software tools to represent a testing process.
Parameters of Test Report:-
TestReportID:- it will define an identity for a particular TEST REPORT, it will unquie and relate with the project.
Tester's name:- The name of QA member who will perform testing operations. if an individual then writes an individual name otherwise team name.
Application name:- The name of the application
Module name:- The name of the module of an application.
Version:- Version indicates a number of retesting processes. after retesting and modification on documents version can be changed.
Test Scenario:- It provides the title of the test case report
Test Cases ID:- It provides a unique id for all test case summary one by one.
Test Case Description:- It is also called a test case summary that provides a description of testing steps.
Application name:- The name of the application
Module name:- The name of the module of an application.
Version:- Version indicates a number of retesting processes. after retesting and modification on documents version can be changed.
Test Scenario:- It provides the title of the test case report
Test Cases ID:- It provides a unique id for all test case summary one by one.
Test Case Description:- It is also called a test case summary that provides a description of testing steps.
Test Data:- We will write data that will be used for testing. we should always use test data to implement form element testing.
Expected Result:- It will be implemented by SRS documents and provide client requirements for a particular test case.
Expected Result:- It will be implemented by SRS documents and provide client requirements for a particular test case.
Actual Result:- It will provide the outcome of test execution means it describes the result of a particular test case.
Test Result:- It provides a Test case result that test case execution is Pass or Fail.
Bug Priority:- It provides the strength of Bug that it is critical, High, Medium, and low.
Bug Priority:- It provides the strength of Bug that it is critical, High, Medium, and low.
Critical:- when a particular option is not working, suppose the URL is not opening then it is critical.
If the Login form does not work for a valid user id and password then it will be critical.
If any security lake then it is called critical.
High:- If the options present but not work and it is not affected by the application completely.
Forgot password option is present but not work then it will be High priority Bug.
Medium:- It is an average type of bug, mostly UI problem of an application measured by Medium type error. if form elements not validated properly that is also the part of medium type bug.
low:- It is an optional bug that is not mandatory for an application then we can provide low priority, for example, font-size, color combination mismatch, test case(upper, lower, proper case), etc Tester Comment:- tester can provide a detailed description of an error or suggestion.
Developer Comment:- developer can provide a detailed description of an error or suggestion.
Precondition:- it is the required data before testing implementation. for example, you have the details of login credentials before testing the login component.
browser compatibility, device, and os compatibility are also the part of pre-condition.
Post Condition:- it is used to provide information after test case completion. suggestions, extra link, screenshot link.
POST Answer of Questions and ASK to Doubt