Agile Testing: A Practical Guide for Testers and Agile Teams

Keyword-driven testing is another tool used in automated testing, where predefined keywords are used to define actions. These actions correspond to a process related to the application. It is the first step in creating a domain testing language. These keywords (or action words) represent a very simple specification language that non-programmers can use to develop automated tests. You still need programmers or technical automation specialists to implement the fixtures that the action words act on. If these keywords are extended to emulate the domain language, customers and nontechnical testers can specify tests that map to the workflow more easily.

The sample spreadsheet in Figure 9-11 shows how one company used action words to automate their test setup. The same action words can be used to test. The words Signup, Signoff, and CCDeposit are words that are domain-specific. Their users could easily write tests without understanding the underlying code.

Figure 9-11 Sample test spreadsheet with action words

Combining data-driven and keyword-driven testing techniques can be very powerful. Fit and FitNesse use both keywords and data to drive tests. The other tools we’ve described in this chapter can also accommodate this approach.

Any test strategy can run into trouble if the code isn’t designed to be easily tested. Let’s take a look at testability concerns.

Testability

Business-facing tests built with appropriate design patterns and written ahead of any coding help the team achieve a testable code design. The programmers start by looking at the business-facing tests, perhaps together with a tester, analyst, or customer, so that the need to execute those tests are always in their minds as they proceed with their test-driven design. They can build so that the tests provide inputs and control run-time conditions.

Janet’s Story

I ran into a snag when I was trying to automate some GUI workflow with Ruby and Watir. The calendar pop-up feature was not recognized, and the data field was read-only. I took my problem to one of the programmers. We paired together so that he could see the issue I was having. The first thing he did was to understand the calendar feature. He thought it would be too difficult to automate the test, so he suggested another alternative. He created a new method that would “fool” the input field so it would accept a date into the text field. We knew the risk was no automation on the calendar, but for simplicity’s sake we went with his option.

Not all code is testable using automation, but work with the programmers to find alternative solutions to your problems.

—Janet

Let’s look at techniques that promote design of testable code.

Code Design and Test Design

In Chapter 7, “Technology-Facing Tests that Support the Team,” we explained how test-driven development at the unit level ensures a testable architecture. This is true for business-facing tests as well. The layered architecture Lisa’s team designed works just as well for functional testing. Testing can be done directly against the business logic without involving the user interface, and if appropriate, without involving the database layer. This doesn’t mean that the database layer doesn’t need to be tested. It still needs to be tested, just maybe somewhere else.

Testability has to be considered when coding the presentation layer as well. GUI test tools work better on well-designed code developed with good practices.

Lisa’s Story

When I first started trying to automate GUI tests using Canoo WebTest, I discovered that the HTML and JavaScript used in the system didn’t comply with standards and contained many errors. WebTest and the tool it’s built on, HtmlUnit, required correct, standard HTML and Javascript. Specifying tests depended on good HTML practices such as giving each element a unique ID. The programmers started writing HTML and JavaScript (and later, Ajax) with the test tool in mind, making test automation much easier. They also started validating their HTML and making sure it was up to industry standards. This also reduced the possibility of the application having problems in different browsers and browser versions.

—Lisa