Categorizing Defects by Severity

Introduction

What is Defect Severity?

Defect Severity or Bug Severity?

Some tips on finding the severity

Defect Classification by severity

Introduction

Is Testing an Art or Science? We have different answers for the above question, but certainly Testing is an Art while

determining the severity of a defect found in a system. The classification of impact of Defect is important for following

reasons:

It helps to determine the efficiency of Test Process.

It helps to decide the priority of the defect, hence improves overall development process by fixing higher priority

defects first.

The bug tracking process can be made more effective if the severity of the defect is clearly defined.

The focus of this paper is providing some ideas on Defect Severity and its classifications.

What is Defect Severity?

A defect is a product anomaly or flaw, which is variance from desired product specification. The classification of defect

based on its impact on operation of product is called Defect Severity.

Defect Severity or Bug Severity?

A bug is matured term of defect. A defect usually refers to as bug only if it affects operation of system and negatively

impacts the user of the system, while defect itself may not have any impact on operation of system. In other terms, all bugs

are defects but not all defects are bugs. Since severity classification also includes those anomalies, which doesn’t have any

impact on operation of system (like cosmetic errors etc.), it is appropriate to mention as Defect Severity rather than Bug

Severity.

Answer yourself the following before determining the severity

Following questions allows you to decide yourself the measure of severity.

• Does the system allow me to work even after defect occurs?


• Does the system recover from the defect by any means?


• If the defect is recoverable, does the system can do this on its own or any external effort is needed to recover from the
  
  defect?


• Did I check whether the same defect is reflected in all other related sections (or entire system)?


• Can I be able to repeat the defect in some other system having same configuration (O/S, Browsers etc.) as that of the
  
  system
• where I found the defect?


• Can I be able to repeat the defect in other configurations also?


• Does the defect affect only particular category of users or all?


• How frequently the defect occurs?


• Which inputs make the defect?

The severity level increases if the answer for some of the above question is ‘Yes’ and for some others ‘No’. For example,

if the answer for question 1 is ‘Yes’, then further testing of the system is not possible and hence severity is high. Also

the defect should be generalized as far as possible. i.e. after you find the defect, try to find out that the defect is

repeated in all cross-browsers, cross-O/S etc.

Some tips on finding the severity

Decide the impact

Some defects are obvious to decide its severity. For example, “HTTP error occurs when navigating to particular screen”.

Sometimes, a minor defect repeats in all sections or the frequency of such defect is more. In such cases, impact of the

defect is more in users perspective even though it is minor defect. Hence such defects get higher severity.

Isolate the defect

Isolating the defect helps to find out its depth of impact.

Analyze the defect with what class of inputs does the defect supports.

Make sure that the defect occurs only with particular sequence of operation or list out other sequences, which cause the

defect.

Defect Classification by severity

The impact of Defect Severity can be classified into four categories:

• Fatal
  
• Major
  
• Minor
  
• Cosmetic
  

Fatal Defects are the defects, which results in the failure of the complete software system, of a subsystem, or of a

software unit so that no work or testing can be carried out after the occurrence of the defect.

Major Defects are one, which also causes failure of entire or part of system, but there are some processing alternatives,

which allows further operation of the system.

Minor Defects does not result in failure but causes the system to produce incorrect, incomplete, or inconsistent results,

or the defect impairs the system usability.

Cosmetic Defects are small errors that do not prevent or hinder functionality.

Following are examples of type of Defects, which falls under each category.

Fatal Defects

1. Functionality does not permit for further testing.
   
2. Runtime Errors like JavaScript errors etc.
   
3. Functionality Missed out / Incorrect Implementation (Major Deviation from Requirements).
   
4. Performance Issues (If specified by Client).
   
5. Browser incompatibility and Operating systems incompatibility issues depending on the impact of error.
   
6. Dead Links.
   
7. Recursive Loop.
   

Major Defects

1. Functionality incorrectly implemented (Minor Deviation from Requirements).
   
2. Performance Issues (If not specified by Client).
   
3. Mandatory Validations for Mandatory Fields.
   
4. Images, Graphics missing which hinders functionality.
   
5. Front End / Home Page Alignment issues.
   

Minor Defects

1. Screen Layout Issues
   
2. Spelling Mistakes / Grammatical Mistakes.
   
3. Documentation Errors
   
4. Page Titles Missing.
   
