Agile Testing Days Website
Tuesday after the lunch at the Agile Testing Days there were two Keynotes and in the evening an Oktoberfest celebration. Following is my write-up of the notes I took in that period.

Agile testing, uncertainty, risk and why it all works

Elisabeth Hendrickson started with examples of Unagile Architecture where parts of the product intertwine with other parts, so that you never know if you’re failing until late in the project. She mentioned the mantra to Fail Fast in a project. If this project is going awry, then I want to know this as soon a possible, not when it’s already two years overdue. She cited Mary Poppendieck:

To go very fast you have to go very disciplined.

She denoted her current seven key practices for Agile testing to succeed:

• Acceptance Test-Driven Development
• Test-Driven Development
• Exploratory Testing
• Automated System Tests
• Automated Unit Tests
• Continuous Integration
• Collective Test Ownership

The term Collective Test Ownership was just recently coined in a discussion about a week ago. Elisabeth described the need for Collective Test Ownership (in comparison to Collective Code Ownership – a core XP practice) to be a side-effect of the testing as a bottleneck situation. Collective Test Ownership means that everyone on the team – testers, developers, architects – is allowed to change a test and submit it back in the version control system if the situation demands this change to happen. Of course this is just related to positive changes, not sabotage, and often needs to be discussed with the product owner or the customer.

She cited Tobias Mayer for the getting together of the Voice of the What and the Tribe of the How for Acceptance Test-Driven Development. She made clear that the product owner (or customer representative) and the team define together the examples for the acceptance criteria of a particular story.

For the TDD cycle she pointed out special care for the refactor before the submission. When the test finally is made pass in an heroic effort, you don’t want to submit it and run over your mess months in the future and think: “What an idiot wrote this?” The clean-up in the Red-Green-Refactor cycle is crucial. She told the anecdote of the first XP team she was on. Though this team had 80% fluctuation in the team over each iteration, the project succeeded. She mentioned that she noticed that by using TDD you end up with pretty similar designs and code, though you might be pairing for the first time with your partner.

Gojko Adzic did a great write-up of the session details that I did not denote on his blog entry. Make sure to dive into it to get more informations about Elisabeth Hendricksons keynote.

Agile Quality Management – Axiom or Oxymoron?

David Evans discussed many viewpoints and impediments of Agile adoption especially from previous test managers. I really look forward for the foils of this talk, since I did not take notes on how to overcome common prejudices for Agile adoption. Though, what I noted down is to view a late change in the requirements not as an impediment, but instead as competive advantage. The customer lets you know, that you can be the first to realize his expectations. Agile Test Management include to manage the team instead of managing the testers as a separate silo. By managing the team, Agile testing is able to succeed, so Test Managers should take the opportunity to widen their scope and learn how to manage teams. Last but not least he coined the term Quality Debt, which occurs if you don’t treat your tests as you treat your code. In viewing test automation as software development effort, I follow this mantra since at least two years.

Testify – One-button Test-Driven Development tooling & setup

Mike Scott introduced into Testify, a utility that is able to set you up for the zeroth iteration in a project. Testify is able to bootstrap your project creation directly. Using self-defineable templates it created folders with dependencies and everything your project might need. In the live demonstration I found amazing that it created not only a project by entering a name for the project, it also already created a .NET application with unit tests (which were basically checking for the proper name), a FitNesse environment with already existing FitNesse acceptance tests, a build file, an installer created during the build process for direct installation of the resulting application and a clock class to use, so you can influence the time during your unit tests – a clear testability feature. In the end he pointed out that he plans to extend testify based on the input from colleagues in the industry.

Agile Inspection

Tom Gilb introduced himself in his keynote as having visited several testing conferences in his life though being not a tester. He introduced his work regarding inspections in software. Over the past decades Tom Gilb has helped companies realize that inspections can be used as Specification Quality Control and reduce requirements documents by a factor of eight. Tom claimed that traditional requirements are written for designer, but not for acceptance test writers. He has three simple rules for clear requirements:

• Clear and unambigious – requirements shall not be misunderstandable
• Quantified Quality – they should be specific to the degree that they are measureable
• No design – no design shall be included

Over the keynote he went into a case study and showed that at a company he took two example pages from a requirements document. He had the management review the documents and identify each issue based on the previously mentioned list for ten minutes. Based on the outcomes he had a mathematical model to predict certain assets of the projects like bug counts and how late the project will actually turn out to be.

He made clear that real requirements usually fit up to just a few pages using a language he invented for and thereby fulfilling the above rules. Over the course I was wondering if Tom sees a connection between his approach to requirements and the ATDD approach that Elisabeth Hendrickson and Gojko Adzic mainly coined over the past few years. I was not yet able to receive an answer from him, though, but I think both are aimed at the same direction: defect injection prevention by making requirements clear, unambigious and testable right from the start. This includes that design decision like in “Do A by B” should be avoided. The requirement here is A, and the design is to do this by B.

Oktoberfest

In the evening there was a large Oktoberfest celebrated. Over the discussions I had at the table with Gojko Adzic, Mike Scott and David Evans were very interesting things, which I did not note down. Basically I was too much afraid to screw up my first conference talk the next day. After two beers Mike Scott and Gojko offered to listen to my presentation in try-run. They gave me great feedback on improvements, though I realized that I’m not as good an entertainer.

After that we went to the hotel bar, where I participated in a conversation with Tom Gilb. He pointed out that one requirement for a space travel or a nuclear reactor is be to have a system which can repair itself in just 5 seconds. This was amazin and I wasn’t able to come up with a solution to this. He explained that in an architectural decision this is quite easy to do, by simply bringing in redundant systems. Build two, three or four systems independently and have the other systems cope up if actions to take would result in loss of life. This is not a design decision, but an architectural one. He claimed that there are few real architects in the IT.