Along with other testers from ScanJour, I participated in todays Danish test conference held by the Danish Software Testing Board. My “30 seconds commercial” from the conference would contain the following:

First presentation was on the subject “What defines an excellent test manager”, presenting a survey made among European and US companies. Nothing much really to say from that presentation…

From John Fodehs presentation/workshop on metrics:

  • Seen as a production process, the testing activity doesn’t bring any value/features to the software product itself, since we’re not as such modifying the software itself. John used a figure similar to the following, to describe this situation:
     image
  • So what value does the testing activity bring into the process? Luckily there was an answer to this, and it’s “Information”:
    image
  • Back to metrics (which the workshop was about); metrics can help us to understand, assess, predict, improve and finally communicate the progress of our software development project.
  • The ISTQB syllabus says “In order to control testing, it should be monitored throughout the project”, meaning that monitoring metrics should be an ongoing activity and metrics must be SMART (Specific, Measurable, Acceptable, Relevant and Timely)
  • In order to identify metrics, we were shown a technique called GQM (Goal-Question-Metric), where you start to define your goals, then the questions you would like answered and finally identify your metrics. This is shown in the following figure:

    image

    An example could be to have a goal of “Get release overview” and the question could be “Are we ready to release?” and then identify the metrics needed to answer this question.

    Looking forward to use this technique, which I actually think I can find use for in many situations, not only within my professional worklife.
  • Then we had a discussion about “what is software quality”. Of the presented statements I like “Conformance to requirements” [Crosby] and “Fitness for use” [Juran]. I find it important to be able to measure the quality somehow (although it’s not always easy).

In the remaining part of the workshop John presented a “Dashboard” from a real project. Interesting to see, and all in all a good presentation on use of metrics.

Saxo Bank had a presentation about “Agile release test in practice”, where they presented how they have one team that fulltime perform the integration tests, being able to release every second week. I like this concept of having somewhere where an integration test can be applied to all your products, and this certainly an idea that I will bring home. And then this presentation mentioned “There is no testing best practices – only good practices that can be used in a given context” (see http://context-driven-testing.com/)

Nykredit talked about their way to TMMi level 4. Interesting to hear about TMMi and their central test excellence center. But they live in a world of long waterfall-ish projects, so not easy to use their experiences on the agile projects we’re running.

Then finally Dorothy Graham had a presentation on her latest book Experiences of Test Automation (which I’m currently reading – will write a blog post when I’m done with it). I had the pleasure of attending a workshop by Dorothy Graham a couple of years ago on EuroSTAR in Copenhagen; a session I still remember as being really useful. Her book contains 28 case studies on test automation projects throughout the world. Some of her main points (at least how I see them) are:

  • Test Automation is development. You have to consider a test automation project like any other software development project, i.e. have clear requirements, an architecture, sufficient resources etc.
  • Define an architecture for your test automation, otherwise you end up with automated tests that cannot be maintained and then probably will be dropped sooner or later.
  • Build “Keywords” (or actions) that can be reused in different test cases. Again simply a good development practice.
  • Of course pay attention to your failed tests, but remember to review your green tests regularly to ensure they are still correct (also see my previous post)

And from her summary slide:

  • Test automation will become more critical for everyone
  • Management support and understanding is essential for long-term success
  • The right testware architecture is essential for minimizing maintenance and maximizing use of automation
  • Learn from others’ mistakes – life’s too short to make them all yourself!

It’s a little bit surprising at first, that Dorothy Graham is able to talk about test automation without showing any tools, but she certainly does a good job on viewing it from a theoretical level, and my impression is that my colleague domain testers also got a good idea about test automation possibilities and challenges from this presentation.

Actually it was from Dorothy Graham I first learned the concept of preparing a “30 seconds commercial”, so you are prepared when people back at the office asks you how the conference went. Although I’m probably not able to tell all this in 30 seconds…