Bug - Severity and Priority

Severity:It is the rating given to the bug based on how the bug is going to effect the functionality of the product/project we are building. How much deviation from the expected results and whether we can survive with the bug going forward or needs to get fixed before proceeding further.

Sev 1 Bug: This is bug is much like a stop stopper for the functionality and testing cannot be proceeded with this bug Active. This needs to be fixed for the testers to continue testing.
This is completely deviating from the expected functionality or would be leading to major issues in the product.
Example: System crashes when the user click on the Print button(major functionality of the product we are building) on a  web page.

Sev 2 Bug: This the deviation from the functionality. Major functionality breakage but still we would be able to continue testing the other functionalities of the Project/Product.
Example: Not able to submit the input page. But still able to do validation checks on the page and for time being workaround exists for user to navigate to other pages.

We cannot sign off on the products if we have Sev 1 and Sev 2 projects in Open Status.

Sev 3 Bug: This is a slight deviation from the functionality and of not much importance to consider. These would be some UI functionalities, features that do not much effect the flow of project.

Project can be signed off  even if they have Sev 3 bugs and which can later be taken known issue and can be considered to be fixed in next upcoming CR or a Bug fix drop.

Sev 4 Bug: These are the issues that could be a typo or product improvement suggestion. These consist of UI, Error messages/Validation checks etc.


Priority: This is the scale to define how to segregate the raised bugs to the concerned developer to fix the bug.And how much important the issue is to be fixed as early as possible.

When working on the bugs, priority helps the people to decide which work to take up first.

Priority 1: The bug needs to be fixed as soon as possible.
Priority 2: This bug needs to be taken care of to move to the next level.
Priority 3 and 4: The bugs can be handled later and some time can be taken as suggestion and can be implemented as a part of  future releases.

Priority and Severity for a bug is defined and set in the bug triage meetings.And this helps in segregating the bugs and taking the most important ones into consideration and maximum utilization of time and resource for the project to be finished with in the time lines.

Priority and Severity could change based upon the project/project we are building.

Test Plan Template

Here are some of the points that needs to be included in the Test Plan:

Table of Contents

1. Project Information
 1.1. Background
 1.2. Feature Complete Date
2. Assumptions and Test Approach
 2.1. Assumptions
 2.2. High Level Test Approach
 2.3. Out of Scope
3. Test Schedule
 3.1. Milestones Tracking
 3.2. Test Milestones Defined
  3.2.1. Milestone 0: Planning
  3.2.2. Milestone 1: Test Plan and Test Cases Creation
  3.2.3. Milestone 2: System Testing
  3.2.4. Milestone 3: UAT
 3.3. Escalation Patch Process
 3.4. Risks and Dependencies
 3.5. Test Status Reporting
4. System Overview
 4.1. Test Type Priority Levels
 4.2. Features to be tested
 4.3. Features Excluded from Testing
 4.4. Backend Testing Approach
5. Bug Reporting Tools and Methods
 5.1. Bug Reporting Tool Strategy
 5.2. Bug Classification Strategy
 5.3. Triage Strategy
 5.4. Bug Closure Criteria
6. Test Environment Needs / Setup
 6.1. Server Details
 6.2. Platform
7. Test Deliverables
8. Release Criteria
 8.1. Test Pass/Fail Criteria
 8.2. Pass / Fail Criteria
 8.3. Suspension Criteria for failed Acceptance Test
 8.4. Resumption Requirements
 8.5. UAT Entrance Criteria
9. Testing Staffing & Training Requirements
Appendix A: Document Change History
Appendix B: Extend Team Members
Appendix C: Glossary/ Definitions
Appendix D: Related Documents/References
Appendix E: Issues

Note: The Test Plan may differ from Project to Project /Company to Company.

Daily Status Report- Software Testing

Daily Status Report: A self explanatory report explaining all the activity status of the individual/team on a daily basis to showcase the work status.

This report will consists of following details:
Note: The Report may differ from Project to Project/Company to Company.

