Developer/Tester colocation, what a novel concept

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:

  1. The testers are attached to the project, but don’t sit with the developers
  2. The project had no testers.  Depressingly and stupidly common out in the world.
  3. 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.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • jmiller

    Chad,

    I’ve liked JIRA for bug tracking when I’ve used it in the past

  • KG2V

    Ah, you think NO testers are best, because then we don’t find any bugs, and if we don’t FIND any bugs, there ARE none, right? Right?….

    Sarcasim off

    Unfortunately, as you said, it seems to be the norm – you should see what I have to do to do unit testing – my boss has actually told me NOT to unit test “we have above average developers, and therefore we make many less errors than the average, so testing, including unit testing, is just a waste of time”

    AAARRRGGGHHHH

    But it’s a nice company to work for

  • http://www.hdri.net cmyers

    “Good bugtracking tool” seems like the three-toed jackalope or the spotted killer dolphin… do they even exist?

    If so, where the people in-the-know hiding them? Any recommendations?