Speed Kills

Some of my testers have become embedded on a newly formed agile team. Its been a roller coaster ride for sure. Lots of fun, thrills and a few scary points in time where I thought for certain we were not going to make it, or we were heading in the wrong direction.

From a testing perspective, we were quietly confident. Our testing is exploratory by nature, and so it lends itself easily to being flexible and adaptable.

We’re testing before the acceptance criteria are developed by attending the workshop and asking questions about the upcoming feature, learning why its needed and what problem its trying to solve.

And when it comes to testing the feature, we all jump head first  into the deep end, swimming with long powerful strokes through the water of doubt and complexity and only surfacing for air to congratulate and high five each other on another completed testing charter.

Its been a wet wild ride, but not without some uncomfortable moments.

While we’re revelling in the warm waters of upfront information and involvement, we’ve also noticed the cooler waters of reduced timeframes. Shorter iterations has placed a lot of pressure on the testers. There’s a feeling that we’re unable to pause and reflect during our testing, the pressure to be done within the iteration lends to the temptation of minimalist testing.

We had to change something to make sure we were testing well enough.

So, we slowed down.

We made sure we spent time to think critically about our testing, coming up with test ideas, understanding what done meant, and most importantly sharing these ideas with each other (including developers).

Now we test like this:

We still jump into the deep end, splash out, learn some stuff about the product but before we continue with some serious swimming we stop and confer. We reflect on our learning so far, we discuss our ideas and how we know we are done. Only then do we continue with our swimming, our strokes confident and strong.

Its been a revelation for some testers that are new to exploratory testing. They thought the objective was to test as fast as you can without stopping for a breath.

We still have the same time pressure on us, but that stop, that moment of pause and reflection has been sufficient to gain confidence in our approach and confident in delivering the best testing that we can.

 

 

Crossing the bridge over no-man’s land

Indiana Jones in the Temple of Doom  has a “moment of indecision” when half way across a bridge he realises he’s been cornered by Mola Ram(the baddy) and his henchmen.

He looks back and there’s a hoard  of lusty savages baying for his blood, no luck there. He looks ahead only to find an equal challenge ahead. What is poor Indy to do?

Anyone who has introduced change into a corporate environment will empathize with his situation. You know the decision to break away from the past is the right one, you run eagerly and embrace change, only to find half way through the journey, your path to success becomes blocked.

I’ve been working with my test team for a while now moving from a process driven approach to a more of an Exploratory one.

Its not been without its challenges. Some concepts I’ve introduced have been welcomed warmly but the reception to others has been a little icy. In particular I’ve tried to move the team away from a test case management system. This was met with real concern and there was quite a resistance to the idea.

This troubled me as while I understood their concerns, I knew the system was limiting the generation of new testing ideas.

But how could I overcome this resistance? And really was it worth it? Perhaps the changes I had already made would be enough? The company was already more than impressed with the changes I had made so far.

I felt like Indy at the foot of rope bridge, how the hell was I going to solve this one?

So I stood at my crossroads and dithered. Oh God, did I dither. I ummhed and ahhed and pondered what to do. . But worse, I  knew my indecision was making the situation worse, and that the more I dithered, the harder it would be to rid ourselves of the dust bag of tired and well worn ideas.

Indy at this point, decides his only move is to cut the bridge leaving everyone to hang on for their lives.

Fortunately, unlike Indy I had a reliable and trustworthy sidekick.  Together, we setup a task force within the team to attack the problem. After some discussion we decided our approach needed four cornerstones. They were:

1) Creativity.

However we tested, our approach needed to enable us to foster and encourage creativity. With creativity comes new ideas, new models, new tests and so discover new bugs.

We’re covering this one with a number of approaches. One is to improve tester skill through practice and coaching. I’ve also created a folder of ideas for people to draw upon to help trigger new ideas.

2) Visibility

We wanted to be able to provide reporting on any testing we do. The reporting has to be simple yet with sufficient detail to ensure that our stakeholders understand what we have tested and why.

We have our trusty whiteboard which mostly hits the spot. We need to be able to pull up our actual testing including results in an easy to manage way. We’re looking into BBExplorer to handle that.

We will also track any essential test results on wiki in the form of a test report at the end of each iteration.

3) Coverage

We wanted to have some way of ensuring that key functionality/key features are always tested.

