Monday, March 12, 2012

Want a great Continuous Integration system? Write great User Stories!

One day, I was working with a team lead to build out their Continuous Integration (CI) system.  He asked me to write down the requirements, so I did even better and wrote these user stories. Why was this "even better?" I find whenever I use the User Story Format, it makes me think differently about what I'm trying to do.  (Especially the VALUE part "So that:."  Then the Acceptance Criteria force me to put to paper the ideas of what is acceptable that I'm carrying around in my head but perhaps not communicating.

Every time I bother to use User Stories, I get higher quality documentation. Every time! The team lead I did this for agrees. The head of the PMO came by and said, "those user stories you wrote about CI are really clear" -- hey, this is a non-technical manager who understand the value of a technical implementation like CI because of User Stories!

If you've more questions, Agile Thoughts podcast (episodes 1 through 8) did a series of short, fun, and creative episodes on the test automation pyramid.  It won't put you to sleep, I promise!


As a: Team Lead
I want a: Continuous Build environment that compiles my code.
So that: the team can clearly see when we've checked in broken code

Acceptance Criteria:
  • The moment code is checked in, the CI environment builds it and displays on the dashboard that the code is building.
  • Check in uncompilable code and watch that the dashboard displays there is a problem.


As a: Team Lead
I want: CI to run system tests each time code is checked in.
So that: the team can discover regression between modules of the system as soon as possible.

Acceptance Criteria:
  • When all the system tests are passing, the CI environment should report that all is well.
  • Check in a failing unit test, and the system tests don't execute (wasting server resources and making future builds slow).
  • When all the unit tests are passing, execute the system tests.  If there are no failures, the CI reports everything is good.
  • Check in a failing system test.  The CI environment should build the software, execute the unit tests, execute the system tests, and then report there is a problem.  Anyone can surf to the CI website and look at the test reports.

As a: Team Lead
I want: CI to run unit tests each time code is checked in.
So that: the team can discover regression as soon as possible.

Acceptance Criteria:
  • When all the unit tests are passing, the CI environment should report this fact.
  • Check in a failing test case, the CI environment builds it, executes the tests, and then displays on the dashboard that a test failed.
  • When there is a test failure, anyone can surf to the CI website and look at the report and see what test failed.
  • When the test failure is fixed and checked in, the CI environment builds, executes the tests, and then displays on the dashboard that all tests are passing.

10 comments:

  1. Well explained. Has got a badic idea regarding Continuous integration DevOps Online Training

    ReplyDelete
    Replies
    1. Confessions Of An Agile Coach: Want A Great Continuous Integration System? Write Great User Stories! >>>>> Download Now

      >>>>> Download Full

      Confessions Of An Agile Coach: Want A Great Continuous Integration System? Write Great User Stories! >>>>> Download LINK

      >>>>> Download Now

      Confessions Of An Agile Coach: Want A Great Continuous Integration System? Write Great User Stories! >>>>> Download Full

      >>>>> Download LINK V4

      Delete
  2. Confessions Of An Agile Coach: Want A Great Continuous Integration System? Write Great User Stories! >>>>> Download Now

    >>>>> Download Full

    Confessions Of An Agile Coach: Want A Great Continuous Integration System? Write Great User Stories! >>>>> Download LINK

    >>>>> Download Now

    Confessions Of An Agile Coach: Want A Great Continuous Integration System? Write Great User Stories! >>>>> Download Full

    >>>>> Download LINK

    ReplyDelete