In agile development, the team is responsible not only for development, but also for testing. However, many developers are challenged with the notion that not just any test is a good test.
Here is a fairly comprehensive list of criteria which good tests meet:
- Valid: It measures what it is supposed to measure. It tests what it ought to test.
- Clear: Test instruction and test objective should be clear.
- Comprehensible: The language of the test should be comprehensible to the reader.
- Relevant: It appropriately and accurately covers a significant portion of the Object Under Test.
- Focused: It should do one, and only one thing (“Single Purpose Principle”).
- Detailed: Failure conditions should be sufficiently specific to discover the source of the defect.
- Practical: It is easy to conduct and requires a low amount of preparation.
- Fast: It should take only an insignificant amount of time.
- Efficient: It only consumes a reasonable amount of resources.
- Unique: For one specific attribute of the software, there is only one test.
- Repeatable: If it is repeated, the result will not differ.
- Reproducible: It should yield the same result, regardless of where it is executed.
- Independent: It should not rely on the results of other tests.
- Economical: It should require lower creation and maintenance efforts than the value of the test (risk covered)
Violation of these criteria may (or may not) be a problem. However, they provide a good guideline when designing tests. regardless of whether these are acceptance, system or component (unit) tests.
Working with the list
When your test process has problems, check a sample of your tests against this list and try to discover hotspots for improvement.
When creating your first couple tests, you should pick some criteria from the list which seem to be the most difficult to achieve. Then design your tests to actually meet these criteria.
No comments:
Post a Comment