We most likely will rely on our test case management system for this, but we’re cleaning out all the dead wood and making the tests lighter and less authoritative.

4) Knowledge

We wanted to create a knowledge base. Our system is complex and it requires in-depth knowledge to test some areas. We want to store that information and knowledge. We also have a serious amount of test data we want everyone to be able to access, modify and improve.

We’ll use our internal wiki for this.

What I really like about what’s happened here is that the team came up with a solution to solve the problem. It’s a team decision which has got to mean easier implementation.

I think a couple of really powerful things have come out of this. I’m listing them here:

1) Change can be scary. Not changing is worse. Get on with it.

2) Use people around you to help bring about change.

3) Never lose site of your goal. This reminds me of Scott Barber’s email signature: “”If you can see it in your mind…you will find it in your life.”

I feel good. I hope my team does too. We faced a challenge. We examined it, questioned it and overcame it and we’ve all come out sharper, enlightened and positive about the changes ahead.

Now that’s what Exploratory Testing is all about.

 

On conferences and insomnia

For me, the sign of a good conference is insomnia the night after the conference.

Its as if my brain is unable to let go the new ideas and discussions I’ve had with other testers. Ideas that haven’t had an opportunity to be digested and reflected upon and usually around 2am after the close of a good conference my eyes snap open, my brain alive and alert ready for action.

Ideas and discussions from the day merge and meld into a boiling cauldron of fizzling synapse and bubbling endorphins and, as much as I try to breath deeply relax and let it all go, I know deep down its all pointless.

I’m going to have to get up and write down my thoughts and ideas.

STANZ Melbourne is one such conference and its given be a double dose of insomnia resulting in frenetic writing at 12, 2 and 4 am until finally my brain exhausted became compliant and allowed my poor weary body to sleep.

STANZ is sponsored and hosted by SOFTED. These folks at SOFTED really understand and ‘get’ software testing and it shows.

As well as  hosting this conference and getting some pretty impressive speakers in(I urge anyone who has the opportunity to hear Goranka Bjedov speak to do so) they also sponsor the Sydney Testers Meetup by supplying thirsty and hungry testers with drinks and nibbles at networking events.

Whats more they host peer workshops. The last one they hosted in New Zealand which was a huge success so much so that next year they hope to host one in Sydney.

Watch this space.

For me, STANZ gave me two core learnings.

The first was Goranka’s talk about the future of quality. I think this was really insightful and gave me much food for thought. The concept that quality is dead and that as testers we need to reflect how this will impact us. I’m not sure yet what this means for me(I need some more 4 am thinking on that one!) but  somewhere deep down, this struck a real chord.

The second re-enforced to me the power of sharing problems and getting ideas from your network of testers. In 30 minutes, Trish Khoo had a plethora of new ideas and suggestions for me to take away. Many thanks Trish.

Now off to order a double shot espresso….

 

Put your lips together and blow

When I first heard about Tacit Knowledge, I had a vague idea what it was. The word “tacit” sounded a bit like “tactile” so I guessed it was knowledge that you could touch.

I was a bit off the mark.

Normally, I try to avoid starting my posts with definitions, it reminds me of those dreary debates we had at school where everyone started their discourse by using the dictionary definition.

I’m making an exception in this case as I think its important that we all understand what tacit knowledge is, so here is the wikipedia definition (Don’t be lazy, click on it)

This morning my son had a bit of a crisis going to school. As some of you know, we’ve moved country and continent. For my kids, this means new school, new friends, new environment. It can be a tough challenge for an eight year old.

Suffice to say, he needed a bit of cheering up, so I suggested he look on the bright side of life. Cue Monty Python Bright Side of Life

Well, it sort of worked especially when I tried to teach him how to whistle.

Have you ever tried to teach someone to whistle?

Lauren Bacall had a go, in the movie “To have and to have not”

But you know what? As Alex found out, if you do put your lips together and blow it doesn’t mean you can whistle!

Actually being able to whistle is pretty hard.(I’m sure many of you have memories of trying to whistle in vain!)

But why is it so hard? The basic facts were explained and it seems quite simple. What vital peice of information is missing from Becall’s instruction?

That my friend is tacit knowledge. Simply put, its the knowledge you can only learn by doing.

And so to software testing.

The reason why software testing is so hard to teach is because it requires the student to learn by doing.

