In my firm, we have the practice that the test phase is made by the same people who develop the software and you are responsible for what the client does.

The organization has 2-3 software packages with a lot of code that is always modified every day in each part or we add new functions to them.

Please can you tell me what the professionals (if there are) do to leave all the development and test to the same people (1) and the tests and what are the cons (if there are) to assigning testing to another person or team?

Can you show me a model of the testing process that has been successfully applied and that works well in a firm of 50 people who work on different projects, divided into teams of 3-4 people?

  • Frank, I tried to clean up your English. I hope I didn't change the nature of your question.
    – user246
    May 31, 2013 at 14:59
  • 2
    Are you having quality problems? Do you ship with lots of bugs or not? Why do you think you need a testing process? May 31, 2013 at 16:25
  • I would follow Phil's questions... How complex those packages are? Can they be tested in isolation by non IT people from your organization? At what level do you find problems? When integrating the packages coming from different teams or not?
    – dzieciou
    Jun 1, 2013 at 9:16

3 Answers 3


The short answer to your question is that if the same person does both the development and the testing, he's going to bring a lot of assumptions into the tests. On the other hand, he probably already knows the weak points and how the code works, so he's got a lot to offer in the testing process too.

It doesn't sound like you have dedicated testers, so working in those constraints, I think one of the first steps you could do to improve your tests would be to have coming up with and designing test cases be a collaborative process. With teams of 3 or 4, that shouldn't add too much overhead to people's jobs and will get more diverse ideas into the process.

Having dedicated QA engineers really has value. Quality and testing, not the development of features or behaviours, is going to be on their mind full time and they're going to add a lot of depth to your testing, but I don't know if that's an option available to you in your organization.


Here are thoughts from my experience in making a transition, small team, no dedicated testers towards adding a test member. Your situation (company, product, customers, technology) is probably different that I experienced, so please take caution:

  • At some point in the project, frequent releases of new functionality requires the overhead of running regression testing on the old functionality. It can be more effective to have a test team handle the regression testing, so the developers can concentrate on new functionality. (preferred automated regression)

  • Be careful when introducing a test team member, and make sure that
    the current developers don't relax their personally quality
    standards. The current dev team should not relax, assuming the test team will take on the testing they were previously doing. This may
    cause a paradox, adding testers results in poor quality.

Sounds like you have multiple project teams. Perhaps try your new practice on one team only, as an experiment.

Good luck


From having worked in groups as you seemed to be working into managing QA groups of all sizes I can tell you that dedicated QA people can bring things to the table that are hard to get otherwise.

My advice would be to look at your output. If the product(s) that you are delivering has the quality your customers are happy with don't change a thing.

But if you are seeing an increase in tickets and issues, it may be a good idea to look at the cause. Many times, this happens when the product has matured enough where the testing required has passed the level that the developers can or want to do. In that case, offloading the work to dedicated people is a good idea.

The hardest thing I found that developers have trouble with is regression testing. Testing the same things over and over in different ways is a very mundane task that developers seem to have a hard time with.

Just as development experience is desired and measured in years, so is testing experience. Good testers, like good developers, can have a 6th sense on what to look for and where to look for issues.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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