Being in the embedded world I have always tested products that go 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?
Add a comment
|
6 Answers
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.
answered May 31, 2011 at 12:28
-
"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.– RsfMay 31, 2011 at 12:55
-
3Rsf - 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. May 31, 2011 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.
answered May 31, 2011 at 11:25
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.
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.
-
-
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.– MichaelFJun 1, 2011 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.
I think that it is one and the same thing. If you are in a top software testing company, they will emphasize equally on both of the products. It is the quality that all matters. If we are able to get our in-house product tested well than only we can able to satisfy the customer needs.
All it depends on the management of the organization. If they are good enough to allocate time, budget and resources then definitely Internal projects will also be of the same quality.
