Viability of a Development Team with no *dedicated* Tester role

Question

I've been thinking a lot lately about how to build a lean development team. Ultimately, I'd like to open up my own little software house with a small number of like-minded people. The goal won't be to become rich, but rather to have a healthy work environment.

So far, I'm defining a lean team as the following:

• Small;
• Self-organizing;
• All members must have QA in mind;
• Members must be capable of performing multiple roles

The last point is where I'm worried a bit because, as the mantra goes...

Developers make bad testers.

While I understand that, often, developers are "too close" to their code or their colleague's code to make higher-level assessments of quality, I'm not convinced they are de-facto bad testers. On the contrary, I'm of the opinion that the qualities of a good developer overlap greatly with the qualities of a good tester.

Assuming this is correct, I've been thinking of different ways of getting around the dev/tester problem and I believe I have come up with a viable model.

My model requires:

• A small software house with 2+ projects
• An Agile (iterative) approach to development and delivery
• 1 team per project
• All team members will be Software Developers
  • Their job description will clearly state Development, Quality Assurance, Testing, and Delivery as responsibilities

If all these preconditions have been met, then the projects can be organized in the following fashion (this example will refer to two projects, A and B):

• Every team member will alternate between Developer role and Tester role
• If a team member is a Developer on project A, they will be a Tester on project B
  • Members will work on only 1 project at a time, and therefore are expected to be acting as either a Dev or a Tester.
• A Role Cycle consists of 3 iterations as a Dev and 2 iteration as a Tester (again, on two different projects)
• Project teams would have 3 Devs and 2 Testers at all times.
• Member Role Cycles should be out of phase by 1 iteration.
  • This minimizes the abruptness of the team changes. For each iteration, 2 Devs and 1 Tester will remain the same as the previous iteration.

Given the above, I see the following Pros and Cons:

Pros

• Distributes project knowledge throughout the company.
• Ensures team members aren't testing the code they helped write.
• Out-of-phase role cycles means no project ever has a 100% member switch.
• Alternating roles breaks the monotony of boring projects.

Cons

• The iterations of both projects are tightly coupled. If one project were to cancel an iteration halfway through and start again, then the two projects would be out of sync. This would make the role-cycle difficult to manage.
• Hinges on hiring Developers open working as Testers as well.

I've received mixed reviews when discussing this approach with friends and colleagues. Some believe that few developers would ever want to alternate roles like this, while others tell me they personally would love to try it.

So my question is: Could such a model work in practice? If not, could it be tweaked into a working model?

Note: For the sake of brevity I have only focused on the Dev and Tester roles. I'll expand on other roles if needed.

Answer 1

I don't agree with

Developers make bad testers

Most of the teams I've worked on in my career have not had any QA support. This includes a couple of large, global corporations involving products like their global login and registration system. In another case, I had 30% of the company's revenue running through a box on my desk. (These practices are not advised BTW ;) ) These companies were reliant on the engineers to make sure their code worked correctly. And us, being detail-oriented, a bit compulsive, and proud of our work, would go to great lengths to make sure our software worked correctly.

Also, as a developer I do much more testing than the Testers. I routinely unit test my code to 90%, or 100% if I'm not working with Java.

