I asked a friend/coworker a question at one point in time about ideas and how to prove that you had the idea first?
The friend replied can they show the idea in practice or have they done it in practice to show it before you showed the information?
And to that, I thought it was a good enough reply. I mean after all, if they had the concept of how to do things such as finding more bugs and what not, they would be working towards that goal to prove it right? If they believed that exploratory testing was the way to find more bugs, then they would already be researching that information to try to become experts and not having to ask for experts in that field right?
In an interview question, I was asked an unique question of “What does automation show you?” My answer was “change”. The reason I answered this was because change in the code means change in the result of the test. It doesn’t necessarily mean that there couldn’t be bug in the automation test, or the automation tests were rigged to alert when a bug was fixed etc. You still need to verify that the change in the test result is the correct behavior. So if a person that understands these concepts that regression automation tends to give a lower frequency of finding “newer” bugs, and understands that “exploratory” testing leads to a higher bug count, then wouldn’t he be leaning towards how to do more exploratory testing? Perhaps even trying to figure out where automation might be applicable to exploratory testing? Not only that… wouldn’t he be finding a lot of bugs to try to get the data to back up the fact that he could find more bugs?
Automation can be done on exploratory testing in my opinion, but the act of creating the automation and also verifying the automation takes time. Things that can be automated are redundant one off tasks like creation of test files, or variants of test cases. I am amazed at mozilla’s fuzz testing. I still think that there are room for potential growth here in automation for exploratory testing.
[Don’t get me wrong. There is a need for regression automation, so that the product can quickly be detected for change that occurs throughout the product. My point is that if someone is claiming the credit for a task without backing it up with empirical data, then how can he really take credit for the idea]
That goes along with the concept of bug finding. In my opinion, it’s really whoever gets to the bug first and looked at that gets credit for the bug. (Some bugs end up getting written, but not understood well or overlooked so it then gets dupped forward). It doesn’t really matter in the end result of the product who finds the bugs, but more so how the end product looks like after the bugs get decided to be either fixed, defered to the next project, or never to be fixed. Theoretically, since the developers are writing the code, they should end up being the first ones to write and fix their own bugs. Esp if their task list is done through bug writing.
The point is, we’re all a team. I agree that QA should be the leaders in understanding how to find defects in products. Having said that, they should not be the only ones looking for defects.
Most people in the industry is familiar with the cost graph of showing that bugs have a higher cost the longer it lives in a product. (If you’re not here is a sample chart ( http://agileelements.wordpress.com/2008/04/22/cost-of-software-defects/ )
Looking at the chart, if this chart is correct; I believe that this shows that having QA from the beginning of the design and the specifications, should add up to cost savings in the long run. If the QA person is able to voice their concerns, and have these concerns addressed early; then chances are that it may end up curving the issues later at the end and quite possibly having to redesign the feature/product. This all depends on how much the QA is involved, and if the team is open to hearing the concerns in the very beginning. It may go to show why Steve Jobs had talented people on the design team and how he assured the quality of the product from the inception of the ideas that were presented.
Designers, Developers, and QA aren’t the only stake holders. In the end, it’s also the end users and how effective the product becomes. When they are able to speak up in the beginning, the product I believe tends to be in a better quality state. I am not the only one thinking this way, see James Dixon’s blog about open source quality assurance.
As a bottom line, and a leaving factor… after worrying about how do I prove that I came up with the idea first and certain techniques… I came to realize that I was dealing with something trivial in the big picture of things. Who cares who gets credit, because in the end it’s about finding the bugs and getting them solved, so that we get a high quality product. We’re all on the same team. And in the end, I’m happiest with this answer to my own question.
Filed under: Uncategorized 
