Agile Testing Days Website
Over the past three days I was able to attend the Agile Testing Days in Berlin. It was a great conference and I met up with very interesting people, attending really great talks and keynotes. Personally I hope to get back there next year. I wouldn’t have thought such a great event could take place in Germany with such brilliant people from all around the world attending. Jose Diaz and Alex Collino did a great job putting up the conference. Here is a series of reflecting write-ups about certain aspects of the conference. I decided to bring them up one by one just as I experienced the conference and have a short wrap-up in the end. The first entry in this series is about the tutorial session I participated in on Monday.

Human influences

On the tutorials day I attended Elisabeth Hendricksons Tutorial on Acceptance Test-driven development. While I was sort of familiar with the content after having read her blog posts over the past year, having read Gojko Adzics Bridging the Communication Gap, it was interesting to follow the dynamic of the learning class. Most interestingly was the fact for me that we have to deal with just five percent of technical based impediments, but with 95 percent of human aspects in our daily work. Reflecting over the situations of my most recent projects, this might be true – though I don’t have numbers, but my first-order measurements tell me that it’s likely.

Technical constraints become Business decisions

Another interesting aspect was the fact that for acceptance test-driven development to work, there might be the case where the team runs into technical constraints. At this time the team consisting of programmers, testers and business experts (customers and analysts) have to identify these technical constraints and have to make the business decisions based on that knowledge to go on. An example would be handy right now? Consider a password system just as Elisabeth had in the tutorial session. Since there will always be limited space available to encrypt and store the password, there will be a limitation about the length of any given password in the system. Due to the technical constraints underlying the actual architecture and design here, the customer needs to make the business decision on how to deal with this limitation. If there are just 300 GB of storage available, but the system needs to serve 300 billion accounts, this constraint will be actually hit. (Actually this won’t work.) So the business decision taken could be one of the following:

• Limit the password to one character.
• Limit the user count to 300 thousands but use multiple deployed systems. Decide if the resulting password length is by then acceptable or not.
• Expand the actually available storage for passwords, so that the system can deal with 30 characters of password length

By the time the constraint is raised by the developers, the business can decide, but the previous technical decision about passwords has then become a business decision – and these are made by the customer.

Silo thinking

Over the session there were several points that seemed to fit into silo thinking. Thinking in silos is a problem and more often than not leads to failure. Why? Well, as I read from Alistair Cockburn: there is only us. The team needs to find their way to the target to deliver a software product to the customer, that is accepted so the team makes money and can survive. Period. Tom & Mary Poppendieck simply transform the goal to a higher level in their Lean thinking approach in order to get teams to succeed. It’s not that you need to find as many bugs as you can, it’s not that you need to write as many lines of code as you can, it’s that you deliver working software that brings value to your customers. If you can’t do that – i.e. by building software that does not have any purpose, or by building software that no one actually wants to use – you screwed it up. Over the whole conference I noticed several tries to reach a common understanding of “Done”, to which I have a definition, but I will get back to it later. Cockburn introduced to me the idea to think of decision floating through the software project. If decisions are made and implemented, but get a late feedback, in case they were right or wrong, you’re not able to learn from it. Silo thinking simply leads to this lack of feedback in your software development system. Made decisions pile up in queues, getting passed over to the next person to work on and occasionally rot. Silo thinking just leads to queues up decisions with no feedback.

Definitions

Elisabeth had some very interesting definitions, which I will simply repeat, but not elaborate here. The TDD cycle is often referred to as Red – Green – Refactor. The ATDD cycle was named by Elisabeth with Discuss – Develop – Deliver. Getting into Delivery, she had a pretty clear definition of what done means. Done means Implemented and Tested. Referring to Michael Bolton Tested means in an Agile context both, checked and explored. Regarding the course of ATDD and TDD compared to each other, when writing your first unit test you decide what your design shall look like. This is a design decision, a decision about the code you make, how it shall look like. The Acceptance Test written first is a business decision. The business decides what shall be delivered when this particular test passes.

Quality requirements

Elisabeth pointed out that the ilities usually considered in software development can be separated into internal and external requirements. Internal are those decisions about the design, the external ones are the decisions regarding that face the business. Maintainability for example is more an internal requirement, Performance an external one. Unfortunately I was not able to write down her categorization.

Responding to change

Last but not least I would like to bring in a quote from the session, which I found remarkable:

Software is under development until it is abandoned.

Addition:

Adam Goucher coined the term Discover – Decide – Action for the Exploratory Testing loop. Putting together with the TDD and ATDD memes you get:

• TDD: Red – Green – Refactor
• ATDD: Discuss – Develop – Deliver
• ET: Discover – Decide – Action

I love this list.