“Nobody — calls me — chicken.”

One of the morals of the Back to The Future series is be able to walk away from a fight. It took three movies for Marty McFly to learn this self control.

Biff Tannen calling Marty “chicken” in 1955.

One thing that the scriptwriters failed to predict was the birth of speaking your mind in 140 characters, aka Twitter.  If they had, it would be easy to see how Marty might have been pulled in to a twitter diatribe and feel unable to resist  responding.

Screenshot 2014-10-14 07.47.54


It’s easy to engage on Twitter. It’s fun and easy to throw out ideas, thoughts and its mildly useful for debate. My personal experience though is that its much harder to disengage. I  feel compelled to reply to a challenge. It’s as if each tweet directed at me is a personal call to respond (sometimes it is). As much as I want to ignore and avoid, I find myself compelled to return and <sigh> to respond. My reasoning mind tells me, desist, desist, but my ego overrides this. I must have the final word!

There comes a point in any twitter engagement when you realise the conversation is little about debate and more about chest beating. When I’ve come to this realisation, I’ve lost the battle. I’m no longer in control regardless of having the last word or not. There’s little dignity in wining such a battle.

We need to learn the art of disengagement, the ability to walk away without feeling somehow less of a person. It’s important to engage, but its also important to be able to disengage.

I’ve come up with some heuristics to help me battle the McFly syndrome.

Yes, And Heuristic
I got this from Lynne Cazeallys book Create Change. Instead of think ‘yes but’, think ‘Yes and..’. .it goes some way to appearing collaborative, perhaps reducing the antagonism in the twitter conversation.

How about this? Heuristic
Another Lynne Cazeally suggestion. It uses a lot of characters but you can apply the sentiment to help sound more congenial.

Rule of Three Heuristic
Sometimes, attempting to understand other reasons why someone might write something helps you to walk away. Taken from Jerry Weinberg’s rule of three.

Out to Lunch Heuristic
I’ve seen people use this occasionally where they excuse the challenge to go out and walk the dog, feed the kids etc. I haven’t tried it myself but its a method of walking away with some grace. Even better if the reason is valid.

Blank Wall
Simply don’t respond. Oh to have the will power to apply this, especially in the heat of battle!

Blocking Heuristic.
A crude yet highly effective way of not knowing is someone is responding to you or not. You are now blissfully unaware. The downside is that you will never hear anything that this person has to say. You may consider this a good thing.

Turn off Twitter 
The ultimate solution and something a few people have resorted to. Not only does twitter seem to bring out the worst in people it’s incredibly time consuming. Ask yourself do you really need it?

What tactics do you use to help you disengage from a twitter war?

Take the ‘Crappy Work’ Litmus Test

We’ve placed a ban on crappy work within my test team. From now on, we declare that the testing team will refuse to do crappy work.

The challenge is in knowing how your doing good work or crappy work?  This is why I’ve created this simple 5 minute ‘Crappy Work’™ ² test to help any tester to figure out if you’re doing crappy work or not. ¹

1) Do I fully understand what I’ve been asked to do?

2) Why am I doing this task?

3) Who will benefit, and I have spoken to them ?

4) Am I doing this task simply because its part of the process?

5) If I think it’s crappy work, how can I make it valuable?

I’m sure there are plenty more ‘crappy work’  questions that would be useful to add, but my 5 minutes is up.

Why not share your ‘crappy work’ litmus tests? 

¹ Maverick Tester takes no responsibility if you take this quiz and continue to do crappy work

² It’s a 5 minute quiz because it took me 5 minutes to think it up. It’s trademarked so I can sell you a certificate in passing the ‘Crappy Work’ test, thereby making a whole lot of money out of it.

How will Continuous Delivery affect network traffic?

I was recently in New York and had a chance to walk along the High Line. The High Line is a disused overhead train line converted into a walkway and park. It’s a really lovely walk.

High Line by David Berkowitz

High Line by David Berkowitz

