Learning Testing

Five key challenges for agile testers tomorrow (#agileTD 2011)

Gojko Adzic (@gojkoadzic)talked about the five key challenges he sees for agile testers tomorrow. He has two basic statementes/ assumption which guide him to these challenges: Technology is changing fast and the field of agile testing is quite well defined today.
According to Gojko, these challenges are

  1. shorter delivery phases
  2. agile is now mainstream
  3. faster feedback
  4. large „enterprise“ projects
  5. validating business, not software
Learning Testing

A Balanced Test Strategy Strengthens the Team (#agiletd 2011)

The initial statement of Anko Tijman (@agiletesternl) in his talks was, that agile testing is about migitating the risk, therefor a test strategy should focus on risks in

  • code
  • interfaces
  • requirements
  • architecture
  • business acceptance

Lessons Learned since Agile Testing Was Published (#agileTD 2011)

In this talk Lisa Crispin (@lisacrispin) and Janet Gregory (@janetgregoryca) presented some major issues they learned about since they published their book Agile Testing some years ago.
These topics are:

  • Feature Acceptance
  • Test Automation
  • Large Organisations with Multiple Teams
  • Distributed Teams
  • Culture
  • Continous Learning

Agile Testing Days 2011

From monday to wednesday I had the chance to visit the Agile Testing Days in Potsdam. It was an awesome event: I met a lot of interesting people (delegates, speakers & tutors), had many interesting conversations, met former colleagues, listened to amazing talks, and learned a lot. Far too much to wrap everything up in one blog posting. Therefor I will use this article to list up all the articles about the Agile Testing Days 2011 (#agileTD), the list will be updated as a add articles, so drop in from while to while, or subscribe to the RSS-feed:

Fun Testing

How to make your bug report most useless for your team mates

The idea of writing a blog post like this was in my mind for quite a while already, but as too often, I was just procrastinating. Today I have been busy retesting (and closing) a lot of items from our defect tracking system (DTS) and started writing down the following items, as I stumbled upon them (and as they came to my mind as I remembered them from previous projects).

Of course I´m exaggerating a bit on some of the listed items, but all of them are real examples of what I´ve experienced in the past. 😉

So here it is, my (not-yet-complete) list of things to do, to make your bug report most useless for your team mates (none ordered):

Learning Testing

German Agile Testing and Exploratory (GATE) Workshop 2011

Short notice: I will participate at the German Agile Testing and Exploratory (GATE) Workshop 2011 on October 1st & 2nd in Hamburg, Germany. My topics will be „Shared responsibility for quality vs. separate QA teams“.
Other guys participating so far: Markus Gärtner, Maik Nogens, Meike Mertsch, Eusebiu Blindu & Sven Finsterwalder.
More info available on the GATE homepage: www.gate-workshop.de.

I´m looking forward to have a productive weekend full of learning and insights with these guys!


QuickLinks for August 2011

Here a quick list of articles I´ve read during the last month:


Expand/ Collapse included FitNesse pages in CruiseControl.NET´s web dashboard

In this post I will explaing how to make included FitNesse wiki pages visible in CruiseControl.NET´s web dashboard result page.


FitNesse & FitSharp: Some troubleshooting (2)

Could not load file or assembly…

When setting up FitNesse & FitSharp for a project recently, I ran into a really strange problem. I tried debugging using FitSharp´s RunnerW.exe and got the following error message:


FitNesse & FitSharp: Some troubleshooting (1)

Debugging FitSharp FitNesse tests

I´ve worked a lot with FitNesse & FitSharp during the last months in several software projects. Until lately it has always been a big pain to solve any problems when no tests have been executed at all when you clicked the „Test“ button in FitNesse or when tests have been executed via commandline, e.g. within the automated build. Most of the times it was more or less guessing in the wild, changing something here, adapting something there, until the tests ran again.