We've been cutting labels and sending products to testing for years - both developers and QA know the rules implicitly without even looking down at written guidelines. What scared me the most this week is that when system rules are violated and there is a massive confusion on both developer and QA sides, one of the arguments was "we've been doing it like that since I joined the company"
Nobody likes reading the rules, operation manuals and workflow guidelines, but still they are there for a reason. If you forget about them, you'll be hearing from me soon
Let's get a few things straight:
1) Devs, there's no more Continuous testing; you cannot just send in a new major build without some internal testing and expect to have QA determine if the product can start or not, then find/fix a few bugs each day until the build is stable for real testing; instead conduct a few days of internal testing (plan it in your Sprints) to pick the low hanging fruit, resolve critical issues immediately (product doesn't start, main features don't work) and write down all non-critical ones to forward to QA along with the first label to log down to bug tracking system
2) Devs, make sure you always send modified product version to testing; we cannot have two builds with identical versions that are functionally different just because engine takes too long to rebuild. Consider updating the way engines are referenced and versioning strategy, suggest solutions proactively; Everyone leads - proactively identify problems and solve them, don't ask questions but make recommendations
3) Devs, always send an official request for testing when a new build is ready; specify testing areas as detailed as possible even when it means you have to roll back your sleeves and write detailed guidelines for back-end high-tech stuff that QA might not understand on their own; Everyone shares - communicate widely and effectively, educate your customers
4) QA, it IS your job to determine if the product can start or not; Everyone serves - treat everyone as a customers and take personal ownership of their issues vs. "it's not my job" attitude; if you got a version that doesn't start at all assume that it did work on devs' side and that it is your job to isolate on which systems product works and on which it doesn't, then report Bugs
5) QA, report all found Bugs professionally following the established procedure without sending additional emails with built up emotions and no concrete analysis or actionable suggestions
6) QA, use your right to cut testing short if there are too many obvious Critical issues found, however always follow the procedure and send in testing summary at the end and allow devs to fix the Bugs to surprise you in the next test round vs. hate-mailing about the build quality
Upside from this week's confusion related with our new product is that almost everyone managed to transition to constructive discussions with actionable suggestions lead by analysis and pros/cons; we need more of this in all aspects of our work
No comments:
Post a Comment