The Agile Testing Days 2014: Conference Day 1

If you’ve read my previous post about the tutorial day, you may wonder why there’s another ‘Day 1’. — Well, the official conference program mentions the 11th of November as the 1st day, so I stick with that.

For me the day started with a Lean Coffee, a format where people meet, gather topics everyone can bring, vote on these topics and then discuss the topics based on that voting (see the link to the site for more information). I like this format, because it allows to get to introduce a topic and discuss it without spending much time. That way one can see whether at least some other people are interested in a particular topic.

Afterwards, Lisa Crispin & Janet Gregory gave the inspiring first keynote, titled “WELCOME TO THE FUTURE – Preparing For Your Agile Testing Journeys”. They presented their view of how software testing may be in the future and also shared the slides. I liked the Star Trek theme presentation, which also nicely matched the topic.

Next, I attended George Dinwiddie‘s talk “A Poet’s Guide To Automated Testing”. He demonstrated how important a good choice of words is, when writing automated tests. By questioning every single word in a rather typical test, he showed how the tests can be improved. For example a typical test often reads: “When I log in to the system…”.

Who is the ‘I’ mentioned in that line? A customer? A system administrator? The ‘I’ who wrote the test, whatever his or her role was? — After a while, sometimes a rather short while, this knowledge gets lost. So it’s usually better to make this knowledge explicit in the automated test.

The following presentation by Carlos Sanchez was titled “Continuous Delivery, the Next Frontier”. I found it very interesting to see him talking about Docker a lot. Also interesting was so see that, while many people know about Docker and also use it, not many people do use it in a production environment, at least none of the people attending the talk.

Also he provided a funny explanation about where Docker works:

In the the early afternoon I attended Jeff “Cheezy” Morgan‘s workshop “Patterns of Automation”. There was an enormous amount of interest in the workshop and the room filled up quickly. He gave a good number of patterns and even (successfully!) live coded his examples. Super interesting, entertaining and funny!

At the end of the conference part of the day Bob “The Flowchain Sensei” Marshall gave his keynote “The Antimatter Principle” (explained on his blog), a very inspiring, thought-provoking and slideless presentation.

The conference day ended with the now traditional Halloween and costume party, excellent food, super interesting conversations and Matt Heusser receiving the “Most Influential Agile Testing Professional Person” award. Congratulations!

The Agile Testing Days 2014 – Day 1: The Tutorial

The 1st day of the Agile Testing Days for me was a full-day tutorial by Alan ‘The Evil Tester’ Richardson about technical testing. The tutorial was very hands on, and we actually tested something — a website.

I liked how we started with the website as such and focused on the relatively simple aspects of getting a user account and logging in. We did some testing and then reflected on what we were doing and how we did it. For example there were various ways of note-taking:

  • I mostly used pen & paper, and for some notes a text editor (e.g. when I knew that I would like to make a note of text I would enter more than once)
  • Some used their text editor of choice, Evernote or similar tools.

After interacting with the application ‘just’ using the basic browser feature of rendering HTML, we stepped down to a slightly deeper technical level and used ‘developer tools’. These allow interaction with the DOM and, for example, manipulate what an HTML form would submit back to the server — including, but not limited to, selected values of drop down lists. — While not every user will do that, some will. And it’s a good idea to test that your server can candle this unexpected input. We also looked into a number of tools to capture (and again manipulate) network traffic, such as HTTP proxies.

I liked how ‘technical testing’ was presented as something that is different from ‘test automation’. Many of the tools we use for testing enhance our possibilities as testers — and sometimes they also allow for some automation. The main point of technical testing though, is increasing the testers reach into the technical details of the system under test.

This is what I expected from the day and also what was delivered in the tutorial.

Thank you Alan, I liked it a lot!

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.

%d bloggers like this: