Quality Assurance & Testing

QA & Testing - What’s a test case?
.................................
What’s a test case?
..................................
Let’s start with the basics. What’s a test case?
IEEE Standard 610 (1990) defines test case as follows:
“(1) A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.

“(2) (IEEE Std 829-1983) Documentation specifying inputs, predicted results, and a set of execution conditions for a test item.”

According to Ron Patton (2001, p. 65),
“Test cases are the specific inputs that you’ll try and the procedures that you’ll follow when you test the software.”

Boris Beizer (1995, p. 3) defines a test as “A sequence of one or more subtests executed as a sequence because the outcome and/or final state of one subtest is the input and/or initial state of the next. The word ‘test’ is used to include subtests, tests proper, and test suites.

Good Test Cases /Cem Kaner

Bob Binder (1999, p. 47) defines test case:
“A test case specifies the pretest state of the IUT and its environment, the test inputs or conditions, and the expected result. The expected result specifies what the IUT should produce from the test inputs. This specification includes messages generated by the IUT, exceptions, returned values, and resultant state of the IUT and its environment. Test cases may also specify initial and resulting conditions for other objects that constitute the IUT and its environment.”

In practice, many things are referred to as test cases even though they are far from being fully documented.

Brian Marick uses a related term to describe the lightly documented test case, the test idea:
“A test idea is a brief statement of something that should be tested. For example, if you're testing a square root function, one idea for a test would be ‘test a number less than zero’. The idea is to check if the code handles an error case.”

In my view, a test case is a question that you ask of the program. The point of running the test is to gain information, for example whether the program will pass or fail the test.

It may or may not be specified in great procedural detail, as long as it is clear what is the idea of the test and how to apply that idea to some specific aspect (feature, for example) of the product.
If the documentation is an essential aspect of a test case, in your vocabulary, please substitute the term “test idea” for “test case” in everything that follows.
An important implication of defining a test case as a question is that a test case must be reasonably capable of revealing information.

----------------------
Acceptance testing
----------------------
Acceptance testing is a testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria of a given use case. It is usually performed by the expert-user, customer or other authorized entity to determine whether or not the system is acceptable. A test pilot is an aviator who tests new aircraft by fling specific maneuvers. In aeronautics top pilots, navigators and engineers conduct flight tests and at the end of the test missions they will provide evaluation and certification data.


-----------------------------------
A Use Case is not a Test Case
-----------------------------------
There is a growing trend of organizations using Use Cases as Test Cases. It is simply wrong. Use Cases are written by business analysts or project managers. Writing Use Cases takes a lot less time, requires fewer resources and less expertise.

Use Cases are user scenarios—typical sequences of tasks performed on the software by a typical user. A Use Case is useful in User Acceptance Test to verify the software works correctly in typical workflows. Use Cases cover only fairly normal end-user workflows.

Test Cases are written by engineers. Test Cases cover the software more thoroughly and in much more detail than Use Cases. Test Cases include every possible input that software is capable of (or is theoretically capable of); handling every type of data input/output, every expected behaviour, every warning, and every error case. There are a much more Requirements that are not covered in Use Cases. But all possible test inputs & execution conditions, must be covered in Test Cases.


================
QUESTIONS & Remarks
================
Are all the inputs to the system specified, including their source, accuracy, range of values, and frequency?
Are all the outputs from the system specified, including their destination, accuracy, range of values, frequency, and format?
- Planning tests case examination during the iterative software growth stages,
- Create tests case examination scenario, with input parameters and desired output data must be done upfront, before the coding starts.
- specify valid test case
- create a sequence of test instances in a batch,
- monitor test case execution in a Log file, and report success, failure, and a type of error or warning during and after the execution of the code