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.

 

 

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. 

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 

Question with sprinkle of humility on the side

Michael Bolton tweeted yesterday:

Why do testers insist on trying to be influential? I suspect part of the reason is that part of a tester’s job is to recognise problems. Too often , testers see that the *real* problem is not the software itself, but the process behind the software and go into bug prevention mode. That sort of change requires influence.

Often though, we simply don’t have the authority or the influence to do make change. We may moan and tear our hair out in frustration, but at the end of the day, without the mandate to make change and the influence to implement it, there’s little we can do to change an organisations culture or process.

Trying do do so regardless, can lead to a sense of helplessness and even slowly, over time, a sense of powerlessness. I suspect most of us at one time or another have felt like this. It’s not a great position to be in.

I know I’ve been there. I tried to change the culture of a company (company no less!) that had some  negative ideas about testing and teamwork in general. (I’m talking about this at Eurostar this year). As a consultant, I probably should have known better, but I argued (to myself) that the culture was affecting the tester’s ability to perform their job. It needed to change!

We  testers are gifted with keen observation skills and the nature of our role sometimes means we get to see and recognise problems that perhaps others don’t. But lets not get away with ourselves. Without a mandate for change, we become close to the schoolyard tale tattler, dobbing in on everyone and despised by all (including often the teacher). I failed to recognise that I hadn’t the authority or the influence to make these sorts of changes. I fell into a classic consultants trap. I really should have known better.

It’s not that we *should* or *should not* ignore these problems. Often these challenges are too complex to be solved with simple answers and probably need to be dealt with on a case by case basis. But I think adopting the tone of helper (or servant) goes a long way to contributing to an answer. In some cases a question sprinkled with a little humility can be more helpful than smothering the problem with large doses of  tester sauce.

I hope I’ll remember that next time!

Knowing the unknown

As a teenager, I remember being struck by the poignancy of the tomb of the unknown soldier. I’m not sure which tomb it was, in which city. I don’t recall there being one in Ireland, so perhaps it was in London. I remember feeling sad and perhaps a little understanding of the horror of war crept into me. For such a simple monument, the message was powerful.

For me, the tomb itself signified a lot more than missing soldiers. Somehow it symbolises those untold stories. Who was that person, why did they die? Was it painful, did they have a wife, children? it makes me think about history too, and how really its a story told by the victor. We rarely hear the story of the defeated. So many stories untold.

Roll on many, many years and I realise that we in software development, particularly in agile, we have many untold stories that only make the light of day when we find bugs in software. We fail to hear the stories that stakeholders wanted to say, but fell aside because of time pressure. We fail to hear stories that stakeholders have not realised exist. We fail to hear stories because some stakeholders weren’t seen as needed. We failed to tell the story because we simply didn’t think it was important enough.It’s a wonder software works at all!

Testing to helps us uncover and tell these untold stories. How? Each bug we find, has a story behind it. It may be story of why the bug came into being in the first place. Or the story may turn out to be unimportant. Often not only do we uncover stories,we also end up adding meat the stories that exist.

I find this particularly true of agile. The simplistic approach to stories that start with “As a <insert oversimplified description of user here>, I want <some oversimplified goal> so that I can <insert oversimplified ambiguous reason>” . I do understand that the point of these stories is to initiate conversation, but it’s my experience that often conversations are skipped and this skeleton like sentence ends up becoming the story. And as Allister Scott pointed out these stories would totally fail the bedtime story test performed by any 5 year old. Regardless these skeleton like stories then become converted into automated acceptance tests which significantly influences the decision to release or not. Well, in my experience anyhow.

As I understand it, one of the reasons for these simplistic stories is to achieve the goal of “dealing with the problem at hand”. By focusing on only what needs to be done now, we avoid over engineering a product. Now believe me, after working on some large scale telecommunications switches in the 80’s and 90’s, I totally appreciate this sentiment. However, the drive to simplicity has I think led to deficiencies in how we model our systems.

