[DanielRibeiro]

For startups you usually don't have enough people to have QA team. Therefore you have to take a more lean approach: Build Quality In.

On the other hand, when you are building your MVP, progress is not built features, but validated learning. So QA tasks takes more of an approach of building measuring tools (which have to be done by the people building the MVP).

Even on a later stage startup, QA takes a whole new role, specially when you start doing continuous deployment and start developing immune systems. These can get quite complicated (think of Netflix Chaos Monkey[1]), and having a dedicated team can be beneficial.

What we don't need is a 20th century waterfallish QA. But ensuring the quality of a product[2] has never been more important.

[1] http://www.codinghorror.com/blog/2011/04/working-with-the-ch...

[2] http://www.ashmaurya.com/2011/06/your-product-is-not-the-pro...

[MartinCron]

Build Quality In isn't just something you do when you don't have the luxury of a QA department. It's something that you can do to prevent having to have a distinct QA department at all.

[DanielRibeiro]

Agree. Having a seperate department can be helpful for large organizations, so that you can have one team supporting many products. However, if you prefer to hire generalists[1][2], then you can do away with it. Which is also a great away to mitigate Conway's Law[3]

[1] http://jessicamah.com/the-ceos-job-part-2

[2] http://blog.eladgil.com/2010/12/5-myths-to-building-awesome-...

[3] http://en.wikipedia.org/wiki/Conway%27s_Law