Spectacular: An Acceptance Test Driven Development tool for teams who like and/or must write official specs and who do not want to be constrained to a single ATDD tool.

Spectacular is an Acceptance Test Driven Development (ATDD) / Behavior Driven Development (BDD) tool that aggregates several different types of testing frameworks into 1, and it also introduces the idea of Executable Use Cases (EUC) – if you have to write use cases, you might as well make them Not Suck.

The idea is that a Business Analyst (BA), Quality Assurance engineer (QA), or Developer can write a spec in any way they feel comfortable with, including diagrams and business rules if necessary. They can write tests in the form of Executable Use Cases, BDD-style tests (Gherkin/Given-When-Then scenarios), and/or FIT-style tests all within the same document. The tool will run through the document, “detect” test cases, execute them, and print out the results in the same format as it was input.

Why build Spectacular?

I work at a large financial services company, where compliance with Sarbanes-Oxley (SOX) and Office of the Comptroller of the Currency (OCC) rules and regulations is of utmost importance, specifically with the audit requirements.

I suspect that there are many, many organizations out there who have to comply with the same set of rules, so I took what I learned about SOX and OCC audit requirements, combined them with what I learned at Elisabeth Hendrickson’s AMAZING ATDD course, and created Spectacular to make writing requirements more natural while also making those same documents executable, and not restricting any team to any single tool.

Also, I found through practical application of various ATDD tools that they are all pretty amazing and useful, but it was really annoying to use all these various tools to write specs and tests in different ways located in different locations depending on the tool being used. Plus, I would suspect that most teams would prefer to write story tests in a single document in a single format rather than having them live all over the place.

Isn’t this whole idea… un-Agile?

I don’t think so. Actually, I think something like Spectacular will help any large organization with an established corporate hierarchy and previous experience writing specifications in a use-case format adopt Agile more easily, especially those with “hardened” quality-assurance/quality-control groups. In my experience, these large organizations can be like “steering the Titanic with a small rudder” when it comes to transitioning to a more Agile process – allowing teams to continue writing requirements in the form of Use Case flows and documenting the tests in the same document will let them experiment with the various ATDD best-practices while remaining compliant with their regulatory bodies.

Spectacular helps those teams constrained with writing full-specs by allowing those teams to write the specs with tests embedded in them. Agility is introduced because those specs – written in a format they are used to – are now executable. A core Agile practice IMHO.

Use Cases? Really?

Yes, really. Use cases can tell a lot of the “story” if written well. Use cases, just like implementation code when written after a unit test is written, can be written well if there a constraint of execution behind it. Also, traditionally use cases have been taken to a far extreme of complicated. Not necessary IMHO.

To me, Use Cases fill the role of “Epic Spec” in an agile process. I’m a huge believer in the practice of Story Mapping and Persona Development (from Jeff Patton and Dave Hussman, respectively. Two of my personal geek-heroes). While doing your story mapping workshop, the high-level “activities” that you decompose into stories can very easily be Use Cases. In fact, in my experience writing Use Cases to explain the high-level activity (or “Epic”) can help to decompose it into discreet stories. And as such, each level of requirement-granularity (from Epic/Use Case to the Story) requires a different way to test it.

As such, I use Spectacular myself to execute Use Cases against Epics, and BDD/Gherkin and FIT tests to execute Stories.

Enough already. I get it. Show me how it works…

Visit the Google Code Wiki for documentation and to download Spectacular!