The context driven testing community

At the recent Let's Test Oz conference, James Bach presented a model of the context driven testing community. His diagram showed the community split across three levels of engagement where an "inner circle" contained those capable of deep intellectual exchange; committed innovators and philosophers.

James talked about the community in his signature blunt manner, with straightforward language of cliques, pretenders and lobbyists. He assigned the task of niceties to a greeter, the friendly face of welcome, and coupled these people with guides, who identify and elevate people with potential.

James spoke plainly of an exclusive and elitist culture; by definition 'a select group that is superior in terms of ability or qualities to the rest of a group or society'. I believe that James is comfortable in this type of environment, which is similar to the way that he described the ISST on Twitter earlier this year:

@badbud65 I like exclusivity. I want to exclude people who aren't serious enough. It's okay if you don't like that. You can have YOUR club.
— James Marcus Bach (@jamesmarcusbach) June 14, 2014

My concern is that this rhetoric of exclusion and elitism creates the impression that the context driven testing community is actually a crowd, a commotion, or even a cult.

I believe the community has grown beyond a central clique. I would like to see it represented in a more inclusive way. I see a group of people that are interested in furthering their professional skills; where intent rather than commitment is the ticket to entry.

As such, I'd like to see us adopt an inclusive model:

If it looks a bit like I turned things inside out, then you're on the right track. Let me explain.

Someone with no knowledge of context driven testing is likely to encounter a leader of the community first. These are the people with the greatest reputation and professional presence. To a newcomer, these leaders may appear to be offering a lone dissenting opinion.

Consequently, the leaders of the community are not hidden at its center. They are the public face of context driven testing, and most likely to be approached by those who are eager to learn more. I am certain that James is dealing with more enquiries about context driven testing every day than I am!

Rather than expecting a greeter to welcome people, a path should be marked so that anyone in the community can simply direct the newcomers to this route. I believe there are a common set of first steps that any person with an intent to learn more about context driven testing may take. These should be known and accessible.

This model suggests six ways that people become involved with the community:

• Readers - start reading testing articles and magazines, e.g. Testing Trapeze
• Followers - subscribe to context driven testing blogs or follow the Twitter accounts of people who are active in the community
• Viewers - watch a testing presentation or conference talk online
• Event Attendees - participate in a local testing MeetUp group or attend a testing conference, e.g. Let's Test 
• Students - attend a training course on context driven testing, e.g. Rapid Software Testing
• Inexperienced Practitioners - try a new testing practice in your workplace, e.g. visual test coverage modelling

Newcomers should feel from the very beginning that they have walked into the middle of an inclusive environment. Rather than joining the outer edge of an intellectual clique, they are in the midst of a sphere of possibility. This model offers clarity in the growth and progression that is possible within the context driven testing community.

Commitment and reputation are implicit in the layers of the model. From the center, where people are consumers of information, a person may progress to participating in the community with an active voice.

Contribution is naturally associated with challenge, as by expressing an opinion there's a chance that others will disagree with it. The community ethos is that "no one is entitled to an unchallenged opinion". I simply suggest we move the challenge from our doormat and place it at a point where people are better prepared to respond appropriately.

Finally, the strength of the community is wider than researchers, philosophers, and innovators. Those who are truly committed will naturally aspire to the highest levels, but in a variety of contexts. There are many opportunities, and most of those who operate at this level will happily assist others that want to develop as leaders.

The context driven testing community should articulate the ways in which people can join, market the opportunities for personal development, and encourage newcomers to grow the craft. Creating an inclusive model of the community is a first step in demonstrating the nature of a group that has grown beyond an elite club.

Test Leadership

Fiona Charles began her Test Leadership tutorial at Let's Test Oz by sharing, in her own words, a definition of leadership from Jerry Weinberg:

Leaders create a space where people are empowered to do their best work 

She then offered her own version of this definition, which differed only by one word:

Leaders create a space where people are inspired to do their best work 

This set the scene for an interactive tutorial that provided clarity about how leaders are defined, how they act, and how they grow.

Defining a leader

The first exercise asked us to reflect on our experiences with testing leaders. In small groups, we were asked to share our stories, and discuss the skills and strengths that these leaders possessed.

