test design

Exploratory testing has gained increased recognition as a valid testing methodology. As a test manager or engineer you may be considering which approach to take. However, just as with other aspects of testing, such as automation, its application must be carefully chosen to ensure a successful outcome. In this article we examine the factors you need to consider when making that choice.

This is the fourth and last in a series of articles written to, a) introduce you to the most important diagrams used in object-oriented development (use case diagrams, sequence diagrams, class diagrams, and state-transition diagrams); b) describe the UML notation used for these diagrams; and c) give you as a tester a set of practical questions you can ask to evaluate the quality of these object-oriented diagrams.

When building large test suites, one problem that crops up is test case redundancy. Test suites are especially vulnerable to this when many members of the test team are writing test cases. The likelihood of one engineer writing test cases that are somewhat covered by another engineer's is very high. This results in duplication of effort when executing the tests. I will present some strategies for avoiding this problem when constructing the test suite, as well as methods for maximizing efficiency with your test suite.

Imagine a world where applications are written with automated testing in mind. Fantasy? Before you dismiss the idea, read this column. Linda Hayes makes some simple suggestions for designing for testability, including using unique names and adhering to class consistency.