Excellent Executable Requirements

excellent_executable_requirements.markdown

Presenters

@ericlandes @dan_sb

Agile and Beyond Conference (dry-run)

What bad looks like

• lengthy
• ambiguous
• verified manually

How did the issues come about?

• Working in isolation
• Speaking different languages (developer v. customer)
• Trying to cover too many...
  • Types of Users
  • Actions of a specific user
  • Exceptions to the 'happy path'
• Limiting to one type of artifact

A Better Strategy

• Closer Collaboration with Product Owner

  • acceptance criteria

• Get different parties together

  • same room (face-to-face)
  • Skype
  • collaboration tools like dabbleboard
  • phone call

• Creating a common language

  • capture common theme
    • elevate statement/theme
  • create shared workspace
    • real
    • wiki
      • humans are not used to dealing with wikis (FitNesse?)
  • consistent team
    • turnover is disruptive

• Removing Ambiguity

  • provide additional context

    • picture(s) of diagrams, mindmaps, pictures of whiteboard
    • wireframes
    • have the conversation

    Richnes of communication channel

• Layer Your Tests - More

  • Developers may embrace Unit Testing
  • Automated Functional Tests are good
  • Manual Tests - Primarily Exploratory Tests

  UAT Manual Tests Automated Functional Tests Unit Test

• Types of Executable Requirements

  • Automated Functional Tests
    • Functional tests can be written, regardless of the use of Unit Tests
    • Automated and integrated into the build activity
    • Not necessarily UI tests (e.g., Selenium tests tend to be fragile)
  • Unit Tests cover small pieces of the code, are created by developers, and are outside the scope of session
  • Good Executable Requirements are a time saver
    • Get the feature right the first time
    • Lowers cost of iterating
    • Reduced maintenance and "end of project" tails to regress
    • Helps IT and Business work more closely together
  • Frees team up to improve software without big cost of manual regression testing
    • Introduce new features
    • Fixing defects
    • Refactor code
  • Good Executable Requirements
    • Understandable to developer, business
    • Unambiguous
    • Automated
    • Runs frequently

How it happens

Better ways

Example

• Used FitNesse

Feedback

• confusion between requirements and tests in demo
• when you don't know when you're done, you shouldn't start the story
  • estimate the story in points which means knowing a good chunk of the story to understand how to estimate (my opinion)
• technology side person is nice to have in acceptance criteria "meeting"
• answers to questions about how to solve problem in their own company is context-based (my opinion)
• if story is too big, split into separate acceptance criterias

Mentions

Bob Martin's Clean Code Martin Fowler Alistar Cockburn Cucumber RSpec Selenium