tl;dr - Zusammenfassung

Kontinuierliches Testen ist hilfreich in der testgetriebenen Entwicklung (TDD) für schnelles Feedback bei gleichzeitiger Beibehaltung des so genannten “Flows”. Drei unterschiedliche Beispiele zeigen wie kontinuierliches Testen den Kontextwechsel bei TDD minimieren kann.

Was ist TDD?

Testgetriebene Entwicklung (TDD) wird praktiziert um bei der Entwicklung kontinuierlich und in kleinen Schritten die Struktur des Codes zu verbessern, Regressionen zu verhindern und schnelles Feedback zu erhalten.

TDD unterscheidet drei Phasen. In der ersten Phase - “Red” - wird ein neuer Test geschrieben. Dieser Test beschreibt einen kleinen Teil der Fachlichkeit und er sollte bei der Ausführung erwartungsgemäß fehlschlagen. Jetzt folgt die zweite Phase - “ Green”. Hier wird nur soviel produktiver Code geschrieben bis die Tests wieder grün sind. Beim Refactoring, dem dritten Schritt,  wird der Code und die Tests von Duplikationen befreit und strukturiert bis sie verständlicher wird. Beim Refactoring müssen die Tests _immer_ erfolgreich durchlaufen.  Gerade in dieser Phase arbeitet man in kleinen Schritten und führt sehr häufig die Tests aus.

Und wo ist nun das Problem?

Bei allen drei Phasen müssen immer wieder die Tests ausgeführt werden. Praktisch bedeutet das jedesmal einen Kontextwechsel für den Entwickler. In diesem Wechsel werden typischerweise die folgenden Schritte ausgeführt:

 

1. Der Code wird gespeichert
2. Wechsel zum Test-Runner
3. Die Tests werden gestartet
4. Das Ergebnis wird abgewartet
5. Wechsel zurück zum Editor

 

Dieser immer wiederkehrende Kontextwechsel beinhaltet viele kleine Schritte die per Tastatur oder Maus ausgeführt werden. Dabei ist man als Entwickler doch nur an dem schnellen Feedback interessiert und riskiert dafür den Verlust der Fokussierung.

Im schlimmsten Fall verliert man sogar den Flow - den Zustand der hoher Konzentration und absoluten Fokussierung. Sven Peters und Stefan Roock haben jeweils über Flow geschrieben.

Wie kann man das Problem lösen?

Alle fünf aufgezeigten Schritte haben keine eigenes und unabhängiges Ziel, sie werden für nur das Feedback gemacht. Die einzelnen Schritte sind alle nur Zwischenschritte zu der Antwort auf die Frage: “Laufen die Tests jetzt wie erwartet?”

Um eine Ergebnis zu erzielen, sollte auch maximal eine Aktion notwendig sein. Drei exemplarische Beispiele sollen das Prinzip verdeutlichen, wie mit nur einer Aktion alle aufgezählten Schritte erledigt werden.

Pragmatisch

Eine sehr einfache und pragmatische Lösung ist es diese Schritte per Makro in einen Befehl zu verpacken.

Ein Beispiel am Editor vim. Mit dem folgenden Befehl wird ein Makro für die Tastenkombination Strg-t aufgezeichnet:

:nnoremap <C-t> :w<cr>!nosetests<cr>

Anstatt einzeln zu speichern und den Test auszuführen, kann ich jetrzt Strg-T drücken. Es wird dann gespeichert und sofort meine Test gestartet

 

Manche Editoren oder IDEs lassen auch automatischen Builds zu. Ein Beispiel wie das noch mehr und schneller in den Editor integriert werden kann zeigt das Video von Gary Bernhardt in seiner beeindruckenden String Calculator Kata in Python 

Wächter

Eine weitere Möglichkeit ist es unabhängig von dem Editor die Tests zu starten bzw. automatisch starten zu lassen. Wie soll das gehen? Um auf Änderungen im Dateisystem zu reagieren gibt es Werkzeuge wie Guard in Ruby oder watchdog in Python. Diese können nach einer Änderung eine Aktion ausführen.  

Wie sieht das am Beispiel watchguard in der Praxis aus? Hier für habe ich ein Shell-Skript runtests.sh das zuerst die Tests startet und mir danach das Ergebnis per notify-send einblendet:

 

