October, 2008

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 20 2008   10:30AM GMT

10 Must-do for Vendor to have clear Software requirements in first go!

Posted by: Jaideep
Project Management, SDLC, Project Lifecycle, Customer Requirements Document, software requirement

This is in continuation of my previous blog where I listed the 10 most important must-dos for customer to have clear software requirements in first go. Ten most important must-dos for vendor to have clear software requirements according to me would be:
Vendor End:

1. Understand that an unclear or incomplete software requirement is never going to build good software.
2. Ensure that management selects the right person(s) for the purpose.
3. Ensure that management at back office is continuously involved in the whole process as per plan.
4. Ensure that customer management is clear in their goals to be achieved by this software.
5. Ensure that customer has identified the right people who are actually the process owners and not the subordinates of the process owners.
6. Do not hesitate in analyzing the each sub process station.
7. Ensure that analyst gets process owner’s ample time to document each and every process requirement well.
8. Don’t trust on your mind. Document along with the understanding of the process or soon after it. Keep getting it vetted by the process owners.
9. Keep updating customer management after the finish of each process.
10. Don’t compromise with time and documentation.

Note: Please do not hesitate in giving your valuable add-ons. I might have missed out certain important points (if! Any!!).

Oct 17 2008   11:22AM GMT

10 Must-do for Customer to ensure clear Software requirements in first go!

Posted by: Jaideep
Project Management, SDLC, Project Lifecycle, Customer Requirements Document, software requirement

Having clear software requirements is very important as it is going to be the foundation of the software to-be-built. Having clear software requirements in first go is equally important especially in case of overseas client. Few things are very well known to all:

1. Face to face interaction brings out more clarity as compared to any other mode of communication.
2. Documents collected and prepared are the vital asset of software requirements.
3. Selection of right person for the customer/software requirements study is very crucial (and sometimes it hurts at a very late stage)
4. Travel and time is a cost that is affecting the overall Project Cost, Margins and Profits - irrespective of whether customer or vendor is bearing it in the beginning.

Keeping all this in mind, the 10 must-do to have clear software requirements in first go, which I am listing below. There could be many more (which I would like to be added in the comments section), but these come to my mind as most important:
Customer End:

1. Ensure that management knows the purpose of the project
2. Ensure that management is continuously involved in whole process.
3. Ensure that the vendor representative(s) coming for the purpose is the right person(s). They should not only be the master of their domain but should have fairly good number of years of business exposure too.
4. Ensure that the process owners are the right persons to explain the process.
5. Ensure that the process owners have their process charts ready with them, the document is going to help really.
6. Ensure that the processes are sequenced in proper fashion.
7. Ensure that the time should not be the constraint for process owners. Devoting 6-8 hours for 2 days is always better than devoting 2 hours per day for 10 days. After all more time spent by the vendor representative is equal to more cost to the customer (overall project cost).
8. Ensure that the analysts (vendor representatives) keep updating their documents during the understanding of process or at the finish of a process. Let not a lot remain in the mind and be documented later.
9. Ensure that both the managements (vendor and customer) finally sign the document finally prepared (both have equal ownership on whatever has been documented).
10. Do not get bogged down by the size or volume of the document. Let it is as elaborative and explanatory as possible. Just be sure that it is crisp and to-the-point. Attach hand written papers, reports, formats, legacy manual with specific markings of important features required to be built in the new software.

Note: Please do not hesitate in giving your valuable add-ons. I might have missed out certain important points (if!). A similar set of guidelines for the vendor end, I would be posting in my next blog.

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 13 2008   10:59AM GMT

Unclear Software Requirements could lead to a deadlock

Posted by: Jaideep
Quality Assurance

Unclear Software Requirements could lead to a disaster. It may lead to a dead end or deadlock from where there is no way back, with zero possibility to move ahead. The situation may cause the company a huge cost in terms of understanding the requirements again, rebuilding the software, re-testing, re-configuring and re-implementation. The cost involved sometimes is small enough that the company is able to absorb it or adjust it, else sometimes it is so huge that it effects not only the current project(s), but has a recursive disastrous effect. Sometimes companies are never come out of this crisis and gradually have to bear huge losses.

Usually it is lose-lose situation for both the vendor and the customer in this scenario. The loss at both the ends could be in terms of money spent on customer visits (travel and stay cost, borne by vendor or customer, but it is spent and has gone waste), time consumed by vendor in development of the product based on these unclear or incomplete requirements, the reputation of vendor (which is somehow irreversible if the name goes bad, and has recursive effects), confidence of staff at both the ends (customer and vendor), management’s trust (in each other).

The reasons for this situation could be many but the ultimate result is always the same – DISASTER.

Oct 10 2008   10:56AM GMT

Why pay to vendor for understanding customer requirements?

Posted by: Jaideep
Project Management, SDLC, Project Lifecycle, CRD, Customer Requirements Document

In normal scenario when an order is finalized between a vendor and a customer, for building new software by the vendor, the payment terms are set in such a manner that some percentage of the project cost is paid soon after the completion of customer requirements study, generally on finalization and submission of customer requirements document (CRD) by the vendor to the customer. The completion of this phase shows that the vendor has clearly understood the customer and business requirements and is capable enough to build all those requirements in the software product that he is going to build for the customer.

Customer’s ultimate goal is to acquire or purchase the final product that fully meets its functional and business requirements. Then why customer should pay out of his pocket for something at a stage that is of no use to the customer. The requirement study is the need of vendor and not the customer. Customer finally needs a product.

What if the product built is incapable of meeting customer’s requirements. Then why not customer pays to vendor just once at the time of product delivery, User Acceptance and implementation completion?

Do we buy a complete car or pay in parts – for steering, for body, for brakes, for seats, for belts… and so on…

Just a thought…

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.