Testing phase in the development

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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.