persona driven development - agile alliance · 2019. 12. 16. · acceptance test driven development...

© copyright Tim Andersen, 2010. All rights reserved.

Persona Driven Development

Tim Andersen


Full-Time Developer


• Established 1979

• Private, Non-profit corporation


Mission: To help Iowa students and families obtain the resources necessary to succeed in postsecondary education


Overview

• Acceptance testing with FitNesse

• Common problems with Acceptance Tests

• Getting the business to care about acceptance tests

• Using Personas to augment communication

• Combining personas with acceptance tests


Types of TestsLevel of

Abstraction Purpose Tool

Unit Tests low breadth JUnit

Acceptance Tests high depth FitNesse


Unit Test

• Small, focused purpose (micro tests)

• Tests one thing

• Technical/Implementation focused

• By programmers, for programmers


Three Laws of TDD(according to Bob Martin)

• You are not allowed to write any production code unless it is to make a failing unit test pass.

• You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.

• You are not allowed to write any more production code than is sufficient to pass the one failing unit test.


Acceptance Tests are different

• Workflow style, may have many branches

• Sequence of activities or events that produce results that can be validated

• Not concerned with implementation details


Acceptance Test Driven Development

• Business requirements are expressed as executable tests

• Developed collaboratively with the business

• Used as documentation


FitNesse is a lightweight, open-source framework that makes it easy for software teams to:

• Collaboratively define Acceptance Tests

• Run those tests and see the results


Problems with acceptance tests


It is hard to make acceptance tests clear

• You can’t tell what the test is doing doing without looking at the code

• Each test requires an explanation


Technically aligned rather than business focused

• The business folks did not value our acceptance tests

• In terms of process steps, not the user voice


Prone to “fantasy state”

• Even though we practiced TDD and had a lot of tests, we still had bugs

• Wrong entry point encourages fake data

• Symptom of technically aligned tests


High Maintenance

• Each new feature requires a new Fixture to set up the scenario

• Adding a new scenario requires small changes to many other tests (aka Shotgun Surgery)

• The tests were too low-level, more like glorified unit tests


Common problems with acceptance tests

• Not clear or easily understandable

• Technically aligned, not business focused

• Prone to fantasy state

• High Maintenance


Personas


Creating Personas


...Personas Cont’d


How Personas Help

• Create a shared language between the business team and developers

• Requires the developers step out of the technical world view

• Think about the software from the perspective of the user


PDD


Focus on Test Clarity

• When a business term changed, we renamed everything to reflect the language that the business used

• Using Personas to talk about new stories became much more natural because everyone knew what behaviors each persona possessed


Make Acceptance Tests always make sense to the business

• We sought ideas to make tests more clear

• Our aim was to make the purpose of our tests clear enough that we didn't have to explain the scenario to the business, it should be obvious


Don’t Fake It

• Use the real system to set up state

• The way we implemented our personas, they used the real system to enter data instead of setting up a fake state


Implementing Personas

• We experimented with using personas in one of our tests because we used personas when discussing our stories

• Our first test looked radically different than our old tests


Three Guidelines of PDD (according to me, inspired by “The Dude”)

The Acceptance Test...1. makes sense to the business

2. walks the life of the persona

3. emulates the business process


Impact


Increased Test Clarity

• When the tests made sense to the business, the business team took ownership for creating new tests and analyzing existing tests

• The quality of our tests continued to improve because the business team could express requirements through personas


Provides business with a language for expressing requirements

• Once we had the basic abilities of our first persona, we paired with our BA to show what else is possible.

• Our personas grew into a rich toolkit that provided a common language for BAs and Programmers to communicate


High-Bandwidth Communication

• By using the same terminology the business team used in our tests, we avoided the cost of translating

• Personas were canned-context that could express a lot of background information for the users involved in a scenario very effectively


Reduced Maintenance

• Instead of coding the scenario into the Fixture, it was defined by the interaction between personas in the test

• Our Fixture code changed much less frequently and new scenarios could often be built without any changes to test code


Increased Trust

• Because our personas harnessed the real system instead of faking state, they were much more truthful

• Failing tests were real bugs

• We caught several bugs by simply cutting tests from the old way to using personas


Take Aways

• FitNesse is an excellent tool to collaborate with business experts for developing software

• Clarity is king because it reduces the cost of translation

• Providing business people with the tools to express what they want is worth the investment

• To sustain agility and avoid stagnation, make time to experiment with new techniques and tools


Summary

• The goal is to deliver working software to fulfill a business need

• Quality, communication, and trust are necessary to succeed

• PDD is one technique to help you get there


Business Stories

•No Funding in 2008•High-Risk Fraud Alerts


Thank you

[email protected]@timander

mailto:[email protected]

mailto:[email protected]

persona driven development - agile alliance · 2019. 12. 16. · acceptance test driven development...

Documents