I’ve stated that I love exploratory testing. This is where you will find the most bugs rather than automation that focuses on regression testing and same with litmus manual test cases. Why? Because you have to do exploratory testing in order to get an idea how to write the automation and litmus test cases. I will stand by this claim.
To clear some confusion though, this is not to say that neither of these items are important. These regression types do still need to exist, it’s where your focus is. If you can some how make it so that you are doing more exploratory testing rather than spending time, maintaining or creating test cases either through automated or manual (litmus) means, then you will be more likely to find more bugs. Esp in products and companies that move fast like Mozilla. And of course, you need a way to measure what was covered, which litmus as well as unit tests and regression automated tests provide.
I will also state that code coverage tools can help some but they will still miss bugs. Not just UI bugs, but also code bugs. Why? Because there are paths that have not been taken into consideration that could be missing that could be considered bugs. More specific example would be things like forgetting to include an observer or an alert.
It is not a complete waste to use code coverage tools, it will give you some basis on how much is covered in various areas as a starting base. In QA, it’s about trying to make the unknown of how many bugs there are as little as possible and using various means, techniques, and tools in order to make it as small as possible in a limited amount of time. This means that you should try to figure out which tools, methods work best for you in terms of finding bugs in the areas that you are covering and use some risk analysis to determine the best outcome. With a stable, nonchanging build and unlimited time, it’s possible to run all sorts of test cover and eventually come to like a 99.99% coverage. The reality is that software keeps evolving and there are diminishing returns with running all tests. Each change of line in code is a delta, which should be checked. Running all methods could push you past deadlines. Doing some risk analysis and also time study and trying to make certain processes more efficient becomes necessary in my opinion. Theses are concepts from Industrial Engineering, that have been used for numbers of years. I am not advocating that each person should be studied by other people, but they should be timing themselves, taking personal responsibility for their time and trying to figure ways to shorten tasks the more and more they understand the tasks.
This is where the genius of being able to combine time use will be a great win.
If the automation is easy to create in terms of integration, and you can do it while exploratory testing, this saves a great amount of time.
seetest by http://experitest.com/ and testdroid recorder are great examples of this genius. See http://www.youtube.com/watch?v=2ZIVMIfZmvY
for an example of what I am talking about.
This allows you to do exploratory testing, and writing to tests that get automated in a faster fashion. Now if only they were open sourced…
Bottom line : automation should be easy to get written. This provides a way.
Filed under: Uncategorized 
