How do you create a friendly conference?

One of the things that really impressed me about TestBash a few weeks ago was the warm and friendly tone of the event. I haven't been alone in my remarks on the environment created by Rosie Sherry, Vernon Richards and others.

As a conference organiser, I've been thinking a lot about what made each attendee feel this way. What were the specific actions that made such a noticeable difference when compared to other events. Here are five things that I've identified, which I'm hoping to try at the next event that I run.

Pre-Event Emails

Rosie sent an email per day to TestBash attendees in the week leading up to the event. These included the schedules for the workshops and conference, details of associated MeetUp events, invites to a slack channel, social media hashtags, information for a book swap, and a set of behavioural requests.

These emails created a sense of hype and expectation. They got everyone on the same page about the logistics of the event. They allowed people to start interacting online prior to the event itself, if they wished to do so.

These emails also served as the foundation for the community focus of the conference itself. In particular, here are the six things that Rosie asked from attendees in one of her pre-event messages:

• I ask the old timers to reach out to those that look lost.
• I ask for everyone to be brave and speak to anyone who looks like they could do with some company.
• I ask you all to be human, kind, and helpful.
• I ask you all to focus on making friends and having a good time.
• I ask you all to create some incredible memories to remember, for yourselves and everyone else who attends.
• I ask you all to speak to speakers. I can assure you they want to speak to you too.

This clearly set expectations for behaviour prior to the event.

Personalised Name Tags

The first task after registration on conference day was to create your own name tag using very large Ministry of Testing speech bubbles and a permanent marker. The name tags were handwritten. You could choose how to present yourself to others at the conference. First name only, full name or nickname. With or without social media details.

The name tags were large and colourful, which made them easy to locate on a person and easy to read. Though they clearly incorporated the Ministry of Testing brand, they didn't feel corporate. The variety of handwriting on display made something that is normally staid into something that felt informal and fun.

The name tags put a little piece of each personality on display.

No Tester Stands Alone

As the host of the day, Vernon Richards did a great job at specifically reminding people to interact with those who they didn't know. He reiterated the TestBash ethos from the pre-event emails that "No Tester Stands Alone".

This expectation was set at the start in his opening remarks and we were prompted of it prior to each break. Many of the people that I met were attending as the only tester from their company, yet I rarely encountered anyone by themselves.

Vernon demonstrated that you don't have to be afraid to remind people to be friendly.

Single Track

I had never been to a single track conference before. I was really amazed by how different it felt to be part of a large group of people who were all experiencing the same set of speakers. Having over 200 people in one place, focusing on one thing, for an entire day, creates a vibe in itself.

I also found that it changed the type of conversations I had in the breaks. Often at conferences the exchanges over tea and coffee are about what each person listened to during the last session. You'll hear snippets and impressions without really understanding what the other presentation was about. At TestBash we had all heard the same topics, so we had deeper conversations about the ideas, what could work in our own organisations, the doubts that we had, etc.

A set of shared experiences can offer opportunity to explore further together.

Open Social Events

There was a Pre-TestBash evening social and a Post-TestBash evening social. There was a Pre-TestBash run and a Post-TestBash brunch. All of these events were publicly advertised in the Software Testing Club MeetUp group.

Though they were located in a pub, the evening invitations weren't focused on drinking. They instead put emphasis on connecting with other testers. The invitations were open, inclusive, and there was room for everyone, even if it was sometimes slightly crowded!

By keeping those who wanted to socialise in one place, no one felt any fear of missing out. People were really present at these events instead of occupying social media in search of what else was happening.

There was a huge amount of support for people to connect outside of the event itself.


I'm hoping that these five ideas will help bring a little bit of the TestBash magic to my next testing event, and perhaps yours too?

Use your stand up to make testing visible

Imagine that you're a tester in an agile stand up meeting with your development team. You have all gathered around your visual management board, each person is sharing an update and it's your turn to speak.

"Yesterday I tested story 19574 and didn't find any bugs." you say, moving that story to Done. 

"Today I'm just going to test story 19572." you continue, moving that story to Doing.

