Habit #2 of Stephen Covey’s, “The 7 Habits of Highly Effective People” says,
Begin with the end in mind
The end of a well written test case is the validation. And in my experience, beginning test development with the validation helps inform the development of the other phases of the test case — initialization and execution.
The most common practice in manual testing is to write a separate test case for verification of a specific requirement. Each “passed” test case represents alignment of the application with a very specific requirement. For manual testing, this approach makes sense, ensuring accurate and comprehensive accounting of each requirement.
However, this approach fails to leverage the computers ability to quickly and accurately verify any number of requirements, without the risk of overlooking a single one. Though there is benefit to the speed at which the computer runs tests written in a manual style, automating tests using this approach will never unleash the full potential of the computer.
It is a widely held belief that a well written test verifies one and only one requirement. To fully realize the potential of the computer, this definition must be expanded for automated testing: a well written test validates that the current state of a specific entity meets all related requirements. Examples of entities are: web page, database record, or browser cookie.
Consider it this way: Given the related systems in an initial state, When a path is executed through the application to a specific destination, Then the state of a specific entity can be validated. Combined with a modular test design, this approach supports well agile approaches like Business Driven Development (BDD).
Rather than numerous test cases using equivalent test data, navigating the same path through the application, with each verifying a very specific requirement, instead a single test can use one set of test data in an initial state, execute the necessary path, and validate any number of requirements for an entity. The validation of an entity can be described using an individual verification for each requirement, making it easier to use the requirements to reconcile the actual results.
Reconciling your method of test development to this approach involves starting each test case with the validation statement. In automated tests cases this line will look something like “expected.validate(actual);”, with the validation details encapsulated in the validate() method. In manual tests, this line will be something like “Validate [web page]”, with a reference to the validation details. Continue writing each preceding line of your test until the test data definition is in place. For many, this will seem awkward at first, but I encourage you to follow this approach strictly for at least one software delivery cycle, then evaluate the overall results of this method.
Be reconciled!