For example, we fail to recognise that firstly, some systems cannot (and perhaps should not) be modelled from a user perspective. (I’m happy to be proven wrong in this, my experience in testing r&d products and layer3 protocols leads me to believe this is the case though). Also by focusing on only the problem at hand we fail to appreciate the subtleties and impacts of the unknown unknowns.

I’d like to see software development attempting to re-address this balance. When I went to Agile Australia lots of people were talking about systems thinking and my first response was “Brilliant!” but it seemed that the systems thinking was focused primarily on business systems, as opposed to products. Perhaps its me with too narrow a focus, but I’d really like to see more discussion on how we can become better at modelling software in agile.For one thing, lets move away from telling stories ONLY from a user perspective. There are many ways to model a system and greater diversity of models may bring about deeper appreciation and understanding of the problem were trying to solve.

And so to the unknown solider. I’m glad no-one has tried to simplify his story into a sentence beginning with “As a soldier…”.  The monument conjured up more questions than answers, questions about the unknown. Questions that can never be answered. He was the unknown solider and it was fitting. i guess one question to ask is this:  is the unknown story a fit for agile?

The title for this post is inspired by Colin Cherry’s talk at KWST3 about Johari windows. [thanks for the spelling check Srinivas]

The engineer’s curse

Its a rare luxury this week as I have the house to my own. Perhaps those of you with partners and or younger kids will identify with this sentiment! Suddenly life seems to be easy and manageable. I don’t feel responsible for looking after other people and their problems. The challenge to manage a house, be a mother and partner, run a business, organise a conference and oh yeah, do some testing is a lot easier when its only yourself to look after!

When I took PSL last year, one of the ‘skills’ I realised I had was running around making sure everyone on the team was being heard and was ok. Another word for this is meddler. How, I thought could the team function without me, unless I was there to keep it together?

I guess after reading the first paragraph again work isn’t the only place I fall into meddling.

In a moment of retrospection, I feel my desire and ability to solve problems is sometimes more of a curse than an asset. Perhaps in my drive to solve problems, I forget something crucial. That is, often it’s not about solving a problems its about having the conversation.

Earlier this year, Michael Bolton introduced me to Marshall McLuhan and his concept that “the message is the medium”. Is it possible then, that solving a problem is not as important as the process used to solve the problem? Or in other words, the conversation you have to solve a problem, is more important than the resolution of the problem you are having?

A while back I read David Bohm’s book “On Dialogue”. In it, he encourages groups in dialogue to take the focus off decision making and instead put the emphasis on the process of communication.He encourages participants in the dialogue process to suspend judgement and be open to what emerges from dialogue. In this way a group can develop deeper meaning. For example, instead of trying to create a common terminology, common terminology becomes created.

He also talks about the challenge in problem solving. Mostly, what we call ‘problems’ are in reality paradoxes and inherently its impossible to solve such ‘problems’. Bohm believed that the dialogue process(I haven’t tried it) is a way of acknowledging and respecting differences allowing new ideas to emerge.

We all have a basic need(well I like to think we do!) to connect and understand each other. To be *human* if you will. Its this human need, at a tacit level that perhaps defines who we are, more than any high level problem solving skill dictated by our frontal lobes. As an engineer, I’m taught communication is essential to solve a problem. As a human, I’ve learned that its about taking the time to include people in your day, to actively listen regardless of the outcome.

Just a thought.

Where have all the good jobs gone?

If you follow and believe the twitter conversations, it seems that the main reason for getting ISTQB certification is to pass the screening when applying for work. No ISTQB? No interview!

My personal experience has been that yes, on one or two occasions I’ve failed to be interviewed based on lack of certification. Rather then see this as a negative, I see this as a blessing. After all, if your idea of a tester is that narrow, then I’m probably not suited to your company. On occasion I’ve cited ‘NO CERT’! to justify why I can’t apply for a role. “I’m so sorry, I’m not ISTQB certified…” as I edge my way to the door.

