Tuesday, 24 November 2015

Testing for Non-Testers Pathway

This pathway is designed to help non-testers tackle testing activities. If you're asked to test something in your team, this is a set of practical resources to help you.

There are a variety of steps that you may approach linearly or by hopping about to those that interest you most. It is a little different to the other testing pathways as it is:
  • Specifically for non-testers
  • Designed to help people with immediate questions like "How do I decide what to test?"
  • Does not include exercises, instead assuming that the provided resources will be applied in practical situations within your development team

STEP - Why non-testers should be involved in testing

Agile development teams generally seek shared ownership of quality. In order to achieve this, the tester may have to yield some control and others in the team may need to be more willing to pick up testing activities. These teams want to move away from the tester as the only person who tests, towards an environment where the tester leads testing and empowers others to contribute too. These articles describe the shift in thinking towards testing as a shared activity:

STEP - How to make an application testable

As developers and business analysts, the easiest first step to aid testing of the product is to understand the attributes that make it testable. Changing the way you specify solutions and design software can have significant impact on a tester's ability to verify and explore what is delivered. Learn to consider the various facets of testability:

STEP - How to decide what to test

When asked to pick up a testing task, the non-tester may wonder where to begin. Testers are often poor at explaining how they test an application, which can make testing seem like magic. In fact, testers will have their own set of testing heuristics, whether they can articulate them or not! Fortunately there are resources that provide common test heuristics to help you determine which tests you'd like to perform, or prompt you to think of your own ideas beyond these boundaries:

STEP - How to document your test ideas

One deterrent for a non-tester to test may be your perception of the amount of documentation required. Within your development team, the testers are likely to have an approach that you can adopt. However there may be freedom for you to utilize lightweight documentation to map out your thinking. Perhaps to simplify what you need to do, a tester might transfer your results into the wider ecosystem of test artifacts afterwards. These articles give practical examples of using mind mapping software for test planning and execution:

STEP - What to think about while testing

Testing isn't just about picking up and blindly applying the heuristics of others. When interacting with the software you may also want to consider what user persona to adopt, what bugs to raise, and what test evidence to collect. Though many of these decisions will be driven by collaborative interaction with your development team, these resources may help you understand the possible compromises being made and approaches that are possible:

STEP - How to debrief

A key aspect of getting non-testers to pick up test activities is following up with a post-testing debrief. This provides an opportunity for the tester and the non-tester to sit together and spend a few minutes discussing the testing activity that has occurred. These resources provide common questions that may be asked during a debrief:

STEP - Where to automate

Finally, you may be asked to contribute towards automation. Agile teams will usually require automated checks to support their rapid delivery cycles so that testers have time to understand new functionality, explore the application and find interesting problems. These articles describe factors to consider when determining what to automate, where to implement and how to interpret the results:
Posted by at No comments:
Labels: , , ,

Friday, 13 November 2015

Using strong-style pairing and a coding dojo for test automation training

At work we're implementing a brand new automation suite for one of our internet banking applications. This is the first framework that I've introduced from a coaching perspective as opposed to being the tester implementing automation day-to-day within a delivery team.

Aside from choosing tools and developing a strategy for automation, I've discovered that a large proportion of the coaching work required is to train the testers within the teams in how to install, use and extend the new suite.

I've done a lot of classroom training and workshops before, but I felt that these formats weren't well suited to teaching automation. Instead I've used two practices that are traditionally associated with software development rather than testing: strong-style pairing and a coding dojo.

I've been surprised at how well these practices have worked for our test automation training and thought I would share my experience.

Strong-style pairing

After a series of introductory meetings to explain the intent of the new suite and give a high-level overview of its architecture, each tester worked independently using the instructions on our organisation wiki to get the tests running on their local environment.

As the testers were completing their installations, I worked in parallel to create skeleton tests with simple assertions in different areas of the application, one area per tester. To keep the training as simple as possible I wanted to split out distinct areas of focus for individual learning and reduce the potential for merge conflicts of our source code.

As they were ready, I introduced an area to each tester via individual one hour pairing sessions using strong-style pairing. The golden rule of strong-style pairing is:

"for an idea to go from your head into the computer it MUST go through someone else's hands"

For these sessions I acted as the navigator and the tester who I was training acted as the driver. As the testers were completely unfamiliar with the new automation suite, strong-style pairing was a relatively comfortable format. I did a lot of talking, while the testers themselves worked hands-on, and together we expanded the tests in their particular area of the application.

As the navigator, I prepared for each pairing session by thinking up a series of objectives at varying degrees of difficulty to accommodate different levels of skill. My overarching goal was to finish the hour with a commit back to the repository that included some small change to the suite, which was achieved in two-thirds of the sessions.

As a coach, I found these sessions really useful to judge how much support the testers will require as we progress from a prototype stage and attempt to fulfill the vision for this suite. I now have a much more granular view of where people have strengths and where they may require some help.

I had a lot of positive feedback from the testers themselves. For me the success was that many were able to continue independently immediately following the session and make updates to the tests on their own.

Coding Dojo

At this point everyone had installed the suite individually, then had their pairing session to get a basic understanding of how to extend an existing test. The next step was to learn how to implement a new test within the framework.

I felt that a second round of individual pairing would involve a lot of needless repetition on my part, explaining the same things over and over again. Ultimately I wanted the testers in the team to start pairing with each other to learn collaboratively as part of our long-running pairing experiment.

I found a "how do you put on a coding dojo?" video and decided to try it out.

