Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

closed as primarily opinion-based by GrandmasterB, mattnz, Martijn Pieters, Bart van Ingen Schenau, gbjbaanb Feb 25 at 10:31

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

    
    
While there is overlap regarding whether Developers can or should be testers, I think the crux of this question is about the out-of-phase 2 roles on 2 projects model. –  MetaFight Feb 24 at 17:40
2  
FWIW my personal opinion is that you're risking quite a lot with approach like that. I am an ex-tester (and not the worst one) and when I once landed in a project where I could "interlace" 2 roles I first thought wow, a chance to figure how to do that right. After about half year I changed my mind and never want to try that again. Both roles (dev and QA) require 100% focus to do it right, but when you interlace, you distract and loose either in quality or in productivity or in both. BTW getting dedicated tester in that project produced most impressive ROI I ever witnessed –  gnat Feb 24 at 17:48
2  
@gnat, but you haven't explained why a Developer couldn't fulfil the Tester role. Granted the person in question would need to take it seriously as a full-time role, which is why I suggested they alternate projects and only work on one project at a time. I don't expect any Developer to be able to do this... just those who would make good Testers had they chosen that path. –  MetaFight Feb 24 at 18:27
2  
Paraphrasing what you want to do :"I want to open a medical surgery, rather than hire a couple of anesthetists, I'll employ enough surgeon's and rotate them thorough that role". Your proposal shows a (typical) lack of understanding of what a professional tester offers a team. You could do it, many do, some make it work. What you will never know is what you are missing out on and what you could be doing better. By the way - Testing is not QA - just one lesson a professional tester will teach you. –  mattnz Feb 24 at 19:37

5 Answers 5

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.

share|improve this answer

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.

share|improve this answer
    
Maybe my model needs a Sr QA role to review the proposed approaches of my dev-testers and to recommend best practice approaches. Oh, and most people don't find me awesome, but my Mom does :) and that's good enough for me! –  MetaFight Feb 24 at 20:58

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.

share|improve this answer

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.

share|improve this answer
    
The Tester role in this case would probably involve manual and automated testing. I would expect developers to write unit and integration tests, but the Testers would do the same as well. The exact division of coded test writing would hopefully be a natural equilibrium reached after a few iterations. –  MetaFight Feb 24 at 20:54
    
It really shouldn't even be a case of whether candidates are willing to play dual roles or not. If you want to run a successful company you should put people where they excel. Why put the guy on testing who can design and code 2 reliable systems on his own where it takes a team of 4 or 5 to do a single system in the same time? Likewise, testing has its own skills to be able to do it well. The biggest advancements in human civilization occurred when humans started to specialize. Why would running a software company be any different than mother nature has already proven works best? –  Dunk Feb 24 at 23:25

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.

share|improve this answer
    
this post is rather hard to read (wall of text). Would you mind editing it into a better shape? –  gnat Feb 25 at 10:34
2  
Sorry, morning brain-dump. I've broken it up now. –  Rory Hunter Feb 25 at 11:36

Not the answer you're looking for? Browse other questions tagged or ask your own question.