I was interested to learn that the train line had been built in the 1930’s but had become disused by 1980’s. It’s main purpose had been to transport meat and produce to manhattan from the upper west side. With the advent of trucks the train line fell into disuse. It was about to be torn down when a small group of inspired locals advocated it be turned into a park. The movement grew and now the disused train line is a lovely walk and respite from the busy traffic.

I think it’s interesting that the train line fell into disuse in the first place. Why were so many companies eager to drop the train line in place of trucks? My guess is they wanted the ability to freight cargo when they wanted. Rather then delivering in one bulk they delivered smaller amounts more frequently. That way they could become more responsive to their customers needs.

That’s what we’re aiming to do with continuous delivery. We want to   be able to deliver in a faster way, to be more responsive to our customers needs.


World Class Traffic Jam by bk

I wonder if our existing network will be able to handle it though? Look at the traffic jam that is NYC and it makes me wonder that with the ability over faster and more frequent delivery comes the cost of greater traffic on our networks. Remember, if it was just your company wanting to deliver, of course there’s sufficient bandwidth, but when everyone has the same idea will our current network be able to handle it? I  guess only time will tell!


My Testing Manifesto 2014

It’s my first day in permanent employment for, oh, about 20 years. I feel a little giddy, like someone’s first day of school – nervous but excited.

Unlike my first day of school, I have some clear goals and ideas I want to implement. I thought I might outline them here to help remind me of what I want to achieve and also to see how different it turns out.

Testing Philosophies

Testing is an skilled activity(not a phase) that all, to some degree can acquire.
Testers need autonomy to make decisions, to develop and perform excellent testing.
Quality is something we all care about, though it means different things to different people.
Every test has a cost (design, building, maintaining, reporting)

Goals for Testing

To develop a company wide reputation for excellent testing
To develop a test team that is able to handle testing problems with courage, skill and humility.
To coach and help develop the skill of testing with whoever may need it
To identify where testing is occurring and help augment that
To develop and the grow the test team in size, skill and expertise.
To engage with and support the testing community

Personal Goals

To acquire knowledge in testing within a continuous deployment, delivery environment
To learn more about functional programming
To be able to identify how to repair code
To work with integrity and within the bounds of what I consider ethical

Dropping the Ball

Does the thought of ‘dropping the ball’ fill you with dread ?  Perhaps you feel you will let people down, or more importantly yourself?

Here’s a thought experiment: What if you actually let the ball drop? Do you know what might happen?  Will the sky fall?  Are people let down?

If so, is that so bad? We all fail at some point in time in our lives. We don’t expect perfection from others, but for some reason expect it from ourselves. But that’s not physically possible is it?  Expecting perfection in this way is about as practical as promising perfect software right?

So next time your spreading raspberry jam too thinly consider giving yourself permission to drop the ball. After all as a tester you owe it to yourself to try, don’t you?

 Apologies for mixed metaphors :)

The fine art of being precise

Jon Bach this morning wrote a post about how we need to be precise in our thinking. Thank you Jon, its a lovely honest piece with lots of wisdom.  But it got me thinking how sometimes precision can let us down too.

For instance, we can get fooled into thinking that being precise always matters. There are many situations where vagary(what a wonderful word!) is incredibly useful.

When my husbands asks me how my day was, I don’t reply with “What do you mean by day?”, instead I typically respond with ‘fine’ or something equally inane.  What’s important here is not the precision of the question or even the precision of the answer. My husband’s not that interested in my day at all but it’s his way of asking “are you ok?”.  My answer though perhaps a little short, is important too, though it’s not really the answer that matters, its the tone of my answer that he’s listening out for.

You see this vagary in software teams that work closely together.  Over time, these teams have developed their own language and don’t feel the need to question every definition. Team members pick up cues from body language and follow unwritten rules without much thought. I see this ability to follow such rules without question as a way of building trust. Often teams that work together for a while just ‘know’. They’ve built up a certain amount of tacit knowledge which doesn’t need to be openly discussed.

