tag:blogger.com,1999:blog-7722108.post4270803691079009329..comments2024-03-28T12:11:07.539+05:30Comments on Thinking Tester: When method dictates outcome and Goal – See Goal displacement in action - IShrini Kulkarnihttp://www.blogger.com/profile/10782753752478547381noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-7722108.post-77555097963646243212008-05-17T16:21:00.000+05:302008-05-17T16:21:00.000+05:30Hi Shrini,This is indeed a big problem in our soft...Hi Shrini,<BR/><BR/>This is indeed a big problem in our software industry. I have experienced it personally. In our team suddenly they said that we will have KPI's for measuring test engineers productivity. Prior to having all this non measurable stuff things were working very fine, quality of Bugs found was great and engineers were devoting time to find bugs and test using different techniques. However lets see what side effects this measurement concept gave to my team:<BR/><BR/>One of the KPI's given to our team was that on an average their should be 1 bug per day logged by a person and eventually it was suposed to rise to 1.74 to achieve the figure on a Business Unit level. <BR/><BR/>The Outcome:<BR/><BR/>Every one was counting how many bugs he needs to log in the system and by which date. Any stupid bug or just anything was getting logged into the system like a page is not opening, lets log a bug, server is down lets log a bug. <BR/><BR/>The main goal changed from quality oriented bugs to number of bugs logged so that in the ALL HANDS meet they will get recognition.<BR/><BR/>In my perspective the type of bug logged and how crucial the bug found was, what impact that bug had on the application, what would it have costed to fix it at a later stage in case the bug was founded later, what was the scenarion in which bug was found were all important factors in deciding the performance of test enginner and not the goal of achieving 1 Bug per day.<BR/><BR/>Their were long discussions about how many bugs have a person logged and how many more he needs to log in the system in the Cafetaria's.<BR/><BR/>On top of it their was a PDF attachment sent at end of every month containing a list of all people with number of logs they have logged and declaring someone to be the winner.<BR/><BR/>What impact it had on good test engineers?<BR/><BR/>If i consider my case then i logged very good bugs which were all never seen by anyone though the application was being tested from 2 years, all were accepted by development team as valid bugs, most of them very quite critical in terms of usability of the application, some of them were pertaining to context getting lost in navigating to next pages and coming back to previous ones.<BR/><BR/>But since the no of Bugs which i raised was very less in compared to their goal of 1 bug per day and i was never satisfied with this idea of implementing this for all people in the whole team where most of them were working on independent modules which are definitely different from others.<BR/>The Bugs found will also be different and will be of different severity and found for different applications.<BR/><BR/>I can say this is a perfect example of the Title for the post.<BR/>"When method dictates outcome and Goal- See Goal displacement in action".<BR/><BR/>Do you agree?Madhukar Jainhttps://www.blogger.com/profile/04304311670407522649noreply@blogger.com