Tag: Agile Testing Days

Tips for Conference Proposals & Sessions

Disclaimer: This year I’m one of the reviewers for the Agile Testing Days.

It’s proposal season again, at least for one of my favourite conferences, the Agile Testing Days; the call for papers is open until March 28th (for 2021).

There is a good number of articles and blogs available on the topic of Agile Testing Days proposals alone: I suggest to follow the advice Uwe gives with his blog post “Call for Papers Submission Pitfalls & How to Do it Better! Tales from a Conference Organizer“. There’s more info to find from that same conference over on YouTube: https://youtu.be/QxC-Ee51xmM

Mind The Context

Another important tip (especially for those thinking about a keynote) comes from Liz Keogh:

If it’s an opening keynote, I try to open people’s minds to learn and question. If it’s a closing keynote, I try to help them reflect on what they learned. Keynotes are there to frame the rest of the conference.

Liz Keogh on Twitter

I believe similar thinking applies to other sessions too: Make your session fit into the frame of the conference and what you know about the attendees expectations.

Tell a Story

I personally try to at least come up with a story, either one I made up or a personal one. Both worked well for me:

For a ½-day tutorial about testing and the Internet of Things (IoT), I set up the story of Goblin King Jareth the 42nd, who wanted to control his kingdom with a set of IoT devices and tasked the participants with testings these devices. The framing story helped to provide some reason to actually participate in the exercises.

For a (read: ‘the’ 🙂) keynote I gave at Agile Testing Days 2019, I chose the most personal story I possibly could: My diagnosis of and treatment for cancer – and why I still consider myself lucky. Read about it in “Being Lucky — A Keynote at the Agile Testing Days 2019“.

If you like to know more about telling a good story, be sure to read Huib Schoots’ blog post “Storytelling“! You’ll find — no surprise — a good story (and many links to more information, too).

Be Prepared

Things can go wrong: The notebook you planned to give the presentation with may crash. The projector may break or the sound system my fail. You may forget what you wanted to say. These things all happened to someone somewhere.

It’s better (and impressive!) to be prepared. For my keynote, I prepared index cards with notes of what I wanted to say when, when to make extra long breaks and other instructions, such as when to proceed to the next slide. At first I numbered them, so I could sort them, if I dropped them on the floor.

Numbered index cards

Later, I also put them on a thread: Now, even when I would drop them, they would still be sorted! This would have saved the talk, had I dropped those cards.

Index cards on a thread, to prevent shuffling

Some of the directions didn’t work out in the moment the presentation was live: The introduction was totally different from what I expected (and significantly louder!).

Mind the Last Possible Moment

One important, even obvious, aspect: Don’t miss the dead line. I did once and it’s annoying. Very annoying. — Most of the work was done for nothing, because I forgot to check the calendar. I learned it the hard way: If I’m too late to submit, it doesn’t matter how good the proposal was. Only if submitted within time, a paper has a chance to be selected.

I hope to see many great and inspiring proposals for the Agile Testing Days 2021!

Agile Testing Days 2020 – the Other Two Days

In a previous post I summarised the 1st day of the Agile Testing Days 2020.

Lean Coffee

2020 was the first year, I facilitated a LeanCoffee. Thank you Janet Gregory & Lisa Crispin for inviting me to help!
Since this was an online-only conference, we used a web application and Janet selected LeanCoffeeTable. I found it easy enough to use. I particularly like the ability that all participants can enter actions and learnings during the topic discussions as well as generate a PDF to summarise the meeting. I found this a very pleasant experience.

Here are some of the ideas and insights, I kept:

  1. No Testing Column
    I’ve learned that some teams entirely remove the testing column(s) from their boards. Obviously, this simplifies the board. But more importantly, it also seems to help teams integrate testing tighter with the overall development. This in turn supports teams working as one entity, and not as a number of people who happen to work on the same story.
  2. After all those years: So many topics about testing
    Even after years, in some cases decades in testing, there are still areas that one can learn about, drive into and possibly thrive in. The next point is one that surprised me a bit.
  3. Automated accessibility testing
    At least some parts of accessibility (commonly abbreviated a11y) testing can be automated. More on that later.
  4. Productive ensemble testing
    Test in an ensemble testing (formerly known as ‘mob testing’, similar to mob programming) can be productive even with people that haven’t worked together. This was mentioned by a Lean Coffee participant who joined a group of people (with whom they never worked with before) for a testing session. To their surprise people worked together quite well.

The Last Talk On Software Testing

I had the great pleasure to moderate Rahul Verma’s talk ‘The Last Talk on SoftwareTesting’, where he explained were he thinks the business of tasting (no typo!) went wrong. Entertaining, hilarious and light hearted. And thankfully not actually the last talk on software testing at all. Here’s a very nice summary by Ekaterina Budnikov:

Automated Accessibility Testing

I participated in Cecilie Haugstvedt‘s workshop ‘Automatic Accessibility Testing for All‘.

I was really surprised how far automated testing of accessibility is possible – and how easy it is to get started! In addition to that, I found it interesting that automated a11y (the common abbreviation for accessibility) tests can and should be divided into unit and integration tests.

An important learning: The tests that check contrasts (e.g. of text and background) are integration tests: Most often colours are set site using CSS, so not every article, product description etc. needs to be checked individually. Also the computation of how good (or bad) the contrast is, seems to be more time consuming than I thought it is.

For a first step to get some idea of accessibility of a page in Chrome: Using “CMD-OPTION-I” (on a Mac) or “View ➙ Developer ➙ Developer Tools” (via the menu) open the developer tools. Then go to the ‘Lighthouse’ tab & click generate report.

Moderating a New Voices Track

I also really enjoyed moderating Chris Baumann‘s talk ‘Extreme learning situations as testers’. The talk & topic were so good, some of the attendees stayed in the Jitsi room to discuss the topic for the whole next time slot! The following tweets cover some of the ideas & insights Christian shared with us:

Thank you Mariia for the wonderful summary!

Do you also have insights and ideas you took home (where you probably were all the time anyway, this year)? What are they?

Agile Testing Days 2020 (and 2009)

These are some insights I had today, posted as Tweets:

And last, but certainly not least Miroslava Nikolova made me (re?) post a message on a piece of cardboard that circled around at the Agile Testing Days 2009.

I think it is still valid and covers the spirit of this very conference and the attitude of everyone taking part so well.

Here’s the plain text (and if you know who’s the original author, I would really like to know who they are):

We are a community of professionals. We are dedicated of our own continuing education and take responsibility for our careers. We support each other in learning and advancing our craft. We certify ourselves.

— Unknown author(s?) at the Agile Testing Days 2009

I thank everyone who made this day so great!

Agile Testing Days 2020

I’m really excited that the Agile Testing Days accepted me as a speaker again. This year I’ll offer two workshops, one of them at two times.

“Get The Most Out Of This Conference” is meant for newcomers to conferences in general. If you haven’t attended a conference before, this is for you. The plan is to have the first one on Monday afternoon (9th, Nov. 2020), and then to have the second go right after the morning keynote on Tuesday morning (10th, Nov. 2020). There’s a teaser video available at vimeo.

Let’s Start Learning Elixir — Together” is the second workshop. It’s two hours of looking into a functional programming language, getting started to learning it. This is scheduled for Wednesday morning. For the Elixir workshop there’s a teaser video, too.


%d bloggers like this: