I'm wondering how should testing take place in small teams (or start-up teams).

I'm talking 5-10 developers that are assigned to multiple development tasks.

From my experience there is little to none testing in the development process, but I also hear small teams can get through the initial level of software process maturity.

How does QA and testing take place during development in a mature-but-small team?

(please, if you can, describe the whole software process including who should be doing what)

EDIT (more detail):

I'm especially interested in a team developing a distributed processing-intensive back-end with a website as it's API. The two parts (back-end, front-end) are developed by two different groups of 3.

I want to understand who tests what, and when. If I write a module and it's unit tests, do I write integration tests when completing the code? Should you assign a developer on such a small group to focus on testing?

closed as too broad by Simon Bergot, gnat, Glenn Nelson, GlenH7, gbjbaanb Jan 22 '14 at 19:03

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • What kind of testing are you talking about? What kind of product? – Simon Bergot Jan 22 '14 at 10:38
  • I'm not sure what you mean, but I'm talking about testing the code (unit testing), integration, system and acceptance testing (and later on progression and regression). Does the actual final product matter? – Reut Sharabani Jan 22 '14 at 10:44
  • 2
    Well I would say that testing a web app differs from testing an image processing IP for embedded systems or a nuclear reactor controller. But maybe you can be more precise, because your question is very broad right now. What do you expect in an answer other than a description of all those kinds of testing? I don't think that there is One True Process which could satisfy all small teams. It depend of the culture, the budget, the criticity of the product, etc. – Simon Bergot Jan 22 '14 at 10:53
  • 1
    We can't "describe the whole process" on this site. That is a subject for which entire books have been written. The answer depends not only on the software being written, but the makeup of the team. – Bryan Oakley Jan 22 '14 at 18:46

If the team is mature, they should be writing both unit-level tests and automated acceptance testing. There's simply no good way to write robust code without testing. All of the good software developers I know are constantly asking themselves "how can I test this?".

I've worked on teams where each developer was responsible for testing their own code, and teams where there were one or more dedicated test engineers. In both cases, the teams were able to deliver high quality software. The teams I've been on that thought testing was not something a software engineer should do generally produced low quality software.

At the end of the day, the team should be responsible for the quality of the software they produce. Somebody needs to be writing tests daily. Whether they each take a part, they take turns, or they have a dedicated tester or two, should be left to the team to decide. To decide to do none of those is to decide to produce crappy code.

In my opinion, every software team needs an appropriate number of people dedicated to testing. The number goes up with the size of the team, and the number should never be less than one. In addition, every software engineer should be responsible for unit-testing their own software.

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