Unfortunately many of us have, at one point in time, worked in situations where this culture (for want of a better word) is not so healthy. I worked in one such company where open questioning was implicitly discouraged to the point where a developer worked on the wrong story for a whole iteration. I’ve seen many a tester battered and torn from attempting to pull down those unwritten walls of silence and ambiguity.

But what’s  important here is we recognise that in certain situations its appropriate for us to be loose in our language. In fact, I often hold off from being precise especially if I’m new to a team or client. Instead, I sit and listen, waiting for ambiguity to bubble up and emerge. This intentioned act of silence allows me to witness rather than be told where implicit assumptions may fester.

So while being able to be precise  is an important testing skill, another important one is the ability to identify when and where precision is most required, and when and where we can allow ourselves to be a little more accommodating.



Hanging up my boots


photo by shankar.s

My family and I  arrived in Dublin on a cold dark wintry November night in 2008. At least metaphorically speaking it was. It was right after the GFC and we watched a country and economy wrestle with the prospect of becoming bankrupt. Regardless, Dublin’s IT and entrepreneurial spirit flourished. People who were made redundant invested their expertise into new ventures. There was a sense of familiarity in being in a recession (The common term for the GFC was recession 2.0) but also that the future was very much up to themselves.

I decided to start an Irish testers meetup, an opportunity for testers to share their expertise and learn from each other. Our first meetup had 4 testers. It never grew beyond that. I discovered that there was more to running a meetup than post on a blog. I learned that testers cannot thrive on testing alone, and that having a nibble or two and a drink goes a long way to attracting turn out. Having noteworthy speakers also helps.

So when I returned to Australia in 2010, and heard of a Sydney Testers Meetup I was keen to join. I discovered a hardy band of testers. Amongst them were Trish Khoo, Marlena Compton and Bruce McLeod. But they had similar problem as I had in Dublin. It was hard to get the word out and attendance was poor.

Sponsorship by Softed and getting some few heavy hitting speakers quickly changed that. We had James Bach, Elizabeth Henrickson, Scott Barber come along and speak. Trish has fantastic ideas about different types of activities. We had games nights and book nights. Julietta Jung came along and brought along enthusiasm and excellent pizza ordering skills.

The Sydney Testers Meetup rapidly grew but not without its ups and downs. We’ve lost sponsorship, turned down sponsorship and for a while lived without any sponsorship. We had have committee members move to far away lands. But throughout it all we managed to maintain the spirit of the Sydney Testers Meetup. Today Attribute Testing sponsor the meetup that has a 600 strong membership.

It’s time now for me to hang up my boots as organiser of the meetup. It’s been a blast and I’ve loved seeing people become infected by testing. I’m leaving the STM in safe hands. Richard Robinson and Devesh Maheshwari will be taking over as organisers. I wish them the best and look forward to seeing the STM do great things.

Scientia potentia est

“Knowledge is power”

Jerry Weinberg cites courage as the most important trait in a tester. Quoting Kipling, Jerry says testers need to “keep your head when all about you are losing theirs and blaming it on you.”

But I see a another type of courage at play in software testing. Testers are foremost learners. Through enquiry,they learn about a system. The information they gather facilitates many kinds of decision making from releasing to designing new features.

Observe great testers and you will discover an insatiable desire to learn more, not only about the product, but the world around us, often incorporating what they learn into their testing.

For many of us, discovering that our learning is within our control and within our means, can itself be a road of discovery. It takes courage to start that journey, but it also take courage to continue along its path.

Young Luke Skywalker found the ‘Force’ early on in life. Yoda helped him connect with that power, but even then, he needed guidance and a reminder to ‘Use the Force’ when up against the evil Empire.

Some of us need that reminder now and then. We know we have the ability to learn, and we know of its power, but we forget to use it. Especially when things get tough.

“Knowledge is power”

When things don’t go the way you want, when the pressures of daily life cloud your ambitions and goals, it can be easy to lose site of learning. Here’s what I’ve discovered though, through focusing on learning in these times you gain great strength.

