What are the benefits of working in QA before working in software or research engineering? What about founding a startup?

Question

So I'm wondering what the benefits of working in QA are before switching over to software engineering. I'm not too concerned about getting pigeonholed into the role of QA or anything like that.

What are the most important things one would learn from taking the QA route first?

Also, what can I learn from being a QA that would benefit me if I plan to found a startup?

Answer 1

This is hard to answer in absolute terms because differences between QA and software engineering vary from company to company. Looking across the nine places I've worked, the difference is more pronounced in big companies than in startups.

Quality is probably less of a concern at a startup than at an established company because users who go with startups tend to be more interested in taking advantage of a new opportunity than in minimizing risk.

If you do QA at a startup, you may learn about moving quickly, living with resource constraints, and making trade-offs between quality and the interests of early adopters. You may be able to use what you learn right away at your startup.

If you do QA at an established company, you may learn about using more resources to achieve and maintain a higher level of quality for users who won't tolerate buggy software. You may not use those experiences right away at a startup, but it may help you plan for the future.

Answer 2

Having hands-on experience from different stages of the product lifecycle is always beneficial. Experience counts. Attitude is NOT a valid replacement for experience.

Startups could be (at least) two kinds:

• developing custom product for one or small number of customers: very concerned about the quality, making the good impression and building the trust
• developing product for mass market: more concerned about cool features, less concerned about the quality, because is hoping to gain two new customers with new features for each old customer leaving because of the bugs. This strategy can work while you have few percent of the total market, but starts be detrimental to growth once you get 10-20-30%.

Of course product should pass minimal requirements - if is too buggy to be used, it is too buggy, period. But (to certain level) early adopters are willing to tolerate quirks and weird workarounds, if other features of the new product cannot be found anywhere else.

As your product matures, this attitude has to change: Only very few companies can survive with the approach like Microsoft had: everyone knows you should do not even bother to use first two released versions of any new product.

All developers are concerned about the speed of the development, and the only speed which matter to startup is "speed to the market". If startup misses it's opportunity window, game over. Bigger company might have another chance. This inevitably will influence how either company values QA.

Basic automated unit and regression tests are crucial, especially in a startup, because you do not have resources to do lots of manual testing. All team members have to be very productive, and automated test will help them do so.