No women speakers? No Bother!

That might surprise you if you listened the Eurostar Webinar last week where Fiona Charles and I explored the numbers of women speaking at software testing conferences. If you didn’t hear it you can now  (Spoiler ahead it’s roughly 25%*)

FemaleConferenceSpeakers

 

Considering that there are more women in testing than other technical professions you might be surprised by this.

Unfortunately I’m not surprised. Fortunately, I’m not bothered by this. In fact, I’m not even bothered that in 2015 the percentage of women speakers has dropped in some conferences, or that the number of women on program committees for many conferences is a big fat zero.

Percentage of women on program committees

I’m disappointed of course, but I’m not bothered by it.

That’s because there are some phenomenal women in software testing and they’re taking the matter into their own hands.

Rosie Sherry working with Anna Royzman for example, has dropped the teaser that women makeup ~50% of TestBashNY 2015 using a merit based selection process. They had a lot of women submitting proposals and I think it’s clear why. What female tester wouldn’t want to speak at a conference run by those two phenomenal and respected women?

There’s more though:

Maaret Pyhäjärvi & Adi Bolboacă have decided to create a conference that they would want to attend. It’s called the European Testing Conference 

Mieke Gevers & Nadine Raes run Belgium Testing Days and there’s typically a high percentage of women speakers (30% this year).

I’m sure there are other examples too.

It’s simple folks. When you create an culture where women feel welcome to speak, the submissions come flooding in.  What does that mean? Well, perhaps women no longer need to be concerned about being underrepresented at dinosaur conferences. Instead, women can focus on conferences that are already offering a healthy environment. Conferences were women are compelled to submit.

I suggest that for any conference in software testing, if the trend of  women speakers is decreasing or wildly fluctuating, if the percentage is consistently below 25%, then conference organisers need to rethink how they are attracting talent.

FemaleSpeakersByConferenceTime

In this day and age, I think there is little excuse for poor female representation. Conferences such as CAST have demonstrated it can be done. CAST has high calibre talks and a high percentage of female speakers. Who would have thought?

How about you, do you think conferences organisers need to rethink how they attract talent?

*figures were taken based on information on websites. We may have made errors in counting, but we think they are fairly accurate representation. Please let us know if we’ve made any glaring stuff ups. 

Agile Australia and Intent based Leadership

Today I went to Agile Australia as an attendee. That’s a first for me, usually, I’m speaking. It was wonderful to go with a different purpose, which is to learn from others. Typically, if I’m speaking I’m so focused on ‘my talk’ and getting ready for ‘my talk’ that I don’t feel very open to learning new ideas.


I’m glad I went, because I had the opportunity to listen to David Marquet’s (nuclear submarine commander) talk about the abdicating control (not responsibility) to the people who worked for him. In a military organisation I can’t imagine the mindset shift & the struggle his crew must have felt!


There were many aspects of the talk I enjoyed, how subtle changes in  language was used to help people think differently. For example instead of his crew requesting permission, they informed authority by using the phrase “I intend”. He emphasised the need for constant training and drills to help keep people prepared for when the inevitable mistakes were made. I also liked the concept of pushing ‘authority down’, allowing his crew to control their decision making.


The biggest resonator though was his perspective that you can’t change people, all you can do is provide an environment where people can change themselves. After all “When a flower doesn’t bloom, you fix the environment in which it grows, not the flower.” I have this ideology too in building & developing test teams. In 2013 I spoke at Tasting Let’s Test about building a context driven test team. In it, I talk about creating a habitat where testers can thrive and grow, with a focus on coaching to support that work. I’m working hard to create a habitat like that in Tyro Payments.


The underlying belief he had was that “people are fine the way they are stop trying to fix them” struck deeply with me. If you start with that premise you come to coaching with a different mindset. And just like I came to Agile Australia with a mindset of learning this year as opposed to speaking, I can approach coaching with intent to listen instead of teach. Instead of focusing on where a person needs to be, you think of were a person is. The spotlight is placed on the person not your perception of that person.  Perhaps it’s subtle differences like this that can make all the difference in coaching. Or maybe not. I don’t know. It’s an experiment, but one I’m performing on myself rather than on other people.


And I think that’s exactly how we all like to learn.

Nice girls don’t get the Keynote

Keynotes are something to be earned and rightly so. Typically a keynote comes from someone who likes to speak, who is good at speaking, and has something interesting to talk about.

I know many women testers who meet the above criteria. They have the requisite ‘merit’ required to be a keynoter. They have thoughtful ideas, are good speakers and are well respected in the testing community.

So why are they not keynoting?

Could it be that to be a keynote takes more than ‘merit’?  Could it be that keynoting is also about your place in the community and your connections within that community?

My experience as a conference organiser and being on program committees is that ‘who you know’ is equally as important as ‘what they know and how they speak’. I don’t apologise for that. It’s important for me to base my decisions not only on an abstract but on a speaker’s reputation.

