Software Quality

Defect Life Cycle which is also called as Bug Life Cycle. Below is what we cover in this post:

• Defect Status
• Defect Status Explanation
• Different Flows of Defect
• Defect Life Cycle Implementation Guidelines

Defect Status:

• New
• Open
• Assign
• Test
• Verified
• Deferred
• Reopened
• Duplicate
• Rejected
• Closed

Defect Life Cycle

Defect Status Explanation:

New:

When the bug is posted for the first time, its state will be “NEW”. This means that the bug is not yet approved.

Open:

After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state as “OPEN”.

Assign:

Once the lead changes the state as “OPEN”, he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to “ASSIGN”.

Test:

Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to “TEST”. It specifies that the bug has been fixed and is released to testing team.

Deferred:

The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.

Rejected:

If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “REJECTED”.

Duplicate:

If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “DUPLICATE”.

Verified:

Once the bug is fixed and the status is changed to “TEST”, the tester tests the bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “VERIFIED”.

Reopened:

If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “REOPENED”. The bug traverses the life cycle once again.

Closed:

Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “CLOSED”. This state means that the bug is fixed, tested and approved.

Different Flows of Defect:

• New — > Opened — > Fixed — >Closed
• New — > Opened — > Rejected — >Closed
• New — > Opened — > Fixed — >Re-opened — > Fixed –> Closed
• New — > Opened — > Deferred
• New — > Opened — > Rejected– >Re-opened — > Fixed –> Closed

Defect Life Cycle Implementation Guidelines:

• Make sure the entire team understands what each defect status exactly means. Also, make sure the defect life cycle is documented.
• Ensure that each individual clearly understands his/her responsibility as regards to each defect.
• If a defect tracking tool (i.e. JIRA, Rational Clear Quest, Bugzilla etc ) is being used, avoid entertaining any ‘defect related requests’ without an appropriate change in the status of the defect in the tool. Do not let anybody take shortcuts, else you will never be able to get up-to-date defect metrics for analysis.

Latest Posts

In this article, we will be covering following:

• About Priority and Severity
• Defect Severity Levels
• Defect Priority Levels
• Defect Priority and Severity Examples

Defect Priority & Severity:

Priority:

—  Importance of the bug is known as Priority/Urgency to fix a fault.

Severity:

—  Impact of the bug is known as Severity /Impact of a failure caused by  this fault.

Defect Severity Levels:

Critical / Show Stopper

— An item that prevents further testing of the product or function under test can be classified as Critical bug. No workaround is possible for such bugs. Examples of this include a missing menu option or security permission required to access a function under test.

Major / High

— A defect that does not function as expected/designed or cause other functionality to fail to meet requirements can be classified as Major Bug. The workaround can be provided for such bugs. Examples of this include inaccurate calculations; the wrong field being updated, etc.

Average / Medium

— The defects which do not conform to standards and conventions can be classified as Medium Bugs. Easy workarounds exists to achieve functionality objectives. Examples include matching visual and text links which lead to different end points.

Minor / Low

— Cosmetic defects which does not affect the functionality of the system can be classified as Minor Bugs.

Defect Priority Levels:

Low

— The defect is an irritant which should be repaired, but repair can be deferred until after more serious defect have been fixed.

Medium

— The defect should be resolved in the normal course of development activities. It can wait until a new build or version is created.

High

— The defect must be resolved as soon as possible because the defect is affecting the application or the product severely. The system cannot be used until the  repair has been done.

Priority and Severity Examples:

High Priority & High Severity:

— An error which occurs on the basic functionality of the application and will not allow the user to use the system. (Eg. A site maintaining the student details, on saving record, if it doesn’t allow to save the record then this is high priority and high severity bug.)

High Priority & Low Severity: 

— The spelling mistakes that happens on the cover page or heading or title of an application.

High Severity & Low Priority: 

— If  there is an application that crashes after multiple use of any functionality (example–save Button use 200 times then that application will crash). Means High Severity because application crashed but Low Priority because no need to debug right now you can debug it after some days.

Latest Posts

In this article, we will be covering following:

• What is Requirement Traceability Matrix (RTM)?
• Requirement Traceability Matrix – Parameters
• How to Create a Matrix?
• Mapping with Simple Example

What is Requirement Traceability Matrix (RTM)?

• RTM is a document that links requirements throughout the process of validation .
• It is to ensure that all requirements defined for a software are tested.
• It is a tool for the validation team to make sure that requirements are met during the validation of a software.
• Matrix is created at the beginning of project on the basis of the project’s scope and deliverable’s.
• It is bi-directional, as it tracks the requirement forward by examining the output of deliverable’s & backward by looking at the business requirement that was specified for a particular feature of the product.

Requirement Traceability Matrix – Parameters:

• Requirement ID
• Requirement Type (BRD and FSD)
• Risk
• Test Scenario ID
• Test Case ID
• Status
• Defects ID

How to Create a Matrix?

Requirement Phase

QA Team start writing Test Scenarios & eventually Test Cases based on some input documents – Business Requirements Document (BRD), Functional Specification Document (FSD) and Technical Design Document (optional).

