Unit Testing: Severity List

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 3

Unit Testing Unit Testing is done to check whether the individual modules of the source code is working properly.

i.e Testing each and every unit of the application separately by the developer in developers environment. Unit Testing is conducted by the Developer during code development process to ensure that proper functionality and code coverage have been achieved by each developer both during coding and in preparation for acceptance into iterations testing. The following are the example areas of the project must be unit-tested and signed-off before being passed on to regression Testing: Databases, Stored Procedures, Triggers, Tables, and Indexes NT Services Database conversion .OCX, .DLL, .EXE and other binary formatted executables

Explain the different types of Severity. User Interface Defects Low Boundary Related Defects Medium Error Handling Defects Medium Calculation Defects High Interpreting Data Defects High Hardware Failures & Problems - High Compatibility and Intersystem defects- High Control flow defects High Load Conditions (Memory Leakages under load testing) High
The tester entering a bug into GForge is also responsible for entering the bug Severity.

Severity List
Severity ID Severity Severity Description
The module/product crashes or the bug causes non-recoverable conditions. System crashes, GP Faults, or database or file corruption, or potential data loss, program hangs requiring reboot are all examples of a Sev. 1 bug. Major system component unusable due to failure or incorrect functionality. Sev. 2 bugs cause serious problems such as a lack of functionality, or insufficient or unclear error messages that can have a major impact to the user, prevents other areas of the app from being tested, etc. Sev. 2 bugs can have a work around, but the work around is inconvenient or difficult. Incorrect functionality of component or process. There is a simple work around for the bug if it is Sev. 3. 1 Critical Level

2 High

3 Medium

4 Minor

Documentation errors or signed off severity 3 bugs.

Priority List
Priority Priority Level ID 5 Must Fix
4 Should Fix

Priority Description
This bug must be fixed immediately; the product cannot ship with this bug. These are important problems that should be fixed as soon as possible. It would be an embarrassment to the company if this bug shipped. The problem should be fixed within the time available. If the bug does not delay shipping date, then fix it. It is not important (at this time) that these bugs be addressed. Fix these bugs after all other bugs have been fixed. Enhancements/ Good to have features incorporated- just are out of the current scope.

3 Fix When Have Time 2 Low Priority

1 Trivial

What is Entry and Exit Criteria in Software Testing? The Entry Criteria is the process that must be present when a system begins, like, SRS Software FRS Usecase Test Case Test Plan The Exit Criteria ensures whether testing is completed and the application is ready for release, like, Test Summary Report Metrics Defect Analysis Report.

The load testing process involves the following steps: 1. Identify key scenarios. Identify application scenarios that are critical for performance. 2. Identify workload. Distribute the total application load among the key scenarios identified in step 1. 3. Identify metrics. Identify the metrics that you want to collect about the application when

running the test. 4. Create test cases. Create the test cases where you define steps for executing a single test along with the expected results. 5. Simulate load. Use test tools to simulate load according to the test cases and to capture the result metrics. 6. Analyze the results. Analyze the metric data captured during the test.

The current guidelines on response times have split into faster response times for broadband users (3-4 seconds) and slower response times for dial-up users (on the order of 8-10 seconds).

You might also like