Showing posts with label Bugs/ Defects. Show all posts
Showing posts with label Bugs/ Defects. Show all posts

Saturday 29 July 2017

Classification of Defects

Severity of Defects / Failures: Rating of defects can be done into four different levels according to the severity of the resulting failures.

The severity is the extent to which a defect causes a failure that degrades the expected operational capabilities of the system of which the software is a component. The severity is classified from the point of view of effect on business efficiency.

The software users, who discover the defects, are the best judges to classify the severity of the defect.
Following classification of defect severity assumes that the software remains operational.

A) Critical Defects: These are the extremely severe defects, which have already halted or are capable of halting the operation of a business system. It means the defect has stopped some business function thereby forcing the deployment of manual workaround procedures into the operation.
Example of critical defects can be

  • The software application refuses to run or stops in-between; 
  • Corruption of data
  • Serious impact on customer operations for which the customers is aware of the consequences.

B) Major Defects: These are also severe defects, which have not halted the system, but have seriously degraded the performance of some business function. Although this is also a failure, but the business operation continues at a lower rate of performance or disable only some portion of the business operation.

Example of critical defects in a financial application can be

Software allows the input of customer details but refuses to confirm the credit information. This affects the customer facing operation - although the customer may not be aware of it.

C) Minor Defects:

These types of defects are the ones, which can or have caused a low-level disruption of the system or the business operation. Such defects can result into user inefficiency. Although a software with a minor defect suffers from the failure, but it continues to operate. Such a disruption or non-availability of some functionality can be acceptable for a limited period.
Minor defects could cause corruption of some data values in a way that is tolerable for a short period. But the business operations continue despite some degradation in performance - although the business customer may not be aware of it.

D) Cosmetic Defects:

These types of defects are the ones, which are primarily related to the presentation or the layout of the data. However there is no danger of corruption of data and incorrect values.

Example of cosmetic defects are

Headings, Banners, Labels, or Colors are absent or badly chosen. These can be considered as a failure of the software product despite the software being completely operational.
Cosmetic defects have no real effect on the customer facing operations & many times the customers don't come to know of any degradation in performance. But cosmetic defects can cause frustration & annoyance among the users due to continued inefficiency of using such defective software.


Priority of Defects: When some defect is discovered, a suitable priority is assigned to it. This priority is an indication of the urgency with which the defect must be fixed.
Generally, defects of the greatest severity will be assigned the highest priority. However, due some overriding factors, a high priority may sometimes be allocated to even a minor or a cosmetic defect. For example a cosmetic defect in a presentation by the companies CEO can be assigned a high priority. Or sometimes, it is wise to club many easily resolvable, but low severity defects before undertaking fixing of a higher severity defect.


Different Levels of Priority:
1) Very Urgent: This priority is allocated to a defect that must be attended with immediate effect.
2) Urgent: This priority is allocated to a defect that must be attended to as early as possible generally at the next convenient break e.g. overnight or at the weekend.
3) Routine: This priority is allocated to a defect, fixing of which is scheduled by the next or some particular release of the software.
4) Not Urgent: This priority is allocated to a defect that may be rectified whenever it is convenient.

Tags: Software Testing, Software Quality, Software design defects, software data defects, quality Assurance, software defects

Root cause analysis


Let’s start with the “WHY?” questions, (The list is not limited). You can start from the outer phase and move towards the inner phase of SDLC.
How should I handle root cause analysis in software testing

It's important to take finding the root cause of a defect seriously in an Agile team using continuous improvement. Expert Amy Reichert explains how she narrows it down.
What is Root Cause Analysis?

Introduction:


RCA (Root cause analysis) is a mechanism of analyzing the defects, to identify its cause. We brainstorm, read and dig the defect to identify whether the defect was due to “testing miss”, “development miss” or was a “requirement or designs miss”.

