Test

       We test to verify and validate. From the programmers point of view, there's focus on the functionality. I.e., it's a small thing, that the page is red, when the user wants a blue page, but quite serious, if the update of the database isn't usccessful, so the wrong player wins. (Also because the first thing is quicker to correct than the second.) The typical result of a test is also, that you find some errors, and then correct them. You can test both documents (e.g. a specification) and a program.
       A well organized test has its own document to run by, where you can mark whether item 1, 2, 3 etc. are OK. This test plan should be written right after the specification (and be updated concurrently).
       There are many different kinds of tests.
       The module/system test - here all parts are tested separately, and then the whole is tested. There's also a test for extreme conditions, like a power failure.
       The user test - here a potential user tests the program, and it's revealed whether the user can find his way around.
       The acceptance test - the purpose of this test is to let the customer see for himself, that the program does what was demanded, before responsibility is transferred, the money paid etc.
       The prototype test - here a part of the program is tested, before the program is fully finished.
       The peer review - here the program is tested by a colleague.
       The beta test - here the program is tested by users, unlike the alpha test (this concept is hardly ever used), where the programmers tested it themselves, and removed the worst errors.

Concept last updated: 07/08 2003.

Relations
can be part of

Other sources

TCP/IP Test Tidsplan

Libellus