"There's nothing blocking me at the moment, so that's it." you finish.

Sound familiar?

Now consider whether, based on the information you've just provided, anyone in your development team actually understands what you've done and what you're planning to do.

If you were to ask them, they might say that you're testing. You are the tester. You just told them you were testing. They're not stupid. 

But what exactly does that mean? Have you been confirming acceptance criteria are met? Have you been investigating how this story handles error scenarios? Have you tested from the perspective of each of the business user personas? Have you tried some simple penetration tests to determine whether this story has covered the basics of security?

We can make testing more visible through the use of visual planning. Illustrating our thinking through visual test models or visual test ideas is a great way to engage our team in conversations about testing. But we can also make our testing more visible by being transparent in our stand ups. 

Start making a conscious effort to be more specific. Take the opportunity in your stand up to verbally create an image in someones mind of the activities that you're undertaking. While you may not have time to tell the whole story, you can certainly share the blurb rather than the title alone.

Without this detail there's a good chance that what you do is a little bit of a mystery to your team. And if they don't really understand what you're doing, then it may be difficult for them to identify opportunities to collaborate with you or help to anticipate problems that could prevent you from completing a testing task.

Making testing visible is not just about changing the documents you produce. Take the time to prepare for your stand up so that you can briefly explain what you are actually doing. I'm sure that you are not "just testing".

How I explain software testing to people who don't work in IT

Can you think of a time when you've been frustrated while using your computer?

There are a lot of reasons that you might feel this way. A website that takes a long time to load. Error messages that stop you from doing what you want to do. Being unable to find that thing you need within all the options that are available in a menu.

Every time you get frustrated, you are encountering what software testers call a bug. Simply put, a bug is something that bugs you, and my job is to prevent bugs from reaching you.

To do this, I talk to the business people who ask for the software, the designers who decide what it will look like, and the analysts who specify how it should work. I think of things that I have seen cause problems in the past and try to prevent the same mistakes from being made again.

I sit alongside developers, the people who write the code that creates the software, and pick up problems while they work. Sometimes they miss a piece of what they're supposed to do, or I might disagree with the way that they've chosen to write something.

Once the software is finished, I check that it works. I think about all the ways that people might intentionally or accidentally break it, and make sure we handle that elegantly. I see if it works on all different sorts of computers and mobile devices. I check whether it is easy to use, responsive, and secure.

All through this process, I am testing. I test through conversation. I test by actually using the software on my computer. And I test by writing automated checks with tools that can run the same things over and over again, to make sure that specific bits of the software are working properly.

Testing helps to eliminate the things that bug you. It's an important part of creating software that people feel happy to use.

Brave Questions

This year I did not make any New Years Resolutions. But something that I am trying to do more of is to ask brave questions. By brave questions, I mean the type of questions that make me uncomfortably nervous to voice. They are questions to request the things I really want to happen that are perhaps a little unusual or unexpected, so there's a higher probability of people saying 'no'.

I thought I'd share three brave questions I've asked in January in the hopes that it may inspire others to push themselves to ask for the things that they want too.

Asking to pair on a proposal

When proposals for the Conference of the Association for Software Testing (CAST) opened I didn't pay much attention. I'm travelling to Europe shortly for CopenhagenContext and TestBash, so it seemed a bit cheeky to submit for another overseas jaunt in August. I'm also trying to avoid paying to speak this year, and I knew that CAST don't cover speaker travel and accommodation.

Then a friend of mine decided to move to Vancouver in June, and suddenly a trip to Canada in August became a lot more appealing! Having decided to propose, I then started to think about topics that I could talk about and the work involved in creating a presentation from scratch. The more I thought, the larger the whole task seemed, and I spent a few days trying to decide what to do.

I've been facilitating a lot of pairing within my team over the past year, but haven't had the opportunity to do very much hands-on pairing myself. I've heard other presenters speak very positively about their experiences delivering paired presentations. I started to wonder whether pairing might be a way to submit to CAST and see my friend with just half of an idea and half of a talk.

