Aspects of a Good Session

Still in time for this year’s submissions for the Agile Testing Days 2015 here’s a list of takeaways from an Open Space session at the Agile Testing Days 2014.

This blog post is the result of George Dinwiddie and me asking what makes a good conference session at one of the Open Spaces. In this session we were about 8 people, so the information gathered may not be a representative for all attendees of the whole conference—and it may or may not represent other conferences.

That said without further ado, here’s the list:

  • Context for the content
    Providing context helps listeners to relate to the content and understand the circumstances in which the information was gathered. Both can be important to transfer the presented information to ones own work place.
  • Funny
    This has also been noted down as ‘makes you laugh’, which may be subtly different from ‘funny’. Most people like to laugh or at least smile. It also helps to remember a presentation if it’s entertaining as well as informative.
  • Little text
    Don’t bother people with too much text on slides. Many people will start reading—and at the same time stop listening to what’s being said. In addition to that some of the people who do not start reading, will be annoyed because the text is too small to be read.
  • Share pain points and problems, not just successes
    There’s hardly any project at all that doesn’t run into some kind of trouble. That’s OK.
    Tell people about the issues your project experienced—and also how you managed them.
  • Tell a story—a personal story
    Most people love listening to stories, even more so for a personal story.
  • Short
    Well, keep it short and stay in your assigned time box.
    Extra credit if you manage to give your audience some extra time to switch conference room after your session.
  • Experience things
    Let the audience have an experience versus just listening.
    At best this is an interactive workshop. At least this is a vicarious experience.
  • Interactive
    People like to provide input, even when attending a conference talk. Providing some interactive tasks also helps people to engage with the presented topic.
  • Speaking from experience
    At least at the Agile Testing Days, people like to learn about, dare I say it, real life experiences.
  • Can ask questions along the way
    If you can (or even like) answering questions and responding to comments along the way, by all means do so.
    However, I respect it when presenters prefer to answer questions after the talk.
  • Things that connect different topics
    Learning about new ways in which things are connected is interesting for many people. (However, I recommend against forcing this into a presentation.)
  • An outlandish topic
    Some like bizarre, unconventional stories. This certainly helps to get the audiences attention.
    Notwithstanding, don’t forget to link the presentation to the overall theme of the conference.

Some things that came to mind after the session: 

  • Images
    Provide meaningful and consistent pictures, graphs and diagrams.
  • Big, easy to read text
    This matches well with ‘Little text’ from above.

Please do not hesitate to add a comment, if you would like to add to (or disagree with) the list.
In any case, consider submitting a proposal for the Agile Testing Days! It’s a great conference, it’s fun and there was a costume party in the past few years.

London Tester Gathering Workshops 2015: “Fast Feedback Loops & Fun with Ruby”

My workshop at the London Tester Gathering Workshops 2015 is announced now! They’re offering an early bird rate until the 18th February, by the way. Find the abstract on the conference page or just read ahead. 🙂

Fast Feedback Loops & Fun with Ruby

Ruby is “a Programmer’s best friend”. Let’s use Ruby to get feedback including getting feedback automatically when working on projects. Whether it’s about transforming source code into test results (a.k.a. running automated tests) or generating image files from raw data, Ruby can be used to automate these tasks. Furthermore, it can also be used to automate actually running these tasks, e.g. upon saving a file to disk. Does that sound like a good idea? This session is for you.

I regularly bump into tasks that are…

  1. tedious, if done manually
  2. not done often enough, unless automated
  3. still not done often enough, unless running them is automated, too.

In the workshop we’ll combine some Ruby tools to remedy this situation. In particular the workshop will cover:

  1. Writing a simple Ruby program that does something useful, e.g. turn a markdown file into HTML
  2. Wrapping that in a Rake task
  3. Automate running the task

Knowing how to do this is useful, not only for projects using Ruby as their primary language, but can be handy in all projects.

What is expected:

  • Some Ruby knowledge; you don’t have to be an expert or anything like that.
  • A notebook (or tablet) with an internet connection & Ruby installed.
    Cool if you’re using RVM, rbenv, chruby or similar
  • Mac OS X, BSD; Linux & friends are fine, Windows may be a bit problematic.

 

The Agile Testing Days 2015 – Early News

Yes, this is the first post about the Agile Testing Days 2015.

I’m proud to announce that I’m a speaker:

Again, thanks to everyone involved in making this possible!

 

CRUDCA – Create, Read, Update, Delete, Create Again

I recently tweeted:

A new test sequence: CRUDCA: Create, read, update, delete, create again. — Because sometimes an object can’t be again.

I got some feedback from this, so let’s present the idea in a bit more detail.
Many systems know these 4 basic actions for an object:
  • Create
  • Read
  • Update
  • Delete
That’s where the abbreviation CRUD comes from. In many cases that’s also a rather typical test sequence to check whether the system can handle these actions. — And often it’s also good enough testing.
But sometimes there are more restrictions at work:
  • An object may only be created once and only once. It may be removed, but then not created again.
  • It must be possible to create an object with identical properties again and again.
This is how I came up with ‘CRUDCA’: Create, read, update, delete, create again.
Obviously, it depends on the particular (business) context whether or not it is allowed to create a certain object. The ‘create again’ part covers the action of attempting to create the object. The expected behaviour comes from the requirements or specification of the system.

Have A Good Time And A Great Year 2014

Have a peaceful and great time everybody, enjoy & relax.

I recently found this Santa Claus at the beach in Sankt-Peter Ording while taking my dog for a long walk.

Santa, Sand and Shell

Santa, Sand and Shell

Merry Christmas!

%d bloggers like this: