It’s me!… A BUG

When developer missed something, I was born.
When developer fixed something, I was born.
When reviewer neglected something, I was born.
And when functionality does nothing, I was born.

I was born with so many types…
At times I am critical, at times I am time-pass.
I was in disguise and could not be caught,
Until a tester finds me and I was just draught.

Though I was the same but now got a status and a name,
I am lying at developer’s task queue,
I know I will either die or grow.
But if I live, I make everyone sway.

Tweet to report defects!

Twitter and Facebook have changed the way we used to communicate in the past. Instead of email, people are finding them as a better communication medium. These 2 are often the mediums to get the instant first hand information on almost anything.

There have been times and even today we use various tools, OSS or Paid, to report and manage defects so as to keep a record for any product development team. Let us revisit what these systems provide and how are they used by various teams.

Defect Cycle configured in any Defect Management Team (generally followed by most of the teams in various companies)

1. Open a new defect
2. Provide Summary
3. Write complete description on how to reproduce that defect
4. Assign proper severity/priority and other details like build number, browser etc.
5. Save the defect
6. The Test Lead evaluates the defect and, if valid, assigns it to the dev lead
7. The dev lead assigns it to the dev engineer
8. The dev engineer fixes the defect and routes it back to the test lead
9. The test engineer verifies the defect and if found fixed closes the same
10. If not fixed, the defect is reopened and routed back to the dev engineer

In the whole process there are various checks where automatic emails are sent to the stakeholders (mostly configured for steps 5 to 10 above) to notify about the incoming defects or change of state, if any. There are various processes also defined that make it mandatory for any lead to review all the logged defects at the end of day or participate in defect triaging meetings scheduled regularly. Overall these tools and processes are good to keep focus on defect reporting and fixing, but here are the limitations/disadvantages that they bring in.

Limitations of current Defect Management Systems

1. Communication lag: There is an overall communication lag between testing and development teams. Both the teams often communicate by putting comments for any particular defect which wastes a lot of time in turn and sometimes they don’t understand each other’s point.
2. Defect language issues: Many a times it is raised that the testing team is not drafting the defects correctly. Or the summary of the defect does not communicate exactly what is mentioned in the description.
3. More meetings as project progresses: Frequent defect triage meetings are needed to keep a tap on incoming vs closed defects. Also, in such meetings the lead is mostly explaining the defects and might not be able to do complete justice to the defect.
4. Time lag: It has also been seen that whenever any tester finds a new defect, the tester first notes that down in his/her local file and at the end of the day logs all of them into the defect management system with all the details. Due to this sometimes critical defects that needs immediate attention by other stakeholders lose time to take action.

If we look at twitter and how it has changed the communication, I feel that if we integrate twitter in our day to day defect reporting mechanism, the whole process can be made better.

How Twitter can help

1. Whenever a defect is found, the tester tweets about it. The developer and tester can discuss it immediately and both of them can agree/disagree on the same.
2. Twitters 140 chars limit will force tester/developer to be more crisp in doing the communication about the defect. It will also help them in improving their communication skills.
3. Unnecessary mail communication can be minimized as everything can be discussed live.
4. As the defects will be discussed immediately, so it will remove the need of having (sometimes) unnecessary triage meetings.
5. The whole product team/sub teams will be together on twitter so they will be able to immediately know which area of product is getting more defects.
6. The management can also have a feeling of how the two teams are performing and can have a complete access to each individual in the team, at the time of need.

As the world is moving towards Agile based development and it is definitely bringing development and testing teams more closer, twitter can play a very important role in building harmony between both the teams. Though it might not be as easy to implement as it is said above due to various issues like

1. This will require teams to be online everytime, and teams might complain of wasting their times due to this.
2. Managers who are driven by metrics might feel this a bit unrealistic as they will not be able to measure based on tweets.
3. To keep track of the defects, the defect needs to be logged into the defect management system that will definitely require some extra time.

Defect reporting is only one form where Twitter can help. It can also be helpful during test case creation, evaluation, testing etc. Let us see how things converge to build a better platform for futuristic teams. Feel free to post your comments/thoughts on the same.