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 everyday 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 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.
–
user246May 31 '13 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?
–
Phil KirkhamMay 31 '13 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?
–
dzieciouJun 1 '13 at 9:16

2 Answers
2

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 development of features or behaviors, 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 a 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.