Comments on: Mending Broken Windows

By: Michael Johnston

Michael Johnston — Wed, 16 Feb 2011 22:40:37 +0000

Having just been through a release I would agree that we don’t communicate the impacts. I would also argue that it’s difficult to do in a meaningful way. I’ve spent a week consulting and fine tuning a test summary. Each stakeholder wants something different, and none want too much information. If i’m finding it difficult to pitch enough but not too much information i’m sure the testers have the same trouble.

I’m finding that time spent with stakeholders is always beneficial. challenging and always worthwhile.

I’d be interested in any reading recommendations you have.

By: Martin Jansson

Martin Jansson — Wed, 16 Feb 2011 17:13:04 +0000

One thing I see often is that we as testers adapt to our situation and plan accordingly. At this stage we take shortcuts based on our new situation. I rarely see us communicate back to our stakeholders what these shortcuts mean.

When I coach I tell the test lead to plan according what she and her group needs to do to meet a specific the information objectives and quality level. Lack of resources is a state that could change.

I think this area can be delved a lot deeper into. Weinberg has written a lot in this area and it might need to be resurfaced.

By: Michael Johnston

Michael Johnston — Tue, 15 Feb 2011 23:33:50 +0000

Thanks Martin.

That’s quite a thought provoking comment. Worthy of a dissertation in answer.
In short though I would say that there are a couple of things that can be done to help manage the testing debt. And avoid broken windows.

I’m keen on testing early, testing often and testing as close to reality as possible. But as functionality grows, it’s not possible to test everything and testing debt creeps in. Choosing what tests to run, managing that debt whilst being a bug advocate, or flagging failing automation to stop the broken windows is what makes us testers, not just robots.

I’m sure i’ll post again about these skills.