Better Software - November 2008 - (Page 21)

Management Chronicles STORY LINES • Functionality changes that aren’t reported to QA can result in timewasting bugs. • Keep the QA group in the loop by letting it help keep the spec up to date. • Inviting QA members to development scrums and meetings keeps them up to date on changes and helps them gain technical knowledge. • Consider putting the specs on an internal wiki to help them become a living document. “Well, a lot of changes are decided on the fly.” “If clients want to change something, they need to be able to,” Corey said. “Of course,” Olivia agreed. “But just tell us about it.” Corey shrugged. “The code is the priority.” “In other words,” Lynn thought, “they don’t think about telling QA.” “I hate adding more process,” Lynn said. “But we might need to.” Olivia broke in. “What if you cc me when you’re telling the client or other developers about the change? I can take care of forwarding the info to the right person on my team.” “That would really benefit development,” Lynn pointed out. “QA’s test cases could then concentrate on finding real bugs.” Lynn had her doubts that development would make that change overnight. She’d seen that QA team members were now attending scrums, but she had the feeling that the new attitude would take time. “And, there’s another problem,” Olivia said, shaking her head. “I have to be honest with you. We can’t always document some of the more technical things, such as network protocols or API changes, so we can’t be solely responsible for updating the specs. But if we added a section in the project leader’s weekly status report to identify those changes, it would warn QA not to write test cases based on outdated info.” “But the status only goes to the client,” Corey said. His eyebrows knit together. “Send it to the mailing list,” Olivia suggested. “I guess that’d be OK. If we want to go big, we could use the wiki to track the spec changes so you don’t have to search the mailing list every time you want to find one. As they come from the stakeholder, we could even track the requests in a table that shows the request, who requested it, and the request status.” “When does QA need to know that a code patch implements a spec change?” Lynn asked Olivia. Olivia took another sip of tea. “Before we have to test it. Ideally, with enough time to identify and adapt all affected test cases or write new ones. We just want to be confident that the test plans reflect what needs to be tested.” “We already have sections in our code patch submissions that summarize changes and unit test results. QA already reviews this, so what if we also include a section that tracks when a patch implements a requirement change?” Lynn suggested. “I guess that wouldn’t add too much to the process,” Corey said. “You know,” Lynn reflected, “he’s really been a lot easier to deal with since he switched to decaf.” {end} What methods have you used to keep non-developers in the loop? Follow the link on the StickyMinds.com homepage to join the conversation. www.StickyMinds.com NOVEMBER 2008 BETTER SOFTWARE 21 http://www.StickyMinds.com http://www.rallydev.com/bsm http://www.rallydev.com/bsm http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - November 2008

Better Software - November 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles Getting Agile with User-Centered Design Google Web Toolkit Simple Summaries of Complex Projects Product Announcements 10 Things You Might Not Know About … The Last Word Ad Index

Better Software - November 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.