I do like working with Testers because they do come at it from a different perspective, and catch things I didn't think of. But I really don't count on them to provide more than about 30-50% test coverage, while I hold myself responsible for 100%. (BTW That's not a slam on them -- they are usually spread thin across projects.)

Rather than ask the engineers in interviews if they want to do QA, ask: if a bug shows up in production, who's responsible? If I introduce a bug, and a customer experiences it, I feel bad and take responsibility. I don't blame the QA guys. IMHO That's the kind of engineer that you want to hire (and work with)

My method of ensuring quality is a) super aggressive unit testing (although I can't quite bring myself to do full Test-Driven Devlopment), b) a strong code review process really helps, and c) integrating an intolerace of and impatience with defects into the team culture.

It's always struck me that the most senior guys were the ones who were most dilligent and attentive to even minor issues, because they could point to a larger problem. But mainly they were the ones most willing to spend the time to get it right.

But most of the teams I've worked on, especially for small companies, have not had a formal QA component.

Answer 2

I agree with @Rob Y's answer, and would like to add a few points:

• In agile, dedicated testers within a team are an anti-pattern, because they force teams to pipeline work and be inherently inefficient. You constantly end up with stories which are "dev done" but not tested. Dedicated testers are fine if they work outside of the team (or a separate team).

• Dev make bad testers... and testers make bad testers. QA is hard. In fact, it's very hard. Your problem might not be people and roles. Your problem might be that your software is rushed out. Again, in agile, it's your team's responsibility to test before production (whether they have dedicated QA or not).

• QA is part of development, like refactoring, architecture, etc. It's the responsibility of a development team to produce software to a certain, agreed, realistic standard. QAs will not improve that standard. Better developers probably will.

• Provocation: Who says that QAs are better than developers at QA-ing? It's something people say but... [citation needed]. The needed "hacker" mentality of QA is a developer mentality. In fact, basically all hackers are or were developers, not QA...

• Provocation 2: 99% of QA work can be (and, dare I say, should be) automated via scripts. A good team will do this, and to do this properly you need... developers.

Answer 3

At a previous job, we had only developers and no QA staff. As a result there was no one else to blame if a problem made it through to production. We took our QA responsibilities very seriously, and relied heavily on automated test suites. Since writing automated tests is still coding, it wasn't a big deal to get developers to do it.

The key thing is to make it part of the culture of the team, and part of every project. We wrote up test plans (just brief lists of tests we intended to write for a project), and other developers would review and suggest cases and scenarios we'd missed.

If you're rigorous about it, it can work very well. It did for us - we had excellent uptime and low defects in an always-on e-commerce web service.

Answer 4

First a caveat - I've worked professionally as both a QA engineer and software engineer.

Could such a model work in practice?

Anything is possible.

While I understand that, often, developers are "too close" to their code or their colleague's code to make higher-level assessments of quality, I'm not convinced they are de-facto bad testers. On the contrary, I'm of the opinion that the qualities of a good developer overlap greatly with the qualities of a good tester.

It depends on what sort of testing you need. If you need mind-numbing, monotonous, repetitive manual testing to make sure that every single screen or element really has been translated to Elbonian... you're going to have problems.

And in my experience, every project requires at least a little bit of this sort of testing (even if not every project did that sort of testing). The problem is that you don't get this sort of testing from people unfamiliar with QA best practices. Hell, you don't even get it from people who know best practices, but "trust" the developers.

As a tester, you can't trust the developers. I've lost count of the bugs I've found that "could not have possibly been caused by that change" or "works perfectly well on my dev box".

Even if you can find developers who can tolerate not doing what they love to do 2 weeks out of 5 you also will run into this core contradiction. Worse yet, you're spending time and energy to train people to be good at two jobs rather than one. Companies have a hard enough time finding and training people good at a single job, let alone two.

Maybe you're awesome in some way I've not yet encountered - but I doubt it.

Answer 5

I think it could work, but there are a couple of things I would make sure you do.

1. Be very upfront about the dual roles to candidates. It's not for everyone for many reasons. If you have too many people who don't like it, you'll have failure and turnover.
2. Have a plan where you can evaluate the best way to incorporate this with the team. Although I like to focus on one task/project at a time, I'm not sure I would want to not be programming for a very long period of time. Maybe testing is a nice vacation away from programming. Not that it is easier, just using some different brain cells for a change. Be prepared to try it in different ways before you decide on what is best.

Synchronizing projects doesn't seem like a practical solution. If someone is a testor on a project, they may be the best candidate to replace a programmer and vice versa.

This plan doesn't let the teams self-organize enough. One strategy probably won't fit all teams and all projects.