Cereal Box Course Summary

When I return to work after attending a training course, my colleagues and my boss usually want to know how it went. The conversation might go something like:

Them: "How was your course?"
Me: "Good."
Them: "What did you learn?"
Me: "Oh, lots of stuff."
Them: "Okay. Cool."

Though this is slightly exaggerated example, I often find it difficult to remember and describe what I have learned. When I leave a course, my brain feels full of new ideas and enthusiasm. But, by the next morning, I have usually returned to thinking about other things.

As a trainer, I don't want my course attendees to return to work and have the conversation I've described above. Instead I want them to be articulate and passionate. One of the ways that I have attempted this is using a cereal box course summary.

This is not an original idea. I heard about it from my colleague Ceedee Doyle, who had heard it from someone else, unfortunately I don't know the source. However, here's how it works.

Ask participants to construct a cereal box for everything they've learned on the course. What they have to put on the box will follow the same conventions as for a real packet of cereal.

The front of the box should show the name of the course, pictures, and a slogan.

The side of the box should list the ingredients of the course.

The back of the box should have highlights, reviews and testimonials.

I have used this activity during the last hour of a two day training course. The participants had 30 minutes to make their cereal box, then we spent 30 minutes sharing their creations, reflections and feedback on the course as a whole.

I found the cereal box course summary a creative and fun activity to finish off a course. People are relaxed and talkative as they work. The cereal box captures a positive and high-level view of the course overall, which creates a favourable tone to end on.

I also like including an opportunity for reflection as part of the course itself. One of our students summarised the benefit of this in their testimonial, saying  "I especially liked the final summing up which made me realise how much I’d learned." [1]

Finally, this activity gives each participant something quirky and concrete to take back to work with them. The appearance of the cereal box on their desk may initiate conversations about the training they attended. The writing on the box should support the conversation. Their colleagues can see what they have learned, and the format in which the information is presented is reflective of the interactive and engaging training environment that we work hard to create.

Review the Future Retrospective

I was co-facilitating a client workshop recently, and I wanted to include an agile retrospective activity. It was my first introduction to the team and they were using a waterfall development methodology, so I didn't want to go too zany. However I wanted to know how they thought they could improve and, as a facilitator, I find the constant 'post-it notes then sharing' retrospective format to be quite boring to deliver.

I looked through Retr-O-Mat for inspiration and decided that the Remember the Future idea would form the basis of my activity:

Source: Retr-O-Mat

I liked that the premise of this idea put the team in a forward thinking mindset. However it wasn't quite the style I was after so, for the workshop, I chose to adapt the exercise in several ways. 

To get the team talking to one another so that I could observe their dynamics, I wanted to create a more interactive collection activity rather than an individual one.  I asked the team to break into groups of three people rather than working by themselves.

As the team weren't using iterations I changed the language to "Imagine your next release is the best ever!". To shift the focus from looking inwards, imagining only the team perspective, to looking outwards, imagining the reaction of others in the organisation, I asked each group to think about the reactions to their amazing release from their managers, business owners, end users and the team themselves.

Instead of capturing jotting notes or keywords, each group had to capture these reactions in a series of reviews that included a 5-star rating, a comment, and a name, e.g.

★★★★★ "Our key process is now 10 minutes faster! Amazing!" - Bob from Business

Once the reviews were complete, each group presented back to the team. It was interesting to see different themes emerge from each group, including feedback focused on successful delivery of key functional improvements to business people, unusually quick turnaround of tasks that improved flow of work, and simple recognition of the team's achievement.

After the presentations we returned to the activity as it was described in Retr-O-Mat. We asked the team to think about the changes they would have made to their process to receive these reviews. Suggestions for improvement appeared rapidly and, with this shared context, were relatively consistent across all the participants in the workshop.

I found this activity collected the type of information that we were seeking, while also keeping the team engaged and interactive in the workshop itself.

Conferences build community

Community is important to me. The primary reason that I volunteer my time to organise testing events is to offer people an opportunity to meet their peers and share ideas. It is the opportunity for interaction that I value, and I think that conferences are an essential part of this. Conferences build community.

A successful conference is not just about delivery of great content. It also provides a platform for every attendee to genuinely connect with another; an interaction that is the start of a supportive, inspiring or challenging professional relationship. When reflecting on a conference I find that the presentations may have faded from memory, but the conversations that spawned ongoing associations are much easier to recall.

