Lately it seems as if my QA Team is doing quite a lot of juggling.
We juggle...
When we have more work than timeWhen we have staffed for three simultaneous projects, but we are currently testing eightWhen new requirements pop up at the last minuteWhen planned releases to QA slip, but the ship date doesn'tWhen a developer casually mentions that he decided to refactor one of the core componentsWhen it is decided that we should "fast track" an unscheduled changeWe can't staff for the worst case, and have people on the bench. So if we are temporarily understaffed, we have to continually decide "Who gets to be unhappy this time?".
It gets complicated, since testers are not fungible.
The worst part about it - when you juggle, sometimes things get dropped!
When things get crazy and we can't get additional help, we:
- Just because Suzy has an hour of free time on Tuesday, doesn't mean that she can jump in and contribute an hour's worth of testing on Project X (which she has never before even seen).
- Just because new hire Brian comes free for 1 day sometime next month doesn't mean he can contribute a day's worth of testing on Advanced Project Z.
- Just because Ted is expected to be out for a few days with back problems, doesn't mean that Jake can drop what he's doing and fill in - Jake has other commitments.
The worst part about it - when you juggle, sometimes things get dropped!
When things get crazy and we can't get additional help, we:
- Try to re-order tasks so that we are not a bottleneck
- Try to remove obstacles and distractions early
- Allow people to work from home if they can be more productive
- Run interference for the busy testers
- Deflect requests until later, when possible
And we juggle!
 | My name is Joe Strazzere and I'm currently a Director of Quality Assurance. I like to lead, to test, and occasionally to write about leading and testing. Find me at http://strazzere.blogspot.com/. |
Your approach sounds practical and pragmatic. I hope that despite the busy schedules, your testers have time for learning, experimenting and improving, that keeps them passionate about their work and continually improve quality.
ReplyDeleteIn our company, the testers are integrated into the development team. When we get behind on testing tasks, the programmers pitch in on testing tasks. They mainly help with automating regression tests, but they also do manual exploratory testing or write up test cases when needed. Our whole team is committed to producing the highest quality software we can, so nobody minds doing what's needed, even things that might not be part of their "job description".
Thanks for the comments, Lisa. Sounds like a great team approach to quality in your shop!
ReplyDeleteWe work very closely with our developers too, although they usually aren't in a position to help much with the testing effort (they are juggling their priorities as well).
On occasion, we have had a developer write up test cases and perform the testing. We did this a while back for some back-end enhancements. As part of this effort, I spent some time with the developer reviewing the tests he expected to execute. Interestingly, I found that his tests were signficantly skewed toward the positive tests, and virtually ignored negative test cases.
I spent some time with him talking about testing philosophy, and helping him expand the types of tests to be performed. In the end, it worked out reasonably well.
When time allows, I hope to present a "Testing for Developers" session to the entire development team. Hopefully, this will give them an appreciation of what we do, and better prepare them to help out should the need arise.