5. Alt Text for Images.
   
6. Background Color for the Pages other than Home page.
   
7. Default Value missing for the fields required.
   
8. Cursor Set Focus and Tab Flow on the Page.
   
9. Images, Graphics missing, which does not, hinders functionality.
   

Cosmetic Defects

1. Suggestions
   
2. GUI image color etc.
   

Price Estimation

The total cost of the application has been decided by the following four factor's

1. prevention
2. Appraisal
3. Internal Failure Cost
4. External Failure Cost

Prevention
Costs of activities that are specifically designed to
prevent poor quality.
Poor quality include coding erros , design errors ,
mistakes in the user manuals & bad document.
Most of the prevention costs don't fit within the
testing group budget.

A. Staff training
B. Requirements analysis
C. Early prototyping
D. Fault-tolerant design
E. Defensive programming
F. Usability analysis
G. Clear specification
H. Accurate documentation

Appraisal
Designed to find quality problem such as code
inspections and any type of testing.
Design reviews are part prevention and part appraisal.

A. Design review
B. Code inspection
C. Glass box testing
D. Black box testing
E. Training testers
F. Beta testing
G. Test automation
H. Usability testing

Internal Failure Cost
Failure costs that arise before your company supplies
its product to the customer.

A. Bug fixes
B. Regression testing
C. Wasted in-house user time
D. Wasted tester time
E. Wasted writer time
F. Wasted marketer time
G. Wasted advertisements
H. Direct cost of late shipment
I. Opportunity cost of late shipment

External Failure cost

Failure costs that arise after your company supplies
the product to the customer.
External failure cost are huge. it is much cheaper to
fix problem before shipping the defective product
to customer.


A. Technical support calls
B. Preparation of support answer books
C. Refunds and replacement with updated product
D. Lost sales
E. PR work to soften drafts of harsh reviews
F. Lost customer goodwill

Test Estimation Process

The testing estimation process
In my opinion, one of the most difficult and critical activities in IT is the estimation process. I believe that it occurs because when we say that one project will be accomplished in a such time by a such cost, it must happen. If it does not happen, several things may follow: from peers’ comments and senior management’s warnings to being fired depending on the reasons and seriousness of the failure.

Before even thinking of moving to Systems test at my organization, I always heard from the development group members that the estimations made by the Systems test group were too long and expensive. Then, when I arrived at my new seat, I tried to understand the testing estimation process.

The testing estimation process in place was quite simple. The inputs for the process, provided by the development team, were: the size of the development team and the number of working days needed for building a solution before starting systems tests.

The testing estimation process said that the number of testing engineers would be half of the number of development engineers and one third of the number of development working days.

A spreadsheet was created in order to find out the estimation and calculate the duration of tests and testing costs. They are based on the following formulas:

Testing working days = (Development working days) / 3.

Testing engineers = (Development engineers) / 2.

Testing costs = Testing working days * Testing engineers * person daily costs.

As the process was only playing with numbers, it was not necessary to register anywhere how the estimation was obtained.

To exemplify how the process worked, if one development team said that to deliver a solution for systems testing it would need 4 engineers and 66 working days then, the systems test would need 2 engineers (half) and 21 working days (one third). So, the solution would be ready for delivery to the customer after 87 (66+21) working days.

Just to be clear, in testing time, it was not included the time for developing the test cases and preparing the testing environment. Normally, it would need an extra 10 days for the testing team.

The new testing estimation process
Besides being simple, that process worked fine for different projects and years. But, I was not happy with this approach and my officemates from the development group were not, either. Metrics, project analogies, expertise, requirements, nothing were being used to support the estimation process.

I mentioned my thoughts to the testing group. We could not stand the estimation process for very long. I, myself, was not convinced to support it any more. Then, some rules were implemented in order to establish a new process.

Those rules are being shared below. I know that they are not complete and it was not my intention for estimating but, from now, I have strong arguments to discuss my estimation when someone doubts my numbers.

The Rules
1st Rule: Estimation shall be always based on the software requirements
All estimation should be based on what would be tested, i.e., the software requirements.

Normally, the software requirements were only established by the development team without any or just a little participation from the testing team. After the specification have been established and the project costs and duration have been estimated, the development team asks how long would take for testing the solution. The answer should be said almost right away.

Then, the software requirements shall be read and understood by the testing team, too. Without the testing participation, no serious estimation can be considered.

2nd Rule: Estimation shall be based on expert judgment
Before estimating, the testing team classifies the requirements in the following categories:

• Critical: The development team has little knowledge in how to implement it;
• High: The development team has good knowledge in how to implement it but it is not an easy task;
• Normal: The development team has good knowledge in how to implement.

The experts in each requirement should say how long it would take for testing them. The categories would help the experts in estimating the effort for testing the requirements.

3rd Rule: Estimation shall be based on previous projects
All estimation should be based on previous projects. If a new project has similar requirements from a previous one, the estimation is based on that project.

4th Rule: Estimation shall be based on metrics
My organization has created an OPD, Organization Process Database, where the project metrics are recorded. We have recorded metrics from three years ago obtained from dozens of projects.

The number of requirements is the basic information for estimating a testing project. From it, my organization has metrics that guide us to estimate a testing project. The table below shows the metrics used to estimate a testing project. The team size is 01 testing engineer.

	Metric	Value
1	Number of testcases created for each requirement	4,53
2	Number of testcases developed by Working day	14,47
3	Number of testcases executed by Working day	10,20
4	Number of ARs for testcase	0,77
5	Number of ARs verified by Working day	24,64

For instance, if we have a project with 70 functional requirements and a testing team size of 2 engineers, we reach the following estimates:

	Metric	Value
	Number of test cases – based on metric 1	317,10
	Preparation phase – based on metric 2	11 working days
	Execution phase – based on metric 3	16 working days
	Number of ARs – based on metric 4	244 ARs
	Regression phase – based on metric 5	6 working days

The testing duration is estimated in 22 (16+6) working days. Plus, 11 working days for preparing it.

5th Rule: Estimation shall never forget the past
I have not sent away the past. The testing team continues using the old process and the spreadsheet. After the estimation is done following the new rules, the testing team estimates again using the old process in order to compare both results.

Normally, the results from the new estimate process are cheaper and faster than the old one in about 20 to 25%. If the testing team gets a different percentage, the testing team returns to the process in order to understand if something was missed.

6th Rule: Estimation shall be recorded
All decisions should be recorded. It is very important because if requirements change for any reason, the records would help the testing team to estimate again. The testing team would not need to return for all steps and take the same decisions again. Sometimes, it is an opportunity to adjust the estimation made earlier.

7th Rule: Estimation shall be supported by tools
A new spreadsheet has been created containing metrics that help to reach the estimation quickly. The spreadsheet calculates automatically the costs and duration for each testing phase.

There is also a letter template that contains some sections such as: cost table, risks, and free notes to be filled out. This letter is sent to the customer. It also shows the different options for testing that can help the customer decides which kind of test he needs.

8th Rule: Estimation shall always be verified
Finally, All estimation should be verified. I’ve created another spreadsheet for recording the estimations. The estimation is compared to the previous ones recorded in a spreadsheet to see if they have similar trend. If the estimation has any deviation from the recorded ones, then a re-estimation should be made.

Skills of a Tester’s Skull

Software Testing is one of the key practices in the Software Development Life Cycle that requires diversified skills. Because, developers find it difficult to find out the defects in their own code psychologically, the developers cannot test their code effectively. Hence, there arises the need for an Independent Testing Group, who approaches the code with a different perception to test them effectively.

Provided this scenario,

1) What are the unique skills required for the “Independent” Testers (which may or may not be required for a developer)?
2) What are the best practices that an “Independent” Tester need to adopt?

This paper tries to find out the answers for the above questions. Biologically, the skills and talents of a human being is managed by the brain and hence the title “Skills of a Tester’s Skull”. “Tester’s Skull” does not mean exactly the Skull of a tester; it is the Tester’s Brain inside the skull.

Understanding Skills

The first and foremost activity of Software Testing is to understand the requirements/ functionalities of the software to be tested. Formal Documents like Software Requirement Specifications, Software Functional Specifications, Use Case Specifications and other Documents like Minutes of Meeting serves as the key references for planning and executing the testing tasks. The testers must have very good understanding skills to read and understand the information written in these documents. Many a times, it is possible to have many interpretations for the information presented in the documents. The testers must be able to identify the duplicate & ambiguous requirements. If the requirements are not clear or ambiguous, the testers must identify the sources of the requirements and get them clarified. The sources of the requirements in most of the project development team should be Business Analysts, Business Users or any other competent authority as identified by the Project Management team. The testers shall analyze and co-relate the information gathered within the perspective of the project.

Listening Skills

Documents are not the only source of reference for the testing activities. The information required for the testing activities may be acquired through offline meetings, seminars, conferences, etc. The minutes of the meetings, conferences, seminars may or may not be recorded in a formal document. The testers must have very good active listening skills in order to collate and co-relate all of that information and refer them for the testing activities. While the requirements or functionalities of the software are discussed over a meeting, many a times, some part of the requirements are missed out. The testers should be able to identify and get them clarified before heading towards the subsequent testing phases.

Test Planning Skills

All software requirements shall be testable. The software shall be designed in such a way that all software requirements shall be testable. The test plan shall be formulated in such a way that paves the way for validating all the software requirements. In the real time scenario, there could be many requirements that are not testable. The tester with his/her test planning skills should be able to find out a workaround to test those non-testable requirements. If there is no way to test them, that shall be communicated clearly to the appropriate authority. There could be many requirements that are very complex to test and the tester should be able to identify the best approach to test them.

Test Design Skills

Software Testing Science preaches many techniques like Equivalence Class Partitioning, Boundary Value Analysis, Orthogonal Array and many more techniques for an effective test design. The testers shall be aware of all those techniques and apply them into their software test designing practice. The tester shall be aware of various formats and templates to author and present the test cases or test procedures in a neat fashion. The tester shall aware of the best practices and the acceptable standards for designing the test cases. The tester shall be aware of the how to write test cases – non-ambiguous, simple, straight to the point.

The test case needs to contain Test Case Description, Test Steps and its corresponding expected results. The tester shall be aware of how to present the content in these three topics effectively in such a way that they can be read without any ambiguity by all the project stakeholders.

Test Execution Skills

Test Execution is nothing but executing the steps that is specified in the test design documents. During the execution, the testers shall capture the actual results and compare against the expected results specified in the test design documents. If there are any deviations between the expected and actual results, the testers shall consider that as a defect. The tester shall analyze the cause of the defect and if it is found and confirmed in the application under test, the same shall be communicated to the developers and it shall get fixed. If the cause of the defect is found with the test case, the same shall be communicated to the test designers and the test cases shall be modified/ amended accordingly. If the testers are not confident about the application functionalities and the test design documents, they may not confidently come to a conclusion about the defect in case of any discrepancies. This will lead to defects being leaked to the next phase and the testers needs to avoid this scenario. The testers shall be confident about the application functionalities and in case of any ambiguity or clarifications; they need to get them sorted out before executing the tests or at least during the test execution.

Defect Reporting Skills

Defect Reports are one of the critical deliverables from a tester. The defect reports are viewed by the development team, business analysts, project managers, technical managers and the quality assurance engineers along with the testers. Hence, the defect reports shall carry enough information about the defect. Steps to reproduce the defect, its expected result and actual result along with other information such as Severity, Priority, Assigned To (developer), Test Environment details are very critical for a defect report without which, the defect report is considered as incomplete. The tester shall be aware of the importance of the defect report and he/she shall create defect report in such a way that it is non-ambiguous. During the course of fixing the defect, the developers may come back to the testing team for more information regarding the defect and the tester shall provide the same without failing.

Test Automation Skills

Test Automation is a wonderful phenomenon by which the testing cost is drastically reduced. The manual test cases upon automation can be executed by running the automated test scripts. This means that the manual effort to run those automated test cases is not necessary and hence the total test effort is reduced drastically. The testers shall be aware of the technique for adopting test automation into the current testing process. Identifying the test automation candidates is very critical for the success of the automation project. Automation candidates shall be identified in such a way that the testing cost towards manual test execution would reduce significantly. This involves lots of thoughts from the financial perspective as well. The testers shall understand the process of do’s & don’ts of automation to make the automation project successful.

Conclusion

The testers shall understand/ learn and be confident about the application functionalities. Test planning, designing, execution and defect reporting are the basic and essential skills that a tester shall possess and develop in his day-to-day career. Professionals who are perfectionist in using these skills are called as “Testing Professionals” or “Testers” or “Testing Engineers”. Hope now, you are a tester…

Article By
R. Sankara NarayananThe President,
Software Testing Society
http://www.stsociety.org/

Tel: +91-98840-65497
e-Mail: narayanansss@yahoo.co.uk