As a conference organiser, the responsibility for setting the tone of the conference weighs heavier on me than selecting the ideas. It seems that achieving success in the community aspect of a conference is much more difficult than the content.

And everything begins with the speaker selection.

I get frustrated when I feel that a list of speakers isn't a true mirror of the community behind a conference, but instead a distorted reflection suited to a fairground Hall of Mirrors. As a conference organiser,  I am looking for strong presenters with innovative ideas who truly reflect the diversity of our profession. I am constantly conscious of creating a speaker line up that engages the brain and accurately shows who we are as a group.

This is a challenge and, when I consider diversity, I consider many attributes. As a woman in testing, I certainly think about the gender ratio in our speaker selection. But I also think about years of experience in testing, where people are employed, ethnicity, age and reputation. If I want the conference to offer something for everyone in the community, then I have to consider everyone in the community by focusing on what distinguishes us from each other.

I don't feel that I have ever had to select a speaker who didn't deserve their place. I simply consider diversity alongside the experiences and ideas that people bring. I think about the audience for a topic rather than the topic in isolation. There are instances when a proposal holds little appeal to me personally, but I feel it would be a great session for others within the community, both for its content and the opportunity to establish the presenter as an active voice.

Ideas are rarely innovative in every context. So considering ideas alone is an injustice to the community that the conference is for. I believe that every organiser should actively think about the people that they serve when selecting speakers.

When asked "What did you enjoy about the conference?", attendees at the recent WeTest Weekend Workshops referenced the topics, discussions, session and learning. I think we had fantastic content. However the strongest theme in responses to this question was the people. I believe this feedback reflects our effort as organisers to put the people of the community at the heart of our decisions on their behalf.

What did you enjoy about the conference?
WeTest Weekend Workshops 2014

Different Ideas for Defect Management

I believe that a good defect management process should encourage and facilitate discussion between developers and testers. Frustration with the way in which defects are reported and managed may be due to a lack, or absence, of conversation.

The way that you manage defects should depend on your development methodology, location of team members, and company culture. Yet it seems that many testers adopt a bug tracking tool as the only way to communicate problems, with little consideration to establishing team relationships. Finding a bug is a perfect excuse for a tester to speak to a developer; utilise this opportunity!

Here are four different ideas for defect management that pair the tools we use with developer interaction based on my own experiences.

Bug tracking tool

I worked onsite with a client in South America, installing hardware and software then co-ordinating testing across the wider solution. The developers supporting this install were based in New Zealand, which meant that they were largely unavailable during South American business hours.

Though our software had a user interface, much of the function was performed by backend components. The information required to identify and fix problems was recorded in multiple log files stored in different locations.

During the day, I would identify problems, reproduce them, capture a clean set of log files, and then raise an appropriate defect in our bug tracking tool. The tool required a number of attributes to be set for each bug; priority, severity, component, etc. They also had a title, short description, and a set of attached logs that the developer could reference.

In this environment, I felt that the tool was essential to manage a high volume of problems with associated logs. However communicating via the tool alone was ineffective. When the New Zealand based developer arrived at work, he would have an inbox full of notifications from the bug tracking system reflecting the problems resolved, remaining and discovered during our day. The volume of these messages meant that he occasionally missed information that was important, or prioritised his time incorrectly.

I initiated a daily skype session for defect triage to explain which bug tracking notifications he should focus on, and why. This happened at the end of my day and the beginning of his. During this time he would try to ask enough questions to understand the complexities of the problem, so that he could provide a timely fix. These conversations helped us to create a rapid and effective defect turnaround.

Visual management board

I worked in a team developing a web application using a kanban development methodology. We focused on flow through the process, which meant that stories were rarely owned by individuals. Instead tasks across multiple pieces of functionality were shared among all the developers.

The team used a visual management board that occupied a large whiteboard alongside our workspace. This board was frequently referred to and updated throughout the day, not just at our morning stand up meeting. Upon completing a task, both developers and testers would determine their next activity by visiting the board.

We used the same board for defect management. If issues were discovered during testing, I would write each one on a post-it note and attach it to the board. In this team, issues generally manifested in the user interface and were relatively simple to reproduce. A post-it note usually captured enough information for the problem to be understood by others.

New defects would be picked up as a priority when a developer visited the board in search of a new task. They would place their avatar on the defect, and then speak to me about anything that they didn’t understand, or wanted to question the validity of.