Doing the RCA accurately helps to prevent defects in the later releases or phases. If we find, that a defect was due to design miss, we can review the design documents and can take appropriate measures. Similarly if we find that a defect was due to testing miss, we can review our test cases or metrics, and update it accordingly.

RCA should not be limited only to the testing defects. We can do RCA on production defects as well. Based on the decision of RCA, we can enhance our test bed and include those production tickets as regression test cases to ensure that the defect or similar kinds of defects are not repeated.

How Root Cause Analysis is Done?

There are many factors which provokes the defects to occur


  • Unclear / missing / incorrect requirements
  • Incorrect design
  • Incorrect coding
  • Insufficient testing
  • Environment issues ( Hardware, software or configurations)


These factors should always be kept in mind while kicking off the RCA process.

There is no defined process of doing RCA. It basically starts and proceeds with brainstorming on the defect. The only question which we ask to ourselves while doing RCA is “WHY?”and “WHAT?” We can dig into each phase of the life cycle to track, where the defect actually persists.

Key Benefits of Root Cause Analysis in Software Testing


  • Analysis of near-misses
  • Reinforcement of quality control
  • Continuous improvement
  • Early identification of risks
  • Enhanced Project management
  • Improvement in Performance Management



Failure Mode and Effects Analysis (FMEA)

This method derives the idea of Risk Analysis approach to identify points or areas where a system could fail.


  • Impact Analysis


This is yet another useful method which provides the facility to analyze the positive & negative impact of the change on different areas of the system or application which can be affected.


  • Kaizen or Continuous Improvement


Kaizen or CI provides significance to those in the organization who are able to identify the places for improvement. Based on the applied small changes or solutions, one can make the system better.


  • Identification of Defect Injected / Detected phase


The Defect Injected Phase (the phase in which the defect was injected) and the Defect Detected Phased (the phase in which the defect was identified) are two important aspects to be identified for any ideal tester. Identification of the found defect and the rectified defect is known as Defect Age.

What is Defect Based Testing Technique

Defect Based Software Testing Technique:

A defect based testing technique is a technique where test cases are derived on the basis of defects. Instead of using the traditional requirements documents or the use cases (Specification based techniques), this strategy uses the defects to base their test cases.

The categorized list of defects (called as defect taxonomy) is being used. The coverage using this technique is not very systematic, hence driving your test cases based on this technique only, may not solve the purpose of the quality deliverable. This technique can complement your test driving conditions and can be taken as one of the option to increase the coverage of testing. Or in some other sense – This technique can be applied when all the test conditions and test cases are identified and we need some extra coverage or insight into testing.


Defect based technique can be used at any level of testing, but it is best suited in Systems Testing. We should base our test cases from the available defect taxonomies as well. These defects can be the production ones or the historical ones. Root cause analysis can also be used to baseline your test cases.

The 5 step plan to write the test cases through defect based testing techniques can be:


  1. Identify and prioritize the requirements
  2. Identify and collect all the defects
  3. Brainstorm on the defect
  4. Link the defect to the requirement
  5. Write the test conditions/test cases based on the linked defects.

Tuesday 6 October 2015

What is bug leak or memory leak

What is bug leak or memory leak 

Bug Leak-: If something is missed out by developer and caught Tester.
Defect Leak-: If something is missed out by Tester and caught by client.
Memory Leak-:When we access the large amount of data from the database that require same amout of buffer memory, if data is exceeded the buffer memory then MEMORY LEAKAGE will happen.
Example-:If we need 100 data then it require same (100) buffer memory, if buffer memory is 99 then memory leakage will happen.

Describe the basic elements you put in a defect report

Describe the basic elements you put in a defect report

Bug means deviation from the requirements. i.e; an application which does not perform the operations as mentioned in the Requirements Document. So we have to report that to the developer. for that we use some tracking tool. in other sense it is called Bug Reporting Tool. which contains the following information.
1.Bug id
2.program name
3. version, release.
4.Type of the bug
5.attachments
6. severity
7.is it reproducible
8. steps for reproducing.
9.suggestion
10.Name of the Reporter
11. date. 

