There is a lot of terminology surrounding testing, but not until recently has there been an industry standard. A new standard (first published in August 1998) seeks to provide a standard set of terms: BS 7925-i Glossary of Testing Terms. Although a British Standard, it is being adopted by the International Standards Organization (ISO) and will hopefully become an ISO standard within two or three years. An error is something that a human does, we all make mistakes and when we do whilst developing software it is known as an error. The result of an error being made is a fault. It is something that is wrong in the software (source code or documentation - specifications, manuals, etc.). Faults are also known as a defects or bugs but in this course we will use the term fault. When a system or piece of software produces an incorrect result or does not perform the correct action this is known as a failure. Failures are caused by faults in the software. Note that software system can contain faults but still never fail (this can occur if the faults are in those parts of the system that are never used). Another term that should be understood is reliability. A system is said to be reliable when it performs correctly for long periods of time. However, the same system used by two different people may appear reliable to one but not to the other. This is because the different people use the system in different ways. The definition of reliability therefore includes the phrase ‘under specified conditions'. When reporting on the reliability of a system it is important to explain under what conditions the system will achieve the specified level of reliability. For example, a system may achieve a reliability of no more than one failure per month providing no more than 10 people use the system simultaneously.
[...] We feel that all developers should use static analysis tools, since the information they can give can find faults very early when they are very cheap to fix Dynamic Testing Techniques 4.1 About Testing Techniques The need for testing techniques In Session 1 we explained that testing everything is known as exhaustive testing (defined as exercising every combination of inputs and preconditions) and demonstrated that it is an impractical goal. Therefore, as we cannot test everything we have to select a subset of all possible tests. [...]
[...] Staffing and Training: Needs Staff required and any training they will need such as training on the system to be tested (so they can understand how to use it) training in the business or training in testing techniques or tools Schedule: Milestones for delivery of software into testing, availability of the environment and test deliverables Risks and Contingencies: what could go wrong and what will be done about it to minimize adverse impacts if anything does go wrong Approvals: Names and when approved. [...]
[...] If you want to find as many faults as possible as quickly as possible, you may start with invalid boundaries State Transition Testing This technique is not specifically required by the ISEB syllabus, although we do need to cover one additional black box technique. Therefore the details of this technique should not be in the exam, but only an awareness of another functional technique. State transition testing is used where some aspect of the system can be described in what is called a “finite state machine”. [...]
[...] Other useful measures include the number of incidents or faults raised together with either the number resolved and / or the number of faults expected Test control Test control is about management actions and decisions that affect the testing process, tasks and people with a view to making a testing effort achieve its objectives. This may be the original or a modified plan. Modifying an original plan in the light of new knowledge (i.e. what testing has revealed so far) is a frequently necessary and prudent step. [...]
[...] The Oracle Assumption is the name given to the (usually correct) assumption that it is possible to predict the expected results Prioritization of Tests Importance of prioritizing We have already said that we cannot test everything, exhaustive testing (testing all combinations of inputs and preconditions) is impractical. It is easy enough to identify far more test cases than we will ever have time to execute so we need an approach to selecting a subset of them. Selecting test cases at random is not an effective strategy. [...]
APA Style reference
For your bibliographyOnline reading
with our online readerContent validated
by our reading committee