Will the actual knowledge you learn help you succeed? Perhaps. What really counts is that through learning comes power in the form of ownership and self belief. You may not be able to control the situation at hand, but through being open to and owning your learning, you regain a sense of control and a sense of focus.

So when the dog bites, when the bee stings and when you’re feeling sad, remember there is solace in learning. It’s not only as an escape, or way of learning how to deal with the situation, but helps you take ownership and responsibility over the next step. Who knows, learning may be the just the ticket you need to recharge those batteries, giving you the juice to continue on your journey or perhaps, dump it for a different destination.

This post was first published on medium. Mauri Edo tweeted about it recently and I’ve decided to post it here too because I like it so much. 

Why waterfall kicks ass

I read a blog post about why waterfall is NEVER the right approach and I feel compelled to respond to what’s touted as the waterfall mindset. Here’s a copy of the paragraph, but you can read the whole post on the above link to get a better sense of context.

I actually don’t believe adopting waterfall as an approach is ever a good choice.  Waterfall comes with the following mindset:

  • we don’t need feedback between the steps of requirements, analysis, design, code, test
  • we can hand work off
  • big batches are ok since they enable us to be more efficient
  • specialized skills working only on their specialty is good
  • we can understand the work to be done before we do it
  • written requirements can specify what we need

Putting aside for now, the use of absolutes, lets address this waterfall mindset:

1) we don’t need feedback between the steps of requirements, analysis, design, code, test

I’ve worked in both waterfall and agile over the years. In those ‘bad old days’ where no-one appreciated collaboration, we used to extensively review requirements. This meant that testers offered valuable input into requirements before any piece of code was developed. Since the invention of ‘agile’ almost everyone has discovered the 3 amigos, but honestly, this is not an agile concept, it existed way before agile was even thought of.

2) we can hand work off

Honestly, I don’t understand this sentence. I’m serious. I can think of many reasons why handing work to others is a good thing. For instance, if I’ve got too much work I’m in danger of becoming a bottleneck, and I hand some of my work over to someone else. If that’s a waterfall mindset, its one I like to have.

3) big batches are ok since they enable us to be more efficient

What do you mean by efficient here? Does it mean quicker, better quality, less waste? Efficient in what? Design, Writing code? Testing? Support? If I wish to carry 20 oranges from point A to point B, is it more efficient to carry them one at a time, or do I get a bag and carry them all together?Try delivering to a customer 1/4 of an IC circuit and request feedback? Sometimes delivering something in one batch IS the the more efficient way to proceed.

In waterfall, we did have teams, and work was allocated into smaller isolated tasks. It was rare one person developed the whole product. In fact, when I worked on telecommunication systems in the nineties, the concept of frameworks was being introduced, segregating data from its transportation method, allowing for people to work on separate parts of a system in parallel to each other.

4) specialized skills working only on their specialty is good

When I started working at Nortel Networks in 1994 it was all waterfall, except we didn’t call it waterfall then, we called it software development. Nortel Networks had a policy that encouraged developers and testers to spend time working in each others ‘specialisation’ area. For six months I became a developer working to deliver software. I was taught C++ and object oriented design principles, so I’m uncertain why you think this is a waterfall mindset?

5) we can understand the work to be done before we do it

Why is being able to understand work before you begin considered a ‘bad’ idea? I think this phrase is too ambiguous to be able to discuss with any merit.

6) written requirements can specify what we need

Is it the word requirement, or is it the fact that it’s written that makes this a ‘bad’ mindset? Yes we do have written requirements in waterfall. We also have written user stories in agile, so what is the point? Just because stories are written in confluence doesn’t make them any less written.

In the bad old waterfall days, I facilitated workshops with the business and IT teams to determine and understand risk. Lots of verbal collaboration, lots of whiteboard discussions.  I’ve worked in ‘agile’ teams were little communication takes place, no stand-ups nothing. In fact, one developer spent a week working on the wrong story without realising it.