To learn software testing you must….software test!

Yes, you can read and learn the peripheral stuff around testing. For example you can learn what a IEEE829 test process is. You can learn how to write a test plan, how to create a test script, but that is not testing.

Testing is the doing bit. The bit where you have to think, judge and act on a testing dilemma. Thats why some companies when interviewing for testers will ask you to test something. They know, intuitively, that testing is about doing, not writing.

My Skype coaching sessions on software testing are based around this principle. You won’t find me “sharing my experience” in the sessions because that’s not how you learn about testing. Instead, you get a challenge, puzzle or dilemma that I work through with you.

To really understand testing, you must do testing but also you must be aware of what you are doing while testing. Why? Because awareness brings about discovery. You discover assumptions you make in testing. You discover conflicting ideas and you discover your bias in testing. From that awareness comes learning and improvement.

I think thats pretty damn cool.

Now all together…

“Always look on the bright side of life…”

(my skype coaching sessions are free, contact me on skype id charretts with the word coaching in the request)

The antipodes are calling

I’m heading to Sydney, Australia on 22nd January 2011.  I will be looking for test consulting work  preferably through my Australian consulting company Testing Times.

What do I offer?

I shed light on testing problems often obscured or caused by a testing process. I bring a new perspective often hard to gain when inside an organisation.

I do this by thinking outside the square, looking for solutions outside traditional process orientated ideas.

So, if you have a problem that you haven’t yet being able to solve using traditional testing approaches, or you want a testing approach based on excellence and speed* why not contact me?

I also deliver one day training workshops on testing. These workshops focus on increasing tester skill.

I offer a context driven approach to testing.

These  principles are:

1.    The value of any practice depends on its context.

2.    There are good practices in context, but there are no best practices.

3.    People, working together, are the most important part of any project’s context.

4.    Projects unfold over time in ways that are often not predictable.

5.    The product is a solution. If the problem isn’t solved, the product doesn’t work.

6.    Good software testing is a challenging intellectual process.

7.    Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.

What this means to you is that the advice I offer is to ensure you the customer get the best value out of your testing.

If you like that idea then contact me at amcharrett @ testingtimes.com.au

Interesting fact on the word antipodes. “The antipodes of any place on Earth is the point on the Earth’s surface which is diametrically opposite to it.” – Wikipedia. So, technically that would mean somewhere in the Pacific Ocean. Though I suspect that not a lot of testing is done there!

* I use a rapid software testing developed & taught  by James Bach & Michael Bolton.

Exclusive cartoon – see it here first !

Here is an exclusive, never seen before cartoon, created especially for the upcoming ebook “If I were a testcase, I would…”

As you may know, this e-book contains over 300 memorable and funny responses to the Twitter challenge started by the Daily Testing Tip prompting testers to complete the phrase

“If I were a test case I would…”

The book will be available for download for free. We are still looking for more sponsors, so please if you or your company wishes to advertise in this book, please check out the advertising details at Daily Testing Tip The closing date for advertising is December 10th 2010. So be quick.

All proceeds from advertising will go the Chandru Fund to help raise funds for Chandrashekar B.N (Chandru) , a software tester in our community that has been recently  diagnosed with Acute Lymphoblastic Leukaemia.

Cartoon Tester (Andy Glover) has created some of his memorable cartoons into this great little ebook.

Here’s a glimpse of what’s to come…..

So if you haven’t joined in the fun why not do so now?  If you were a test case, what would you do???

Next Tuesday we will be holding a special #dttip challenge on twitter, so look out for that.  So please give generously with your ideas and contribute to the challenge.

From Little Things Big Things Grow

One thing that I get occasionally complemented on is my writing. People write and let me know how they appreciate my writing style.

Tree Seedling

Initially this suprised me, because I do not consider myself a naturally gifted writer. In fact, quite the opposite.

Reading and Writing was always a bit of a nightmare for me. I had an elder sister who was extremely talented when it came to English. She naturally ‘ate’ her way through literature and flew through reading the Famous Five whilst I plodded through the Secret Seven. Its not that I couldn’t do it, but I could never do it as well as my older sister and that pained me.

Come secondary school, though proficient in English, I still had this niggling sense of inferiority, exacerbated by the teachers at school who consistently expected more from me, “because my sister is so good….”.

