Priority vs Severity: Defect

When its time to define and set values for Priority and Severity of a defect, the software tester some times gets a concern when the topic is not under control of he/she doesnt have any previous experience on this. The most frequent mistake is to define only the three common values "High, Medium & Low", but there must be an answer of "why those values?", when I should say this is High, and this Low.

Well, I will stop to talk on "Donts", the best practice for these values depends on the context of the methodology that it has being used, but you at least should try to find 5 values for Priority and 5 values for Severity.

According to the importante of the customer to get fix that bug/defect this must be translated to the Priority, and the impact on get this bug fixed on the code, must be transtaled in the severity.

Here I show you an example for those values:

Severity

1. Cosmetic Error
2. Partial Loss
3. Loss of functionality
4. Loss of Major functionality
5. Hard crash

Priority

1. Easy to fix.
2. Workaround for short term.
3. Workaround for long term.
4. Daily process impact
5. Daily process is down.

Then, you can get with these values the weight of the bug, by multiplying the value got on Severity and priority. i.e. if you get Priority = 2 and Severity = 3 the weight of the bug will be 6.

Enjoy it !! and use this information for your records.

DRE - Defect Removal Efficiency

One of the most popular SLAs in the software testing discipline is the DRE, why? well, because it measures our own effectiveness as area & process. In my own experience it has been used in large companies to measure the effectiveness of all testing done since unit test, integration test, function test, UAT and production, in that way you can measure what was not found on all these testing phases.

The formula to measure this indicator is:

DRE = (Defects found in my testing phase) / (Defects found in my testing phase + Defects not found in my testing phase)

Enjoy it !

SLA in an Ondemand Software Testing Factory

By rule of thumb, SLAs (Service Level Agreements) in an Ondemand Software Testing Factory (OSTF) must be defined upfront the Ondemand service starts. This is the way the client and the factory could know if the service both are expecting is in the right way, otherwise a tunning should be activated on the road.

First of all, a contract must be stated, and on this SLAs are defined (among other important things), all the game rules are stated here!, then a pilot project is defined and agreed, the pilot last the enough time to realize we are already to start, the client to send out the work, and the factory to work it remotely.

The SLAs that must be defined on an Ondemand Software Testing Contract are at least the following:

• JIT, Just in Time
• DRE, Defect Removal Efficiency
• OB, On Budget
• OTD, On Time Delivery
• DDE, Defect Detection Efficiency

Software Testing OnDemand?

What about software testing ondemand? are you ready to face this offering to your clients? nowdays (and always...) companies are looking to reduce costs, to get the best product, in the right time, and with the right quality.

Software Testing can be an offering like nearshore/Offshore projects for software development, but, the difference is we do testing.

Here are the requisites to comply an Ondemand Offering for software testing:

• Right People !!
• Right Mature on the Software Testing
• Right Methodology/Process
• Connectivity to the testing environment (if that is the case)
• Own Test environment
• SLAs (Service Level Agreements)
• SLM (Service Level Management)
• Tools !! (Automation, managament, etc.)

QA Open Source Tools

The QA Open Source tools, are now the most popular ways for companies to

perform their projects. Even if they are part of the biggest firms in the world.

In my case I enjoy looking at this kind of powerful tools, there are not easy of use or friendly tools, you must have technical knowledges on how to customize them by programming the source code or in other cases you invest more time on performing the task than using license tools.

The most popular Open Source tools are:

• Ruby/WatiR
• Sellenium
• AutoIT
• PHPunit
• WatiN/WatiJ
• J-Meter
• AB-Apache
• Badboy
• Among others..

Nowdays the companikes are looking for reducing cost through Software Testing, we can help them by looking at these type of tools.

Quaility Center... an experienced implementation

When working with HP technology Quality Center (QC), the first thing that came to my mind was "INTUITIVE" thing, and shorted time implementation than other cheaper solutions, that because the other HP solutions (QTP, LR) are really easygoing and friendlies, but the real thing is that it is not that much as thought, so, the implementation took me more time, because QC is too open, you can do whatever you want on it, it is a brainstorm that has to be carried out in order to determine how your process can fit on it. Researching further with experts on Testing discipline, told me that QC has its own definitions for software testing (scenarios, test cases, procedures, etc) and that is the reason that is not too standard. If you want to implement a TESTWARE on QC, you can not have it on one module, but it need to be distributed in several modules to make it work (could it be a tricky solution), as I understood, QC is only a repository for QTP, and LR scripts, that was the purpose it was constructed, but never for managing a testing process.

Test Process Management

In each company exist quality policies, quality process and standars, that are used to achieve the quality goals defined by the upper management. 

We need to make sure that we understand the purpose of every factor needed to make it success. In the industry for Software testing we have several best practices among others I pointed on TPI, TMM, CMM, use them like a guidelines to set up your testing process and obviously they have statistics that back them up, try to make your life easier using them.