I heard about:

• a leader who could accurately assess the abilities of those around them and determine which tasks each person would find interesting, challenging, or rewarding.
• a leader who worked out how to successfully motivate people so that they became driven to seek knowledge and achieve independently.
• a leader who could link people together, within organisations and further afield, creating mutually beneficial relationships where none had previously existed.

I thought that the experiences of my group could be summarised by one word; connection. In each example it seemed that the leader was creating connection; between people and tasks, between people and what motivated them, or simply between people.

When it came time for the class to share, it became apparent that we had focused on identifying the actions of leaders rather than the behaviours that they possess. Fiona prompted us to think more about the characteristics being demonstrated. 

In my group, connection was what these leaders did, but how did they do it? With thought, I saw that the three stories shared above had illustrated leadership that was perceptive, persuasive, and astute.

From the long wishlist of attributes for leadership that emerged from the class, I noted three other traits that resonated with me; courage, intuition, and flexibility.

Being a leader

The next exercise saw the class split into two groups that were each set a challenge: to invent a test leadership problem that the other team would be required to solve. We were given 45 minutes, with one member of each group acting as an observer.

Fiona then lead a classroom discussion on the group dynamics that had appeared within each team during the exercise. The team members had an opportunity to share their observations, followed by the nominated observers. It was interesting to hear the class reflect on how leaders had emerged.

In both groups, the people that the group identified as leaders were those who spoke first. They were also the people who were first to pick up a pen to start recording the thoughts of the group. I found myself being labelled as a leader, but felt cheated that this was simply through a series of actions rather than any specific personal attributes that I held.

In the second half of this exercise each team received their problem, then worked to solve it while the other team observed. In both teams the leadership dynamic shifted from the first half of the exercise as those who had originally been labelled as leaders, myself included, made a conscious effort to avoid adopting the role again.

My most striking observation from the latter part of this exercise was that the environment in which we collaborate is very important.

The first team set up two lines of chairs that faced towards an individual at a flip chart who took notes. Communication between this group largely traveled back and forth from the single individual at the front of the room. The leader was the person who literally lead the discussion from the front.

The second team set up a circle of chairs so that everyone faced each other. Communication between this group was more collaborative, in that people felt they were speaking to each other instead of the note taker. A single leader was harder to identify, as many people had equal contributions to the conversation and conclusions of the team.

Growing a leader

We finished the tutorial with an opportunity to reflect on what we had learned. As we sat in silence I realised something that has been eluding me for months; why people have started to call me a leader. I have felt confused that, even though I haven't consciously changed anything about myself, this label had appeared.

This tutorial clearly demonstrated to me that people see leadership as actions. Speaking first. Taking the pen. To be seen as a leader, all you need to do is start doing. When you act like a leader, the label of leader naturally follows.

However, Fiona lead me to realise that it is the characteristics of a leader that distinguish good from bad. Our personal attributes are what separate a courageous action from a stupid one, an intuitive response from an indecipherable one, or a flexible plan from a fickle one.

To grow as a leader, I need to identify the personal attributes behind my leadership actions. It is those characteristics that I should look to develop further in order to feel truly comfortable in a leadership role.

Heuristics and Oracles

Heuristics and oracles may seem like inaccessible concepts for new testers. The words sound academic, removed from the reality of what a tester does every day. In fact they are immensely useful tools for critical thinking.

What are heuristics and oracles, and why should you learn more about them?

Heuristics

Imagine that I want to eat a pickle. My pickles are stored in a large glass jar. In my household the last person to eat a pickle was my husband. He has closed the jar tight. On my first attempt I fail to open it.

What do I do next?

I check that I'm turning towards the left to loosen the lid and try again. Then I retrieve a tea towel to establish a better grip when twisting the lid of the jar. Finally, in some frustration, I go and locate my husband. He successfully opens the jar.

When faced with a jar that will not open there are a number of things that I know are worth trying. These are my jar opening heuristics. When I am instructed to test a software application there are a number of things that I know are worth trying. These are my test heuristics.

Heuristics are simply experience-based techniques for problem solving, learning, and discovery. [Ref.] 