Then, the thought of writing a school essay on any topic terrified me. I did not feel I was incompetent, I knew I was incompetent.

Funnily enough, my essays reflected this skewed view of my own ability.

So I did what I normally do when faced with that type of scenario.

I gave up.

Its a strange old world, and the clock turns around and for one reason or another I started blogging about testing.

Me? Writing? My totally creative family were to say, slightly suprised.

But, I’ve been blogging for about 3 years now and it looks like I’m not that bad at writing after all.

And I am proud of this turnaround, in both my writing skill, and my awareness of my ability. Its demonstrates to me, what I can do if I just give something a go.

In fact, I have been asked and I’m in the process of contributing  to a book on testing, as well as collaborating with James Bach on a book on IM Coaching.

Its a little victory, but I think an important one.

From Little Things Big Things Grow is based on the story of The Gurindji Strike and Vincent Lingiari. It describes how the Gurindji people‘s claim sparked the Indigenous land rights movement. The protest led to the Commonwealth Aboriginal Land Rights (Northern Territory) Act 1976.

The Act gave Indigenous people freehold title to traditional lands in the Northern Territory and the power of veto over mining and development on those lands. In 1975, 3,236 km² of land was handed back to the Gurindji people.

Teaching or Learning?

Do you have a focus when giving training?

Sometimes, in my eagerness to ‘teach’ I forget to focus on something important. I forget that the lesson is about the student not me. I become more more concerned in my ability to be able to teach effectively. I want the student to come away feeling they have learned something.

Noble goals perhaps, but its nothing to do with training. Training is about the student, not the teacher.

Much more valuable is to focus on the student and provide a space for learning , giving people the opportunity to learn new things. Focusing on ‘teaching’ is about your ego. Its about you wanting to get something out of the training. I fell into this trap this week.

I wanted to ‘teach’ someone about testing. When their conclusion differed to the one I wanted them to come to, I got frustrated. “How”, I thought, “am I going to be able to teach people about testing, if they don’t learn the lesson”?

But I’m wrong. Its not about me being successful in teaching. Its about me providing a space for them to learn. In this case, they didn’t see it. That ok. Not everyone is going to learn all the time. Thats ok too.

I miss stuff all the time. I don’t get stuff, I miss traps, I fall into traps. I forget to ask questions…often. But thats ok too.

Missing stuff, making mistakes is part of what makes us human. Being human is special, its what we are all about and its something that we all have in common. (Except for Rob Lambert, I suspect he is an alien).

So, go forth and learn. Go forth and create learning opportunities. But you know what? If people don’t learn from you, it doesn’t mean you haven’t taught well. Perhaps its simply that the lesson is for another day.

That was the lesson I learned today.

Addendum

I was chatting to Pradeep Soundararajan online about training. I asked him his view on teaching, and learning. He gave some great reasons why perhaps people fail to pick up a lesson. He agreed to let me post them here:

[09/07/2010 18:16:31] Pradeep Soundararajan: Its not about people getting it always

[09/07/2010 18:16:51] Anne-Marie Charrett: how do you view it?

[09/07/2010 18:17:33] Pradeep Soundararajan: Many ways:

1: I think when people dont get it, they are helping us understand that we have probably not got it either.
2: When people dont get it, they may also have made the choice consciously. So, we don’t need to bother when we identify it was their choice to avoid getting it.
3. When people dont get it, they may require alternatives of explanation. We might want to help them.
4. Learning is not an activity that can be time boxed for everyone. For some people, they need to go back and face a few contexts to get it.
5. I have received emails from people who told they got the value of my workshop not immediately but after an year.

Thanks Pradeep, these are great insights to share.

reinventing the wheel

I liken my experience of creating an Exploratory Testing workshop as similar to recreating the wheel. It would be easy to copy someone else’s version of a wheel, after all there are a lot of great wheels out there. Alternatively, I could create my own wheel.

But how do I do that? How do you improve on the wheel?

My feelings about holding such a workshop range from massive excitement to extreme anxiety as I grapple will the question, “What the hell am I going to talk about”?

I’m not talking about the content, there as been plenty written on Exploratory Testing and I could spend weeks just reading up on other peoples articles, notes etc. If I wanted to, I could re-regurgitate lots of excellent material on the subject. But I have a problem with that approach. In fact I have two problems (maybe even three if you take into account the massive attack of self doubt I had this morning!)  with that approach.

