Breaking Down the Test/Dev Barrier

Similar to the solution I consider in my post on single-function roles, the Braidy Tester has a provocative new post entitled, "Let's Go Bust Some Silos" wherein he asks what happens when you get rid of the test/dev silos and have everyone work together under one roof.  Instead of having one group write dev code and not test it much and another team who wrote tests but didn't understand it much, have a single team which writes and tests fluidly.

One of his commenters, Jim Bullock, raises some good concerns about such an arrangement.  Is it really possible for someone focused on the creation to be objective enough to test?  Do we need someone tasked with breaking things to get over the tendency to see ones own success?  He also suggests that having test/dev silos help different sorts of personalities get along.  There might be some merit to this.  On a team where test and dev are integrated, a non-coding tester is likely to be treated as inferior.  On a test-only team, their value is probably more highly regarded.  This need not be so, but too often it is.

In considering this question, it is interesting to consider why we have separate testing teams to begin with.  How did they come about?  At one point all you had were developers.  They tested their own stuff.  Later, independent testers came into the picture and organized on independent teams.  Why was that?  If anyone was there for this formation or knows of books which speak of it, let me know.

I suspect that this happened because developers were found too busy to give sufficient time over to testing.  The desire for more features made it hard to take the time to test.  In a day without unit tests, the time it took to test was very large.  Stopping to do so might mean missing a deadline.  Based on that, it makes sense to bring in someone whose whole time is taken up by testing.  There is no pressure for that person to add features at the expense of testing.  Today, however, when we have automated tests and unit tests which can give us a lost of testing without a lot of time, do we still need this separate role?

Comments

• Anonymous
  April 07, 2007
  The comment has been removed

• Anonymous
  April 07, 2007
  James, great comments.  I generally agree with your position.  If you look over my blog, you'll find that I've written often against the idea of too much automation.  It serves its purposes, but there is a lot of room for someone who really understands the feature and is probing it deliberately.  Once you write some automation and run it the first time, you're done finding new bugs.  The same is not true of a tester.  Every time he looks at the product, there is a chance he'll find a new bug. The trick is finding the balance.  Like many things in life, this is a pendulum that constantly swings.  We swing from no manual testing to lots of it and back.

• Anonymous
  April 09, 2007
  I think that having developers test their own features is an inherent conflict of interest. Developers are primarily paid to produce features of shippable quality. If they are also in control of the process that assesses whether a feature has met its quality goal then there will be an ever present temptation to skimp on the testing, especially during crunch periods. Having separate testers and developers is just a recognition that we are all human. FWIW, I see feature testing as separate from code testing. Code testing is something that can be safely delegated to developers and often manifests itself in terms of unit testing, and sometimes in automated product testing. Investing in code testing is what good developers do to make themselves more efficient when adding new features and refactoring existing code. Feature testing, on the other hand, is all about testing whether the product is in a suitable state to be released to a customer. This involves not only knowing what the product is supposed to do and how customers are likely to use it but also where bugs are likely to lurk. A good feature tester will understand the product's internal architecture to a reasonable level of detail and will be able to target test cases toward known brittle areas or code that has undergone significant change or classes that are being worked on by less experienced members of the team etc. However, no matter how much a tester enjoys testing there is still something inherently satisfying about writing code that ships to customers. While I think it does make sense for testers to occasionally be developers (and vice versa), I just don't think they should be one and the same for a given feature.