Ex:- BRD & FSD

BRD	FSD
BRD	FSD

Design Phase

Based on the two input documents, below is the list of high-level scenarios to test:

TestScenarios_BRD

For each Test Scenario, you are going to have at least 1 or more Test Cases. So, include another column and write the Test Case IDs as shows below:

BRD_TC

At this stage, Traceability Matrix can be used to find gaps. For example, you see that there are no test cases written for FSD section 1.2 in the above Traceability Matrix.

As a general rule, any empty spaces in the Traceability Matrix are potential areas for investigation. So a gap like this can mean one of the two things:

• The test team has somehow missed considering the “Existing user” functionality.
• The “Existing user” functionality has been deferred to later or removed from the application’s functionality requirements.

If it is scenario 1, it will indicate the places where test team needs to work more to ensure 100% coverage. In scenario 2, TM not just show gaps it also points to incorrect documentation that needs immediate correction.

Execution Phase

Let us now expand the TM to include test case execution status and defects.

The below version of the Traceability Matrix is generally prepared during or after test execution:

BRD_Status

Latest Posts

This article isn’t only going to cover Test Cases Vs Test Scenarios but it will cover following:

• Real Time Examples
• Conditions for Documenting Test Cases
• Test Case And Test Scenario Example
• Difference Between Test Cases And Test Scenarios
• Conclusion of this Post

Few years back, when I was working in an MNC and dealing with a testing project, I suggested my colleagues to document the test Scenarios instead of test cases. Can you imagine, their reaction amazed me as they all were staring at me all together, I could not argue. It was like I have made a big mistake in my life. Everyone’s opinion was same except mine. They prefer to follow the traditional method of writing Test Cases and not Test Scenarios. Those who are newbies in this field might get confuse with the word Test Scenarios and Test Cases. This article will clear all doubts about it by giving real time examples and explanation.

Few years later, I Switched to another company and handled a testing project which was based on searching and generating different reports with the help of different menu options. We in a team were discussing about the project and how we can proceed with that? Actually, client wanted that project early and we were having deadline to complete the project. Considering my last experience about suggesting the documentation of Test Scenarios, I kept quiet and thinking of other idea. Suddenly, one of my colleagues raised his voice that “We should prepare Test Scenarios in a document”. This time, everyone was quite satisfied with his idea and we further started preparing the Test Scenarios. The conclusion of both cases suggests that preparing the Test Scenarios and Test Cases depends on the urgency and requirement of the project. Generally, in companies, test cases are prepared rather than documenting test scenarios.

Test Cases are replaced with Test Scenarios

As we all know nothing is permanent and with this concept, the software industries and their processes are also changing with time and cost constrains.

V-models and waterfall models which are considered to be traditional models are being replaced by iterative and agile models. In every testing project, document is indeed essential but to complete the project fast within the deadline and to make the process transparent and easy, the way of documentation is changed these days.

Following conditions are applicable for documenting Test Cases:

1. Client may ask for the same as part of his project
2. No Time constrain(But, I don’t think, it’s possible)
3. When software testers are fresher and new to the product.
4. When there is Company policy (I strongly have faith that it can be altered)

One of my experience will give you clear picture.

I was handling one of the testing projects from fortune 500 company and they didn’t give us any deadline to complete the project. That mean we were having flexible timelines to complete the project. We were already having template of test cases, and with the help of that we prepared the test cases and it got approved from client as well.

Once the development team finished their module, they were giving us to test it and most of our duty was to follow 100 test cases in a day. We used to document with pass/fail result, further sending it to the client at the end of the day. The project was really big and had different modules within it. To do the same process of documenting the test cases was a monotonous work for some of my colleagues. But at the end of the day, the company was generating revenue from it.

During the project, we had one break where we were not having any task of documenting the test cases. We were having a good time and I was discussing about new ideas and techniques so as make improvement in the existing test cases. I have found during that discussion that none of my colleague was interested in implementing those new ideas and techniques as they thought all the test scenarios is been covered already while making huge amount of test cases. No one was really interested in putting the efforts for new techniques as it a human mentality that we do not want to rework once the work is done. Our mind automatically stops making any efforts for any new ways and techniques for the past work. Same had happened with my colleagues and they just wanted to relax on that certain day.

It is also a fact that in IT companies, most of the testers follow the mechanical process of making the test case and no one really makes effort to make additional test case for the existing one? The same might have also happened with you, if I am not wrong.

Another experience:

While extensively involved in a team challenge activity, we were having a discussion and asked the team members to prepare the test scenarios for the product. We have all started to make the test scenarios and there was not a specific document where we would literally fill expected result and pre-condition for each test case. At the end of the day, we have collected almost 50 test scenarios and it was indeed a great experience while proceeding with that project.

Below example will make picture more clear:

Assume that you are having your website and it has features like username, password, and login page along with cancel button. If you were asked to write the test cases for the above features then your test case may exceed 50 and if you would ask to write the test scenarios, then it will be just a matter of lines. Below explanation will give you the exact idea about test scenario.

