SoftwareGR

Carl Erickson, Atomic Object

Karlin’s “Systir Test Framework”

Karlin Fox, Atomic Object software journeyman, talked about the domain specific language approach to system testing and the Atomic Object Systir framework during the second half of the November meeting.

This is a talk Karlin gave recently at the Ruby Developers Conference.

Karlin started with a demo of Systir. A website for ordering pizza was run through its paces with a system test in the Systir framework using Watir as the driver.

TDD is for developers. SDD (story driven development) is for customers. Expressing stories as system tests lets you use them as acceptance tests, and it requires you get good definition on your specification (stories) since you automate their execution. In other words, SDD keeps your requirements and your code synchronized.

Systir encourages writing acceptance tests incrementally, as you develop. It’s lightweight and easy to get going in (assuming you learn a little Ruby first) and can be extended as the need arises.

Typical vendorscript (as Bret Pettichord has called it) is specific to a vendor and may be a poor general puprose language. Systir scripts are DSLs in Ruby, so the full power of Ruby is available as needed.

Matt Heusser pointed out that Systir scripts are executable English, hence not as ambiguous as human language requirement specs.

Systir DSL == Application ideas + User domain language + Testing/programming skills

A Systir DSL grows from an ongoing collaboration between a customer and a toolsmith.

David Crosby pointed out that redundancy can be added to the DSL to make the customer’s test writing/reading easier. For example, the DSL for checking out in a shopping cart could be either “check out as” or “check out by”. It’s easy to define and allow both phrases.

Systir tests can be data-driven or imperative. The best approach depends on the application and the customer defining the tests.

Fit (Ward Cunningham) is another test automation tool for doing SDD. Compared to Systir, Fit supports only a data-driven approach to system tests. Fit’s great for this, but sometimes the imperative approach is more powerful and expressive.

Systir’s been used for a variety of web apps, for a complex Java server, and for a large C#/.NET GUI application.

Karlin wound up with a dive into the famous Mondo pizza website, the system tests for it, and the Ruby driver suporting the Mondo DSL.

Matt’s “Magic Pixie Dust”

Innovation is about redefining a task, or the way a task is done – Gerald Weinberg

Programmers that innovate are going to disrupt things a bit. How do you encourage that and not let it sidetrack the organization?

Is innovation at odds with high levels of process maturity? [Perhaps the self reflective, feed-improvement-back-into-the-system aspects of higher CMM levels would cover process and technology innovation?]

Status meetings are 20 people in a room, sequentially reporting for 5 minutes each. So for 20 person hours of human resource you get a couple hours of knowledge sharing. [Makes our standups look highly efficient.]

An ambiguous spec is one that is written in English – James Bach.

Efficiency is a false god. Without an infinite length work queue there will always be some downtime for developers. So to be efficient, companies size their development groups to always have work to do. So imagine when a call comes in from a customer, reporting a bug. Help desk person enters the bug. A few weeks later the QA person has time to check out the bug. Now the trail is cold, so it’s harder to repeat and understand, and the customer isn’t available. Finally the developer finds and fixes the bug, submits it to the QA person for change control. They’re busy, so it takes a while before they can check out the fix and submit it to the next release build. Sometime much later the customer may get the bug fix. So the efficient organization can have rather bad responsiveness. “Slack”, by Tom DeMarco advises organizations keep 10% idle time to improve performance.

Multitasking results in higher average completion time for projects. And that doesn’t count task switching overhead. [Simple results from OS class – shortest job first scheduling results in lowest average completion time.]

Johana Rothman – at 2 tasks, people are only 40% effective. At 5 tasks they are not effective at all.

Kevin Hykin cited data that said 2 concurrent projects is good, but going over that results in inefficiency.

Lesson from parenting: forcing your will on another human isn’t as effective as communicating choice and consequences.

Every large, painful, deadfish project has a series of lively, effective, fun projects just dieing to get out.

Developers do have power. Bosses don’t control everything. Offer choices to customers, encourage them to prioritize. Use five magic words: “I’ll get back to you” when pressed for detailed time estimates in meetings. If you can’t do something, don’t commit to it.