As a manager an consultant one of things I frequently encounter when I am hired to increase productivity in the test lifecycle is conflict.
Now there are contructive ways for conflict to flourish but with respect to QA/ testing one of the most common occurences in the Start Up arena is the need to get deliverables out of the door compromising the test cycle. Or unrealistic expectations on R&D creating a need for them to borrow testing time in the lifecycle which creates friction between the R&D teams and QA.
In a previous Start Up the VP of R&D would allow me as QA Manager to borrow back Developers to help with end-run testing. Whilst not optimal the extra hands did help but, there are a few things I learnt to do from this and other occurences:
1. Getting more hands to help if they are not guided doesn’t necessarilly produce good results.
2. Developers shouldn’t (except for Unit Testing) test their own code; the corollary to this is pairwise review which works well for testing too; you can team the developer with a QA tester or another developer.
3. Have the test cases mapped out and ready to distribute/ accessible to the extended testing team [yes, this is why we love Microsoft Team System] and ensure the same for the Bug Tracking.
4. Make it fun! Use Best Bug Awards and a big wall chart in the QA Lab; if the company will spring for it even have a small cash prize/ meal out for the absolute best showstopper.
5. Don’t let this become habit. It’s not healthy for QA to continually compromise the test cycle and R&D testing means they aren’t developing and Developer hours are costly.
When I did Best Bug Awards I liked to use a wooden plaque with a gold painted big bug stuck on it. We would ceremonially review the bug and award the plaque (to be held until the next contest) at our weekly meeting; the person who found the bug would receive the award and then be responsible for explaining the process of how they tested and found the bug.
The most common phrase I used to hear from R&D when we found a bug was “I can’t reporduce this.” so make the QA Lab accessible (even by Remote) and encourage the Developers to feel at home to use the Test environments to see how the bug occurs in the wild.
All of this is part of a greater process with an underlying philosophy of marketing QA as valuable but also ensuring that other teams don’t see QA as an interference in their progress.
A lot of this boils down to something my Grandpa told me,”You can draw more flies with honey than vinegar.” This especially holds true for the sort of work done by QA/ Testing.