7 Things About Acceptance Test Driven Development Everyone Should Know

Agile methodologies have been around for more than two decades, and have given rise to a number of development frameworks. We’ve all heard of SCRUM, Test Driven Development (TDD), Paired Programming, Extreme Programming (XP) and the likes.

While each of these frameworks are quite popular, some are more so than others. After all, all things are not made equal.

Software project teams’ preference for one framework over another can be based on a number of factors – chief among them the type of project itself, ease of use, availability of supporting tools, conducive organisational structure (read management support) and skills.

Of late, I’ve begun noticing one particular framework being bandied about a lot. It’s not necessarily a new thing, yet is now rising in popularity among developers and testers alike. As with all things, it is quite possible that not everyone understands this framework well enough, and just like you can implement SCRUM in letter and not in spirit, some people have started using the term Acceptance Test Driven Development fast and loose.

So in this post, we’re going to look Acceptance Test Driven Development (ATDD).

We’ll cover the 7 key things everyone should know about Acceptance Test Driven Development, and help you uncover yet another tool that you can use for effective project delivery.

#1 – What is Acceptance Test Driven Development (atdd)?

Acceptance Test Driven Development (ATDD) aims to help a project team flesh out user stories into detailed Acceptance Tests that, when executed, will confirm whether the intended functionality exists.

“By continuously testing for the existence of a given functionality, and writing code to introduce functionality that can pass the Acceptance Tests, developers’ effort is optimised to the point of just meeting the requirement.”

In Scrum, you take a user story, and work with the Product Owner to flesh out the detailed Acceptance Criteria that when fulfilled will indicate the requirement represented by the user story has been met. The Scrum team then write Test cases that can specifically test for each Acceptance Criterion.

The test cases are executed immediately after they are written and before any development begins, causing the test cases to fail. The developers then write just enough code to pass the test cases. When the test cases are executed again after coding, they are expected to pass this time.

This is Acceptance Test Driven Development.

By continuously testing for the existence of a given functionality, and writing code to introduce functionality that can pass the Acceptance Tests, developers’ effort is optimised to the point of just meeting the requirement.

#2 – How is ATDD different from TDD?

Not much in spirit. ATDD borrows from the spirit of Test Driven Development (TDD) in that both techniques allow test cases to be written and executed (and hence fail) before even a single line of code is written.

The main difference is that ATDD focuses on testing for business user functionality, while TDD has been traditionally used to run/automate unit tests. In general, TDD is the pioneer that ATDD emulates to fulfil functional testing – however, both the techniques have the same aim: write just enough code, reduce developer efforts, build to detailed requirements and continuously test the product to ensure it meets business user expectations.

#3 – ATDD alone isn’t enough to make your product release-ready

ATDD is good for optimising your development efforts. It isn’t enough to push your product to release. ATDD is only as good as the number of acceptance tests your SCRUM team are able to identify for a given user story. Theoretically speaking, ATDD will help you deliver 100% test coverage. This is, however, not always the case.

From experience

I see new products or enhancements trending towards ATDD to take advantage of the lean coding effort. During product development phase, the team aren’t yet thinking about keeping the product release-ready. They’re hoping to clear as many of the functional niggles as possible to keep the Sprints going until they have enough developed product in hand to finesse.

It is prudent to build more rigorous functional testing into your Sprints to keep the product relatively bug-free. Where this isn’t possible (believe me, it isn’t for some companies), you have to resort to a waterfall traditional test cycle at the end of the sprints. I know – this isn’t really being Agile – but the goal should be to ship out a product that works – so whatever it takes.

Obviously, sprinkle your development efforts with a bit of Exploratory Testing here, and some Smoke Testing there. You could introduce a ‘Testing Spike’ a few Sprints prior to an intended release milestone. These techniques will help you catch more bugs in the background, and feed your Sprint Backlogs.

#4 – ATDD doesn’t necessarily need a specific tool or toolset

Contrary to what everyone is saying (and they are mostly saying those things to make their blogs light up with SEO), you don’t really need to automate all your testing, or use specific atdd tools in order to be able to execute Acceptance Test Driven Development. Surprised, are you?

Well, I’ve run very successful Agile projects off a Microsoft Excel-based Product Backlog, and I’ve watched an Agile project with all the necessary tools and skills fail miserably. As I often say, to run an Agile project with SCRUM, the only tools you need are Sticky Notes, Markers and a Whiteboard. Everything else is optional.

So are Automation tools or tools designed specifically to enable ATDD. Why?

Because you can still get your SCRUM team to write Acceptance Tests manually. Developers can manually execute these tests to verify the requirement is met. Testers can still do manual testing. It is just going to take more time than it would if you were able to integrate some quality tools into your arsenal.

Having said that, everyone’s situation is different. Obviously, I recommend you automate your tests and have a world class Test Case Management system in place to aid this. But if you can’t for any reason, then don’t let that deter you. Press on with your efforts to adopt ATDD. After all, this is the only tool you’ll ever need.