I’ve worked on some fantastic waterfall projects that blew the socks of some really crappy agile teams I’ve worked with recently. In these waterfall projects, I’ve worked in harmony with great developers and testers, working closely together. We were afforded sufficient time to examine the system as a whole instead of its parts, something that these days appears to be a bit of a luxury. I’ve worked in environments that develop hardware, firmware and software where upfront design and ‘big batch’ systems thinking helped us understand that we were not merely developing code, but we were attempting to solve a problem.

Its easy to conflate poor software development practices with waterfall, just as its easy to conflate an agile approach with ‘good’ practice. To me the biggest change since those days are technological ones which allows us develop, integrate and compile it quickly and relatively cheaply. It’s the technology that has allowed us to develop in these small tasks that we are familiar with today. In the early nineties the concept of layering and isolating according to purpose was coming into play but we simply didn’t have the sophisticated systems that allowed us to develop in a way we wanted to.

A second important change was the conception of the agile manifesto. To me the agile manifesto is a stroke of genius. People who had the courage to espouse ideology that placed people over process, tools or artefacts. For many, this has changed how we think about developing software.

But lets not forget, that the agile manifesto was developed by people who worked in what you call a waterfall environment.  It seems to me these people had quite a different mindset than the one suggested above. It seems to me, those who developed the agile manifesto did so with ideas of collaboration and an emphasis on the ‘humanness’   of developing software. Do those ideas come about as a result of what was done badly in waterfall or because of what they saw was working well?

I suspect it was a little of both.

Don’t get me wrong. Lots of mistakes were made pre agile days. There was an idea of segregation between developer and tester in an attempt to avoid bias from developers. I’m glad we’ve gotten over that idea. But many of the mistakes we made in those days we’re still making now. Most software teams fail to understand testing and attempt to measure it using means that appear to have no direct correlation to quality. Many teams use measurement to lock down estimates as opposed to using them as a source of information for change. Go to an agile conference and count the number of talks on process and methodologies and frameworks. Look at today’s obsession with continuous delivery as a process. What happened to the people folks?

It’s easy to understand why. The agile manifesto is bloody hard to implement. Its much easier to point at a tool or a process and say “thats what we do” because its explicit, it’s easy to see. Programming & testing are human activities and are much harder to identify and talk about. It’s hard to describe and transfer these skills. The best way I know of is to actually perform the tasks.

We need a little more humility in acknowledging the great shoulders that agile stands on. Its simplistic to identify in hindsight a ‘waterfall’ mindset. Such a thing did not exist. Instead lets view them as the agile manifesto encourages us to do, to view them as people attempting to deliver quality software just like we are attempting to do today.

Are you serious?

Seriously, how serious are you about testing? Lets presume you study the craft of testing. Does that make you a serious tester?

If you answer yes to this question, congratulations. You are on your way to becoming a serious tester. Now ask yourself this question:

“Do you take yourself seriously?”

If you want to be taken seriously about testing, you need to take yourself seriously. Note the difference here. Taking yourself seriously is much larger than being a serious tester.

Taking yourself seriously means you avoid behaviour and thinking such as:

“I will put myself down in front of others to make them feel better about themselves”
“I resort to behaving childishly when placed in pressure situations”
“I hand over power in order to avoid conflict”
“I feel like a fake even though my actions demonstrate otherwise”

I know this, because its only recently I realised that I haven’t been taking myself so seriously.

When you stop speaking to yourself in such a way and start taking yourself seriously, a wonderful thing happens. You start to believe in yourself. In fact, you have to. You owe it to yourself to do so.

I’ve discovered a new strength in this self belief. It means I have courage and strength to stand up for what I want. In doing so, I give myself the respect and honour for all the hard work I have put in.

So, let me ask the question again: Do you take yourself seriously?

Expression epitomised in Rage comics following a David Silverman interview of Fox News by Bill O’Reilly