The Feedback Loop

Agile Development Processes (TDD, ATDD, BDD)

Why do we do Agile ?

A quick reminder

The V Model

An error here

... is paid here

Mismatched expectations

Communication is key

Communication is hard

Scrum: shorter feedback loops

Agile principles in your everyday life

Your dev workflow

- Read specs

- Write code

- Test the application

- Fix the bugs

- Test the application

- Ask QA to test the application

- Fix the bugs

- Ship the feature

Long and painful feedback loop

How to shorten
the feedback loop

You NEED tests

Really

Non-Regression

  • You can't trust the other devs... nor the future you ;)
  • Am I breaking something ?
  • getpremium.js, 1500 LOC of untested code
  • Don't laugh, we all have at least one file like that ;)

Documentation

  • Beneficial side-effect
  • You're not alone, help other to understand by giving examples

Let's go further

Test Driven Development

Well, it's great in theory...

...but we are a startup, we don't have time for that!

You want to write
​your tests first

  • It shortens your feedback loop / testing loop
    • You pay a cost upfront but you save time + other devs time
  • Design ahead... and think twice before diving in this complex algorithm

Parenthesis: FIRST properties

  • Fast
  • Isolate
  • Repeatable
  • Self-verifying
  • Timely

Is it only for unit testing?

No.

Acceptance Test Driven Development

  • TDD at the feature level
  • Think about all the back and forths you are doing with product and stakeholders
    • Miscommunication
    • Forgotten specs: error states, edge cases, ...

ATDD in practice

  • QA and product write a list of scenarios for the story
  • QA / dev write an automated test
  • Dev implements the feature and make the tests pass

ATDD benefits

  • Better communication : an automated scenario is clearer than a JIRA description
  • Design ahead with Product Guy (forgotten states...)
  • Less back-and-forths and more asynchronous work
  • Non-Regression: did I break feature A while doing feature B ?
  • Documentation: what is the product supposed to do?

ATDD at Dashlane

  • Could be done on so many things!
    • Each feature
    • Installer & Usage logs
    • ...

What's the catch ?

BDD: one DD to rule them all

BDD principles

  • Test => scenario or specification
  • Natural language
  • Focus on the business outcome (from the outside-in)
  • Applicable at every level of the stack (Unit tests, Acceptance tests)

Emphasis on documentation

  • Expected behaviors
  • Everyone can collaborate (QA, product, dev)
  • Readable by everyone
  • Single source of truth

The feedback loop
is everywhere

  • Development
  • Product
  • Business
  • Management

Where do I start?

Thanks!

Made with Slides.com