#5 – You’re already doing some ATDD

If you use SCRUM and user stories to deliver your projects, chances are each of your user stories has many Acceptance Criteria associated with them. And, you’ll notice that each lowest level Acceptance Criterion represents a unit of functional component that needs to be delivered before the user story can be marked ‘done’.

“If you are writing Acceptance Criteria and if you use these to validate whether a piece of code meets the requirement, you are doing Acceptance Test Driven Development in a rough sense.”

Your user stories and Acceptance Criteria could be small enough for an entire user story to be delivered within one Sprint. Or the user story could be large enough that you only prioritise certain acceptance criteria to be delivered within a sprint. How you deliver your user stories and Acceptance Criteria is down to your Scrum practices.

Fundamentally, though, if you are writing Acceptance Criteria and if you use these to validate whether a piece of code meets the requirement, you are doing Acceptance Test Driven Development in a rough sense. What you need to optimise this effort is to flesh out your individual criteria into executable (automated or manual) test cases. And get the SCRUM team to run these test cases before and after development begins and ends to test for the requirement. Simple, right?

#6 – Automation is a must have to run ATDD

Automation is good – we’ve previously discussed the benefits of Automation at length. In my opinion, Test Automation is a must have for all software projects. But circumstances vary. And depending on circumstances, you may or may not have Test Automation for your project, team, organisation, technology. Whether that is right, and how you can enable Test Automation is a topic in itself. Let’s not debate about that here.

Let’s just take it that, due to some reason, Test Automation isn’t really feasible for your situation. Fine. You should still be able to do Acceptance Test Driven Development. There’s no excuse for not employing ATDD – not even lack of Test Automation.

Doing manual ATDD will have its overheads – but, if the alternative is manual testing using other techniques anyway, what’s wrong with going with ATDD? That is my simple argument.

If you don’t have Test Automation, do ATDD anyway. You can still reap the benefits ATDD offers.

From experience

We once worked with a client – a major international bank – on a regulatory project. We were coaching them to introduce best practices in software development and testing in general. As it is with international banks, procurement is a long and drawn out process due to the myriad in-country and global regulations that they must follow before zeroing on a vendor for any services (as a sample, it took me six months to on-board my team to the project, just due to the complexities – legal and otherwise – of procurement with this bank).

We were trying to introduce industry best practices and world class tools and techniques to their IT teams. It was going to take anywhere between six to twelve months to get the requisite approvals and clearances before we could bring in some Agile and Testing tools. And we had a regulatory project with a strict deadline to boot.

So we as a project team decided to make do with the best we could – in this case, again, it was MS Excel, whiteboards, Stick Notes, and markers. We wrote Acceptance Tests on Day 1 of the Sprint – right after the planning session. These were delivered in batches to any developer that was going to pick up the work. With some practices, we were able to get some Acceptance Tests written, reviewed and given to the developer to code within an hour after the Sprint Planning meeting. And we kept the Acceptance Tests coming through Day 1 of each Sprint, sometime spilling over into Day 2. What this did, was to start the developers off in the right direction. Even with Excel-based Test cases to refer, they were able to achieve higher code quality faster than they could previously.

The icing on the cake? We delivered the regulatory project well ahead of the deadline, and well within budget. Other factors helped of course – but as you could see, ATDD played its part – admirably.

#7 – Anyone can write and run Acceptance Tests

By that, I mean anyone. There’s this popular notion today that the Tester as a standalone role is dead – that you need to be multi skilled, with coding one of them. Sure, it is desirable to have more than one skill in your back pocket – that doesn’t mean you can’t be a rock star in one skill and one skill alone.

When I scour the internet for ATDD related information, most everyone says the following two things:

• You need Test Automation for ATDD to work
• Developers need to double hat by writing automation scripts (test cases)

Not necessarily. I’ve covered the first point earlier in this blog, so let’s talk about who can write and run Acceptance Tests.

If we remove all the fluff and look at the facts, you need

• Someone that can write a user story
• Someone that can help flesh out the Acceptance Criteria
• Someone that can transform Acceptance Criteria into Acceptance Tests
• Someone that can write Automation scripts for the Acceptance Tests
• Someone that can execute the Acceptance Tests
• Someone that can write code to meet the Acceptance Tests

The someone can be someone or many. If it has to be different people that perform each of these activities, then so be it. If you can reduce the number of people involved to finish all these activities, then good on you!

---

Bringing it all together

Acceptance Test Driven Development is a great Agile technique to employ in your project, and instantly improve the results you are seeing. ATDD enables so much efficiency, and helps you optimise, optimise, optimise.

In an increasingly competitive Digitally driven world, releasing your product a matter of days earlier can mean the world in terms of customer uptake and market share.

So what are you waiting for?

You can leave your thoughts in the comments section below. Why not click share and let friends know?