Having worked as an SDET on several great software development teams, I’ve had the opportunity to become familiar with various approaches to automated UI testing. The truth is, there isn’t much variation at all. The common approach is to develop a library of scripted automated test cases identical to a library of scripted manual test cases.
It may seem there is benefit to having the computer perform the same test steps that would be run manually, but there are heavy maintenance costs, and limitations to reporting and alignment with acceptance criteria. This approach also fails to maximize the ability of the computer to perform a large number of validations in a minimum number of steps, providing accurate, detailed and meaningful results.
Every test case, whether manual or automated, includes three main phases:
- identify/create data to be used for the test
- navigate the necessary path through the UI using the identified data
- validate by comparing the actual results to the expected results.
These three phases are recognized in The Agile Alliance Guide which recommends their use in writing Acceptance Criteria for User Stories. That guide uses the terms Given, When and Then, which are growing in use. This format improves the readability of manual tests within a library and reveals commonalities, but there is little that can be done to take full advantage of identified commonlities.
Though some automated test libraries apply this format to group test steps and provide some code reuse, they tend to fall short in providing effective reuse at the level of the common test phases: initialization, execution, and validation. Developing modules, if you will, at this higher “phase” level makes it possible to build a more resilient and efficient library of tests that provide more detailed and useful test results.
When tests reuse Initialization modules, reliable test data can be provided without the overhead of maintaining test-specific data. When tests reuse Execution modules, resilient paths through the application can be maintained with minimal effort. When tests reuse Validation modules, verification of specific requirements are readily available for review.
This modular approach results in much more thorough verification in fewer test executions, and a library of tests that invites change, making it much more responsive in an agile environment.
You can begin reconciling your method of test case development to this approach, whether working with an existing test library or starting from scratch. The first step is to label clearly the three phases as they exist in tests you review or develop. The comments “Initialization”, “Execution” and “Validation” (or if you prefer, Given, When and Then) can be used. Doing so will provide the information needed to take this approach to the next level.
Be reconciled!