Teaching Testing to High School Girls

This Saturday I participated at a Digigirls event where I taught a testing workshop. Digigirls is an event series in Estonia founded by Tech Sisters – a non-profit organization – to provide girls (9th to 12th grade) encouraging practical experience with roles in software development. Tech Sisters is a community that aims to inspire, educate and encourage women and girls in technology and IT. I was the mentor for testing workshop alongside other professional women who led workshops in project management, programming, design, and UX.

I’m not new to participating at community events be them casual discussions, panels, peer conferences, etc. However, I am new to designing and running a workshop for teenage girls. I must admit that back in the day I sometimes had a hard time relating to girls of my age since I always had my nose in the book, and I genuinely liked to study. Hence, designing a workshop spanning 2×45 minutes that would keep them engaged but also teaches them about the testing profession was a challenge that kept me anxious the few weeks leading up to the event, and also the night before.

Well, I actually did not have to worry so much as the girls were engaged, seemed to have fun, and some were making good observations and were able to describe what they saw quite succinctly.

I wanted to outline the workshop design and my thoughts afterward. Maybe someone will find it helpful when they participate in such events.

Structure and setup

• 2×45 minute sessions with a break in between
• girls in pairs or trios (depending on group size)
• introduction by me – why testing is needed, what it is, what a good tester is like
• 3 rounds of testing using different test objects for each round
• overall direction: moving from simple bug hunt to test design
• around 10-15 minutes of pair testing followed by discussing their findings (why these are issues or not, asking for their evaluation of the program they tested, expanding on and adding context to their observations, adding snippets about tester’s role, etc)
• each bug/issue written on a post-it note and put on whiteboard

Introduction

Since I loved Kevlin Henney’s idea that “software is executable fiction”, I mulled over it and figured that I could extend it into a metaphor to explain the role of testing.

Imagine writing a book alone. It’s quite a bit of work, you need to edit and rewrite bits of it, then proof-read and edit again. Now imagine if  10 people are trying to write the book at the same time while trying to keep to a deadline. There are many stories customers tell the team, and the team also has their own interpretations and ideas about what this book is supposed to become.

Someone switches around paragraphs. Someone switches around chapters. Someone cuts out some sentences and words and pastes them elsewhere. Someone rips out some chapters and starts rewriting from scratch. On top of that, there’s the telephone game of passing on information and you know quite well what happens in that game.

So a software tester is someone who is working alongside the team: he or she tries to read this book, find the missing chapters, pages, typos, weird characters, abrupt endings of stories that are supposed to continue. They help the team to bring coherence to the stories and the book in various ways. After all, we want all this to make sense to the readers.

I compared testing as an activity to research where hypotheses are constructed, experiments are carried out, and results are produced that need to be interpreted on someone’s behalf. I talked about quick learning, prioritizing, analytic and systems thinking. I emphasized curiosity, asking questions, being a great communicator.

Exercise 1

Assignment: test this game and find what’s broken in it http://www.sohorses.com/games/horse-lunge-game-with-dressage/ (thanks for the reference goes to James Bach whom I’ve seen use it albeit for a different purpose).

Learning objectives:

• a simple program can be broken in complex ways
• something that seems to be an obvious issue may be interpreted in many different ways, hence you need to know your sources

Summary

It was a good introduction and warm-up exercises as the game is conceptually simple. You may start from different places in the game but if you apply some systematic thinking, you will start finding issues quickly (or at least something that looks like an issue).

There were some observations and comments made by the girls that provided some good segues into

• testability – having a one-way path to click through states is annoying and wastes time, so this would be something a tester would take to their team to get it solved (build a secret feature to get into different states instantly)
• states and modeling – you can draw up what you see and see if the model can expose more than just clicking in the game
• domain knowledge – horses can switch between the states in a different order in the real life and knowing this may help you ask useful questions
• purpose – for whom was this game made, why would anyone play it
• context – to understand the difference in states between different horses, you could do more research and find out whether some things were intentional (it’s just an early version vs it’s a supposedly fully-functional game that has some flaws)
• configuration – you might not discover a feature of the game if your computer was muted

