An Introductory Acceptance Test


the percentage was correctly determined. The user interface might look like:”

Discount Percentage Test



Customer Type


Item Total




“With this UI, Tom or I could more quickly enter in all the combinations that are shown in the test table. It would cut down on the possibility of repetitive motion injuries. Our workman’s compensation insurance likes that idea.”

“We would still need to run Tom’s original script for a couple of instances to make sure that it were properly connected up to the discount percentage module. But unless there was a large risk factor involved, you might just run it for a few cases such as:





Item Total

Customer Rating

Discount percentage?

Discount Amount?









“This UI has penetrated into the system. It exposes a test point within the system that allows easier testing. Let me give you an analogy between the difference between this method and Tom’s original test script. Suppose you want to build a car that accelerates quickly. You know you need an engine that can increase its speed rapidly. If you could only check the engine operation as part of the car, you would need to put the engine in the car and then take the car on a test drive. If you had a test point for the engine speed inside the car, you could check how fast it sped up without driving the car. You could measure it in the garage. You’d save a lot of time in on-the-road testing if the engine wasn’t working properly. That doesn’t mean you don’t need to test the engine on the road. But if the engine isn’t working by itself, you don’t run the road test until the engine passes its own tests. “

“If you’re not into cars, let me give a context diagram, as below. The Order Summary Screen connects to the system through the standard user interface layer. The Discount Percentage Screen connects to some module inside the system to some module. Let’s call that the Discount Calculator. By having a connection to the inside, a tester can check whether the internal behavior by itself is correct.



XUnit Testing

Debbie explains, “The next way I could perform the testing is to write unit tests for the discount calculator. These unit tests are usually written in the program language of the application. Here’s a sample of what these tests look like. I know you’re not a programmer. But as you can see, it can be a little harder to determine exactly what is being tested.”

class DiscountCalculatorTest





DiscountCalculator dc = new DiscountCalculator()

assertEquals(0.0, dc.computeDiscount(10.0,


assertEquals(1.0, dc.computeDiscount(10.01,


assertEquals(1.0, dc.computeDiscount(50.01,


assertEquals(1.0, dc.computeDiscount(.01,


assertEquals(1.0, dc.computeDiscount(50.0,


assertEquals(5.0, dc.computeDiscount(50.01,





“Luckily Tom has done some programming, so he can read the code.” Debbie quickly shoots a smile at Tom. “However any time we make a change in the tests that Betty and the stakeholder can read, I also have to make a change in these tests. That’s a little bit of waste. And to effectively produce software, we’d like to eliminate that waste if possible. So Betty, Tom, and I selected the next mode of testing.”

Automated Acceptance Testing

“The three of us agreed that the examples in the table accurately reflected the requirements. So there would be less waste if the table did not have to be converted into another form for testing. There are several available test frameworks that can use this table or a slightly altered form


About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.