Julius Caesar was warned “Beware of the ides of March”. This seemed to make a lot of sense to Tanash when he updated his diary for the events that transpired at the project kick-off meeting on March 1 2011.

Following his training program and induction from the earlier months, Delspe (Tanash’s manager, the Delegation Specialist) assigned the task (delegated, rather) of listing down the all the relevant “Bug Status” fields for the project and present it as part of the project kick-off meeting.

The Participants in the Project kick-off meeting

Almost everyone in “Ele Info Systems” attended this meeting.  Participants included representatives from development, project management, HR, financial teams, certification manager, networking team, process team, other project team that interacted with the clients, other team that worked on the same domain, people from marketing and sales team, training department representatives, business analyst team, a set of people who were biding time in a maintenance project, etc.

Looking at the crowd, Tanash felt that most of them attended this meeting only to display their existence. The funniest thing was that out of the 30-odd number of people in this project, only 2 or 3 would be working hands-on in the project.

Apart from the above crowd, the onsite team and client representatives also attended this meeting through a teleconference. The unwritten understanding was that the offshore teams would keep the phone in mute, whenever they need to discuss something that they did not want the client to know, and any questions during this period from the client would be handled by their onsite counterparts.

The first 10 minutes

The 1st ten minutes were spent on Introductions. Although everybody knew everybody, everyone went through the mundane process of introductions since the company’s process for kick-off meetings mandated this process.  Tanash introduced himself as the tester and almost immediately, the process manager questioned the need for test team members to be involved from the beginning of the project. With the phone on mute, people also hinted at high profitability if test team members get involved only at a late stage of the project.

Delspe stated that they do not want to compromise on quality and that’s why they have testers involved from the beginning.  Ensuring that the phone was still muted, Delspe also mentioned to the others that the client was particular on having a tester from beginning, but he’s a low-cost resource and so, it would not affect profitability by all that much. To Tanash, it seemed that quality had been sacrificed for profitability.

Tanash’s definition of Statuses

When his turn came to speak out, Tanash said — “Trying to keep the statuses simple, I propose to have only 2 statuses for a defect – Open and Closed. Open would be evidence that the bug is still around in the system, and Closed would be evidence that the bug is not in the system anymore.  That’s all, folks!”

Stunned silence all around. Then, everyone started talking.

The developers spoke first. They said – “We need to identify defects that are resolved by us, but are not yet tested by the test team. Let’s have a status Fixed!”

The project manager with an eye for metrics spoke next. He said – “We would also need to identify defects which have been opened and not fixed properly by Dev. Let’s have a new status called – Reopened.” And he whispered to Tanash — “That way, I’d also have a bigger status report. Heh heh!!!”

The Database administrator, who was in a deep sleep, suddenly woke up. He said — “What if I cannot re-create the defect on my machines?” Tanash replied — “But does it ever occur to you that defects are not a figment of our imagination, and that it’s only since they occurred tat we file them in the 1st place?” Giving him an angry glare, the administrator ignores Tanash and tells Delspe “That doesn’t matter. If I cannot re-create it, I cannot fix it.” Delspe plays pacifier and adds a new status called “Non-Reproducible”!

Another developer speaks up. “What if I see a defect which is already logged earlier?”. Tanash says  “Then simply close one of the two defects. Life would be much simpler”!  Taking a cue from the database administrator, this developer ignores Tanash and tells Delspe “We need to track the number of such defects separately. This would also be a parameter for effective testing”. The process manager nodded his agreement saying “We are a CMMi5 company and cannot afford not to follow CMMi standards.”  Tanash says “When 15 testers test a project; duplicate defects would definitely come up. Don’t you think that the simplest thing would be to close them and continue? What I…” The client’s voice on the telephone says “Let’s add a status DUPLICATE!”  Nobody questions the client. The sales and marketing folks were heard telling the client “It’s a brilliant idea!”  They also went on to add “We are thrilled to see you being so participative in our calls. We are happy to see you treat us as an extension of your company…..” Tanash tuned out!!!