I started to consider who to ask. Given that I'm based in New Zealand, I haven't had the opportunity to meet very many people in the wider testing community. This made it quite difficult to decide who to approach, as a lot of my opinions are formed by how people behave on Twitter!

I came to the conclusion that I wanted to pair with another woman in testing, who I felt that I would work well with, and who was a relatively inexperienced speaker with a lot of great ideas to share. I was also aware that I wanted to limit the financial burden on that person if our proposal was accepted, so I decided to look for someone who was based near Canada.

One person ticked all these boxes. Carol Brands.

After deciding to ask Carol, there was a period of days before I made any kind of contact with her. When I did get in touch, due to the joy of timezones we played skype tag a few times before we were both online simultaneously. Finally, it was time to ask:

A brave question in the real world

It took almost 30 seconds of nervous anticipation for Carol's response to come through, and I was excited when she was instantly on board. We've since submitted a proposal and I'm keeping my fingers crossed that we are accepted to speak as I would like to meet Carol in person after all the discussions we've had so far!

I've found asking to pair on a proposal to be as fun and productive as it was advertised to be. It's been fantastic to have someone to bounce around ideas with. I've also enjoyed the collaborative writing process and the challenge that comes from being questioned on the way that I present my thoughts.

Asking for sponsorship for a conference

For the past three years we've run a WeTest Weekend Workshops conference in November. Pitched as an affordable testing conference for local talent, it's been a half day event with a $20 ticket price that includes a multi-track speaking line up, dinner and an event t-shirt.

Three years of WeTest tshirts

We've had generous sponsorship throughout this time, particularly from Assurity, but we've also been operating on a shoestring. None of the speakers have been paid. In many cases, they've been out of pocket for their travel and accommodation. All of the speakers have been from New Zealand. Our format has been focused on discussion to share experiences rather than ideas that push at the boundary of our profession.

This year I decided that I'd like to do something different. I talked to my co-organisers, Aaron and Shirley, and pitched the idea of national series of conferences. I'd like to create a repeatable full day event, with larger capacity, respectable ticket prices, and international speakers alongside the locals. I'd like us to be able to pay speakers, and cater food, and provide t-shirts, like a real testing conference. To do this, we need to ask for help.

So in January I approached four organisations to ask them to invest in this idea. We are asking for more money than we've ever sought for WeTest events in the past. From early December when all the organisers agreed that this was a good idea, it took me six weeks to muster the courage to even ask this question!

So far I've had a positive response from two of the four organisations, which is very exciting. I remain hopeful that we're going to end up with all four on board.

For me, asking this particular brave question has been a reminder that if you don't ask for something then you probably won't get it. And that sometimes when people say "no" it leaves you no worse off than you were originally.

Asking other people to propose to a conference

In mid-January, Rajesh Mathur who is one of the organisers of Australian Testing Days tweeted that their Call for Proposals had a relatively low response rate from within Australia. 

I was surprised by this as I know a lot of great testers based in Australia. I was also a bit disappointed as I was planning to attend Australian Testing Days to hear some of these people and, based on this tweet, it seemed that they may not have proposed.

Over lunch, I was thinking about this situation and suddenly wondered whether I could do anything to help change it. If there were people who I wanted to hear from, perhaps I could ask them to submit a proposal?

I'm not part of the organising committee for this conference, and it seemed a bit of a bizarre notion to try and influence the program of an event based on what I was hoping it would be. On the other hand, the organisers can't choose people who haven't proposed, so perhaps I'd just be giving them more options?

I decided to send out an email to 30 past and potential Australian Testing Trapeze contributors to ask them to consider submitting. I made it really clear that I had no part in choosing speakers but that I'd love for them to put themselves forward. I shared the link to the CFP, then let Rajesh know on Twitter:

Shoulder tapping potential presenters for a CFP

This was probably the most unusual brave question of January. Most of my associated nerves in asking this were because I wasn't sure what the reaction would be, from both the people who received the email and the organising committee.