High Level Scenario:   Login Functionality
Low Level Scenarios:

1. To check Application is Launching
   2. To check contents text on login page
   3. To check Username field
   4. To check Password field
   5. To check cancel button and Login Button functionality

As we all are at short of time, test scenarios just acts as pain killer spray rather than that old time IODEX. And still the effect is same in both the case.

Finally, I would like to summarize difference as below:

Conclusion of this Post:

Test cases are most significant part of Software Testing Life Cycle which is also referred as STLC. With its absence, it’s tough to understand, track, follow and reason out something. But in the era of Agile, test cases are being substituted fast with test scenarios.

Database testing, GUI testing, functionality testing has the common test checklist which is coupled with modern artillery and test scenarios. With participation in trainings, Discussions, questions and practice one can definitely learn and change the final graph of Bug report matrix and your productivity.

Latest Posts

Following sample bug/defect report will give you precise clue of how to log bugs in a bug tracking tool. You can use any bug tracking tool for tracking the bug for your reference.

Below is the sample scenario which caused the bug:

Let’s say you have built a new application. Now, you want to create a new user with new information in the application. To achieve this, you should login and then navigate to USERS menu>New User and under that fill all the required details such as First Name, Last Name, Address, Age, Phone etc. After entering all the details you should save that info by clicking SAVE button. After this, you will get the message “New User has been created successfully”. This is the exact process that you should follow for creating new user in your website.

Log in and then navigating to USERS menu > New User you save all the info by clicking the SAVE button and BANG! You get an error message and system suddenly crashes down. At that moment, you should save that error message by capturing it and saving it into Microsoft paint file or wherever you feel comfortable.

This is actually a Bug scenario for a tester and he now needs to log that BUG into bug tracking tool. Different tools are used for tracking the BUG and some of them are JIRA, Bugzilla, IBM Rational Clear Quest etc.

How the bug is reported effectively in bug tracking tool?

Below is the sample bug report for above stated example :
(Note : ‘bug report’ fields vary depending on Bug Tracking Tool)

SAMPLE BUG REPORT:

Bug Name: Application crashed while clicking the SAVE button for creating a new user.
Bug ID: (It will be automatically created by the BUG Tracking tool once you save this bug)
Area Path: USERS menu > New Users
Build Number: Version Number 3.0.4
Severity: HIGH (High/Medium/Low) or 1
Priority: HIGH (High/Medium/Low) or 1
Assigned to: Developer-X
Reported By: Your Name
Reported On: Date
Reason: Defect
Status: New/Open/Active (Depends on the Tool you are using)
Environment: Windows 10/SQL Server 2008

Description :
Application crashed on clicking SAVE button for creating a new user, henceforth not able to create a new user in the application.

Steps To Reproduce:
1) Logon into the application
2) Navigate to the Users Menu > New User
3) Filled all the user information fields
4) Clicked on ‘Save’ button
5) Seen an error page “OWX847 Exception: Insert values Error…”
6) See the attached logs for more information (Attach more logs related to bug.. IF any)
7) And also see the attached screenshot of the error page.

Expected result: On clicking SAVE button, it should give a success message “New User has been created successfully”.

(Attach ‘application crash’ screen shot. IF any)

Save the defect/bug in the BUG TRACKING TOOL which you are using.  There, you will get a bug id that can be used further as a Bug reference.

Default ‘New bug’ mail will go to particular developer and the default module owner (Team leader or manager) for further action.

Latest Posts

For companies which are into Software Development, where we constantly strive for the delivery of the product. There comes a pressure for deadlines where managers & delivery heads are focusing on the delivery of the software at stipulated dates. Engineers are focusing on delivering stable software with a better efficiency. Considerably a customer uses its product in a random manner & finds a bug buried deeply, as there is no Software Testing is done.

Then, we are projecting a bad impression on to our clients. So in the transit of deadlines and of delivering the product at times of deadline. Are we compromising on quality?

Here is the time we use our most trusted weapon: ‘Software Testing’ which will help us in achieving a quality product within a strict deadlines while making our customers happy & delighted. By testing our products we can assure that we are providing a bug free quality product within the timelines which can be achieved by using the appropriate testing methodologies.

To support that, we have come up with following Software Testing Services which will help Software Development Companies to improve quality of their software and deliver the bug free product in the market:

• Functional Testing
• Performance Testing
• Mobile Testing
• Platform and Database Testing
• Component and Unit Testing
• SOA and Web services Testing
• QA Consulting and TCOE

As per market trend, need of Software testing is gradually increasing. Every company would like to launch bug free product in the market. Lets take a look at some of the facts of Mobile Applications:

FACTS

• Having bug in Mobile Apps is one reason for uninstalling an app
• Bug in an app is one reason of bad reviews on MarketPlaces
• 60% of users will stop using your app if it doesn’t load within 3 seconds.
• 32% of users will report a negative review if they face any crash.

Therefore, many startups and SMEs have started outsourcing testing of their products to dedicated Software Testing Companies.