As problems were resolved, the developer would commit their change to the repository and we would swap my avatar onto the task. Bugs would then move to “done” in the same manner as other tasks on the board.

Desk delivery

I worked in a team developing a web application using the scrum framework for agile development. In this team stories were adopted by one or two developers, who would work on tasks and take ownership of fixing any associated defects discovered during testing.

We had an electronic visual management board that was used regularly and updated often. There was also a physical visual management board, but this would only match the electronic version immediately after our daily stand up had occurred.

The piece of software that provided the electronic board also offered defect tracking functionality. In this organisation I was reluctant to use a defect tracking application, as I felt the team were at a real risk of communicating solely through tools despite being co-located. Instead I decided to record my bugs on post-it notes.

Unlike the previous scenario, in this situation there was little point in sticking these post-it notes on the physical visual management board. It wasn't being used often enough. Instead I would take them directly to the developer who was working on the story.

My post-it note delivery style varied depending on the developer. One developer was quite happy for me to arrive at his desk, read out what was written on each post-it, then talk about the problems. Another preferred that I show her each defect in her local version of the application so that she was sure she understood what to change.

The developers would work from a set of post-it note defects lined up along their desk. As they resolved problems they would return the associated post-it to me. Having to transfer the physical object increased the opportunity for conversation and helped create relationships. There was also a healthy level of competition in trying not to have the most post-it notes stuck to your desk!

Cloud-based visual model

I worked in a team developing a web application using an agile methodology. This team was co-located in one area of the office, as we all worked part time on other projects.

A portable visual management board was created and maintained by the business analyst using a large piece of cardboard. It was kept under his desk and only used during our daily stand up meeting to discuss our progress.

From a defect management perspective, this organisation prided itself on its trendy culture. Though a bug tracking tool existed it was largely used by call centre staff to record customer issues in production.

In this team I decided to communicate information about my testing using a cloud based visual model. Each person in the team had a MindMeister account. I used this software to create a mind map showing my test ideas, reflect progress through testing, and to record defects, which were highlighted in red and had an attached note that explained the problem.

When I completed a testing task, I would send the developers a link via instant messaging to the cloud-based visual model. They could see where the problems were, and would respond with questions if anything was unclear. They seemed to like being able to see defects within a wider context, and were quite positive about a nifty new tool!

Women in Testing on Twitter

After speaking at a Girl Geek Dinner in mid October, I became really aware that my Twitter stream contained tweets that were mostly from men. Over the past month I have experimented with who I am following to try and correct this imbalance.

The categories are imperfect and the list is likely to be incomplete, but here are some of the women in testing that I would recommend following:

DISCLAIMER: I've grouped based on the reasons that I follow these women. Though there are many individuals who could appear in multiple categories, I wanted to share the primary reasons why I value their contributions on Twitter. This is one specific facet of their professional persona and, should you choose to follow them, you may see things quite differently.

Crème de la crème

“the best person or thing of a particular kind.”
Elisabeth Hendrickson and Lisa Crispin are among the most widely known and well regarded software testers in the world. With followers in the thousands, they are likely to be a part of your Twitter stream already. Though Elisabeth and Lisa often tweet about their lives outside of testing, they also share articles and tweets from their extensive professional networks that I would miss otherwise.

Community Leaders

“the person who leads a group or organization.”
As an organiser of WeTest and editor of Testing Trapeze, I like to tweet content from testers around New Zealand to promote the wonderful things that are happening in this part of the world. These are the women who adopt similar behaviour for the communities that they lead.

Alessandra Moreira is the only woman on the Association for Software Testing (AST) Board of Directors and a co-organiser for Weekend Testing Australia and New Zealand (WTANZ). Amy Phillips is the co-organiser for Weekend Testing Europe (WTE).

Anne-Marie Charrett was a co-organiser of Let's Test Oz, Anna Royzman was a co-organiser of the Conference of the Association for Software Testing (CAST) in 2014, Helena Jeret-Mäe is the content owner of the upcoming Nordic Testing Days in 2015, and Rosie Sherry organises TestBash annually as well as running the Ministry of Testing.

In initiatives that specifically focus on women, Jyothi Rangaiah is the editor of the Women in Testing magazine, and Lorinda Brandon runs the Women in Line initiative to get more women speaking at technology conferences.

Challengers

