Among the Standards guiding principles are that test development should have a sound scientific basis and that evidence of the scientific approach should be documented. Although the exact sequence of events for developing a test varies from program to program.
Before we can actually execute a test, we need to know what we are trying to test, the inputs, the results that should be produced by those inputs, and how we actually get ready for and run the tests.
Test cases are documented in a Test Case Specification. Test procedure are documented in a Test Procedure Specification(Also known as a test script or manual test script).
Testing may be performed with varying degrees of formality. The level of formality is also influenced by our organisation - its culture, the people working here, how mature the development process is, how mature the testing process is, etc.
Usually, testing of software is seen as the execution of the Test Object on a computer. The test object will usually call different parts of the program through predefined interfaces.
The objective of testing is to show that the implemented test object fulfills specified requirements as well as to find possible faults and failures.
Driver and stub combined establish the Test Bed. The tester must often create the test bed, or the test must expand or modify standard test beds, adjusting them to the interface of the test object.
Test Analysis is the process of looking at something that can be used to derive test information. This basis for test is called the Test Basis. A Test Condition is simply something that we could test. Testing experts use different names to represent the basic idea of a list of things that we could test.
We need some intelligent thought processes to guide our selection. Test Techniques are such thought processes. A testing technique help us select a good set of tests from the total number of all possible tests for a given system. The test condition that are chosen will depend on the Test Strategy or detailed Test Approach.
Test Conditions should be able to be lined back to their sources in the test basis - this is called Traceability. Test conditions can be identified for test data as well as for test inputs and test outcomes. Test conditions are documented in the IEEE 829 document called a Test Design Specification.
In practice, the number of test cases can reach hundreds or thousands. Traceability makes it possible to identify the test cases that are affected by specification changes.
Part of the specification of the individual test cases is determining test input data for the test object.
Test conditions can be rather vague, covering quite a large range of possibilities or it can be more specific. One test case cover number of conditions. Test cases can be documented as described in the IEEE 829 standard for test documentation. One of the most important aspects of a test is that it assesses that the system does what it is suppose to do.
In order to know what the system should do, we need to have a source of information about the correct behavior of the system - this is call an oracle or a Test Oracle.
Ideally expected results should be predicted before the test is run. Test cases should be prioritize and most important should be executed first. Test cases need to be detailed so that we can accurately check the results and know that we have exactly the right response from the system.
Some test cases may need to be run in a particular sequence. The document that describes the steps to be taken in running a set of tests is called a Test Procedure in IEEE 829, and is often also referred to as a Test Script.
Writing the test procedure is another opportunity to prioritize the tests, to ensure that the best testing is done in the time available.
Test Design techniques divided into 3 categories:
1. Black Box Testing
2. White Box Testing
3. Experience Based Testing
- Log in to post comments