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.