Having been silent for so long and wanting to contribute to the meeting, the onsite counterpart says “We would need a classification for defects so that our client’s would know that a defect has been raised, but not have been looked into yet, since it’s not yet been assigned.”  Tanash said “You have to look into each defect based on the priority. Why do you want to classify what you have seen and what you have not?” Delspe whispered into Tanash’s ear “Since those onsite folks usually don’t know about the project and the clients keep badgering them for this information.” And a defect status called NEW is added.

The onsite folks talk again. He says “What if I don’t understand a defect?”. Tanash says “then, please call me. I am just a phone call away”. The onsite folks tell him “Maybe we may be looking into something of higher priority and may not have the time to call you”. Tanash says “In that case, may be the defect is not that important at all”. The developer says “We cannot come across to discuss every minor thing. Let’s add another status – Need more information!!!”  Tanash felt overpowered!!!

Looking up from his blackberry where he was following the cricket world cup scores, the business analyst speaks up now. He says “What if I don’t agree if it is a defect?” An exasperated Tanash says “If you don’t agree, then close it!!!” The Development manager thinks and says “I have an objective to have fewer defects. Let’s add another status – Rejected!!!” Delspe simply nods in agreement.

The BA continues “Hey, I want a status to indicate I have not yet looked into the defect. Can we add a status?” Tanash says “But isn’t it your 1st priority to look into defects? Defect triages can go for a long time, you know”. The meeting manager, having been silent till now, speaks up and says “Let’s add 2 statuses – To be triaged, Being Triaged. Every morning, we’ll do a small triage to decide the defects that have to be triaged on that day and add it to the “Being Triaged” bucket. We’ll leave the others in the “To be triaged”.”. The client speaks up and says “Very innovative and an exemplary suggestion”. And the sales and marketing team sing praises of the client once more, which I am not mentioning here since it is too redundant.

Now the engineering director mutes the phones and speaks up “We need to indicate defects which we will fix in a subsequent release. After the meeting’s over, add another status – Deferred”!!!

The training department representative says “Hey, this defect is assigned to a developer. But what if he is yet to fix it?” Tanash says “So? Add a new status To be fixed. That way, everyone would know I am working on this defect, but am yet to fix it. And, also do add 2 more statuses Defect By design, Existing System limitation” The process and metrics managers nod their agreement and say “Excellent idea!!!”

The meeting goes on for some more time and more statuses are added — Not a Defect, Partially Fixed, Re-assigned, Withdrawn, Redundant, Pending retest, Pending reject, Remind Me Later, Unconfirmed at the start, Won’t fix, Works for me, Verified in QA Env”.

Originally the two nominated defect status list now read – Open, Closed, Fixed, Reopened, Non-Reproducible, New, Duplicate, Need more Information, Rejected, To be Triaged, Being Triaged, Deferred, Defect by Design, Existing System Limitation, Not a Defect, Partially Fixed, Re-assigned, Withdrawn, Redundant, Pending retest, Pending reject, Remind Me Later, Unconfirmed at the start, Won’t fix, Works for me, Verified in QA Env!!!!!

The client says that it’s his lunch time and so, everyone ended the call.

The training manager was heard saying “Wow. Let’s draw an enormous defect life cycle diagram and add the defect Life-cycle as a separate course in our curriculum!!!”

The testing manager who loved interviewing was heard saying “Hey, that’s 1 great bug life-cycle that you’ve got in here. Now onwards, asking the defect life cycle is a part of our interviews and if anyone gets a status wrong, they cannot become a tester at our company. That way, we would hire only smart testers!!!”

Exerpts from Tanash’s thoughts… Today, I learnt how we complicate our life to satisfy idiots. I also learnt to create a complex solution to a simple problem. Bug statuses are created for convenience. Why do we let them “inconvenience” ourselves? I understand that I made a mistake suggesting only two statues. But do we really need 27 bug statuses for our project?

And… 35 people spent 1 hour at this call. That means 35 hours of productivity has been lost, but this has been billed to the client. Should not the focus be more on productivity, quality, instead of “Client Satisfaction” and “Profitability”? Where are we headed? Where are these leaders leading us?

Fake Software TesterA Fake Tester's DiaryFake Tester,Fake Tester's DiaryJulius Caesar was warned “Beware of the ides of March”. This seemed to make a lot of sense to Tanash when he updated his diary for the events that transpired at the project kick-off meeting on March 1 2011. Following his training program and induction from the earlier months, Delspe...