Testing as Communication: Real-World Techniques Notes

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is from Jon Larkowski from Hashrocket.

Subset of Obie’s The Hashrocket Way talk. No mismatch between what the customer says and what the tests give. Hashrocket values agility & transparency. Communicate all the f***ing time, but only if the overhead is low. Two lines of communication:

  • Client to developer
  • Developer to developer

Tools they use:

Pivotal Tracker: Awesome tool. They don’t write a line of code unless if a story in the application supports. Seriously, just check out http://pivotaltracker.com Tells you when features will be done with velocity. Again, just go to the site. This helps them out with communication because it lets them know who’s working on what. Also a huge scheduling tool. Helps developers talk to developers with estimation efforts.

Stories: All work is driven on stories. Only code what’s on the card. Stories are tokens of a conversation. Writing stories at a developer level where they can start implementing it is important. They used to use index cards but now they just use the Tracker. They slowly train customers to write their own stories. Standard forms:

  • As a / I want to / So That
  • Given / When / Then

They want to understand development efforts in a larger context, so this helps out to see the bigger picture.

Pair programming: Keeps developers honest, focused, and leads to higher quality code. There’s two wheels on the axle since there’s more than one person that knows the code. Laptops on either side of the computer. Ping Pong: one dev writes a failing test, other writes code to pass the test, rinse and repeat. Daily standups for the entire company.

Testing: Express client stories as tests with Cucumber and normal MVC tests. RSpec specdoc format creates documentation. Durable system specification since it’s in English. Tons of techniques used: RSpec, MVC, Factory Girl, Cucumber, Selenium, RSpactor (instead of autotest), Continuous Integration (CruiseControl), even clicking on stuff too.

Delivery: All the f**cking time. Delivered multiple times a day! Very tight feedback loop with client. Smoke test together to demo features. Deployment with Capistrano to EY or EC2. Some Passenger use.

Client Acceptance: Developer-assisted! Hold their hands for a while. Video chats, use the Tracker (automatic updates too). Daily standup with client to touch base.

Impedance Matching: Clients, developers, testers…all speak different language. The goal is maximum power transfer! Need to be able to talk to clients in their language, and not in geek speak. Bridging that gap requires a geek-to-english filter. Code however is a different answer. Getting the code to a geek speak standard is easy with regular code and MVC tests. With integration tests, it can bring that up to a level where both developers and clients can understand it: ENGLISH.

Permalink · Written on: 11-19-08 · 3 Comments »

3 Responses to “Testing as Communication: Real-World Techniques Notes”

  1. Jon Larkowski wrote:

    Thanks for the comprehensive write-ups, man! By reading this I’m glad to see my points actually got across. Cheers!

    November 19th, 2008 at 9:54 pm
  2. Karmen Blake wrote:

    Jon, good stuff dude.

    November 19th, 2008 at 10:03 pm
  3. Great Professional Ruby Conference Coverage : Accidental Technologist wrote:

    [...] 6. Testing as Communication: Real-World Techniques, from Jon Larkowski [...]

    November 19th, 2008 at 10:03 pm

Leave a Reply