This guest blog post is part of an Atlassian blog series raising awareness about testing innovation within the QA community. You can find the other posts in this series under the QA Innovation tag. The post is written by Bryce Day, CEO of Catch and the driving force behind the development of the highly successful QA management tool Enterprise Tester. Bryce has been involved in software testing since 1997. Testers tend to talk testing. That means they want to know things like: the number of test cases, how many have passed or failed, which tests are assigned to who, and how many times has and issue been tested and retested. While all of these numbers provide interesting statistical analysis, they don’t provide the real oil that the management team need. In fact there is only one real measure that means anything and it’s a four letter word – Risk!A question I hear frequently is “what are the key statistics you use to manage your testing?” Look on forums and discussion groups and you’ll get a number of differing views on how best to manage your testing. I, too, have an opinion, but unlike many others I like to focus on what I consider the basics. Forget everything else including all those fancy statistics, risk is the only thing that matters. Not convinced? Well, let me change your mind. Testing versus Quality All testers talk about testing their organisations product, but frankly who cares about testing? What they should be worried about is quality! Quality is very different to testing. Sure, you can validate a products quality through testing but how many of you are called Quality Managers instead of Test Managers? Or how often do you hear in a team “how much more testing have you got to go?” instead of “what’s the current quality of this build?” There’s no doubt about it. Measuring quality and understanding the quality profile of the product is the key to what we as testers do. To me as a manager, quality is a reflection on how much risk I’m prepared to take. For example, I would want to buy a high quality car because my risk appetite for a car breaking down is low, but I’m willing to purchase a low quality $2 toy from a discount store because my risk appetite is much higher that it will break. How many of you reading this have had a discussion with your project manager or management team about companies risk profile around a product release? I would guess very few. So forget the current way of thinking about testing and think of it instead from a risk perspective. How much is too much? The question now becomes ‘how much risk are we willing to take around this project/product/sprint?” Agile guys might say that they bake quality into the process. Sure, sounds great, so do they actually know the risk profile of the project? My bet is that they know about as much as the waterfall or iterative methodology teams, which isn’t much. The only [...]
Previous Topic