I think it’s naive to rely on a certification as a means to getting work. Especially if you are a thoughtful and intelligent tester who cares about the quality of your work, and who wants to be taken seriously in the industry.

But forget about certification for one minute. Are you seriously willingly going to put your career into a strangers hand who then decides your fate by a keyword? There are cleverer ways to play this game.

Have you not noticed that the way companies recruit is rapidly changing? To get a job that interests you, its not good enough to send in your resume or hold a silly piece of paper with a over ornate stamp on it. Those days are long gone. Now you need passion, you need to keep up to date with whats happening in your field, you need to be committed to keeping yourself relevant.

Our family has experienced this first hand when my husband was looking for work last year. He suddenly discovered at the ‘old age’ of 42 that he was unemployable. He is intelligent and personable(yes I am biased) with a first class degree in Electrical Engineering and he had made the assumption that good people always find work. But that’s not enough. Today, if you want a job that’s worthy of you, you need make sure you earn the companies respect.

This is not only based on my personal experience, I’ve spoken to many recruiters in the last few months, and all seem to have similar stories. Companies are more reluctant to use recruitment agencies to find their staff. They want recruiters who know and understand the specific skills they are seeking. I’m seeing recruiters leave the industry, or re-invent themselves as specialists in one field. Other ways the industry has changed is that many recruiting companies work for one company and are in effect the procurement arm of the company.

Of course, the testing industry has changed significantly too. Now that the major consultancies have successfully sold testing as a commodity, testing (or an excuse for testing) is being performed wherever people are cheapest. The adoption of Agile as a development process and its dependency on automation has also reduced the need for testers (though this is not necessarily a bad thing). The fact is, there are less testing jobs out there.

That doesn’t mean there are less quality testing jobs though. While its true that the crumbs from the table need to be shared among more, there is still plenty of meat and gravy at the table. The question is, have you earned a spot there? Here’s a fact. You are not going to earn a spot on this table with a certificate. The path to this table is through credibility and reputation.

My first bit of advice is if you want a worthy job, then you need to be worthy. Examine the work that you have done to date. Does it reflect your skill and perhaps more importantly, your ability? What about your attitude? Does your work reflect that of someone who is passionate and who loves testing? You don’t need rockstar status, but you do need to be an eager apprentice. If you have aspirations to get a great testing job, but you’re not prepared to put in the hard work, then why should you deserve a great role?

Here’s something I do that has proven to be very useful. When I start a new role, I ask myself two questions. The first is “If I leave, how do I want people to remember me”? and second is “what legacy do I want to leave behind me”? It may sound ruthless to think about an exit strategy when starting a role, but the reality is, NO job is permanent so why treat it as one?

So, you are now a worthy tester, the next step is to be able to demonstrate this worthiness and please, put away that tired old resume! I’m talking about blogging, and speaking and contributing to the testing community. Contributing to the community is a great way of meeting local and international people and you learn so much. Regarding speaking, this doesn’t have to be large conferences, there are plenty of small local meetups that offer you a space to speak. No tester meetups near you? Why not create one, or speak at a developer meetup.

Thirdly you need to network. I can’t emphasis this enough. This is where the jobs are. You need to consider two types of networking, local and online. Local is essential if you want to find work in your area. This means meeting people face to face at the local meetup. Yes, I know masterchef is on a Tuesday night and this clashes with the meetup, but hey, do you want a great job or not? Online networking is important too because it allows you to connect with like minded people, plus its a great source of learning. Many jobs come from both online and local networks.

You also need to research. Find out the good companies, speak to people through your network (not agencies) about the ‘good places’ to work, and make a plan on how you are going to work there. Having an online presence helps a lot here, but so does face to face networking. And be patient, great jobs don’t just drop off trees and fall into your lap.

