Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Being in the embedded world I have always tested products that goes to OEM's or end clients, I have never tested a product that my company really use. Besides the fact that you can use and feel the product in the real world, what are the differences ?

share|improve this question

Yes. They are vastly different.

Testing code to be used only by a captive audience has a completely different set of risks, schedules, priorities, impacts, etc. "Good Enough" means something very different for an internal audience than it does for paying customers.

The impact of poor quality has a completely different dynamic.

Very often, the budget allocated is completely different.

share|improve this answer
"Good Enough"is really pain in the... I can only guess that when management knows that a bug will directly hurt their pocket they will not use this term. – Rsf May 31 '11 at 12:55
Rsf - I have to disagree. To me, you can always spend more time testing, enhancing, and improving. "Good Enough" is the appropriate business measure. But since "Good Enough" is a contextual attribute, it is different in every situation, particularly for in-house products versus products which provide revenue. – Joe Strazzere May 31 '11 at 13:37

I think the main difference is the availability of users who actually use your products. If you are shipping an internal system, you have access to users who actually used it day to day, and you can ask them questions, study their usage or get their direct feedback.

Working on an architectural piece, a library or an embedded component, you would only get that feedback from a "Man in the middle" and not the actual end users.

share|improve this answer

If I have understood your question: It really depends only on the product under test. There should be no difference regarding your approach to the testing activities.

share|improve this answer

In addition to what Joe notes I have seen internal applications often get the "well it works here, and its only us so quality doesn't need to be stellar" attitude get used. This is wrong. Anything that goes out should be put under the same guidelines for quality, other people in the company are Customers to, and you can get to them easier and have a better opportunity to stop by and see how the tool/product is being used.

Often this is skipped or neglected, but I always think of it this way: if its not something you'd want on your computer at home, don't ship it.

share|improve this answer
Is shipping it your decision, or the decision of the budget holder? – testerab Jun 1 '11 at 0:36
In some places it's been mine as QA and Release Manager, and in others it's been a group decision within Engineering. The advantage of being in small, web based product companies is the decisions are more egalitarian. – MichaelF Jun 1 '11 at 11:53

It depends on how critical the software is to your business. If bugs in the software "put a kink in the money hose", as my boss would put it, you need to test it just as thoroughly as something you would ship.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.