#!/bin/bash

nosetests

if [ $? -eq 0 ]

then

    notify-send --icon=dialog-info --expire-time=100 "Tests erfolgreich";

else

    notify-send --icon=dialog-warning --expire-time=250 "Tests kaputt";

fi

 

Das Skript wird in von watchguard bzw dem Befehl watchmedo gestartet wenn sich innerhalb des Projekts eine Datei verändert:

 

watchmedo shell-command -c runtests.sh -p "*.py" -R .

 

Der Fokus liegt auf dem Editor, das Terminal mit dem watchmedo bleibt im Hintergrund. Als Ergebnis nach einem Test sieht man dann eine kleine Benachrichtigung.  Und nur bei unerwarteten Fehlermeldungen kann man schnell in die Konsole wechseln und nachforschen.

 

 

 

Das Beispiel benutzt für die Benachrichtigung notify-send unter Ubuntu, für Mac gibt es zBGrowl oder für Windows Notifu.

Integriert

Es gibt Erweiterungen für die Entwicklungsumgebungen die kontinuierliches Testen unterstützen. Für Eclipse gibt es JunitMax - von Kent Beck - oder Infinitest.  Hier werden die Tests automatisch ausgeführt und fehlschlagende Tests als Fehler angezeigt - ohne das weitere Aktionen vom Entwickler notwendig wären. Carsten Mjartan beschreibt diese in seinem Blogeintrag Continuous Testing Tools (nicht nur) für Java – Infinitest vs. JUnitMax.

 

Besonders beeindruckt haben mich dioe Fähigkeiten von “Mighty Moose” für Visual Studio:

Fazit

Mit kontinuierlichem Testen kann ich bei TDD den Fokus von der Ausführung der Tests auf die Entwicklung zurückführen. Bei der Wahl wie ich meine Tests automatisiert starte gibt es eine große Auswahl an Möglichkeiten, selbst nur mit simplen Werkzeugen wie der Konsole und einfachem Editor kann man kontinuierlich testen und den Kontextwechsel minimieren.

Weiterführende Links:

1. Kent Beck
   TDD by Example 
   http://books.google.de/books/about/Test_Driven_Development.html?hl=de&id=gFgnde_vwMAC
2. Ben Rady, 
   Continuous Testing Explained: 
   http://blog.objectmentor.com/articles/2007/09/20/continuous-testing-explained
3. David Saff Michael und D. Ernst, 
   Reducing wasted development time via continuous testing:
   http://www.cs.washington.edu/homes/mernst/pubs/wasted-time-issre2003.pdf
4. Carsten Mjartan, 
   Continuous Testing Tools (nicht nur) für Java – Infinitest vs. JUnitMax
   http://blog.codecentric.de/2011/01/continuous-testing-tools-nicht-nur-fur-java-infinitest-vs-junitmax/
5. Ben Rady and Rod Coffin,
   Continuous Testing: with Ruby, Rails, and JavaScript:
   http://pragprog.com/book/rcctr/continuous-testing
6. http://continuoustests.com/
7. Ruby - Guard
   https://github.com/guard/guard
8. Python - watchdog
   http://pypi.python.org/pypi/watchdog

Permalink | Leave a comment  »

There was a lot of buzz and critics about Scrum-like Sprints around the last time. One of the merits of the discussions was that now only the how but also the why was discussed. I try to do a short wrap up of what I read and think.

Forcing Hard Decisions

A Sprint in Scrum is timeboxed. Every Sprint has the same length and it ends when the time has come – no matter how much we completed. Jim Highsmith wrote on Twitter about timeboxes: “I’ve always said timeboxes weren’t about time, but about forcing hard decisions.” I think this is an important statement since it questions what a lot of Scrum teams do: Plan what to do during the Sprint and get the approval for that in the Sprint Review. When we look at the Sprint through Jims Eyes we get something different. First we have to think about the “hard decisions” we want to force. There are definitely several options. In my point of view there are two very important questions nowadays, that are related to each other:

1. Did we validate or invalidate our assumptions?
2. Did we produce value for customers and users?

