Testing
Testing is part of verification and validation:
- Verification: does the software conform to specifications and regulations
- Validation: is what we are building the software that the client requires
Testing involves executing the software and evaluating its behaviour, it can be automated and can only be applied to code. Inspecting involves scrutinising code / documents by direct examination, there is no code necessary and this can be labour intensive.
Link to original
Test Case
A test case is a set of conditions under which a unit / component / system is considered to be working as intended or not.
Link to original
Test Suite
A test suite is a set of test cases that demonstrate that a system meets certain expectations.
Link to original
Validation Testing
Validation testing checks whether software meets the requirements.
Link to original
Defect Testing
Defect testing checks whether the software is free from defects.
Link to original
Black-box testing
Black-box testing is test cases determined based on requirements without regard for code structure, it does not consider how the system works.
Link to original
White-box testing
White-box testing is test cases determined based on understanding of code / design structure, aiming to test each program path.
Link to original
Testing in a software process
Testing in a software process
Testing can be implemented during the development of the software at different stages:
- Design: n/a
- Build: development testing
- Deploy: release testing
- Maintain: n/a
Link to original
Interface Testing
Interface Testing
Link to original
- Parameter interfaces: data is passed from one method to another
- Procedural interfaces: set of procedures encapsulates a subsystem and other components interact with the subsystem through these procedures
- Shared memory interfaces: block of memory is shared between two distinct processes
- Message passing interfaces: one subsystem is designed to respond to requests made by other subsystems
V-model
V-model
The V-model is a type of process where we sequentially design each component in more depth and write suitable tests as we go along, then after building everything we test everything from the smallest components first.
Link to original
User Testing
User Testing
Customer tests system to determine whether it is ready:
Link to original
- Alpha testing: selected users test the system during development
- Beta testing: a release is made available to a larger group of users
Acceptance Testing
Acceptance Testing
Is used to assess to what extent the software is acceptable to the client.
Link to original
Performance & stress testing
Stress Testing
We can start a stress test on a piece of software and gradually increase load to examine behaviour at failure point. We can identify actual performance limits, test failure behaviour and reveal defects that only arise at high loads.
Link to original
Test Driven Development
Test-driven development
Writing tests before code clarifies requirements to be implemented. Tests are programs rather than data, so:
- can be executed automatically
- test includes a check that is has executed correctly
- usually relies on a testing framework
Though programmers usually prefer programming to testing:
- they may take shortcuts when writing tests
- some test are difficult to write
- difficulty judging completeness of a set of tests without full spec
Link to original
Automated v. manual testing
Automated Testing
Automated testing is useful as:
Link to original
- It protects the code from introduction of bugs.
- Takes significantly less time than manual testing whenever changes are made.
- Reassures the client of code quality.
- Informs future developers of expected behaviour.
Partition Testing
Partition Testing
Inputs and outputs are grouped into partitions containing similar values. Unit tests are written to cover at least one value from each partition.
Link to original
Guideline-based Testing
Guideline-based Testing
Choice of tests is dictated / informed by rules of thumbs, heuristics and similar rules. For example:
Link to original
- “Include test cases with empty array, singleton arrays, and multi-element arrays inputs”
- Choose inputs that trigger each of the error messages
- Design inputs that cause input buffers to overflow
- Repeat the same input or series multiple times
Code coverage
Code Coverage
Code coverage testing seeks to measure how completely tests check the code.
We look at Statement coverage, Branch coverage, Loop coverage, Condition coverage, Path coverage, and Cyclomatic coverage.
Link to original