2007-Apr-17 - Does a QA really want to find bugs?
This is my first blog here. I'd like to introduce myself a little bit.
I've been working as a QA engineer in a software company for nearly 2 years now. I'm in a team of about 10 QAs and 10 developers (a HUGE team, huh). The company has a not bad process, and an auditing team to supervise the process, although each develop team may customize the process according to their plan and schedule.
I have the habit of taking some notes whenever I think of something confusing or interesting. And the first thing comes up to me is: does a QA prove a program to be able to run, or prove it to have problems?
Of course, in many software testing books, it always tells us that if you hope the program can run, you will probably see a normal running program, thus you will miss bugs; But if you hope it should have bugs, you will probably see full of bugs.
That's the theory. Practically, in my working team, QAs are willingly taking great efforts in finding bugs during each test -- only before alpha stage. After entering beta, QAs are becoming more and more feared about finding more bugs. We begin to hope everything works fine, and we ignore tiny bugs.
Why that happens?
I find 3 main reasons:
1. Schedule pressure from the top.
If we find more bugs, it will probably lead to delay, which our managers do not want to see. QAs do not really want to frustrate the developers and managers.
2. Performance objective.
One of the QA's performance evaluation points is the percentage of bugs found in alpha stage / total bugs found, compared with beta stage. If we find less bugs in beta stage, this value can become higher.
3. Personally tired of repeative testing.
One may continually test the same module through the whole development cycle. If this takes several months, some will get bored.
What should be changed then? Here I have some ideas though:
1. Managers attitude towards product quality against schedule should be changed. If QA team becomes more powerful in deciding the schedule and product release baseline, and let QA members know that they have that power, I believe it will change QA's attitudes too.
At the same time, from QA's point of view, some types of tests that need a long time, like real-world simulation test, may be considered starting at an earlier stage. So that let problems reveal themselves earlier.
2. Change the performance objective. Make it more specific and measurable.
Test case contribution may be a good evaluation point. A new bugs found is probably related to a new test case added.
3. To deal with personal tiresome, I will propose automation testing if the project takes several months, and will release latter versions. Using automation tools, and writing automation scripts are interesting to some QA engineers.
Also, a QA can do exploration tests, and add new test cases. Let automation do the old cases. We do some interesting new ones.
Of course, finally, the boss and managers are better encourage finding more bugs. And keep encouraging, keep encouraging, until we all believe it's true.
| 
