Bug Management

Jan 19 2009   10:14AM GMT

Bugs are invincible, developers have to be convincible

Posted by: Jaideep
software quality assurance, software testing, software, software quality, Quality Assurance, Software testers, Bug, software development, developer, tester, Bug Management, Bug Control Management, QC

Bugs are often invincible during development, especially in large projects when multiple sub-teams of developers are working on development of different sub-modules of the project. The software developed (or during development) will always appear innocent and bug-free to the team of developers. It is the tester’s tough task to puncture the software and find out the hidden bugs. If bugs during testing phase are not found completely, it may lead to disastrous consequences, depending on the severity of unfound bugs. That is why, for developers and testers it is very important to understand the complete flow, sequence, modules, sub-modules, functional sequence to build accurately by developers and verification by testers.

Testers have to exercise the testing process and they have to ensure that they are following the right process to identify as many bugs as possible.

Jan 14 2009   10:10AM GMT

Digging the 10 precious ‘Experience’ Treasures

Posted by: Jaideep
SDLC, business management, Bug Management, CRD, Customer Requirements Document, team management, customer requirements

Past is not to be buried. It contains a treasure called EXPERIENCE. In software development this treasure is of ample importance for acquiring skills required to handle the unwarranted turns and twists during the development (and implementation) period.
What we can learn from the past is the hiccups that caused delays and stoppages in a development project. We can use that learning as a tool to tackle the problems occurred during the project life cycle. The learning could be in the form of:
1. Handling customer
2. Freezing customer requirements
3. Preparation of documents
4. Selection of a project manager
5. Development Team formation
6. Key users committee formation at customer end
7. Management committee formation at customer and development end
8. Team coordination
9. Tester’s involvement in the development
10. Choosing a right methodology for project management

Nov 5 2008   10:32AM GMT

Testing - A quick walkthrough!

Posted by: Jaideep
software testing, software testing tips, softwaretesting, tester, Bug Management, Bug Control Management

Here are some quick guidelines for a tester. As and when a new product (software) come to a tester for testing, (s)he should keep following things in mind to ensure the full justification to the purpose of testing. The purpose is to ensure a complete and correct testing of the product.

The guidelines are as below:
1. Assume yourself in customer’s shoe: Treat yourself as customer to run/use the product as they are going to use.
2. Walk with open eyes: When you walkthrough the product, keep your eyes open to observe the minutest variation/deviation in the behavior of each unit of the product.
3. Educate yourself before start walking: Before you start testing, ensure that you have thoroughly gone through the customer/business requirements documents.
4. Don’t compromise with the Docs: Ensure that the documents are complete in all aspects, as any ambiguity in documented business process/rule will have marred the purpose of testing and would lead to wrong results.
5. Don’t cross the red signal: If documents are incomplete or ambiguous, never start the testing.
6. Ensure all passengers are on board: The documents you are studying must be vetted by the customer and project manager before it reaches you.
7. Don’t sleep during flight: Keep your Pen and Paper or excel file ready as soon as you start testing. Keep noting each and every test case results.
8. Don’t take snacks at Food time: Place appropriate screen shots wherever required for your each test case results.
9. Ensure you have a right pilot in place: The project manager/ project team should be available to you while you are testing so as to ensure you all are travelling through the same path.
10. Appreciate the Air Hostess: Appreciate at places where a good job has been done by the developers by putting your remarks.
11. Mistakes are unintentional: Don’t blame the developers for the mistakes (bugs) in the product, purpose is not to punish or fire a developer.

Oct 30 2008   10:10AM GMT

Various Stages of a Bug

Posted by: Jaideep
software quality assurance, software testing, Project Management, software, software quality, Quality Assurance, SDLC, software qa, Bug, software testing tips, softwaretesting, STLC, tester, Bug Management

A bug right from its insertion into the software till its removal crosses through different stages. These different stages of a bug formulate bug lifecycle. Each stage has an action and meaning connected to it. Various stages of a bug are:

Unconceived: A bug that has to come into a future software, not even knowing who is going to write it, and in which software.

Unborn: A bug not yet taken its shape, still lying in the mind of a developer.

Unconcealed: A bug residing in software but unrecognized by a tester.

Open: Any misbehavior in the software identified and recognized by tester is recorded with “Open” status.

False: Not actually a bug but marked as bug.

Disguised: A bug existing but identified with a different behavior.