Every tester will have their own set of heuristics that guide their testing every day. These are innate and developed through experience. The value of learning more about heuristics is in discovering how other people think, and becoming capable of describing our own thinking.

When I run out of inspiration during my testing, there are numerous heuristics that might prompt my next move. Rather than relying on my own brain, two of my favourite resources list a variety of techniques to apply based on the experiences of other testers. These are:

• Test Heuristics Cheat Sheet Elisabeth Hendrickson
• Heuristic Test Strategy Model James Bach

This insight into how others think allows me to introduce variety in my own approach. Instead of consistently finding the same sort of bugs, I broaden my horizons. It's like a single person adopting the mantra of "two heads are better than one". James Lyndsay illustrates this difference with a nifty visualisation in his blog post Diversity matters, and here's why.

Heuristics also give me the words to describe my testing. When questioned about how I discovered a bug my response had always been a nonchalant shrug; "I just played with it". Heuristics changed the way I communicated my testing to others. Once I could clearly articulate what I was doing I gained credibility.

Oracles

Imagine that I go to lunch with a friend. I enter a restaurant at 12pm on Thursday. After an hour enjoying a meal, I leave the restaurant at 1pm on Friday. Although I have experienced only one hour, the world around me has shifted by a day.

How do I know there's a problem here? 

I may have several notifications on my mobile phone from friends and family wondering where I am. I may have a parking ticket. I may spot somebody reading a Friday newspaper.

There are a number of ways in which I might determine that I have skipped a day of my life. These are my time travelling oracles. There are a number of ways in which I might determine that I have discovered a bug in a software application. These are my test oracles.

Oracles are simply the principle or mechanism by which we recognise a problem. [Ref.]

The test oracles that I consciously use most often are those described by Michael Bolton in Testing without a Map. This article describes the original mnemonic of HICCUPPS; history, image, comparable products, claims, user expectations, product, purpose, and statutes. The list has since been extended, which Michael describes in his blog post FEW HICCUPPS.

When I find a bug during my testing I always consider why I think that I have found a bug. I don't like to cite my "gut feeling" or claim "it's a bug because I said so!". Oracles help me to discover the real reason that I think there is a problem.

Knowing my oracle means that I can clearly explain to developers and business stakeholders why the users of the application may agree that I have found a bug. This means that I am much more effective in advocating for the bugs I raise, so they usually result in a change being made.

If I cannot associate the problem with an oracle, then it makes me question whether I have really found a problem at all. I believe this self-imposed litmus test removes a lot of noise from my bug reporting.

Ten things to read after Agile NZ

I've just spent a great two days at Agile NZ. There were plenty of great speakers who gave me a lot to ponder. Here's a collection of ten articles that reflect the stories, tools, and ideas that I will take away from the conference.

Note that although I've referenced the speaker who introduced me to the material, in most cases they didn't specifically endorse the articles that I have linked to.

The US B-2 bomber crash in Guam [3 minute read]
A cautionary tale of edge case system use and communication failure.
Speaker: Gojko Adzic

Single-Loop and Double-Loop Learning Model [3 minute read]
An explanation of the two ways that we can learn from our experiences.
Speaker: Steph Cooper

The Ladder of Inference [10 minute read]
Examines how we reach conclusions, can be used to improve communication.
Speaker: Steph Cooper

Shifting from unilateral control to mutual learning [20 minute read]
Explains the characteristics of two mental models; unilateral control and mutual learning.
Speaker: Steph Cooper

Shu-Ha-Ri [3 minute read]
A way of thinking about learning techniques.
Speaker: Craig McCormick

Visual Test Modelling [10 minute read]
An examination of how to approach the creation and evolution of a Visual Test Model.
Speakers: Adam Howard & Joanna Yip

OODA Loop [10 minute read]
The process that defines how humans react to stimulus; observe, orient, decide, act.
Speaker: Bruce Keightley

The Palchinsky Principles [3 minute read]
Three principles for innovation.
Speaker: Gojko Adzic

Digital by Default Service Standard [10 minute read]
A set of criteria for digital teams building UK government services.
Speaker: Ben Hayman

6 Days to Air [3 minute read | 40 minute watch]
Learn about the six-day production schedule for writing, recording, and animating a South Park episode.
Speaker: Ben Ross