Fortunately the responses that I did receive were all positive. Recently the programme was announced and I was delighted to see Catherine Karena in the line up, a speaker selected who I particularly wanted to listen to! I'm also keeping my fingers crossed for the selection of the Speak Easy slot, which is yet to be announced.

This experience has made me wonder why more people don't do this. If you feel like the events in your community could be better perhaps that's because you haven't made any efforts to change them? If there are people who you'd like to hear from, why not encourage them to propose? If there are topics that you'd like to learn about, why not suggest these to the conference organisers?

Brave questions make me uncomfortable. They are also how I stretch the bounds of what I believe to be possible. They are often a doorway into something new and different.

Increasingly I feel like the risk of asking these questions is not as great as my nerves would have me believe and that the opportunities behind each enquiry are worth the effort. Making a point of asking brave questions might be a way to expand your world in 2016. Good luck.

Introverts in Agile

Being a part of a highly collaborative agile team can be challenging in many respects. One of the things that I have personally found difficult, and have observed being difficult for others, is balancing the demands for interaction against a need to reserve my ability to have good conversations.

I am an introvert. This doesn't necessarily mean that I'm shy, or quiet, or withdrawn - though occasionally I am each of those things. I like to think before I offer an opinion, but I don't think that's unique to introverts either. A simple definition of introverts that I relate strongly to is:

"Introverts give energy to conversation. Extroverts take energy from conversation." 

Let me give you an example. In a previous role, I worked as a tester in an agile team running fortnightly scrum. Every Thursday morning we would have a three hour sprint planning meeting, from 9am to noon, to discuss the upcoming stories, create tasks, estimate hours, and commit to a backlog for the sprint.

This meeting wrote off my day. Some of the team would leave the meeting buzzing about what we'd agreed to and be excited to get stuck into it that afternoon. I left feeling completely drained and incapable of starting any meaningful work until Friday morning. The contrast of an extroverted versus and introverted response.

When I look back on this, we weren't doing scrum wrong. We weren't doing agile wrong either, we valued "individuals and interactions over processes and tools". But what we were doing felt wrong for me, as an individual, and I believe would pose similar challenges for other introverts in the same situation.

I'm not about to suggest that you stop talking to one another to accommodate the introverts in your team! However, I think there are a lot of practical things that agile teams can do to better accommodate introverts, and that introverts can do to improve their ability and stamina in communication.

Scheduling Meetings

If someone schedules a meeting with me, I like to spend some time prior to think about what I want to say and what I may be asked to contribute. This quiet period of preparation means that I'm ready to participate when I arrive. Similarly, at the end of a meeting I like to spend a few minutes digesting what was covered, noting my action points, and thinking about whether I have any other questions to ask.

With a lot of meetings, these extra pieces of time can add up and limit the hours I have available to complete my actual work. However, if I don't have space between meetings, then my ability to productively participate in meetings drops at an alarming rate.

Although my calendar doesn't always allow for these luxuries of preparation and reflection, it's amazing how many people schedule meetings with very little regard for their impact on the people who attend them.

There are many facets to consider here. I'd encourage you to read:

• Maker's Schedule vs Manager's Schedule - Paul Graham
• How to Manage Time with People who Make Stuff - Rob Lambert

Personally, I now try to schedule meetings adjacent to lunch hours. This limits the disruption to people who "make stuff". It also maximises the opportunity for introverts who need to balance conversation with quiet time for themselves on either side of the session.

Additionally, where I need to schedule a very long session across multiple hours, I try to book these in the afternoon so that people don't have to return to work afterwards.

Agile Rituals

The agile rituals of planning, stand up and retrospective appear to be ubiquitous. I've seen them performed in a variety of ways and I believe that some formats are better suited to accommodating introverted team members.

Planning within the scrum framework can be an onerous task. The scrum guide states "Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint." Eight hours! That's a full day meeting!

By contrast, adopting a kanban workflow may mean that planning is completed as work is pulled onto the board. I've been part of a team that used huddles, where at a minimum a developer, business analyst and tester would discuss the story and create tasks against it.