The Sprint timebox forces us to decide how to proceed based on the feedback we got. Should we pivot or persevere? Should we stay with the current Product Backlog or adapt it?

Without timeboxes it is – of course – still possible to force these hard decisions. But most of us like to avoid hard decisions and tend to postpone and postpone and …

Creating Rythm and Flow

Tobias Mayer wrote on Twitter: “Reading anti-timebox tweets. It’s amusing how much disgust is aimed at a unit of time. Units of time create rhythm. Rhythm creates flow.” He added a blog post called “Timebox != Commitment” where he explains his perspective on timeboxes. It is NOT:

1. Set a timebox size
2. Commit to a bunch of work
3. Realize you are failing to complete it all
4. Rush to finish
5. Produce crappy work
6. Be exhausted
7. Go to #2—repeat until dead, or company goes out of business

But it is:

1. Set a timebox size
2. Engage in dialog with requester/s. Review requests, prioritize
3. Select a request, small enough to fit inside the timebox
4. Complete the work to the satisfaction of the requester
5. Breathe [reassess remaining requests if necessary]
6. Go to #3—until there is no request that can fit in the remaining time.
7. Stop work [if time remaining, take Slack time]
8. Reflect. Learn from mistakes, and adapt accordingly
9. Go to #2—repeat until all requests met, or deadline arrived at.

This perspective is supported by the latest modifications to the Scrum-Guide published by Ken Schwaber and Jeff Sutherland: The development does not commit to the Sprint Backlog but does a forecast (like a weather forecast) about what might be achieved.

Other options

Scrum-like Sprints are one possible implementation of timeboxes. I know of at least two other possible implementations. Here are the three options I am aware of:

1. In Scrum we batch together a set of features during the Sprint Planning and use this feature set for the Sprint Review.
2. In Kanban planning and release/review cadences are often decoupled. Review cadences can still be used in a timeboxed way (in the sense of Jim Highsmith to force hard decisions). In this case we batch together some features for review but not for planning.
3. Eric Ries suggests to have a kind of deadline per feature in his book “The Lean Startup“.

In the end it is just the question of when and what to batch together and that is a question of transaction/coordination costs. Batching features together for a review is an easy-to-implement solution when we want to get face-2-face feedback from customers and users. When we have a lot of active users and work a lot with Lean Startup-like cohort metrics and the like we may not need to batch together features for review. Batching features together for planning is an easy solution when the “feature requesters” are not continuously available. When the “feature requester” is available all the time (e.g. because the Product Owner role is shared across the team) it may not be the best solution.

Tagged: Scrum

In march 2012 seven it-agile people (including me) formed the StartupMarch team. We decided to build a product to make online discussions more effective. In the end we had built http://www.discuss2decide.com and http://www.discumeter.com.
This blog post is about the “process” we used. We just started to build the product – without any discussion of the process to use – Scrum, Kanban, XP? We just didn’t talk about it. This is what emerged:

• Before the start of the StartupMach we only had decided on the problem to solve (online discussions) and the technology we would use (Rails). So we invested the first day for some conceptual work.
• At the second day we started the development of the first ideas. We had the first product (Duscuss2Decide) live at day 3 and the second (Discumeter) at day 5. After that we had more than 15 releases per day. The rule was simply: whatever you commit into the master (aka Trunk/Head) will go live immediately.
• Typically we started the day with an informal wrap up of the product usage (a kind of review if you want). Then we discussed what to do during the day (kind of planning). And then we did it. For both “meetings” together we invested 30 to 90 minutes.
• During the day we had 2 to 4 sync meetings to check where were and how to proceed (kind of Daily Scrum).
• We did no Task Breakdown but Story Splitting on a very tiny level. We worked with MMFs (Minimal Marketable Features) that we broke down into User Stories. Most stories were done in less than 2 hours.
• We managed work in progress by gut feeling. Normally we all would work on the stories of one MMF (single piece flow). That way a MMF normally needed one day to complete.
• We did Pair Programming in most cases and often switched pairs at the sync meetings.
• We had two retrospectives. One in the middle of march, one at the end of march.
• There were no roles. No Product Owner, no ScrumMaster, no Testers etc. Just team members. During our second retrospective we had a discussion about the roles. The conclusion was that we sometimes would have profited from a ScrumMaster for facilitating discussions and forcing us to face uncomfortable facts. And we thought that the absence of a Product Owner person was helpful. The team was not only empowered to decide on how to do the work but also on what to work on.

It was a great time. We had a lot of fun, we learned a lot and it felt very productive. Although we didn’t acquire millions of venture capital for our products, Discuss2Decide seems to have value for users. There are some regular users of the tool and most online discussions at it-agile are done with the tool today.

Will it travel?
Will the “process” travel to other contexts? I don’t know. I think there were two special ingredients that are uncommon and may have been crucial:

1. With the seven team members we had roughly 45 years of experience with Agile of different flavors in the room: Scrum, XP, Kanban, FDD.
2. All team members shared a common cultural background (it-agile) that showed up as an extreme openness for other’s ideas, perspectives and needs.

Read more about the Startup March.

Tagged: Kanban, LeanStartup, Scrum

In October 2011 I had the idea of giving a talk about the advantages of WIP limitation. The whole talk should be told as a story and all slides should be cartoons. The opportunity came in the shape of the conference Lean Kanban Benelux. The talk was videotaped, so you can watch the video below if you would like to.


Arne Roock - Limiting your WIP - Why and How? from Agileminds on Vimeo.


I still like the idea of telling stories and having them illustrated as cartoons. So a couple of weeks ago we at it-agile decided to print a little brochure with an updated version of the story about Justin and his experiences with Kanban. The brochures was handed out at the conference Lean Software & Systems 2012 in Boston. 



If you could‘t make it to Boston (and you live inside Europe), you can order a free copy at this it-agile website. If you live outside Europe, please get in touch with me, so we can see what we can do.

And if you have any kind of feedback, please do not hesitate to leave a comment or send me an email!

The second GATE workshop will take place on September 8th 2012 in Munich, Germany. GATE is a workshop that falls into the series of peer workshops on testing like LAWST, LEWT, DEWT, and SWET.

As the content owner of this workshop, I worked with my peers to identify the following main theme:

The future of Agile and Exploratory Testing

We expect participants to submit content in line with this theme. We are interested in contributions such as

• innovative approaches to testing
• combining session- and thread-based test management
• collaborative test chartering
• testing in practice (Testing Dojos, Testautomation Coderetreat, Hands-on testing)

Feel free to contact us if you are unsure. We will be most glad to provide you feedback.

You will find more detailed information on the GATE homepage over the course of the next months.

I look forward to meeting lots of testers in Munich in September.

At the Let’s Test conference, the first ever context-driven testing conference in Europe, Michael Bolton delivered the first keynote on Monday morning. He was talking about context-driven testing – what else?

Michael emphasized that the title of the talk is irony. He was surprised to find out that people took it serious when he held the talk for the first time.

Michael mentioned the “How to think about science” series. He mentioned the starting point of scientific experiments when people started to investigate influences of air on the human body system. This was the first time an intersection between engineering and art came into place with the air pump. Everyone had one.

Robert Boyle introduced the term of fact-based experimentation. He tried to solve a human issue by inviting people to his experiments so they could witness the results.

On the other hand Thomas Hobbes argued against Boyle’s method. He approached the scientific problem from a philosophy point of view. One of Hobbes principle objections was that Boyle started his experiments based on the models that led him to come up with the experiment. The second objection Hobbes had about Boyle’s experiments is that he didn’t solve the social problem underlying the arguments of the time. Mere evidence doesn’t convince people – Knowledge has a social dimension.

Michael concluded referring to work from Kuhn and others that the whole body of scientific method was questioned in the 1980s. They found out that scientists were merely good at convincing others of their approach and their results, but didn’t lead to generalizable insights, but merely observed facts. At the same point, it seems that similar debates started to rise in the testing community as well.

Michael read a part from “The gift of time”, a gift for the life and work of Jerry Weinberg. He referenced a section from James Bach’s chapter, where Jerry trapped him into insights about testing and testers. Testers know that some things can be different.

Michael referred to the seven principles of the context-driven school. He pointed out that every principle carries uncertainty in it. In a complex world, we have to be able to deal with uncertainty.

Michael raised the point that we are in the middle of a big change. This change started in the 1820s/1830s with the uprising of electricity. Michael continued to challenge that in traditional testing, the only kind of certainty comes from test cases and test plans. Is that all we have to provide for certainty? Is that all you need? I agree with Michael here – from a distance it sounds rubbish.

A key part of our service is to reduce unwarranted and potentially damaging certainty about the product. Science has been going through significant changes over the last few decades. Testing cannot make any absolute promises about what it delivers. Instead we deliver partial answers that might be useful. Testers are anthropologists in the field of software development projects. We observe what happens, and provide our observations. But we don’t make the decisions about dealing with the uncertainty.

Michael concluded the keynote by pointing to the third principle of the context-driven school:

People, working together, are the most important part of any project’s context.

He explained that this means that we have to develop ourselves so that we as testers can be a valuable part of the projects that we are working on.

Wer würde nicht gern so schnell Neues lernen wie Neo im Film Matrix? Einfach ein paar Lernprogramme im Schnelldurchlauf „einspielen“ und schon ist man Kampfsportprofi, kann Hubschrauber fliegen und zig andere tolle Sachen…

Seit einem Monat habe ich das Gefühl, mitten in so einem Lernprogramm zu stecken – bei it-agile. Im April bin ich zu it-agile gewechselt und bin einfach zu begeistert, um nicht darüber zu schreiben.

Gleich an meinem ersten Arbeitstag bin ich in das Kickoff Meeting des Teams „Innovative Produkte“ gestolpert. Direkte Folge: Ich bin jetzt Teil des Teams, habe zwei neue Bücher auf meiner Leseliste: LeanStartup und The Startup Owner’s Manual und muss mir mal Dimensional Planning ansehen.

Schon vor dem ersten Tag hatte ich das Glück an einem it-agile Tuning Tag teilzunehmen. Ich kannte dadurch schon fast alle Kollegen, bevor ich überhaupt angefangen habe. Einfach genial. Nebenbei habe ich auch noch diverse neue Moderationsideen mitgenommen.

Insbesondere über Yammer gibt es einen ständigen Austausch mit den Kollegen. Es vergeht kaum ein Tag, an dem ich nicht darüber neue Impulse bekomme oder schnell mal vom Know-how der Kollegen profitieren kann. So kommen dann mal spontan neue Bücher auf die Leseliste wie Liftoff, The Secrets of Consulting oder Innovation Games. Ach ja, dann gibt’s noch Story Maps, Delegation Poker und und und …

Dass ständiges Lernen in der IT-Branche dazu gehört, ist ja nichts Neues. Aber eine so ausgeprägte Lernkultur wie hier, habe ich wirklich noch nie gesehen.

Kein Wunder also, wenn man sich da etwas wie Neo fühlt oder

Leider klappt es mit dem Hubschrauber fliegen noch nicht so ganz, aber das wird schon auch noch…

Some time ago, I read in a blog post something like "Kanban is good for small teams, but it does not work for bigger teams." A couple of weeks later, someone told me "Kanban is appropriate for big teams, but it is nonsense for small teams." What I hear really often is: "Kanban might be good for maintenance teams, but it‘s not working for development teams." But at the same time people say: "Kanban can never work for operations teams." And of course there are rumors that "Kanban is not working in startup environments" or "Kanban is not working in big enterprise environments."

I think there‘s a misunderstanding about the nature of Kanban that causes people to tell such things. Kanban is not a software development method. And Kanban is not a project management method in the first place. Instead, Kanban is a change method. In this respect the answer to the question: "When does Kanban not work?" should be "If a team or organization does not want to change/improve".
And there is one more thing to this: Kanban focuses on improving the flow of value-added tasks. In his Keynote from Lean Kanban Benelux 2011 (which is highly recommended!) David Anderson argues that Kanban is not appropriate when your process does not suffer from overburdening or variability in flow.
That‘s it! If you want to improve and your process suffers from overburdening or variability in flow, Kanban might be an appropriate method. Of course that does not mean that you will automatically succeed with Kanban - there are still quite a lot of pitfalls.

