I received a lot of generous and interesting feedback from my presentation, QA Role in Scrum – Leveraging Agile for Defect Prevention at PNSQC last October. Some came in the form of written comments on little sheets of paper handed out at the end of the presentations. One that particularly stood out for me was,
“Nice job not demonizing dev.”
I laughed on first reading it. Why would I demonize dev? We’re all on the same team; we all want to create a high quality product. Right? Right. Continue reading
Update February 19, 2014... Another great evening presenting on Agile Quality! This time at AgilePDX in Portland. Many thanks to Diana Larsen for the invite, and to everyone who attended for the great conversation!
Links to the white-paper and slides here (or slides with animation here.)
East coast Agile enthusiasts: Hope to see you in April at QUEST 2014 in Baltimore!
QA Managers get asked all the time, “How long will it take to test it?” Scoping testing is one of the most challenging tasks we face in QA. To understand why, we first need to look at the question itself. What the questioner really means is, “How long will it take for you to tell us it’s okay to ship it?” This is a different question, and a much harder one to answer. …read more >>
Test automation, it turns out, is a broad term. The tools with which to do it range from the massive, expensive, infrastructure intensive, to the open source download-and-run. The latter are easy to deploy and make quick use of in an agile environment, but even in this context some suggest the best outcome is achieved by assigning dedicated resources to it. Continue reading
Recently, I did a Google search on “agile test automation”. I’m struggling to figure out how, if at all, test automation fits in to a very agile and loosely structured software development model. I come from a world of three- to twelve-month software release cycles. Where I work now, we release new code to production at least once a week. It’s exciting and invigorating. What I most enjoyed about writing test automation was Continue reading
Our team had another heated debate last week about the definition of Severity vs. Priority in software defect logging. Every bug database I’ve ever used contains the fields Severity and Priority. I’ve always thought of the distinction between the two as pretty straightforward, but it turns out it’s not. (Life would be a lot less interesting if everyone always agreed with us, wouldn’t it?) Some engineers want to use the Severity setting to prioritize bug fixes. And some QA people want to use the Priority setting to tell engineers which bugs to fix first. I don’t subscribe to either of those uses of the fields. … find out why >>