“a call to prove or justify something.”
There are those who generally seek to challenge opinion and question what they've heard. These women appear unafraid; they share and generate content to disrupt the status quo. Through these women I am exposed to new ideas and test my own assumptions.

Fiona Charles, Karen N Johnson, Trish Khoo, Lanette Creamer, Hilary Weaver, Kate Falanga and Natalie Bennett are all based in North America, Maaret Pyhäjärvi and Meike Mertsch are in Europe, and Kim Engel in New Zealand.

Cheerleaders

“an enthusiastic and vocal supporter of someone or something.”
I was hesitant to use this term, as some may hold quite a negative connotation of a cheerleader, but I mean it in the sense of the definition above. These women are enthusiastic and vocal members of the testing community. They encourage, converse, and share information, usually in a friendly and upbeat way.

Parimala Hariprasad and Smita Mishra are in India, Anna Baik in the UK, Maria Kedemo in Europe, and Jean Ann Harrison and Teri Charles are in the US. They create a steady flow of positivity with links to a wide variety of content.

Constant

"occurring continuously over a period of time."
Claire Moss gets her own category as a live tweeter. Usually Claire is relatively quiet on Twitter. The exception is when she is attending testing events and her account erupts into a stream of constant activity. You'll almost feel like you've attended the conference itself.

Climbing

"to move to a higher position."
Finally there are the women who share and contribute excellent content on Twitter, but may be less well known than others listed here. Carol Brands, Jacky Fain, Alex Schladebeck, Elisabeth Hocke, Ioana Serban and Shirley Tricker.

*****

As with any post of this kind, I'm certain I've missed people who should be included. Please leave your recommendations in a comment below.

Visual Test Ideas

There are some circumstances in which a mind map is not the best format to visualise your testing. In particular, where there are complex relationships between data in the application under test.

Visual test ideas can be useful when it feels clumsy to explain what you plan to test in words. If you need the assistance of a whiteboard to outline your thinking to others, this might indicate that you should record your test ideas pictorially instead of in writing.

As with other visual approaches, visual test ideas are a great way to engage people in the activities of testing and encourage collaboration that improves test coverage.

Here are three examples of different ways to record your test ideas visually.

Timelines

Imagine the Transaction History for a bank account. When you load the page, you see the last 30 days of transactions by default. You can change the date range for transactions returned by updating the start and end dates:

Transactions are only returned for the first 90 days of the specified range. If the specified date range is greater than 90 days then the oldest transactions are discarded. Data is only available up to 180 days ago, no transaction information will return prior to that date. And of course, there are no transactions available in the future.

Given these requirements, a number of different test ideas spring to mind. As these ideas are discussed with other people, they might be captured in a timeline format:

Using a timeline to explain these test ideas clearly shows how they relate to one another within the time relationship, where a mind map format would not.

Buckets

Imagine that you have taken out a loan where your repayment obligations are tied to your income. When your earn beyond specific thresholds, then your repayment amount will change. These thresholds are dependent on the type of earning you receive, whether salary, wages or adjusted income.

The example below is from Aaron Hodder. Using a buckets marked with different thresholds, Aaron clearly shows how his test ideas relate to one another:

Venn Diagrams

Imagine a school grading system. Within a given subject, you can receive credits across one or many topics. For example, in Mathematics you can gain credits that apply to Calculus, Algebra, or Calculus & Algebra combined. The number of credits you have in each topic, and in total, will determine whether you are awarded a given qualification for a subject.

Nigel Charman has written about a team operating in this domain:

"In this case, the team are visualising examples of these complex business rules using Venn diagrams. The richness of the visualisation helps us wrap our brains around the complexity, acting as a shorthand form for discussion." [1]

An accompanying picture shows a team working around a whiteboard that is filled with various Venn diagrams:

Source: Visual Specification by Example

Instead of then attempting to reflect these scenarios in words, these same diagrams become the documented test ideas:

Source: Visual Specification by Example

Using Venn diagrams to capture these test ideas clearly shows the relationships between topics within subjects that a mind map format would not.

*****

There are many options for representing test ideas and the relationships between them by making use of engaging illustrations. Think laterally. Though a mind map is an obvious option to present visual information, it isn't always the best way for a tester to share their thoughts with their team.

Satir Interaction Model