Yes, ultimately, these jobs don’t come easy. They require hard work, and a willingness to put yourself out there. It comes at a cost to your personal lifestyle. but hey! It’s all about choice. Great jobs are around, but its about seizing the day and making the opportunity instead of relying on an agent to do it for you. This is a good thing. Trust me. As I said at the start, why should you put your fate into someone’s hands?

The good news is more than ever before, companies who recognise and value their staff, who recognise and value quality testing, are recruiting in a grass roots way. If you want these types of jobs, it’s easier to get them.

Now maybe this all seems like too much work and you know? I can live with that! Seriously, its your call. But don’t tell me that certificate is mandatory to work in testing, because its not true. Many companies who ‘get’ testing will hire you without a cert. The question that is probably more pertinent is: “Do they want you?”

So get out there, work your butt off and then market your fabulous testing skills. If you stop putting your pearls before swine, one day that dream job will be yours!

Courage in Exploratory Testing

Exploratory Testing takes software testing skill. It also requires the tester be courageous. Let me explain.

Exploratory testing is an approach, not a technique. Exploratory Testing is simultaneous learning, design and execution. What information we learn about a product, helps dictate our tests providing us with information that we can share with people around us.

Exploratory Testing is tester centric, meaning the tester is central to the testing taking place. The tester has the autonomy and the responsibility to make decisions about what to test, how to test, how much to test and when to stop. This may seem blatantly obvious to some, but its surprising the number of test teams where this is not the case.

Its all powerful stuff, generating an environment where the tester must constantly reflect upon the changing project and product environments, enabling the tester to be engaged and mindful as they test.

I honestly can’t think of a better approach to software testing.

But there is a catch. Exploratory Testing also demands great courage.

When you start to take responsibility for your testing it’s not done in isolation. Testing requires interaction with many different people such as developers, project managers, scrum masters, product owners, customer support and business people. We share information that’s not always good news. Its in the form of bugs found and the possible impact of this information on business. The resulting consequences of the information we share often leads to delays in releasing, changes in work load, context switching and revising strategies.

In scripted testing, testers have artifacts which they measure and count giving an illusion of of certainty but really this is smoke and mirror reporting and generally offers little genuine information. “We have reached 78% test coverage, with a DDR of 85%”

Exploratory Testing doesn’t have ‘dutch courage’ to rely on. It requires us to have conversations about our information in potentially hostile environments. Sometimes we can feel like the lone fish swimming against the tide of the silent majority. It can be tough and as testers we need to learn to develop how to speak about our testing, how to tell a story (James Bach and Michael Bolton have both written on this). courage in Exploratory Testing

Here’s a list of ways that have helped a quaking knock kneed tester like myself discover her backbone:

Speak to someone you trust about your concern. Vocalisng a fear helps to make it tangible and sometimes gives strength when you discover its a shared concern.

Be coached or mentored on how to speak about testing with confidence

Take small steps. Speak to people sympathetic to your cause, sound out ideas. See if other people can help.

Try not to lose faith, be persistent. Keep your eyes on the goal, even if sometimes you fail to speak out.

Emotions are your toolbox. Anger and frustration can be very useful emotions! Use your emotion to give you courage to speak out. (I learned that at PSL this year..thanks to Jerry, Johanna & Esther)

Sometimes you need help. Be humble enough to know that sometimes change is out of your capabilities. See if you can find help through the testing community or see if you can bring someone in to help affect the change.

But mostly, its about practice. Courage breeds courage. Standing up to little things helps give you courage to stand up to greater things in the future. Be brave. Be strong.

What drives me most of all is that I want to be able to walk away from a situation with my head held high in the knowledge that I may not have changed the world, but I’ve had my say.

Now that’s a good days work.

 

 

 

 

Growing your own

So, I’m sitting here in my office on a beautiful  Australian spring day. The sun is shining brightly, the air is slightly fresh sending wafts of scent from the spring flowers. Its a good time to be alive and its a good time to be thinking of growth and change.

Potatoes in Spring

