Saturday, September 10, 2016

The Modified Software Bug Cycle

The other day I and my friends were discussing a bug that stormed into the application and didn't plan to leave it soon. So during the spare time at tea,  we decided to haunt the regular bug cycle. How about altering it and just have some fun. Let's tweak in the Agile Testing Process.
It goes like ...
Tester Logs a  High severity , High priority Bug - 
"Bug 999 - Exception occurs and Application hangs on clicking Submit button at SEZ 1 location at Tea Time."
The Bug goes through a series of procedures like the Review Cycle where a group of senior Pundits from the Agile and the Product Development team review the defect. The defect gets a clean chit and it goes to the Product Development team Lead's plate.
The Dev Lead assigns the Bug to the Developer. 
The Developer investigates the bug. That seems to be the most challenging bug. The entire team brainstorms and indicate that it requires a high-level design change. The Design Lead and the Product Owners are roped into the scene. They all work together and come up with a plan. 
The Developer fixes the issue as per the new design. 
He updates the defect with the below comment.
"Issue fixed. For the Impacted Areas, the bug should be tested at Lunch time and Dinner time  and from Sez 1 and Sez 2. Testing at Onsite should be taken care by them once they face the issue.This bug also needs to be tested during Work From Home and during National Holidays."
The Project Manager updates the defect.
"Testing to be done from onshore too. The Onsite QA Team is notified about this defect."
Two days later the Onsite QA Lead comments on the bug.
"Defect is invalid. Who works at tea time? We never work at tea time."
Another QA from the defect logger's team   consults the developer and asks him why breakfast time is not mentioned in the Impact Analysis testing.
"You guys come at 1 PM for stand up and who will test it for the breakfast scenario," The developer replies angrily.
"But still," the QA snaps.
"No But, no If's. Who will come early to test that ?" The developer retorts and displays his animosity by rapidly typing serialisation code that he was working on. He had spent several nights at the office working on this defect. His frustration and anger were visible.
Angrily, he bangs his hand on his desk and glares at the QA.
He then updates the defect and assigns it to the QA who logged the defect.

Did you like this post? Get The Solitary Writers updates via Facebook or Twitter, better yet, subscribe to it via RSS Feed. It’s easy, and free! Comments are just another way to let me know how you feel.Don't forget to comment.