Yesterday evening I had the opportunity to attend a Fiona Charles workshop on Delivering Difficult Messages [1]. Fiona spoke briefly about the Satir Interaction Model, which she presented as:

"I think we have an issue" -- Delivering unwelcome messages
Fiona Charles

The Satir Interaction Model describes what happens inside us as we communicate — the process we go through as we take in information, interpret it, and decide how to respond [2]. In the model above, there are four fundamental steps to going from stimulus to reply: intake, meaning, significance, then response [3].

These four steps are the Gerald Weinberg simplification of the original work of Virginia Satir. Weinberg has written about the Satir Interaction Model in the context of technical leadership, while Satir wrote for an audience of family therapists [4]. When compared side-by-side, the original work included some additional steps:

Satir Interaction Model
Steven M. Smith

Resolving communication problems

The Satir Interaction Model can be used to dissect communication problems. It can help us to identify what went wrong in an interaction and provides an approach to resolve the issue immediately [5].

Many communication problems occur when a response is received that is beyond the bounds of what was expected. Because the steps in the model between intake and response are hidden, the end result of the process that assigns meaning and significance can be quite surprising to the recipient, which can be a catalyst for conflict.

I like the J. B. Rainsberger example of applying the Satir Interaction Model to a conversation where someone is wished a "Happy Holidays". The responses to this intake may vary wildly based on the meaning and significance that people assign to this phrase. [3]

• "How dare this person insult Christmas and deny the Christ...!"
• "If only you'd bother to learn to pronounce 'Chanukah'..."
• "Have you ever even heard of Candlemas...?!"

When applying the model to resolve misunderstanding, Dale H. Emery says:

I focus first on my own process, because the errors I can most easily correct are the ones that I make. When I see and hear clearly, interpret accurately, assign the right significance, and accept my feelings, I understand other people's messages better, and my responses are more effective and appropriate. And when I understand well, I am better able to notice when other people misinterpret my messages, and to correct the misunderstanding. [2]

Finally, Judy Bamberger offers a very useful companion resource for adopting the Satir Interaction Model in practice [5]. She provides ideas about what could go wrong at each step in the model and offers practical suggestions for how to recover from errors, problems, or misunderstandings.

Association to Myers-Briggs

Weinberg drew a link between the Myers-Briggs leadership styles and the Satir Interaction Model that may be useful for adapting communication styles with different types of people. He suggests that:

The NT visionaries and NF Catalysts, both being Intuitive, skip quickly over the Intake step. … NTs tend to go instantly to Meaning, while the NFs tend to jump immediately to Significance. … The SJ Organizers stay in Intake mode too long … The SP Troubleshooters actually use the whole process rather well … (pp 108 & 109.) [6]

Weinberg then offers the following questions to prompt each type of person to apply each step of the Satir Interaction Model:

For NTs/NFs ask, “What did you see or hear that led you to that conclusion?”
For SJs ask, “What can we conclude from the data we have so far?”
For SPs appeal to their desire to be clever and ask them to teach you how they did it. [7]

Distinguish reaction from response

Willem van den Ende draws the Satir Interaction Model so that both sides of the interaction are shown:

"Debugging" sessions
Willem van den Ende

Using this illustration he specifically differentiates between a reaction a response. A reaction happens when a person skips the meaning and significance stages, and simply jumps straight from intake to response. When both people in an interaction become reactive instead of responsive a fight is the likely result [8]. Understanding that these missing steps may be the cause of a misunderstanding could help resolve the situation.

Unacceptable Behaviour

The Satir Interaction Model may also be useful in structuring conversations to address unacceptable behaviour. Esther Derby suggests that these conversations should begin by getting agreement that the behaviour happened, followed by discussion about the impact of the behaviour, then conclude by allowing the recipient of the message to realise that their behaviour is counter-productive [9].

References

[1] "I think we have an issue" - Delivering unwelcome messages, Fiona Charles

[2] Untangling Communication, Dale H Emery

[3] Don't Let Miscommunication Spiral Out Of Control, J B Rainsberger

[4] Satir Interaction Model, Steven M. Smith

[5] The Satir Interaction Model, Judy Bamberger

[6] Debugging System Boundaries: The Satir Interaction Model, Donald E. Gray

[7] Why Not Ask Why? Get Help From the Satir Interaction Model, Donald E. Gray

[8] "Debugging" sessions, Willem van den Ende

[9] intake->meaning->feeling->response, Esther Derby