RE: [kanbandev] Re: Best Practices for Testing Group
- View SourceI'd like to do that David. Of course our group would have to get corporate clearance to do this, but that is doable. Thanks.
Best regards / Mit freundlichen Grüßen,
Robert Bosch LLC
Senior Programmer/Analyst (CI/AMM1-NA)
401 North Bendix Ave.
South Bend, IN 46628
Tel: 1 (574) 237-2290
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of David J Anderson
Sent: Tuesday, January 22, 2008 7:48 PM
Subject: [kanbandev] Re: Best Practices for Testing Group
Wow! This is great story. You guys should think about submitting an
experience report for Agile 2008 and we'll see you in Toronto.
--- In kanbandev@yahoogrou ps.com, "Landes Eric (CI/AMM1-NA) "
<eric.landes@ ...> wrote:
> I like your thought's Stuart. I may give this a try. Our
experiment so far with Kanban for Sustaining Engineering has been a
great success. We have cut our cycle time to half of what it was, and
our backlog is at the lowest point I've ever seen it. With that in
mind I would like to attempt working on quality issues, and your
suggestion is great. Thanks for the input.
> Best regards / Mit freundlichen Grüßen,
> Eric Landes
> Robert Bosch LLC
> Senior Programmer/Analyst (CI/AMM1-NA)
> 401 North Bendix Ave.
> South Bend, IN 46628
> Tel: 1 (574) 237-2290
> eric.landes@ ... <mailto:eric. landes@.. .>
> ____________ _________ _________ __
> From: kanbandev@yahoogrou ps.com [mailto:kanbandev@yahoogrou ps.com]
On Behalf Of Stuart Corcoran
> Sent: Monday, January 21, 2008 4:04 PM
> To: kanbandev@yahoogrou ps.com
> Subject: [kanbandev] Re: Best Practices for Testing Group
> We agree you should have a separate QA group of professional testers.
> Since you don't have that I claim the ROI of defining and implementing
> a process to employ developers as testers is lower than simply
> eliminating the per-UAT test step.
> The way it would work is you tell the developers they will not be
> required to periodically (or constantly) switch roles and become a
> tester for someone else's work. However, any bugs that escape
> development are the responsibility of the developer. They will be
> required to drop their current task and fix and retest the bug. Also,
> they will not be given any schedule relief for their current task.
> The message is "you are responsible for quality, so do what it takes
> to get it right".
> This should lead to self-correcting improvements in developer
> estimates and behavior. Developers would (and should be allowed to)
> solicit their peers for not only code-reviews and the like, but actual
> functional testing.
> Obviously this is simply building up rudimentary a QA/test practice
> within your development organization, but it's across all developers
> and isn't that where we want the quality to be built in anyway?
> The average WIP-time will lengthen naturally over time but this is
> time you would have spent in a pre-UAT test step. And over time it
> could become more efficient than a separate test step.
> My first job as a developer was in an organization such as I
> described. Although there were no WIP-time metrics I can tell you the
> quality was very high. Post-development bugs were rare and considered
> quite an embarrassment to any developer.
> Good luck,