I've found huddles to be less taxing to prepare for and participate in, as they have a smaller audience and scope of responsibility. They also don't take long to do, which means that huddles can be scheduled by discussion at the daily stand up to properly accommodate the people who attend them.

Stand up meetings can be dominated by extroverts who are unafraid to interrupt and take conversation off topic. The most introvert-friendly stand up routine that I've been part of involved a Buzz Lightyear action figure. The stand up was re-branded as "Buzz Time" and the toy was physically passed around the team to indicate whose turn it was to speak.

This simple mechanism helped stifle interruptions and provided space for those in the team who had previously struggled to be heard by giving a clear visual cue of whose turn it was to speak.

Finally, retrospectives. Ideally the team are voicing their honest opinions. In reality, it's often a subset of the team who talk while the others mostly listen. If you see an imbalance in the perspectives being offered, try choosing a format that addresses this.

In a team with a particularly obvious void between the extroverts and introverts, I avoided open discussion when facilitating their retrospective and instead adopted structured data collection and sharing. I asked for post-it note brainstorming then requested that the quietest people, who would usually hesitate to offer an opinion, share what was written on their post-it notes first.

I found this to be a relatively good way to offer introverts time to solidify what they want to say. By sharing first, they have the opportunity to raise problems that are common across the team, avoiding the situation where their ideas are presented by others first. A clear directive of when to speak also helps minimise the anxiety of waiting to contribute, making the whole experience less draining.

Informal Communication

There's a lot of day-to-day chatter that happens when we work closely together. This may be via online channels or face-to-face, but always without warning. Though we want to remain responsive to one another, we also want to offer people the opportunity to focus. It can be hard to concentrate on a difficult problem with repeated interruptions.

I have worked with several developers who used their headphones as a social cue. If they were listening to music, it meant that they did not wish to be interrupted. Of course there were exceptions - if there was a very important problem or the building were on fire! But generally, headphones indicated an intense period of focus.

I've also worked in teams where, despite being co-located, much of the conversation happened via shared chat applications. Some members of the team would treat this similarly to email, checking in on the chat thread at various points throughout the day rather than being continuously interrupted. Again, this was something that others adapted to.

I don't believe that a desire to focus is exclusive to introverts. But my observation in each of these cases was that introverts were more likely to use these methods. Perhaps because each interruption was not just derailing their thoughts but also taking a small toll on their broader ability to think by taxing their energy levels.

*****

A collaborative culture is important in agile delivery. I see a lot of opportunities to tweak the mechanisms by which a team communicates to enable introverts to give their best possible contribution.

As a starting point, take a step back and observe the way your team works now. Do you find it easy to distinguish your extroverted and introverted team members? Is there any variance in how much people participate in discussions during a day? Can you spot any opportunities to balance the conversations you're having?

I'd encourage you to become mindful of your meeting scheduling, the format of your agile rituals, and the way that you interact informally. Small changes could make a big difference to those who give a lot of their energy to communication.

Time to step forward in the testing community

Has anyone else noticed the recent spike in calls for volunteers and helpers from across the international testing community?

Call for Volunteers: AST Technology Team. Want to get involved? Here's one way. Other opportunities coming soon. https://t.co/7BkLnBwT0o -ep

— AST (@AST_News) December 29, 2015

Call for Volunteers: CAST Sponsorship Coordinators https://t.co/hwujW3l6Jq -ep

— AST (@AST_News) January 3, 2016

I Need Your Help https://t.co/BxuQiqHpLT pic.twitter.com/nfOinNOQQO

— Rosie Sherry (@rosiesherry) January 5, 2016

#Active Volunteers needed for @TestingCircus. Write to us describing how you can help us. pic.twitter.com/hau03we368

— Testing Circus (@TestingCircus) January 7, 2016

I know that these requests are partly driven by existing volunteers realising that they are overloaded by the volume of work that they've committed themselves to. But I also believe they are a sign that the testing community is growing.

It feels like there are more people attending testing conferences, registering for testing training courses, watching online testing webinars, and reading testing articles. Perhaps, in part, because the people who consume testing material are not just testers.

