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

Ken Pugh's picture Ken Pugh

A fellow consultant with Net Objectives, Ken Pugh has more than two-fifths of a century of experience in software development—from gathering requirements for stock market analysis to testing real-time radar systems. Ken consults, trains, testifies, and mentors from London to Sydney on lean/agile processes and technology topics ranging from object-oriented design and test-driven development to Linux/Unix. He has written several programming books, including the Jolt Award winner Prefactoring and Interface Oriented Design. He is currently writing Lean-Agile Acceptance Test-Driven Development. When not computing, Ken enjoys snowboarding, windsurfing, biking, and hiking the Appalachian Trail. Ken can be reached at

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!