- This topic has 2 replies, 3 voices, and was last updated 8 years, 5 months ago by
.
-
Posts
-
Recently there was a webinar by Kevin Harris entitled “Striving for Zero Bugs in the Test Environment”. Great webinar I thought – was there live and also listened to a couple of times since. I have heard a lot of this type of content in the past but on this occasion, struck a chord with me.
A thought though – does anyone feel that there would be any negative impact of not recording the defects you’re finding and dealing with them verbally? I get the concept and makes perfect sense but this requires a certain culture within the organisation?
I’m thinking from a measurement perspective, and process improvement – how can we tell if we’re getting better if all the defects are just communicated verbally during pair testing etc.
Say we spend twice as long in the “Dev” environment in order to have zero bugs in the test environment – does this actually mean we’re improving the process? We may be finding them “upstream” but are we conning ourselves?If the true measurement in this case is fewer defects full stop (not that we’re finding them earlier), then capturing that the improvement has worked will be difficult, though would more qualitative data (gut feel for example) be sufficient. Though I know, number of defects is not the only measure we can use.
Can we hamstring ourselves in the quest for data? In that we actually end up reducing the efficiency we can make just to report on the efficiency we have made with various changes?
@paul-french I think the webinar host @kevinharris is a member here so he might be the best man to answer your thoughts.
Hi Paul – sorry for the delay in responding!
Many thanks for listening in to the webinar – I’m glad you found it useful.
I guess it all depends on what you actually use those bug reports for. If we’re finding the bugs on the Dev machine, we save time on the bug logging, bug fix, retest, and cycle time. I’ve also found that the more you sit with the Developer doing your tests, the more they come to understand what and why you’re testing, and that helps them avoid those types of errors in the future. I’m lucky to work in an environment where the teams are trusted (and expected) to continuously improve the way we work, so no one else is interested in measuring the bug numbers outside the team.
Overall, I agree that the culture is very important. The trust and understanding of the people above you is too. We also tend to only hire people who fit our culture, and have good communication skills, and we end up with teams who can talk through problems and are empowered and capable of making positive changes quickly.
- You must be logged in to reply to this topic.