We all know who a monkey is. Monkey does what its said and it just follows someone else. Lot of people including James Whittaker tell that there are monkeys in QA profession. In fact there is a monkey inside in all of us. For me that is perfectly fine as long as the monkey doesn't rule you. Lets find out our monkey scale!!
Read more>>
When we are working on our projects we should always make sure that we do not let the monkey to work. Instead we should always try to engineer what we do. Everyone including devs have the monkey affect in work. It is not specific to testing. However the tendency of being a monkey is high in testing role because of its nature.
We often get lot of repetitive work such as running the same regression suite over and over again, performing the same functional test in multiple browsers, test data creation, regular meetings, review test cases, testing and testing. Yes this is tons of work but product still has bugs? isn't it? That's because our monkey has played a good role in above work. If all the projects that you have work has the similar pattern I would guess that it is right time to go a step back and think with a fresh mind. Because all what stakeholder expects from us is the right product which is built in the right way.
Ok lets take a look at this in a different way!
I believe in quality assurance over testing. QA does prevention where testing does detection. However even though the cost of an incident is high in testing, its easy to perform and organize. Where QA is a tough job because if you get it wrong you are in a serious problem. Just think! if your latest build doesn't have any interesting bugs (yes, we all like to see bugs in the dev build, but not in production) it means either of followings
- You may have run into false positive results
- Your developers are exceptional so that they have done a superb job
- Or, you have solid QA practices even before the dev delivers the build
First two points you have to figure out. They still come under testing framework. The third point, this is the building block of industry giants like Google, Microsoft etc. They take this very seriously. QA activities does not have to be come under your QA department. All what is important is the QA process which is taken place in your development life cycle.
A tester tells, ok I am ready to test the requirements! A QA tells, ok lets see whether this is being built right?
For me these are completely different perspectives. In fact why wait until everything is built? lets start our job right away. What is left from QA can be accommodated by testing.
It is very is to justify QA over testing. Any monkey can speak for that. For me this post is mokeynized as I have not yet told how to apply QA by examples. I will leave this for a future post.
However, I want to point out another aspect. Very often the testing team is measured by the defects they have found. Higher the defect count higher the recognition. This encourages to do more and more testing. This is no bad but it is also very very important to encourage people to reduce the defects through QA. This often doesn't get highlighted. Because it is very difficult to measure the inputs of QA in early stage of the development. More likely your job will not be highlighted. I am serious, this happens. Finally people think you are a cost because you are working for a project where it doesn't have bugs. But end of the day, isn't this what we suppose to do?
Good bye and thanks for spending time to read this. Hope you enjoy! Get rid off the monkey.
No comments:
Post a Comment