I planned the dojo as a two hour session for six testers. I decided to allow 90 minutes for coding, with 15 minutes on each side for introduction and closing activities. Within the 90 minutes, each of the six testers would have 15 minutes in the navigator/co-pilot role, and 15 minutes at the keyboard in the driver/pilot role.

I thought carefully about the order in which to ask people to act in these roles. I wanted to start with a confident pilot who would put us on the right course. I also wanted the testers to work in the pairs that they would work in immediately following the session to tackle their next task. So I created a small timetable. To illustrate with fictitious testers:



On the morning of the session I sent an email out to all the participants that reiterated our objective, shared the timetable, and explained what they would not require their own laptops to participate.

We started the session at 1pm. I had my laptop prepared, with only the relevant applications open and all forms of communication with the outside world (email, instant messaging, etc.) switched off. The laptop was connected to a projector and we had a large flipchart with markers to use a shared notes space.

I reiterated the content of the morning email and shared our three rules:

  • 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

Then I sat back and watched the team work together to create a new test!

Though I found it quite challenging to keep quiet at times, I could see that the absence of a single authority was getting the group to work together. It was really interesting to see the approach taken, which differed from how I thought they might tackle the problem. I also learned a lot more about the personalities and social dynamics within the team by watching the way they interacted.

It took almost exactly 90 minutes to write a new test that executed successfully and commit it back to the repository. Each tester had the opportunity to contribute and there was a nice moment when the test passed for the first time and the room collectively celebrated!

I felt that the session achieved the broader objective of teaching all the testers how to implement a new test, and provided enough training so that they can now work in their own pairs to repeat the exercise for another area of the application.

I intend to continue to use both strong-style pairing and coding dojos to teach test automation.







Posted by at 2 comments:
Labels: , , ,

Tuesday, 10 November 2015

How to develop into a great speaker

Your first conference talk will give you exposure to writing an abstract, marketing your ideas, creating engaging slides, structuring a talk, speaking clearly, keeping to time, and so on. The more talks you do, the more experience you gain in those same activities.

But developing as a speaker is not just about opportunity for repetition. I see a change in speakers when they stop thinking so much about what they're going to say during their talk and start concentrating on how they're going to say it.

By that I mean, when a great speaker is on the stage their content is almost on autopilot. They're not worried about the points they need to cover on the next slide. Rather they're more aware of their delivery. They're operating at a meta-level.

So, what sort of things are these great speakers thinking about?

The audience

A new speaker is learning to feel comfortable making eye contact with the audience. A great speaker is learning to anticipate mood, read body language, understand the response of the audience, and adapt their presentation to react to that environment.

Look at the schedule for the event. How long ago did people have food? How many concurrent sessions have the participants sat through? Whereabouts in the day are you? Whereabouts in the conference? Think about these factors as you watch the audience arrive in the room. Is there energy or will you have to create it?

How do people sit down? Do you see many people with their arms folded or their legs crossed? How many people have an open posture and are tilted forwards in their seats? Are people receptive to your ideas or will you have to establish your credibility and use persuasive language?

When you change the slide in your presentation, how many eyes travel to the slide and then back to you as the speaker? Who isn't making eye contact with you at all, looking downwards, or out the window? Are people engaged or do you have to ask for their participation to draw them in?

Are there people who are still reading a slide when you switch to the next one? Are people zoning out between slide transitions? Look for signs of frustration, like people sighing or pulling out their phones. These may be indicators that you need to change your pace.

The audience won't change the key messages of a presentation, but a great presenter will allow them to massively influence its delivery.

The commentary

A new speaker will often include remarks in their own presentations that are about their delivery rather than about their content. It's analogous to playing the director's commentary across a movie, however in a conference presentation these remarks are often apologetic or self-deprecating.

Do you start your talk by undermining your own credibility or wondering aloud whether you're really an authority on your topic? Do you question the choices of the organisers who granted you a spot on the stage, or the choices of the audience for selecting your session to attend over other alternatives? Do you tell people how inexperienced you are at speaking or how nervous you feel about this presentation? Do you apologise for fumbling content or narrate your disappointment in failed technology?

I believe that eliminating this sort of commentary from your presentation creates a perception that you're a very confident speaker, regardless of how confident you actually feel.

I have a heuristic to mute this doubt track within my own presentations. When thinking about whether or not to vocalise something I like to first consider who I'm saying it for. Often the commentary is stuff I say to make myself more comfortable, or to settle myself in to the beginning of my presentation. It's not for the audience. And if it's not for the audience, I shouldn't say it.

The language

Related to audience, the same presentation may differ wildly in delivery through choice of language. Can you interact informally, use colloquialisms, and make jokes? Or should you take a more professional tone?

Choice of words is influenced by environment. Are you speaking at a MeetUp event or a formal conference? It's also influenced by culture. Your references and examples may change between a talk in New Zealand versus a talk in India.

You might also consider whether jargon appropriate for your audience. What terms will they be familiar with and which should you explain beyond an acronym?

Adjusting to these factors can make a big difference in how accessible and relatable your presentation is. A great speaker can deliver the same slides twice, in two different contexts, with what may feel like an entirely different speech. The key messages don't change, yet the words are altered for the greatest impact.


If you're feeling ready to tackle the next challenge in public speaking, start practicing these meta skills. Think about your audience, your commentary and your language in your next presentation.

What would you add?

Posted by at 3 comments:
Labels: ,
Subscribe to: Posts (Atom)