Acceptance Test Driven Development is a well known software development approach that has synonyms like BDD and Specification by Example. That is build on top of TDD practice where you supposed to think and write test first, but on the Acceptance level. Acceptance it’s something that you are going to present to stakeholders at the end of development iteration.
During the contract involvement with one of my client we went thru a journey of implementing this process for the development team. ATDD as a process required mentality switch not just for the developers but for testers and business people as well.
During the presentation I’m going to show the mistakes we did during the phrase of implementation of the process and what worked, what not for our context.
7. To Do In Development Code Review Testing Demo
User
Story
User
Story
User
Story
User
Story
User
Story
User
Story
User
Story
2 Days Before Demo
Saturday, October 12, 13
8. Daily problems
There is no ID how I can catch the element
How I can test that?
How do you want me to show this on demo?
This is not what business initially wanted
Saturday, October 12, 13
9. Hidden problems
Acceptance Tests desynchronize with
development
Test automator is yesterday tester,
CODING skills are not identical to
programmer’s
Developers do not own acceptance
tests, "it's not our job"
Saturday, October 12, 13
22. Step 1
test automators to automate tests
in parallel with development
HAVE more discussion
on user story
Saturday, October 12, 13
23. New Problems
Requirements are not clear enough
Developers do not own acceptance tests
Test Automator fixing tests all the time
Saturday, October 12, 13
24. STEP 2
Make internal Acceptance TDD training
Prepare detailed description of the process
Explain how it should be to everyone
Saturday, October 12, 13
25. CORE Problem
Work as Acceptance TDD is hard
if you never tried TDD (test-first)
Saturday, October 12, 13
26. Step 3
Deep into and make hands dirty
Implement feature in pair with
developers
Minimize test scenarios on UI layer
Saturday, October 12, 13
27. We remove test automator role
... And yes
Saturday, October 12, 13
28. Developer’s Excuses
Acceptance tests are slow
(write small tests, cover as much as possible on layers below UI, cover on
UI at least positive cases that you are going to show on demo)
Writing tests required switching context
(Import acceptance test project into the same workspace, start application
implementation from Acceptance Test)
Tests are failing because of timeouts
(learn web driver deeper, hire web driver expert to the team to coach
people and adapting your framework, use JS calls)
I do not have IE on my Laptop
(run tests under IE just on server, to debug configure remote web driver)
I do not want to wait until it finished
(make tests smaller, use web services as preconditions and post
conditions. Use HTTP request call if you do not have web service, minimize
tests on UI)
Requirements are not clear enough
(how could you start writing code if you do not understand the goal????)
Saturday, October 12, 13
29. Test Automaton Facts
Software developers are know
better to test something on layer
below and can do it during
implementation
Test Automator role rise from people who
was trying to automate manual testing
Saturday, October 12, 13
30. What Test Automators
do now?
Support injection of Acceptance TDD
Maintaining Acceptance Testing Framework
Helping to define testability spikes
Moving UI checks on lower layers
Saturday, October 12, 13
33. Lessons Learned
Define a test strategy
Make you hands duty
Listen to the people
Pitch - not sell
Better to show rather than pitch
Saturday, October 12, 13
34. Test Automator role is
an excuse for developers
not to do
test Automation
Saturday, October 12, 13