Definitions of Verification (V), validation and testing (V and T) - as per BS7925-1.
The V-model of testing, showing that it identifies baselines (both testing and development deliverables) which should be tested at each stage of development (i.e., testing throughout lifecycle).
The cost of faults escalates as we move the product towards field use. If a fault is detected before field use, the cost of rework to correct the fault increases dramatically because more than one previous stage of design, coding and testing may have to be repeated. If the fault occurs during field use, the potential cost of the fault might be catastrophic. If faults present in documentation go un-detected, then development based on that documentation might generate many related faults which multiply the effect of the original one.
Early test design can prevent fault multiplication. Analysis of specification during test preparation often brings faults in specifications to light.
The cost of testing is generally lower than the cost associated with major faults (such as poor quality product and/or fixing faults), although few organisations have figures to confirm this.
What to consider, based on IEEE 829-1998 Test Plan Outline.
Acceptance testing may be the only form of testing conducted by and visible to a customer when applied to a software package.
User acceptance testing - the final stage of validation. Customer should perform or be closely involved in this. Customers may choose to do nay test they wish, normallly based on their usual business processes. A common approach is to set up a model office where systems are tested in an environment as close to field use as is achievable.
Contract acceptance testing - A demonstration of the acceptance criteria, which would have been defined in the contract, being met.
Alpha & beta testing - In alpha and beta tests, when the software seems stable, people who represent your market use the product in the same way(s) that they would if they bought the finished version and give you their comments. Alpha tests are performed at the developer's site, while beta tests are performed at the testers' sites.
Integration with other (complete) systems.
Identification of, and risk associated with, interfaces to those other systems.
Incremental / non-incremental approaches to integration.
Explain that non-functional requirements are as important as functional requirements.
Very briefly cover each of the listed techniques. (Load, performance and stress as defined on System Evolutif web pages; security, usability, storage, installability, documentation and recovery as defined in Myer's book).
Functional requirement as per IEEE definition, which is "A requirement that specifies a function that a system or system component must perform".
Requirements-based testing - where the user requirements specification and the system requirements specification (as used for contracts) may be used to derive test cases.
Business process-based testing - based on expected user profiles (e.g. scenarios, use cases, etc.).
Integration testing tests interfaces and interaction of modules/subsytems.
Role of stubs and drivers.
Incremental strategies, to include: top-down, bottom-up and functional incrementation. Non-incremental approach ("big bang").
Overview of BS 792502 Software component Testing; component test process. (also known as Unit, Module, Program Testing).
Testing old code - with poor/missing specifications.
Scope of testing with respect to changed code.
Impact analysis is difficult - so higher risk when making changes - and difficult to decide how much regression testing to do.
This page is very heavily based on the ISEB Foundation Certificate Syllabus.
This is unavoidable, as to pass the exam, you have to use their terminology.
Back to top Home Next Serious Stuff
© 2002. Copyright Sue Nethercott.