Functional Test Driven Development

Requirements are always handed out in English. But I think English is a tricky language. For example we I say "The kid ran when the dog barked" it could mean that the Kid started running because the dog barked or the dog started barking when the kid ran. When a simple statement can lead to many different interpretations think about the requirements in complex systems. Usually in such systems, when the developer codes based on his wrong interpretation of the requirement /story, it comes up as bugs during BA/QA signoff. Developers now spend the same or even greater amount of time fixing the bug. In this scenario we can’t blame anyone. As a solution to this it would be great if the developers could have their interpretations checked now and then. And the solution we came up with, in our project, was to develop automated functional tests before development.

Automated functional tests were a boon to the developers in the following aspects:
1.They act like a measurable form of requirements.
The developers were able to visually see how far they are from getting the story done. Also when a different pair started working on the story it made it easy for the new pair to continue from what was left. And also Functional tests helped the developers to know when they are done with the story.
2. They correct the wrong interpretation sooner than later.
When the developer tries to run the automated test after he completes a task the test would fail if his interpretation of the requirements were different from that of the analyst.
3. They don’t lead to multiple interpretations.
These test are straightforward. Either the test passes or fails and the developer cannot move on to the next step until the code meets the expectation.
4. It reduces the amount of bugs that can be found. And in turn reduces the bug turnaround time.
5. Functional tests are too detail.
Even the simple things like formatting cannot be ignored.

It’s really nice to have functional tests ready while developing isn’t it? Yes, But it is not a very easy task. As there are advantages, there are many disadvantages too to have the functional tests written before development on the story starts.

1.There may be a lot of unknowns as the design is not yet complete on the story.
2.When the design changes during development the functional tests have to be modified. This happens most of the times and the analysts will be repeatedly changing the test script based on development changes.
3.The main disadvantage I see is that, as the tests are written based on a virtual flow, there may be lot of missing scenarios.

In my opinion it is great to have the functional tests written before development. But also they need to be revisited when the story is development complete. This will give the analyst come up with more scenarios that cannot be visualized until testing the story. Developers need to have the functional tests in mind before they make UI or other changes and work with the analyst in making the tests pass. If functional tests are ignored while making changes/decisions, it’s merely possible to have functional tests before development.

Decisions

Imagine that you are a CEO of a company and you have to make a decision on selecting one of the following teams. Which team will select and why?(Please leave ur answer as a comment)


Team 1: Has a good manager and has below average developers.


Team 2: Has good developers and a below average manager.

Tasking Sessions

Estimating a story card accurately is always a difficult task. We can be close to reality but never accurate. We should look at our estimates as a variable.

In our project, we developers discuss with analysts about a storycard, and come up with some high level tasks to complete that story card. Looking at those tasks we estimate ideal days (or some other unit system) to complete the story card. To be honest, sometimes we have been awfully off our estimation. Some members in our team question why to waste our time doing tasking when we anyhow go wrong with our estimates whether we task out our stories or not. I totally accept to this argument, by tasking our story we will never get our estimates right. It could be closer to reality but not right("estimates right" sounds like an oxymoron). But (pardon my English) task of "tasking" is not just meant for estimating our story cards but it has many other benefits too. It helps,

1) To get better understanding about our story card
Tasking session allows (or forces) developers and analysts to look a little closer at the story cards. As analysts are right there, it is easy for developers to ask questions about some ambiguous parts in story cards.

2) To have a domain discussion
Tasking session makes developers and analysts to have domain discussion. Developers and analysts, when tasking can see if there is any domain model change for example adding a new domain object

3) To knowledge transfer to new developers.
By involving in tasking sessions, new developers will be able to understand more about why and what needs to be done for a story card.

4) To find some gaps in analysis
Tasking forces developers to have more understanding about a story card. So developers tend to ask more questions to Analysts. When answering to developers' questions, analysts will be able to find some scenarios he/she never thought about before or some gaps in story card.

5) To find whether a story is too big
Tasking gives us a better idea about the size of the story. So it will be easy for analysts and management team to decide whether to break the story into two or more manageable stories.

So I feel "tasking" is a beneficial activity in software development.

Pair Programing - Myth 1

Myth 1:

You don’t need a pair when you are doing a simple “if” condition.

Reality:

You need a pair to make sure, that you need that “if” condition.