What I‘ve observed during the past years from Kanban teams I‘ve worked with or met at other occasions is that there is a huge variety of contexts in which teams and organizations benefit from Kanban. For example there is e-netconsulting, a rather small web agency that is using an end-to-end Kanban systems (watch experience report from LKCE11). We have an IT department in an public institution that is using Kanban. Then there is Jimdo, a startup with more than 100 employees in three continents (watch experience report from LKCE11). We have SAP, one of the biggest enterprises in the world, where some teams are using Kanban (watch experience report from LKCE11). I‘m working with a company that is building a big database engine. Then there‘s a major dating platform which I visited recently. And we‘ve just started using Kanban at a company that is building a famous Smartphone App. Not to forget mobile.de - Europe‘s biggest online platform for used cars - which uses Kanban for site ops teams, dev teams as well as on a portfolio level. And theses are only the teams I know directly!
All these teams and organizations are completely different, their work is different, their customers are different, their technologies are different, their problems are different. And still they all find it useful to apply Kanban - all in a different way. Is Kanban the right tool for every organization? No! Is there a very wide range of contexts where Kanban is applicable? Yes!

Ein weiteres Anti-Pattern beim testgetriebenen Entwickeln. Der habgierige Fänger (The Greedy Catcher) ist eines der unauffälligsten Anti-Pattern.

Es handelt sich hier um einen Test, der Exceptions abfängt und den Stack-Trace verschluckt. Meist ersetzt der Greedy Catcher, die auftretende Exception, durch eine weniger informative Fehlermeldung.

Damit ist es sehr schwierig auf den ersten Blick zu erkennen warum der Test nicht läuft. Hier hilft nur eine "Debugging Session". Das wollen wir aber nicht.

Hier ein Beispiel für den habgierigen Fänger. Ich verwende dafür die DoesNotThrow-Methode von NUnit.







Laut NUnit ist eine Exception aufgetreten, jedoch haben wir keinen Hinweiß darauf warum der Test fehlgeschlagen ist. Die Kundendaten können nicht geladen werden... hmmm. Die Frage warum lässt aber der Test offen. Hier hilft nur das "Debuggen" der Methode.

Wie wäre es den Test ohne DoesNotThrow auszuführen und eine Überprüfung auf einen Kunden in der Liste vorzunehmen?


Dazu die NUnit Ausgabe.




Die Fehlermeldung kommt jetzt direkt durch und wird nicht von der DoesNotThrow-Methode verschluckt. Hiermit erhält man eine viel aussagekräftigere Information als mit der oberen Version. Noch ein kleiner Hinweis. Es wäre auch möglich ohne eine Assert-Anweisung diesen Test zu schreiben. Jedoch einen Test ohne Assert ist kein wirklicher Test. Außerdem ist es für andere Entwickler nicht ersichtlich was hier eigentlich getestet wird.

Ich würde hier selbstverständlich nicht von Unit-Test sprechen sondern von Integrationstest. Da dieser Test mit externen Ressourcen arbeitet.

Qualität ist schwer zu fassen. Jeder will sie haben, aber kaum einer kann sagen, was genau Qualität bedeutet, wie man sie herstellt und wie viel Qualität man benötigt.
Zusammen mit meinem Bruder Stefan Roock habe ich mir mal genauer angesehen, welche unterschiedlichen Qualitätskonzepte es in der Softwareentwicklung gibt und was die Agile Welt zu Qualität sagt. Herausgekommen ist ein Rundgang von der ISO-Norm EN ISO-9000:2008 über Jerry Weinberg und Ishakawa Kaoru bis zu Scrum und Kanban.
Unsere Ergebnisse haben wir in drei verschiedenen Varianten aufbereitet:

1) Als "klassischer" Fachartikel, der im BT Magazin erschienen ist und den man hier lesen kann.

2) Als Detektivgeschichte im Marlowe-Stil, die wir als kleine Broschüre gedruckt haben. Die Broschüre kann man sich kostenlos bei it-agile bestellen.



3) Und als Schauspiel, bei dem Sherlock Holmes und Watson den Qualitäten jagen. Dieses Schauspiel haben wir auf der JAX 2012 aufgeführt. Wer es nicht sehen konnte, dem mag dieses Bild einen kleinen Eindruck geben;-)



Bei der JAX ist übrigens auch dieses kurze Interview zum Thema entstanden