Okay, I’ve never bought into the idea that the testers have to be aloof and independent from the developers to maintain objectivity. We’re all on the same team, and frankly, I find the idea that only testers are concerned about quality to be somewhat insulting. Quality and productivity should be everybody’s goal on the team.
In terms of tester interaction, I’d say that I’ve worked projects that fall into three patterns:
- The testers are attached to the project, but don’t sit with the developers
- The project had no testers. Depressingly and stupidly common out in the world.
- The testers are colocated with the developers in a common area
Guess which arrangement I think is by far the most effective for producing quality code? My tester is sitting across the table from me working through exploratory testing on the ASP.Net portion of our current project. Any time he finds a problem with the website he’s calling me over to show me exactly what’s going on and how it should work. I don’t have to waste anytime going back and forth writing emails, or phone calls, or comments in a bug tracker trying to understand the issue. Because of the open line of communication from him to me I’ve been able to rapidly close down the UI glitches. The faster we can close down problems the more time he can devote to deeper exploration and edge cases.
On the other side of things, I’m available any time he has a question or is blocked. In an iterative environment, or in our case a QA resource-constrained environment, the development team has to make a conscious effort to keep the testers fully utilized. You cannot afford to have your testers idle for 3/4 of the iteration only to work heavy hours at the end. If they need some code migrated, an environment problem resolved, or a question answered, it’s probably more efficient for the team as a whole for you to stop coding and get the testers moving again. In my case, I’ve been able to answer some questions about the way the code works that have stopped my tester from spending time on some unnecessary or invalid test cases. It goes back to Mary Poppendieck’s talks on the fallacies of point optimization. In other words, oftentimes me going slower to make him go faster makes the team as a whole go faster.
We do a lot with FitNesse testing, and we gain a lot of value from that FitNesse testing, but there’s no way FIT style testing will be effective without very close collaboration between the testers and developers (and customers, but you just never get everything you want). I can’t find the link anymore, but I read a great, great post a couple years ago called “the power of the almighty Yo!” Simply put, as much as possible you want questions about a system’s code, tests, or requirements to be accessible by a quick “yo, how are we…?” query.
Previous to having a tester on our team and in the office, we worked with a tester that was remote to us in a different office. The tester’s primary mode of communication was the (awful) bug tracking system. That’s horrendously inefficient and it flat out sucked. Please don’t take this to mean that I’m saying not to use a bug
tracking tool, just that the face to face communication is more
efficient for solving and fixing bugs. Bug tracking is an auditing process, not an effective means of communication. Of course some of the reason I’m down on the bug tracking tool is how much we all hate the particular tool we use.
P.S. If you’ve got a good tester like I do, go give him/her flowers/donuts/etc. immediately. They seem to be rarer than good developers.