The first one is this.

How do you teach Exploratory Testing? As James Bach writes in his article Exploratory Testing Explained and something I WHOLEHEARTEDLY concur with (through bitter experience!) is that:

Among the hardest things to explain is something that everyone already knows. We all know how to listen, how to read, how to think, and how to tell anecdotes about the events in our lives. As adults, we do these things everyday. Yet the level of any of these skills, possessed by the average person, may not be adequate for certain special situations. Psychotherapists must be expert listeners and lawyers expert readers; research scientists must scour their thinking for errors and journalists report stories that transcend parlor anecdote.

So it is with exploratory testing (ET)

The second problem I have is that

If the workshop is going to be any good, I know it has to come from the heart, my heart.

So even if I was tempted to say take James Bach’s course and deliver it (anyone who takes his course has this permission, as long as credit is given) it would be pointless.  Because I know it has to be my story, what my understanding of ET is, not anyone else’s. Its one of the reasons why James’s course is so damn good. His conviction comes through because its HIS story.

As an exercise, creating an ET workshop is a great challenge. It demands the ultimate in story telling. There is nothing better to confirm/challenge your beliefs and/or understanding than to articulate it in front of a class.

There is also nothing more humbling. It makes you realise how much I have still to learn. As part of my effort in creating this course I’m reviewing  familiar documentation again. In particular James’s RST slides.Looking at these slides in a critical way has been very beneficial. Its made me question my depth of understanding of some of its content.

Its been a good morning though. I’ve made some baby steps and have got some ideas that I feel I can call my own.

I know that the workshop is to be practical, and I have a few ideas in mind on that. The challenge is to use the exercises to teach an ET point.

What the workshop(or the wheel) will end up looking like, I’m not yet too sure. One thing I do know is that as time evolves it will become more and more my own story and yes, my wheel.

Blasting off to CAST 2010

It’s my first outing to CAST this year.

CAST has been on my wish list for a couple of years now, but with moving countries, raising kids, and earning a living I’ve found it hard to make it. This year I decided no more excuses, it was time to go.

As well as wanting to attend the conference and meet some great testers, I wanted the chance to complete the BBST Instructors course which is being held as a post conference session. I’ve been assisting in the Black Box System Testing courses for a while now. I find teaching them very satisfying and to boot, I get taught by some great testers on giving courses.

The post CAST session is being run by Becky Fielder a long time trainer and Cem Kaner. So as well as being taught by some of the best, I  get to meet them too. There is some information here on the course.

I was looking for sponsorship for this one though. There was no way I was going to be able to make it on my own. Fortunately the Association For Software Testing stepped in and have sponsored me the conference fees. So a BIG THANK YOU to the AST for that.

The Software Testing Club offered to sponsor my accommodation, so another big THANK YOU to Rosie Sherry and the crew at the STC.   The STC crew work really hard to make a genuine and real experience for many software testers.

I’ve had great support from them in so many areas, from mentoring, recruiting, publishing my articles as well as some great discussions on their testing forum.  It’s also nice to see people bringing fun into testing. I think sometimes we take ourselves way to seriously.

I’m still on the hunt for more sponsorship, so if you know of a company or association willing to support, get them to contact me. I’m happy to wear a T-Shirt at the conference, blog about how supportive they are etc. Another way to sponsor me is to offer me some work!

Below, I’ve included information about this year’s CAST. I hope you can make it!


Attend CAST 2010

The 5th annual Conference of the Association for Software Testing

August 2-4, 2010, Grand Rapids, Michigan, USA

“Skills in Testing”

About CAST

CAST reflects the AST’s core mission: to build community amongst scholars, practitioners, and students for the advancement of the practice of software testing. In 2010, CAST aims to leverage peer collaboration to build an enhanced understanding of how various skills influence tester effectiveness.

CAST offers a unique opportunity to learn and confer with others that simply isn’t found at other conferences. Each scheduled session allocates time for facilitated “open season” discussions that encourage participants to question and challenge the presentation. What takes place in the hallways, at receptions, and during meals and lightning talks truly sets CAST apart; for many attendees, the greatest value is derived from the opportunity to discuss and delve into the topics that matter to them.

Space is limited Register Today!

More information and Registration: www.CAST2010.org

We can’t wait to see you in Grand Rapids!