What do you do if developer not accepted the bug

What do you do if developer not accepted the bug?

1) First of all the developer will be concerntrating on the bugs depending on priority. He first fix the bugs of Critical or show stopper,then High priority, Medium and last the low priority bug. If the developer is not ready to fix the bug means may the bug is of low priority and he is concentrating on other priority bugs.
2) If the bug is not of low priority and even then he is not ready to fix means he didnt understand the bug clearly in that case the tester will sit with the developer and explains him the bug in detail with the help of step by step process how the bug occured.
3) If the developer doesnt have the time to fix as the project release is ahead and if that bug doesnt affect the main functionality in that case this bug as an known issue will be released. The testing team should take care of this known issue is fixed in next release of the project.

What are the defect severity and priority

What are the defect severity and priority ?

Priority :- How quickly we need to fix the bug? Or How soon the bug should get fixed?

Severity : - How much the bug is effecting the functionality of the application or how deadly can it be for the application under consideration.

Eg:-

(1) High Priority and Low Severity
If a company logo is not properly displayed on their website.

(2) High Priority and High Severity
Suppose you are doing online shopping and filled payment informations, but after submitting the form, you get a message like "Order has been cancelled." Normally high severity bugs comes with high priority.

(3) Low Priority and High Severity
If we have a typical scenario in which the application get crashed, but that scenario exists rarely.

(4) Low Priority and Low Severity
There is a mistake like "You have registered success" instead of successfully, success is written.Basically general spelling mistake kind of thing which is not expected.

Why does a software have bugs ?

Why does a software have bugs ?

There are many reasons for a software having errors
1. It may be poor documentation
2. If there are some enhancemnts which has not been designed as per the enhancements
3. The main reason is being human being make errors which leads to defect and which leads to failure of the application
4. Time pressure may be one constraint
5. If the application is not verifying the documents
6. Inavlid inputs may leads to give error
7. Programming errors .e.g. suppose a loop should start from i=0 to 100 ,but bymistakely the loop gets started from i=1.This leads to a error
8. Not properly following the documentation

Saturday 3 October 2015

Bugs / Defect

Defect Life Cycle Or Bug Life Cycle

Defect Life Cycle Or Bug Life Cycle

Defect:
A fault in a program, which causes the program to perform in an unintended or unanticipated manner.

Defect Life Cycle (Bug Life cycle) is the journey of a defect from its identification to its closure. The Life Cycle varies from organization to organization and is governed by the software testing process the organization or project follows and/or the Defect tracking tool being used.

1) New: When QA files new bug.

2) Assigned: Assigned to field is set by lead or manager and assigns bug to developer.

3) Could not reproduce: If developer is not able to reproduce the bug by the steps given in bug report by QA then developer can mark the bug as CNR. QA needs action to check if bug is reproduced and can assign to developer with detailed reproducing steps.

4) Need more information: If developer is not clear about the bug reproduce steps provided by QA to reproduce the bug, then he/she can mark it as “Need more information. In this case QA needs to add detailed reproducing steps and assign bug back to dev for fix.

5) Deferred: If the bug is not related to current build or can not be fixed in this release or bug is not important to fix immediately then the project manager can set the bug status as deferred.

6) Rejected/Invalid: Some times developer or team lead can mark the bug as Rejected or invalid if the system is working according to specifications and bug is just due to some misinterpretation.

7) Resolved/Fixed: When developer makes necessary code changes and verifies the changes then he/she can make bug status as Fixed and the bug is passed to testing team.

8) Reopen: If QA is not satisfy with the fix and if bug is still reproducible even after fix then QA can mark it as Reopen so that developer can take appropriate action.

9) Closed: If bug is verified by the QA team and if the fix is ok and problem is solved then QA can mark bug as Closed.