When is it time to have a QA department ?

Question

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 ?

Answer 1

As soon as you can afford it. You will never have a product which will be as reliable without a qa department than with one. Programmers don't make good QA people, and it is always better to have a second person (or more) reviewing how the app works.

All good software companies, and organizations with a good IT departments which create programs have a qa team. It's vital to software development.

Answer 2

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!

Answer 3

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.

Answer 4

Well - you want someone other than the programmer who wrote the code testing. That doesn't mean you need a QA department. In a lot of shops the business analysts will also do testing which is a lot more economical because you can only be testing during the later part of the build, not during requirements analysis and design. In a very small shop you probably don't even use the word business analyst but you know what I mean - product or design people who don't code. Even in a very large company this model has its advantages; testing groups can take on a life of their own.

Answer 5

it should work without QA but with

• CI Software
• company programming (and analyse and design and and..) guidelines and some tools to "force" the programmer to go with them
• some reviews now and then
• test stages e.g. team-test-environment, integration(all applications together) and consolidation (same as integration but with copies of production data)
• if neeeded a release planning group
• and .. well .. good craftsmen programmers

Answer 6

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.

Answer 7

As a former QA manager of a successful software company, I'd say grow it as soon as you release your first program. (Before, if possible). Really, as soon as you can afford it. But, as a developer, you should be doing a lot of the testing yourself during the entire dev cycle, not just at the end. QA's job (depending on which book you read) is to handle a lot of legacy testing, SMOKE testing, regression testing, real-world testing, and writing automated test procedures, processes and plans, etc.

Ad hoc testing is only a small part of what QA should be doing. There are two major areas of focus for QA. 1) Does the software DO what it is supposed to do, and meet the requirements in a way that is usable by the customer, and 2) Does the software NOT do what it's NOT supposed to do.

Planed, procedural and Ad hoc testing are the basis of QA. I've found that if you only do one type of testing or the other, you will not have a successful QA cycle.

I've released software without QA when working on my own, but I can tell you, it is ALWAYS more error prone, no matter how much I test it. A second+ set of eyes is the best thing for software.

Just make sure you build your team out of A.D.D. anal-retentive, computer geeks. You'll get your best results that way. :) People who are PROUD when they can make someones software go BOOM... heh.. (Just kidding.. I know a lot of QA Testers who do not have A.D.D)...

Answer 8

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.

Answer 9

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.

Answer 10

As soon as the code base grows so big that a single person cannot know all the details.

Reasoning behind this is that 90% of the regressions are made because programmers are unaware of the whole picture and possible side-effect of their code on the rest of the system. In such cases you don't even know that you should never supply -1 as a age parameter or something like that. In most cases, the interfaces should be clear and have error checking, but in large code bases it slips, also when you rush to meet the deadline, or work long hours are concentration drops.

So, although you should do basic testing even when you're a one man show, stuff like Unit Tests and similar automated testing facilities should be used as soon as code grows big enough that you (or anyone else who might be working with you) cannot grasp the entire system in mind.

Answer 11

Hey.
When you have one - two person company hiring a tester may be overkill. Try to spend some time on testing by yourself. Or ask a friend developer (who is not on the team) to play with app for some time. Or ask a friend (non developer) - almost like User Acceptance Testing.
Hire when you will start to sell software, when you will have 3 or more developers, when you will have two much on your mind to do testing (and I mean really testing not 'it starts on my machine', but 'I've been trying to crush it for several hours but it still works. Maybe I should get really creative?').

Answer 12

The Quality Assurance (QA) department is roughly a bunch of testers debunking your app(s) all day

I am troubled that you view QA as "a bunch of testers debunking your app" like QA is a road block to the final product. It makes me think you have had a bad experience with QA in the past. Instead try to look at the value QA brings to your company. You want the end user to be able to rely on your product from the beginning. If the end user is finding issues or defects, and becoming frustrated with your app or website, they trust your app less and less. QA is supposed to mitigate that risk of users losing trust in your app. If the QA isn't doing that then they aren't bring the value that is a must-have for any application. At that point, you need new QA. Not just button-pushers. QA that knows the application just as well as the developer. QA that collaborates with the developer and product owner to make sure everyone is on the same page in regards to requirements and the expectation in the final product.

One final note is developers are not QA. Developers should only put their QA hats on when absolutely needed. This is tough in a small company of 1 or 2 developers. So I agree with others when they say get QA as soon as you can. At my on-site location for a large software development company, developers only put on the QA hat when we have hard deadlines that need to be met and QA time is at a premium. Even when they do put their QA hats on, the testing process is reviewed by one of the lead QA on that development team to ensure that the dev is testing the application fully and effectively. Only until the QA lead is happy with the level of testing that has gone into the portion that the dev has tested will the QA lead sign off on that portion.