The Quality Assurance (QA) department is roughly a bunch of testers debunking your app(s) all day, giving the green light for releases, handling Alpha / Beta programs. And much more.
But without a QA department in a software company, issues arises too often in the field, and problems costs more to fix. However, most companies starts in a garage, with 1 employee being yourself, and then grows into a software company.
When do you tell it's to create such department ? Anything to do with the size of the company, the problems it encounters ?
We are a small new startup with a single developer. Whenever we talk about adding additional resources my first response is hire me a QA person!
it should work without QA but with
It depends. If you're a small company with a little efficient team and your error rate is low, it's probably not the biggest problem you need to solve.
If the market's pressuring you to produce faster, the number of developers is growing, and the error rate is beginning to hurt your client relationships, then you can consider fixing the process by making it more formalized.
The trick to surviving in a small company is to only implement process, when it's value pays for itself. If you're hiring people to get an improvement in quality, it has to be pretty big to pay for itself, which means that prior, the quality has to be pretty bad (and damaging business).
Often a better support process is far more important, because even the best QA group will still occasionally let bugs get out there. The clients will be way more impressed with you if you handle the fixes/patches well (they won't notice a significant reduction in bugs, unless the prior versions were all really really bad).
Paul.
To play devil's advocate: "QA department" is a red herring, and in many cases a cop-out.
Let's deal with red herring first. "Department" is a statement of organizational structure, who reports to whom; that is secondary. "QA" is an umbrella term, with no particular meaning. (Don't believe me ? Here is a test - would you want to not "assure quality" ? Of course not. Everyone wants that.)
So what is it you really want here ? You want to learn about your software's failure modes before your users do.
If your software has "issues" in the field, well, that means the work of figuring out failure modes isn't getting done, and you may want to hire someone with the chops to do that.
I happen to believe that a developer's job description should include at least some of that. If I hire testers, I'd prefer them to have to work hard to find failure modes. If the app crashes within seconds of a tester putting their hands on it, the developers are going to hear about it in direct terms. The phrase "egregious defect" comes to mind.
On to the cop-out. The truth is, you can't put quality into the product after the fact. But "we should hire some testers" is the cry of many developers caught red-handed turning in code well below acceptable levels of quality. (I know - I've been one of them.)
So, if you do hire someone with testing experience, the right thing to do IMHO is to put them to work right alongside the developers. Reporting to the same manager. With the same mission: make it correct in the first place.
I guess you grow a QA department organically: even when you're a solo programmer, you should be doing some of the work that a QA person does.
If, for example, one person spends 10% of their time doing QA activities, then as soon as you get to ten people, you can have one person devoted to QA.
I am currently running a garage-startup software company, right now I substitute a Q & A department with family and friends, I call them up or get them to come over for a few beers and test drive my product for me.
This "hallway" testing has worked pretty good so far, then again my product isn't aimed at technically skilled users, if it was I might have a harder time finding testers.
If you don't have readily available family and friends i'd recommend tossing an advertisement in your local classifieds or craigslist, it should be hard to find a few students or someone that will test for minimum wage.
As for when to hire full time QA personnel I would say depends solely on the financial state of the company.