A keynoter needs to have some of the following:

1) They have interesting topics to talk about
2) They are practiced/skilled at speaking
3) They are involved in some way in the community
4) They network within and outside of their ‘tribe’
5) They make a point of asking for keynotes

I know many practised women speakers with fresh and innovative talks and we are well covered on points one and two.

And we’re not so bad at organising and volunteering for conferences & community either, so….

Could it be, points four and five is what’s holding us back?

Keynotes are typically by invite. That means, the program committee gets to decide who keynotes. Those on the program committee tend to have a good network. It’s probably one of the reasons they’ve been chosen to be on the program.

How are your networking skills?  I’m not talking about card swapping nonsense, but ask yourself: do you have a genuine interest in engaging with people who you respect? Importantly, do you know your network will openly advocate on your behalf? Which brings me to point number five…

Be open to asking to keynote. Is it just me, or is there’s this weird unwritten rule in our community that prevents us asking to keynote? It seems to me that to ‘make it’ we have to Marlene Dietrich like, sit nonchalantly in the corner waiting to be asked for our moment in the spotlight.

Maybe that’s just me and not a general experience. But for those of us who are less direct I’d like to suggest you make it clear to your close network that you want to keynote?

What’s more, go direct to the program committee and ask them for a spot. If the say no, ask why not? and what does it take to keynote,? Who knows you might gain some valuable insights into the process.

Because no matter what skill you have, or how good you are at speaking, or how charismatic you are, there’s dozens of great speakers who can do what you do. It takes more than merit to get noticed. It takes courage to ask and you need allies who will support you along the way. Have you got what it takes?

If you’re reading this post, and you’ve keynoted in the past with a story to share about how you got to keynote, Speak Easy would love to hear it as it may help us understand what it takes to ‘get there’. I’d post a link to your blog post on the Speak Easy website (or I can post a blog).

*Title misappropriated from a book I found useful on this topic “nice girls don’t get the corner office’

Paying Attention to Paying Attention to Detail

One question I often ask a tester in an interview is what they believe are the essential skills that differentiate a good tester from a great tester. One of the common replies is “Paying attention to detail”. But what does that really mean?

Start with detail. What do you mean by detail? Mrs Google offers the explanation “an individual fact or item”, but what sort of detail? Visual detail? Detail from a coding perspective? Any detail or only detail that matter? Is it detail as in ‘small stuff’ as in the Devil is in the detail?

Also what exactly does “paying attention” mean?

Maybe it’s one of these interpretations:

  • A tester is attentive as in a teacher saying “pay attention!”? As in be alert?
  • A tester is only observing detail?
  • A tester is observing detail exists and then noticing they are problems?
  • A tester is noticing detail without a conscious attempt to observe in a methodical manner?

Going deeper, why ‘pay attention to detail’ in the first place?  Is it because you’ve been told to, or because the tester genuinely wants to? Your motivation and purpose play important roles in bug finding. For example what’s your ‘attention to detail’ on being told to complete 40 test scripts in one day, compared to your attention to detail if you get made handsomely for finding a bug or winning a prestigious competition?

Yes, paying attention to detail is important, but so is understanding what you are doing when ‘paying attention to detail’.

In my book, there’s not enough meat on that answer to figure out if someone’s a good fit for my team. I want more. I want my testers to suck the marrow out of that question, to boil it until the flesh falls away from the bone.

Professional testers¹ consciously observes systems using a multiple of models. Their maxim is “the more you see, the more you see”. And that’s only the beginning. Following observation comes evaluation. Now testers get to interrogate information by asking (either explicitly or implicitly) is there a problem? Not content with relying on one oracle they may consciously use many different oracles in their evaluation process.

They then report this information in a way that’s meaningful to the people who want to hear it.

So if you are a  tester coming for an interview on my team and I ask you this question, please have fun with it. Show me your testing process, demonstrate it with diagrams and models and show me a bit of your testing flair. All testers pay attention to detail to some degree. What in particular do you pay attention to?

¹ by professional tester I mean someone who makes an attempt to understand and then improve their personal testing process. They tend to develop a unique approach and style to their testing through years doing, thinking, talking & writing about testing.

This post is a result of a tweet I made which many testers. An interesting aside, my poor spelling was explained away by many as a purposeful trap designed to snare the unwary tester. It wasn’t, though I’m flattered that you would think that of me.

Bobbing for Embedded Apples

One of my first recollections of physics is the image of Archimedes running down the street, dripping wet from his bath and shouting: “Eureka I found it!” on discovering his principle of fluid displacement to measure the force.

Add to that Isaac Newton who quietly sat under an apple tree, musing the day away until he discovered his laws of motion, one which states;

For every action there is an equal and opposite reaction..

Happy days…

Many companies want to improve their testing, particularly if that improvement is translated into reduced time or cost.

