Tenjin.
Let's Make It Better
Process
Humans
People

It starts by asking questions that get to the heart of what you need to accomplish with your software.

Then those answers are formalized into people-friendly User Stories.

Tools
Building

Diagnostic tests are made based on those User Stories. It's kind of like teaching a computer how to use the software.

Party Time!
Happiness

Everything you want working is done! You can now use your shiny new system, or you can ask for additional improvements as inspiration strikes.

... rinse and repeat. You get a useful result quickly, and it only gets better over time.

Breaking down a system into User Stories is a fantastic way to work. It's a great way to prioritize the parts that you need first, and it defines a clear set of expectations for everyone.

User Stories

A User Story describes exactly one task, and comes in three parts:

Title

As a (role)

I will (action)

Because I (motivation)

Role
Who is doing the task?
Action
How do they accomplish it?
Motivation
Why do they want to do this?
Examples
Blogger drafts blog post

As a Blogger

I will write a blog post

Because I want to work over several sessions

Blogger publishes blog post

As a Blogger

I will publish a blog post

Because I want to share my thoughts and opinions

Tested

You wouldn't trust a doctor who never examines their patients, nor an accountant who doesn't double-check their sums. Why trust your business to software that isn't tested properly?

Once User Stories are defined, they're used as a basis for automated tests. This helps:

Clarity
Automated tests give us a common understanding and you get what you want.
Scope
Waste not want not - no extra effort or cost for unnecessary work
Quality
Tests solidify the original intent and protect against breakage.
Documentation
Tests double as system knowledge and knowing is half the battle.
Flexibility
It's normal to think of new awesome features. A test suite means changes can be made without fear.