1. Total  Number of Test Cases
2. Number of Test Cases Executed for that day
3. Percentage of Test Cases Executed
4. Number of Test Cases Remaining.
5. Percentage of Test Cases Remaining for Execution.
6. Number of bugs Raised for that Day based on the Severity.
7. Total Number of Bugs.
8. Overall Status of Testing.(Include if anything is blocking and which needs to be addressed ASAP).

Can Also Include:
1. What is Planned for Today.
2. What is the overall status for Today.
3. What is the Plan for the Next Day
4. Start Date and End Dates of  Testing.
etc....

The Status Report can be in any format, in excel, or word etc but should be conveying the overall testing status for that day.

How to Write a Test Case

Before writing the test case we must have the knowledge on the functionality of the module for which the test case is being written, what is expected from the functionality, Navigation or flow of the functionality and Dependencies.

Steps to Write a Test Case:

Test Case Template Should Contain:

1. Test Case Title
2. Preconditions
3. Test Steps  
4. Expected Results
5. Background check points(if any)
6. Comments (If any).

Test Case Title: A brief statement about what the user/tester wants to test.
     Example: Verify the functionality submit button in the login site after entering valid user name and password.

Preconditions: Details containing:

• URL to access the application / program to test.
• Access Details like user name and password to use.
• Navigation details of the functionality to test.
• Pre-steps that needs to be taken to test the functionality.

Example:
1.  Open IE9 for the test.
2. From Tools remove the Pop up blocker
3. Valid User name and Password User name: Test1, Password: Password
Make sure that the login for the user already exists.

Test Steps: Step by Step navigation details for the user to follow to execute the test case.

Example:

1. Open the URL to test www.mail.yahoo.com in IE9.
2. Enter the valid User name and Password (as mentioned in Pro conditions)
3. Do not select "Keep me Sign in" option
4. Click for Submit button

Expected Results: The output by following the above steps as per the functionality of the system.

Example:

1. User should be able to login into the yahoo site.
2. Default main page should open with Inbox being highlighted and listing all the email from the inbox.

Background Check Points: If anything that gets logged in the DB along with query once the test case is executed(for cross verification).

Comments/Spl Notes: What other ways and environments the above test steps can be executed to get the expected Results.
Example: IE 7, Chroma, FireFox.
This is to avoid move number of test cases with the same condition in different environments.

Definition of Error, Defect, Issue, Bug

Error:A failure of a system to perform some action it has been designed to perform.It can be a mistake made by programmer.

Defect:The defect can be either a failure of a certain section of the code to function as expected could be because of a flaw in the design of the system.

Issue: Can be a suggestion for the improvement of software quality or usability prospective.This does

Bug:This is the deviation from the expected functionality. Extected outcome of the test cases does not match with the actual data/values and the test case fails.

Difference between Regression Testing and ReTesting

Regression Testing:

1.  Once a bug is fixed, testing in done on the application to make to no other functionality around this bug is broken because of the fix.
2. We need to identify the test cases that we need to be executed once the fix is done.
3. Once a Change Request(CR) is applied on the system, identified regression test cases need to be executed to make sure that because of the new functionality if any other existing functionalities get effected/broken.

Re-Testing:

1. Testing to ensure that the bug is fixed.
2. Once a bug is fixed, make sure that the test case associated with the bug gets executed and Passed.
3. Here testing is not done to check of any other functionality is broken because of the bug fix.

Software Testing - Basic Points

Few basic points that we need to know about Software Testing:

1. Software Development Life Cycle(SDLC).
2. Software Test Life Cycle(STLC).
3. Bug Life Cycle.
4. How to define Sevierity and Priority of the Bugs.
5. Entry and Exit Criteria for Testing.
6. What is a Business Requirment Document, Functional Requirment Documnet,Test Scenario, Test Case, Defect/Issue, Bug.
7. Type of Bugs.
8. Types of Testing-Unit Testing,Smoke/Sanitary Testing, Integration Testing, System Testing, Regression Testing , Re-Testing, Alpha and Beta Testing, UAT testing.
9. Test Environments-System Intergration Testing(SIT), User Acceptance Testing(UAT), Production.
10. Status Report Details and Prepartion.