Should a test plan for internal software account for the error states of all possible configurations?

Ie: I have an app.config with some file paths. Should the test plan have steps for testing what happens when those values are incorrect?

  • BTW the question title should mention "internal software" as that is an important point for this question. Commented Oct 4, 2010 at 16:25

4 Answers 4


Two schools of thought on this:

  1. If it's likely to cause an issue, then yes it should.

  2. On the other hand, since it's an internal app, you may not want to spend too much effort dotting every I and crossing every T.

The last one hinges on the scope of the software. If it's just a simple utility that makes something a bit easier to do, then it may be fine without very robust error handling. If it will get a good amount of use, especially by many different people, then it should be relatively robust as the users will likely come to depend on it.


Consider creating a tool that generates a random, but valid, configuration, to be used as part of your test scripts.

  • I like the idea generally, as generating random valid inputs can help find errors arising from situations that you never considered but if you can test for "all possible configurations" I see no reason not to and therefore no need for random inputs.
    – PhillC
    Commented Feb 27, 2012 at 14:14

In an ideal world, yes.

Even if it an internal app, you can't control its use by users and the more it is used, the more it will probably be used in ways you hadn't thought of.

However, we don't always live in an ideal world, so justifying the "budget" may be tricky - "it works, move on".

At the very least, I would advise implementing some form of logging so when (if?) problems do arise, you have a head start on recreating them. As it is an internal app, getting hold of the log files shouldn't be a problem.



(Unless you want the internal users calling you every time there is an error in the install)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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