To achieve this, there’s a big trend to embed testers into development teams. There’s no longer ‘us’ and ‘them’ but an harmonious ‘we’. The wall of independence is torn down replaced by a gleaming whiteboard emblazoned with the banner ‘Quality is a team responsibility’.

The reality though is that just like Archimedes in his bath, or Newton and his Apple, embedding testers into a team of developers is going to create displacement and cause a reaction.

This is common sense. Put one tester into a team of multiple developers and it’s going to change the team dynamics. Add to the mix, that the tester will most likely become a point of constraint disrupting what was perhaps a seamless flow of stories into the Done column and it’s no wonder the apple cart gets upset.

For example, developers discover they need to get more involved in testing and decision making.That can be a big mindset change if traditionally developers are used to handing work over to testers (as opposed to receiving it from them).

Testers need to change and adapt too. They have to let go control over all the testing and entrust the developers to help them test. Again big mindset change for testers who traditionally rely on empirical evidence than a developers word to evaluate quality.

Why then, do we seemed surprised when we face resistance and/or confusion when these changes are attempted?

This is our brave new world. I wonder where we will all end up?  Wether a team develops a true and meaningful relationship or simply an uneasy alliance is I guess up to how much both testers and developers are prepared to appreciate each other’s challenges.

One way we can help each other out is to be supportive as opposed to defensive when people face the impact of changes and perhaps feel displaced and confused. How much we are prepared to let go our assumptions and prejudices about each other will also play a big part in how ‘successful’ these experiments are deemed to be.

Exciting times indeed!

 

How’s your signal to noise ratio going?

It’s not only engineers that need to deal with S/N (Signal to Noise Ratio). 

Test Managers have to deal with lots of noise, in managing projects, dealing with stakeholders, identifying potential future risk, maintaining test environments, hiring testers, and meetings,meetings & meetings. Traditionally that’s what the role has involved. We deal with the noise, so testers can get on with doing their job – testing.

But is this really what is required? The reporting, the stats, the work allocation, the test strategy work and did I mention the meetings? It’s all STUFF. There’s always STUFF to do as a test manager. If we don’t have STUFF to do, we go out and look for STUFF. We roll our eyes at all the STUFF we have to do, but secretly we like it. It makes us feel important and keeps us busy.

Recently, I did a peer review with my team. I asked them to anonymously review my work. One question I asked them was “what I should start doing more of?”.

The resounding signal was loud and clear.  They wanted me to increase the amount of coaching and training within the team.

So I stopped doing STUFF. I dropped meetings that were optional, I’ve distributed recruitment and I worry less about planning for ‘the future’.

Instead I test and I encourage other testers to pair with me as I test, or to invite me over to test with them.

That way I’m sharing my knowledge and expertise.

It’s been hard to let go the high level STUFF but in some ways, these management type activities can be performed by most managers. Very few people can train and coach testers.

How’s your S/N ratio going?

Hi, my name is Done and I’m conflicted

If there is ever one word that highlights the difference between a tester and a developer’s mindset it has to be the word done.

Developers¹ tend think of done as a form of sign off. A story is done when the code is complete. For many developers, it’s when the code is complete, tested and deployed. Done is a sign of completion, of moving onto something else.

Testers² look at Done as the beginning of a quest, an exploration. Done is to be prodded, probed, explored and dissected. Under what conditions can ‘done’ fail? What data tests the limits of Done? How about if two Done’s are put together, how will they behave?

With these two different mindsets it’s no surprise that at times there is conflict and disagreement.

Most testers (most people for that matter) shy away from conflict in order to maintain team harmony. Instead, they try to gain agreement upfront on Done. The goal is clarity and scope definition. Make done clear upfront (before coding begins) and it lessens the conflict later.

In many companies, conflict is seen as a ‘bad thing’. Being in conflict suggests that you’re not a team player. But conflict is a not always bad. According to the 5 dysfunctions of a team by Patrick Lencioni conflict is healthy indicator of trust and ought to be encouraged.

And testers must not forget that our primary role in a team is to raise uncertainty about Done. This has to come ahead of wanting to be everyone’s friend and being accepted. The reality is, if we are doing our job we will be testing the limits of preconceptions of Done.

Because as appealing as it is to think of Done in terms of black and white, zero and one, the reality is a lot different. Done is subtle and muted with hidden dimensions and unknown crevices. Exploring and shining a light³ on these dark corners generates new information. That information helps mould and develop our understanding of Done. The more we test, the better this becomes. Whether this new information turns out to be accepted or rejected is to some extent irrelevant, both contribute to fleshing out our understanding.

So sure, have your discussions on ‘Done’ before code is written, but let’s realise that it’s only the beginning not something final written in concrete. Allow testing and testers to expands that understanding.

In fact, I would go as far to say that true harmony is having a mutual goal of building our understanding of what Done means. Who knows? Maybe through that mutual goal can real trust and respect be built within a team.

¹ ² generalisations

³ kudos James Bach

“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.