3) Test Cases Development:-
To develop the test cases every company will follow the test cases template based on the template we have to write the test cases.
We are going to use the below test case template to develop or prepare the test cases.
Or
1) Module Name:–
The module name for which we are writing the test cases will be described here.
Ex: Menu Bar, Login, Create Account, Logo, Slideshow, Search, and Services.
2) Requirement ID:–
The req id number for which we are writing the test cases will be mentioned here.
3) Test Type:–
Test types are also known as test cases types we have below types of test cases.
1) UI
2) Functional – [+ Positive or – Negative]
3) Validation Test Cases
4) DataBase Test Cases

4) Priority:–
When we plan to write test cases for any requirement we have to apply all 4 types of test cases [if possible]
1) P1 / Priority 1
2) P2 / Priority 2
3) P3 / Priority 3
4) P4 / Priority 4

P1 / Priority: –
If the test case is described above the Main Functionality, then it comes under the P1 test case.

P2 /Priority:-
If the test case is describing the field level, then it is the P2 test case.

P3 / Priority:-
All the UI test cases are P3 test cases.

P4 / Priority: –
If the test engineer is planning to provide any suggestion to the application, then he can write test scenarios and the priority of P4.
5) Test Case Id:–
The serial number of the test case will be noted here.

6) Test Scenario:–
Scenario means a story or flow of the requirements will be divided into multiple possible flows is nothing but the test scenarios.

7) Precondition:–
The condition which is required to execute the test scenario is known as a precondition.

8) Test Cases / Test Steps:–
The list of detailed steps which are required to execute the test scenario will be described here.

9) Expected Result:–
While writing the test cases we won’t be having any kind of application. So we will expect some results for the specific scenario.

10) Actual Result:–
While executing the test cases on the build(application), the actual behavior of the application for the specific scenario will be described here.

11) Result:–
While executing the test cases we will compare the Actual results with the Expectation result, if both are matching then we will update the result as Pass, if both are not matching then we will update the result as Fail.

12) Remarks / Comments:-
We have to write any comments or descriptions provided in this section.

Test Case Execution & Result Analysis: – 

Whenever the build is released the testing team (Deployment Engineer) will deploy the build in the test environment.

The testing team will perform the smoke test on the build if it is passed then they will execute all the test cases on the build.

While executing they will observe the actual behavior of the application for each scenario and update the actual behavior under the actual result field.

If the Actual result and Expected result match, then they will mark as Pass in result confirm.

If it is not matching, then they will update then the result as Fail in the result column.

Reporting:- 

Once the test case execution is done the test engineer has to capture all the fail test cases then the fail test cases need to be sent to the developer.
Reporting is two ways.

1) Report the bug by using Excel / Word Documents – Files manually

2) Report the bug by using Bug/Defect Tracking Tools

1) It is a very old approach, the test engineer will take the bug tracking sheet template and update the bug in the specific template, and send that excel file to the developer.

It contains the below field in the excel file.

1) Bug ID

2) Bug Title/Bug Summery

3) Status

4) Severity

5) Priority

6) Bug Description / Steps to reproduce

7) Screenshot

8) Build Version

9) Due Date

10) Reported By

11) Assigned To

12) Comments 

1) Bug ID:-

It contains the serial no of the Bug.

2) Bug Title / Bug Summary:-

The actual result of the field. A detailed bug summary of the field will be described here.

3) Status:-

The bug will be having the below status.

· New

· Open

· Fixed

· Reopen

· User Error / Not a Bug

· Closed

 

· New: –
Whenever the test engineer is identified the bug initially then the status of the bug is “New”. 

· Open: –
The new bug will be sent to the developer will check whether it is really a bug or not?

If it is really a Bug then he will update the status from “New” to “Open”.

· Fixed: –

All the open bugs will be fixed by the developer. If it is working properly then the developer will update the status from Open to Fixed.

· Reopen: –

All the fixed bugs will send to the testing team. Test engineers will check whether the bug is really fixed or not?

If it is not fixed, then he will update the status from Fixed to Reopen.

Reopen bugs will send to the developer.

· User Error/ Not a Bug: –

The bug reported by the test engineer is invalid. Then the developer will mark it as User Error/Not a Bug and send a bug to the test engineer.

· Closed: –

The test engineer will validate all the fixed bugs, if all the fixed bug is working properly then he will update the status as Closed.

Closed status is the end of the bug means the bug will be removed from the list. 

4) Severity: –

Each & Every bug will be having a severity it is describes how seriously the bug is impacting the application.

Severity is having below types.

    •  Blocker
    • Very High / Critical
    • High / Major
    • Medium / Minor
    • Low / Trivial

 · Blocker:-

If the bug is blocking that testing of the specific module, then the severity of the bug is a blocker.

The developer has to take more attention to the blocker bugs (Developer has fixed them immediately)  

· Very High / Critical: –

If the bug is blocking the partial testing of the specific module, then the severity of the bug is very high.

· High / Major: –

If any fields are missing and it is not blocking in any of the modules then the severity of the bug is High.

· Medium: –

All the GUI bug comes under medium severity. 

· Low / Trivial: –

If any suggestions are there for the application, then we can report the suggestion as a low severity bug. 

5) Priority: 

It describes the order to fix the bugs.  

It is below types.

    • P1 / Priority1
    • P2 / Priority2
    • P3
    • P4
    • P5

➮ P1: –

P1 bugs need to be fixed initially then P2, P3, P4, P5 

We will maintain the priority for each bug based on the severity. 

Blocker – P1
Very High – P2
High – P3
Medium – P4
Low – P5

Note: – 

Priority will be given by the test engineer but in some situations, the development lead can change the priority.

6) Bug Description / Step to Reproduce: –

The test engineer will provide the detailed steps to generate the bug.

7) Screenshot:-

To prove the report bug is valid then we can take the screenshot and the screenshot can be sent to the developer.

 8) Build Version:-

The build number on which we have identified the bug will be mentioned here. 

9) Reported By:-

The test engineer name who identify the bug will be mentioned here.

10) Assigned To:-

The developer name who is going to fix the bug will be mentioned here.

11) Comments:-