True to form, I trotted down to the local garden center and bought back a truck load of seeds and ideas on what I can do in the garden. I feel good this year, the potatoes are growing well, and I’ve managed to grow snow peas for the first time. Having invested a good amount of time in the garden, I feel content enough to sit in my office and allow myself to explore ideas on software testing and training.

And I’ve come up with the crazy idea, wonderful idea. For some time I’ve wanted to invest in online training in software testing. Its a model that I think will suit me well. I live far far away from the rest of the world and as much I as enjoy meeting new testers from around the globe, continuous travel is not for me.

To date, I’ve struggled with the concept of online learning. When I learn, I like to get my hands gritty, experience the stuff I’m wrestling with. With my online coaching, I make sure I include a task of some sort but thats one on one. Is it possible to offer online experiential learning to many people?

And then I read about these guys at Venture Lab. The courses are highly experiential & require collaboration to succeed. I sniffed a model that I could possibly work with.

But I’m taking it one step further. I want to make the students the designers of the course. Its the students who will work out what needs to be learned and how that will be achieved, and how they will know they achieved it. There will be some external structure, perhaps in the form of exercises, some philosophies to abide by, but basically, its the students who will dictate the content & the pace. In fact a lot of these ideas are from the coaching model James Bach & I have worked on holding onto the concept that learning requires real desire from the student, and to do that the student needs to dictate the learning (with the teacher offering space and direction to learn).

I see this courses as being a permission giver. We’re so drilled to think of learning as something we have to sign up for, like its impossible for us to learn outside a course. In this way, I’m helping overcome that little hurdle and get into some real meaty learning.

I’m very excited about these ideas and what will come of them. I’m not sure where they will lead and I guess that’s half the fun! If you want to join me on the crazy, wacky journey, feel free to contact me on Skype at charretts, or else add a comment below.

I’ll be adding information on this model as it progresses.

That coverage problem

Thanks mostly to the BBST classes the AST run, I’ve come to understand and appreciate the impossibility of complete testing and the challenges surrounding ‘complete test coverage’.

I find 100% testing coverage a pretty meaningless phrase. Imagine trying the calculate the amount of water in a swimming pool by multiplying the length and width of the pool. Ha! we’d snort and sniff at the stupidity of the idea. But when test managers, project managers and testers ask for “complete test coverage” that is in essence what they are asking testers to do.

In fact, getting to grips on complete testing is even harder than the pool problem, because at least with a pool, once you know the width, length and depth, the volume can be calculated.

In testing though,the number of models we use to design our tests is limited only by our imagination. To try and measure test coverage is a bit like trying to cover a black hole with a tea towel and say you’ve measured it.

Trying to test like this in a short space of time is really stressful and it seems the agile solution is to automate regression tests. But really, is this the best solution we can come up with?

It seems to me this desire to cover as much functionality as possible ends up in this Wac-A-mole game with testers frantically hitting features as fast as possible in order to be able to say its done.

Well, I’m trying a thought experiment at the company I’m consulting at. I’m challenging everyone to drop the idea of coverage and instead focus on some meaningful and valuable testing.

I’m doing this because it seems to me, we testers are far too hung up on this coverage problem and we bias our testing to try and solve it. Yes, this may mean that we fail to test all the functionality – quelle horreur! But get this, when do we *ever* test all functionality?

Dropping the desire to “test everything” is very liberating. We no longer have to fret about trying to test all the functionality in a week (we do weekly releases with multiple hot fix releases). Instead, it’s freed our minds up to reflect and ponder on what is the most beneficial testing to perform given we only have a few days to test. It’s also freed up our toolsmith, allowing them to spend time solving some testing problems through testabilty instead of frantically creating regression tests.

I’m fully expecting some bugs will get released to production, but you know? that’s nothing new! We’re finding bugs in production all the time, they’re called customer support issues.

Time will tell if this approach proves to be beneficial or not. It’s a little scary, dropping the regression test safety net, but when safety nets start obstructing your work its time to question its validity.