Accepted: The bug accepted (as bug by project manager and its development team for a fix.

One time: A bug encountered by testers, but not encountered/simulated again. Such bugs are required to be fixed unless encountered again.

Not Accepted: Project Manager or development team may refuse to accept a bug in case it is not critical and seeking too much time to fix it, it is meeting customer requirements, tester has not understood the business requirement well and identified a wrong bug, or in case the same bug has already been reported.

Not to be fixed: The reasons would be same as mentioned in “Not Accepted”.

Pending: A bug accepted by the developer but may not be fixed immediately. It could be due to non severity, other priority or any other reason.

On Hold: Some bugs need to be discussed with customer, or management. Or the reasons may be as mentioned above in “Pending”.

Fixed: As soon as a bug is fixed by the developer, it is assigned as status as “Fixed”. A programmer must always doubly ensure before marking a bug as fixed.

Closed: The bugs marked as fixed once verified by tester and are found fixed are marked with the status “Closed”. Tester must doubly ensure before marking any bug as closed. Tester must also ensure that the bug fixed has not generated any other bugs.

Re-Open: A fixed bug found not fixed by the tester is to be marked as “Re-open”, which goes back to the developer for fixing.

Oct 27 2008   10:15AM GMT

Bug Control Management - a void promise! A flawed process! Or a process insanity!

Posted by: Jaideep
software quality assurance, software testing, Project Management, software, Quality Assurance, SDLC, software qa, Bug, developer, Project Lifecycle, software testing cycle, software testing tips, softwaretesting, STLC, tester, Bug Management, Bug Control Management

There are three ways of functioning for any software organizations. First ways is to develop software and deliver it into the market. The survival for these sorts of organizations is too difficult and short. Second category of organization has a well placed “Quality” department in place. The quality department is responsible for ensuring a bug free product going out to the customer. The third category of organizations have a well identified and well structured team in place to ensure that every next production of software is going to have far less bugs as compared to the earlier produce. Most software organizations fall in category number two. Very few fall in category one, as organizations falling in this category will either not be able to survive for long, or will live on a very little customer base and profit. This is the third category that we are talking about – that falls in the bracket of “Bug Control Management”.

This organization lying in the third category will be continuously working towards improvising the processes of product development, ensuring lesser and lesser bugs in each of the next release of the product or new product. The progress of this team will purely be objective subscripting the improvement in every next product release. It does not mean that quality department will have no role now. Rather quality department will have a new meaning and more valuable role to perform.

But point to ponder here is – is it just a void promise, a flawed process or process insanity. Or is it just the darker aspect, brighter aspect is being felt by the organizations who have or are in the process of adopting BCM.

Oct 24 2008   10:15AM GMT

Bug Control Management vs Bug Management

Posted by: Jaideep
software quality assurance, software testing, Project Management, software, software quality, Quality Assurance, Software testers, SDLC, software qa, Bug, developer, Project Lifecycle, software testing cycle, software testing tips, softwaretesting, STLC, tester, Bug Management, Bug Control Management

Bug Management and Bug Control Management are two separate aspects in software development. Bug Control Management seeks a higher maturity level in terms of organization, developers, project managers and all others involved. On the other hand, Bug Management starts in organizations with low maturity level. Organizations that attain the Bug Management level and keep it for years, stop maturing and keep a particular level of maturity sustained within them. There are organizations that move (over a period of time) from Bug Management to Bug Control Management. These organizations keep improvising and seeking improvements in their processes and procedures.
Usually a software organization life starts with software development. Gradually with the increase of business, increase of experience of developers, and increase in customer expectations an increased level of reliability in the software from all directions is expected. To cope up with this pressure, the organization creates a department called as Quality Assurance. This department takes care of testing of software, finding out bugs and getting it verified after the bugs are fixed by the development team.
Bug Control Management is a management initiative to involve all concerned to form a steering committee. The responsibility of this committee is to ensure that lesser and lesser bugs are generated in the software while development.

Oct 22 2008   10:11AM GMT

BLC or Bug Lifecycle

Posted by: Jaideep
software quality assurance, software testing, Project Management, software, software quality, Quality Assurance, SDLC, software qa, Bug, developer, software testing cycle, software testing tips, STLC, tester, Bug Management

In simple terms BLC or Bug lifecycle can be defined as the different stages of bug. BLC or Bug lifecycle will consist of all these stages starting from the birth of a bug till its removal from the application. The various stages of bug lifecycle or BLC can be listed as below:

1. Bug induction or generation in the software
2. Bug identification
3. Bug behavior study
4. Impact study
5. Bug classification
6. Bug admittance
7. Bug removal assignment
8. Bug removal
9. Verification

The birth of bugs is unintentional, uncontrolled and hidden. A bug is prone to take birth while a code is being written. A bug is not a bug until it is identified or recognized.
BLC or Bug Life Cycle starts with an unintentional software bug or unwanted behavior and ends when the assigned developer fixing the bug.

Oct 15 2008   10:34AM GMT

Reasons of Unclear Software Requirements

Posted by: Jaideep
Project Management, Quality Assurance, SDLC, Project Lifecycle, STLC, Bug Management, CRD, Customer Requirements Document, software requirement

Broadly there are two main loopholes in case of unclear software requirements – vendor and customer. Unclear Software Requirements could lead to disaster not only for the vendor but for customer also as I stated in my previous blog. To vendor it may cost money, time, reputation, business and at worst the closure of business. To customer it costs time, money, employees trust in its management, management confidence in selecting a vendor and at worst a decision to not to streamline their business in terms of a new software.

The main reasons of unclear software requirements could be:-
(Vendor Part):

The vendor representative deputed for studying software requirements is inexperienced in terms of customer business
The vendor representative’s tenure is too short at customer site to study its business and requirements
The vendor representative is not curious enough to dig down each process at customer site
The vendor representative being poor at documentation
The vendor representative thinks collection of relevant forms and reports is a waste
The vendor representative keeps more in his mind than documenting (the business rules, processes and requirements)

(Customer Part):

No clear cut representative(s) identified
Business clarity is delivered by the person other than actual process owner
Process owners too occupied
Process owners depute their subordinates and perceive they will explain the correct picture
Management before signing the final documents do not vet each process and business rule
Poor management’s involvement
Wrong perception that vendor will build a strong software that will meet all their requirements on its own

Oct 8 2008   10:35AM GMT

Bug Management - Major Concerns being felt across the Globe

Posted by: Jaideep
software quality assurance, software testing, Project Management, software, software quality, Quality Assurance, software engineering, Software testers, SDLC, software qa, Bug, Project Lifecycle, software testing cycle, software testing projects, softwaretesting, STLC, tester, project manager, testing environment, Bug Management

Senior Management including CIOs, QA Heads, CEOs, Development Heads, Project Heads, Customers, Vendors and/or sub-contractors related to software Organizations across the globe has repeatedly displayed their concern over the Bugs Management Process from time to time.

These concerns could be grouped as below:

1. The results of the Testing process are regularly inconsistent: This means that if same code is being tested by different group of testers under different leads, the results will vary always. Also the same team performing testing on different products will result in different performances.

2. The test results do not lead to more effective coding: The coding is always prone to create bugs (programmers are always as overconfident as ever).

3. The identification and quantification of a Bug is highly dubious: All the efforts by testing team in identifying and categorizing a bug is not always able to meet the seriousness it is meant for. Moreover sometimes a bug becomes an issue of debate over its category (critical/ severe/ desirable etc.).

4. Quality managers and testers often appear to have a limited knowledge of the code and business concepts and related issues.

5. Excessive focus and reliance on quantitative bug analysis is dangerous.

6. Bugs with a low probability occur more often than would be expected.

7. Bug management leads directly to bug avoidance.

8. Bug prioritization by Test managers is usually a simple ranking showing little or no understanding of the business process or customer requirements.

Most of the time the goal of testing is to diagnose the cause of bugs and produce better solutions. Instead the focus should be more on avoidance of bug generation at the code level so that least changes happen in the code once generated.

Oct 2 2008   10:15AM GMT

What is a Bug?

Posted by: Jaideep
software quality assurance, software testing, Project Management, software, Development, software quality, Quality Assurance, SDLC, Bug, developer, Bug Management

Any defect, shortcoming or error in software (built to perform a specific function or set of functions) is known as a Bug. A bug is usually an unexpected event encountered by a tester (or sometimes a programmer himself) while testing a unit, module or a complete product. This unexpected event could be due to a coding error, a code defect, code fault, flaw in coding, imperfect coding, erroneous coding, or improper coding.

The purpose of a code is to perform a pre-defined or pre-conceived function or set of functions. Once the desired function is not performed or is performed with some errors, the code is known to contain bug(s) which need to be fixed. The ultimate goal of a code is to perform as it is intended to perform under all circumstances.

The software built is meant to perform perfectly under all scenarios/ customer requirements/ business rules built in the software to satisfy all functional and business requirements of the customer.