Sonntag, 3. Juli 2011

Why Acceptance Test Driven Development (ATDD)?

First: ATDD is not about testing as primary subject. It is about communication.

But why do I create tests then? Let me start from the beginning...

In software development it is very important that all participants in a project have the same understanding of what should be built. By all participants I mean not only software development, but also QA, UX/UI, business analysts, customers...
If you're working in an agile environment it is very likely that you're already working with user stories. But how does everyone know what to do in the story? This is where acceptance criteria comes into play.

In your estimation and especially later in the planning you start to create a set of acceptance criterias which should specify what needs to exist to make our customer happy.

Let's create an example:

"As a User
I want to be able to find products in the shop
In order to order them"


Where is our acceptance criteria?

Scenarios are a great way to describe acceptance criteria. I'll give you some examples:

"Given I am on the Homepage
And I entered a search criteria into the search box
When I click the search Button
Then I should see a list of products matching my search"

"Given a list of products
When I click on a product in the list
Then I should go to the detail for this product"


(Of course there should be more Scenarios for the complete story)

I used the Given-When-Then (GWT) Pattern to write down the scenarios. These Scenarios will cause a lot of questions in the team, about how things should be done. This is exactly what we want. The examples should help the team to understand what the problem is and what it should look like in the end.

One possible question: Where do I enter my search on the Homepage and where should the search button be?

These are questions that could arise during the workshop and that should be answered during the workshop. All the information that you agree on in the workshop should be written down and committed amongst all team members.
But why stop here and just write everything down? You can and should create tests from that information! The tests specify what should be implemented. Just like a software developer you can use Test Driven Development as a whole Team!
The main advantages of ATDD are, you can
  • immediately get Feedback on how far the story is
  • have a look at what you committed in the planning
  • communicate changes in the requirements by changing the tests
  • establish a common understanding of the problem in the team
  • have a human readable specification of your domain
Of course this should not stop you from talking to each other. This is and will always be the most important skill of a team. The Tests help to establish a common language.

P.S.: The main idea on this topic came from the book "Bridging the communication Gap" by Gojko Adzic which is really an excellent book.

Watch out for my future posts on how to implement ATDD concretely using SpecFlow and Selenium.

Mittwoch, 22. Juni 2011

It's been a while...

... since I wrote my last post on this Blog. A lot of things have changed. I've got a new Job at a very sophisticated company, I learned a lot of new stuff and somehow didn't manage to finish my project (doesn't this sound familiar).
But with my new Job there came a lot of new interesting ideas and practices to my mind. I hope I can do a little more Blogging in the future, because I want to share my knowledge and here your oppinions on it.
Soon I will start with a new topic that caught my mind: Acceptance Test Driven Development

Stay tuned for more information on that topic!

Donnerstag, 8. Juli 2010

The Goal

Last tuesday we had the kick-off meeting for my project. Gregor asked me to explain what the program should do.
The intention of the program should be some kind of easy to use "checklist" tool. So you can build a catalog of rules, instantiate a copy of the catalog and answer the questions. Finally there has to be some kind of report. I've built a MindMap that shows the requirements I have. The MindMap was created from the view of a customer.



We also defined that it should be a Rich Client Windows App saving the files directly to the hard drive.

We need a common language


After discussing a little bit, we decided that we need a Common Language (CL). The main problem with programming for customers is, that in 99% of the cases you are not aware of the Domain the customer works with and the customer of course has - in most cases - little experience in programming. So what do you do to understand each other? As the main goal is to build an application, we ask the customer what he expects the program to look like. You can use tools like Balsamiq Mockups to sketch a UserInterface pretty fast. You should not care about any details or colors. The main focus in this phase is to find the flow of the program and what the customer expects the program to do. Gregor also did an excellent post on that on his Blog.
In the next meeting we will use Balsamiq Mockups to get a picture of what I want. Of course I will post the results in my next Blog Posts!!!!

Montag, 28. Juni 2010

The way

1 1/2 years ago this book crossed my way and changed my way of programming and architecture a lot: Applying Domain-Driven Design and Patterns by Jimmy Nilsson. In the past year I decided to do my new projects with DDD (Domain Driven Design). In my eyes this is the only way that Software can be built readable and maintainable. In combination with TDD (Test DrivenDevelopment) you've got really great tools to build a solid architecture. I've read a lot about all the patterns being used and how to test your code, but I'm constantly struggling when it comes to put all the blocks and patterns together.

A few weeks ago I've been to a .NET Open Space in Karlsruhe. There I met Gregor Biswanger who is the leader of our local .NET User Group. A small project in mind Gregor was so kind to offer help implementing the project. With a very sophisticated Mentor and a lot of motivation I will start (and hopefully finish *laugh*) my project.

The goal of the project is not WHAT is done, it's HOW it's done. I feel the need to do this, because I didn't find a real solution for my problem. I hope I can help anybody else.



The way is the goal!!!



Let's start