What is a "story"?

I got asked today by my Boss, "what is a story?" so i gave him a 5 minute overview, then i realised i could share this.

Simply put a story is a very short (should fit on an description of a piece of functionality.
A story serves several purposes.
It is used to estimate and identify areas of risk during initial release planning and ongoing through development.
A story is always written from the business perspective, and is normally based on an action (e.g. display search results, search stock).
A story is testable through the UI if application is UI based.
Our Stories are written using the form: "As an X I want to Y so I can Z"
Stories answer these questions:

• Who is 'doing' the story (As an X).
• What action is being taken (I want to Y).
• What business need is the story hitting? (so I can Z).

They are at first very high level and i've found that initial story cards are almost always revised and rewritten. They are usually rewritten to lower levels of granularity so that at development time they are testable.

They are small enough that it only takes one iteration to complete. If they are too complex, they are expanded into narratives.
Stories can be either functional or non-functional, E.g. performance should be a story.

ThoughtWorks write the stories on ThoughtWorks branded index cards which are 147mm wide and 104mm high which are bigger than the index cards we could get from our stationers. (Who stocks these size cards? Viking have them on-line, but staples have them in store only. They are called 6x4 index cards by both)

They write on the cards to ensure the story is kept to a small size, this helps the customer "see" what they are saying. The cards are usually kept visible on a board. a Kanban board.

In Agile projects, it's common practice to share the project status via "big visible charts" on a wall in the project room (or elsewhere if a room is not available).

Kanban is a Japanese word which loosely translated, means card or sign. In a "Lean" production system, Kanban is a method which uses standard units or lot sizes (our story cards). The methodology dictates that a new card is only "pulled" into the system when the work represented by a card that is "in Play" is completed.

It works really well. I was away from the project for a couple of days to deal with recruitment. When i returned to the meeting i was able to jump straight in after reading the board for few minutes and attending the morning meeting.

Testers - Thou Shall Not Cut Code!

okay, so its been a while since my last post, and we have some very frustrating times, i'll try to remember them now.

One of our 500lb gorillas is the fact that Fitnesse out of the box comes with limited functionality. By that i mean if you want to pull a value from a database and assert that it is being displayed in the users browser (via selenium) then you have to write your own Java class. As i said before we are a team of dedicated web testers, and while we are very technical testers, we are not Java programmers. So we looked round for some possible solutions to our dilemma.

First up is Anubhava’s Generic Fixture. Anubhava has had the same thoughts as me, but has the skills to actually put the idea into fruition. His generic fixture allows the fitnesse scriptee to write in DSL without writing a single line of Java, eureka!

i tried using the generic fixture for connecting to the DB. However we use Oracle 10G and our connection string details two nodes. In the examples Anubhava gives, the fixture accepts the usual server, port, dbname, user, password strings.

I thought i would share this with any other visitors who may use generic fixture and use similar JDBC connection strings to us. OracleDataSource will accept a url, so i amened Anubhavas example fitnesse tables to

| Generic Fixture | oracle.jdbc.pool.OracleDataSource |
| setDriverType | thin |
| setURL | jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST =(ADDRESS=(PROTOCOL=TCP)(HOST=node1)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=node2)(PORT=1521)))(CONNECT_DATA =(SERVICE_NAME=WEB)))
| setUser | db_user |
| setPassword | db_user_password |
| conn=getConnection |

and we can now connect to our DB, and script without writing Java.

Next up is Gojko Adzic's DbFit another fixture for fitnesse, and comes with some examples for .net and Java and Oracle.

A little bit more of a learning curve with this one, but still within the realms of what we can manage as testers. We can use DbFit with the WebTest fixture and again accomplish a lot without writing any Java.

I guess i should point out here that its not just writing the Java, its where to store it (CVS), compiling the code, keeping it up to date, making sure we are using the right versions of drivers (ojdbc14), that we have the right environment variables set-up and so on. All of a sudden the line between the bounds of a tester and developer have become so blurred. Well okay, maybe i wouldn't just test the "happy path" :-)