Identify the Essence of the Test to Reduce Automation Costs
Do you want to improve the readability of automation tests and make them easier to maintain when code or requirements change? Then you need to take a step back from the automation code itself and focus on what software consultant Dale Emery calls the “essence of the test.”
The essence of the test is “the responsibility it investigates, regardless of the technology used to implement the test,” says Emery. Similarly, Elisabeth Hendrickson says that when distilling a test, testers should “express the intent of the tests as clearly as possible without worrying (yet) about how these tests will be automated.”
Start with a simple naming of what the feature being tested does. Leave out incidental details like dollar signs, braces, and commands, and think about only the essential elements of the system’s responsibilities. “Create Account,” “Place Order,” or “Pay Bill” might be the essence of what the test investigates.
Think about what happens below “Create Account” or “Pay Bill,” and describe the essence of these things as well. For instance, in order to “Pay Bill,” the user’s credit card must be successfully charged. So the essence of “Pay Bill” might actually be “Validate Credit Card” or “Reject Credit Card.” When a credit card payment is validated, the system reports a “Status:” the bill has been paid. When a credit card payment is rejected, the system reports an alternate “Status:” the credit card is invalid.
Identifying and naming the concepts is essential to the system because doing so enables testers to refer to those names throughout the test, thus making the test more readable and more maintainable.
Take the simplification further and name the essence of the test down to the variable level. For instance, perhaps we have this test: “Reject Credit Card 60111111111111.” Is it immediately apparent why the credit card number “60111111111111” should be rejected? Emery says, “Any time spent puzzling out the meaning and significance of a test is maintenance cost.” To avoid this, refer to the essence of “60111111111111” in the test instead of the actual number. The essence is that this credit card number is too short, so an appropriate name might be “aTooShortCreditCardNumber.”
At this point the test might read “Reject Credit Card ${aTooShortCreditCardNumber}.” Sure, there is some syntax required here to pull the variable in, but the test is readable at first glance. If all automation tests are readable, identifying which ones need to change if requirements change is a quick job. Moreover, because essential keywords hide the details in one place, we only need to update the keywords—not the tests where the keywords are called. Design tests like this and test maintenance, which underlies the success or failure of the automation project, will be much less costly.