Exercise 2

Assignment: you need to evaluate and make recommendations for improving the customer’s self-service account tied to their customer card at a particular department store.

Unfortunately, I cannot provide that piece of software (yet)as it’s part of a test assignment I’m developing at my workplace. I can say that it was a simple piece of front-end prototype with 3 pages, a table where to enter other users to your account, shopping history, and some configuration options (limits, discount codes, etc). There were plenty of issues planted in there, also some in the background.

Learning objectives

• test for potential business problems in a close-to-real-life business context
• there is more than meets the eye if you know how to use tools
• it’s possible to test things that aren’t fully functional

Summary

This piece of software looked more like something one would encounter in real life, so it’s easier to relate to. I think they found most of the planted issues as the large majority of them were visual or easy-to-find functional problems.

Once we’d discussed the issues they found, I also opened up Developer Tools and showed console errors and other broken things you can detect. The key point that I think landed quite well was that you have limited view when just looking at the obvious GUI elements. So you can pop open the hood and see what else is there: how much stuff is loaded when a page is loaded, how much time it takes to load something in a web page (so if it’s slow, you can see what makes it slow), etc.

After they had found that some things didn’t work, I also said that well, these can’t work yet as there is no back-end, no database where to save the data. Testers can and should try to get their hands on early prototypes (even if on paper) to test those. It’s possible to test raw things that are semi-functional and it’s valuable. You know it’s possible because you just did it, didn’t you?

One thing I’d change next time is to request them to write down all issues they found but pick 3 that must be fixed above others. That would provide input for a discussion around prioritization and why it matters, why not all issues have the same weight, etc. I did ask them for THE most important bug they thought they found but I think this topic can be built in a bit better.

Exercise 3

This exercise was about testing tours. I figured we could do a few tours so that we can touch upon some test design. I explained the testing tours via being a tourist in a foreign city and how your experience and overview of the city will vary greatly depending on whether you only visit one museum, many museums, only Starbucks, only use underground, etc. The moral of it is that variety will help you learn faster but sometimes you need to focus on one aspect to go deeper or wider.

Assignment: I used Task Coach for this (thanks goes to Huib Schoots who used it in his testopsy at European Testing Conference, so that’s where I got the idea) to get more variety in terms of software.

1. Create a task (specified the criteria)
2. Do a menu tour in task coach

Summary

Since in this exercise I gave some more specific instructions to follow, there was less of freestyle exploring (which kind of made the group a bit more quiet – note to myself, though it was the end of the workshop already). Probably I could have asked them how this exercise felt different from others to get some more specific feedback.

My main goal with the tours was to contrast the reach of the menu tours with just creating one task. Both are valid starting points. Yet one yields more information about what this program is capable of than the other.So this kind of information will help you make decisions about what to test next (and you want to make good decisions not just about one feature but in the context of the entire program).

As a bonus exercise, we also looked at some configuration options and how to combine some of them into one test. That was a dip into test design on a detailed level and provided an opportunity to show how combining can be a good way to get initial input (see if anything “smokes”, then look for fire). On the other hand, it also showed that some of the things in the combination of settings were difficult to observe, so that may justify trying less options together.

***

Overall, I feel like the workshop was a success. I received some compliments from them that I will hold dear. It seemed to me that I was able to keep the pace fast enough and content interesting enough that noone gave up or switched off. That was one of my main concerns as I was not sure how quickly we were going to burn through my prepared exercises.

With the second group, we also ended up discussing business and team model differences as they had different testing workshop experience from previous Digigirls events.

All in all, I’d do it again. I hope other testing ladies out there would also jump on similar opportunities – there’s so much we can share. The smart comments and happy faces and light in their eyes made it worthwhile (even my sleepless nights).