By comparison, there are relatively few people creating and facilitating the delivery of this content. As someone who participates in the community as a speaker, editor, mentor and organiser, I'd like to encourage you to join these ranks. It's extremely rewarding.

Think about roles you fill in the community now and what you'd like to do next. Could you write an article, submit a proposal to speak at a conference, assist the organisers at your local testing Meet Up, review articles for a magazine, act as a mentor to encourage others, or volunteer your time to one of the initiatives above?

What will you achieve in the community this year? 

A model of the testing community

An approach to refactoring test automation

For one of our products, we’ve been using the same front-end test automation suite for several years. We currently have ten testers across five different agile teams who contribute code, and the total number of contributors through the life of the suite must be over 100.

As with any suite of similar history, our implementation varies greatly between different functional areas of the product. Though the coverage decisions are relatively consistent, the way the code is written is unique based on who the author was. These differences are visible through all layers of the suite: in the plain English concordion specifications, our accompanying Java fixtures, and supporting WebDriver utilities.

From mid-December to late January our product is put into a release change freeze. This is the summer vacation period in New Zealand, many of our staff away on leave, and due to Christmas it’s one of the busiest banking periods for our digital channels. As development of new features slows, it’s the perfect time to focus on activities like refactoring our automation!

In mid-December I ran a brainstorming session for the testers of this product to identify the technical debt in our associated automation. We quickly came up with a list of over 20 high-level items including standardising the implementation of common actions, creating naming conventions, removing duplication, consolidating utility classes, and improving documentation.

We voted on those that were most important and two items emerged as an immediate priority:

1. Standardise how we use waits
2. Determining a consistent approach to login

I scheduled two coding dojos prior to Christmas and these two priorities became the objectives for these sessions. The dojos were scheduled for two hours on a Tuesday, each with 8 or 9 testers participating in the traditional dojo format where:

• The facilitator asks questions and doesn't give answers
• Everyone must participate in the code being written
• Everyone must take a turn at the keyboard

Prior to each dojo, I created a refactoring branch using git. During the dojos we made changes against the branch, generally working on a single specification and associated fixture that I selected in advance. We collectively agreed on what our standard approach would be by making the first set of changes as a group.

We were working on a framework that the team use on a daily basis, so every attendee had good knowledge of the code. There were different opinions about the right way to do things; refactoring created a lot more discussion than when we used the dojo format to extend a framework into new areas. The testers were engaged in the process and stayed invested in the outcome throughout each of the two hour dojos.

After each dojo, I pushed our changes to the refactoring branch so that the testers could pull the work we had completed. Then I created a backlog of related refactoring tasks. Through the remainder of the week I asked each tester to independently pick up a task from this focused backlog so that they could immediately apply what we had decided as a group by refactoring with the same purpose in another area. Each task doubled as both a learning exercise and a way to improve our suite.

Each person who claimed these tasks worked on the same refactoring branch and pushed their changes when complete. At the end of the week, once all the backlog tasks were finished and committed against our refactoring branch, we merged our changes back to master via a peer-reviewed pull request that included the entire test team and a few developers too.

Branching strategy for refactoring via coding dojo and shared backlog

Using dojos as a tool for collaborative refactoring has worked well for us. During the session, the high level of prior knowledge of the code has created a healthy environment for discussion. The team have been passionate but flexible, and able to establish agreed standards relatively quickly.

The granular introduction of consistency in our automation gives us time to understand each decision being made and to create associated documentation with refactoring examples in our expanding how-to library. The huge amount of tidy up to be completed seems more manageable when we tackle small pieces. Using dojos makes it feel like everyone is across the desired solution rather than just a couple of people championing “the right way” to do things.

During the week following each dojo, having all the testers working on a common backlog of refactoring tasks against a single branch of the code has improved collaboration. The testing chat channel has been noticeably more active! Because the testers usually work in five different delivery teams, on five different functional areas of the application, it’s unusual for them to have to interact with such regularity.

Regular coding dojos have been the cornerstone of an inclusive, engaging and collaborative approach to refactoring our test automation.