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

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

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

timander@gmail.com@timander

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

Documents

persona driven keyword research by michael king

idbi executable

data-driven precondition inference with learned featuresity...

net executable requirements

executable test definition for a state machine driven...

model driven architecture and executable uml

persona-driven marketing: integrating community outreach,...

executable uml

chapter 2 - 1 abstraction concrete: directly...

raise the bar on persona-driven marketing with better data...

co-simulation environment for event-driven distributed...

empirical analyses of executable acceptance test driven...

executable systems design with uml 2 · executable systems...

teaching model driven architecture approach with … ·...

persona driven keyword research

portable executable standard

executable model en

writing executable statements

formatul portable executable

executable biology tutorial