First: it seems easy, but it is hard to be good at it. Second: there is statistic kept supposed to measure your efficiency. Third you can’t (neither practically nor theoretically) win all games, just as you can’t find all the bugs. Last but not least to improve you need practice and a will to develop your skill.
On Monday I started writing this to talk about skills required to be good at FreeCell. While writing I kept discovering more and more analogies. I hope you will be as much exited as I was for how much I was able to learn about testing while thinking about FreeCell. For example I realized how statistics were blocking me from improving my skills in FreeCell. Now I understand how some testers are affected by the same issue.

Recently I’ve found my (sever years old) presentations with a lot of defect metrics and analysis. Only one slide I am proud of still – the percentage of “cancelled” bugs (drilled-down to percentage of reject reason: duplicated, not repeatable, etc.). What I like about this measure that it is direct – I’m really interested to keep the number of rejected bugs low – yes I’m interested in testers not reporting them in the first place.

If you’re interested in data analysis and/or want to improve your Excel skills, check out this podcast. Bill Jelen, the self-proclaimed, MrExcel, offers a free daily 2 minute podcast. His podcasts are well-labeled so you can locate the topics you’re interested in. The opening music is so awful I’m not sure if he’s trying to be amusing but hang past the music because the tips are highly usable.

In the past in my current position we reported results in terms of failure rates. Our release critera was based on failure rates. Our ISO internal auditors loved this. However, these numbers were more than often misleading. They were not a true measure of the quality of the product under test. Some features with a small number of test but with 1 failure showed a failure rate of 10% where larger features with more failures showed a much lower acceptable failure rate. However the larger feature would be the one that we were concerned about but the numbers showed it was acceptable.

Last week was very important in my life span as a Software Tester. I realised that no matter how precise you are at estimating efforts and schedule - estimates are just that - Estimates - rough idea initially, but as you refine it - you get a more solid view of what is realistic estimate.

I Was surfing on QAForums -> Estimation & Planning section and read that estimation is all about experience. Tools and Templates help you to some extent - calibration needs to be done by you.

Run-log pass/fail flag is common in T.M. tools such as test director. My studies indicate the most typically definition of pass/fail is: failed if any defect is encountered while execution; it is passed otherwise.
More over I’ve seen publications that suppose failed test case % to be the best indication of product quality. I find such measure even weaker than defect trends that are also attacked as inadequate. For example this approach doesn’t differentiate if a feature is not implemented or there is typo on user screen.
In my projects I use different approach and it gives me a really useful measure. Please be patient and read the whole story backed up with IEEE standard.