When is it time to have a QA department? [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 5 years ago.

Improve this 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 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 2

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 3

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 4

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 5

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 6

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.