T is for Training (My A to Z of Software Testing, Part 12)

Over the past week or so I have been doing something I’ve never done before – Housesitting for a family who have gone to Canada for their annual holiday. The Housesitting predominately involves looking after their 9-month old dog Lexi by walking her for a couple of hours a day and keeping her safe, while also looking after the house itself. The reason I am doing this is because I am in the UK for the birth of my granddaughter Heidi, who was born just a few days ago.

So, how did I get this gig and am I really qualified to do it? I’ve never been on a formal training course for dog ownership and I have actually owned my own dog for over 30 years… It’s not rocket science, but I believe you do have to fundamentally like dogs and preferably have an affinity to them; i.e. you enjoy being around them and you both respond to each other in a positive way. I love nearly all animals and generally feel at ease around them; exceptions include the obvious ones like crocs and alligators, poisonous snakes, nasty looking spiders and sharks – pretty much anything else is cool in my book. And so it goes with software testing…. there are some very dangerous animals within the software testing world – most of them loiter on social media, so it’s not too hard to avoid them!!

But let’s get back to the Training aspect of my story. In my opinion, I can be a perfectly good dog carer/walker etc. because I grew up with a dog in our house and I underwent many years of “on the job” training. I’ve also had refresher sessions over the years caring for family and friends dogs, so I believe that my lack of a piece of paper stating that I am a “certified dog carer” is no impediment to my credentials as a professional dog carer. I know there are some of you out there who probably think I’m a bit of a “fly by night” cowboy for taking this approach, but I truly believe that on the job experience and a true passion for what I do makes me more qualified than those types who have been to the right schools, read the requisite books or attended a certified training course.

Likewise, I have worked with hundreds of proficient Testers who have never been subjected to ANY formal training in the art of software testing. Now, this doesn’t mean they haven’t trained or practiced their art either. Training can take many forms and my preferred method is to discuss a new skill and then practice it in the real world and this is what I encourage my teams to do. Learn together, train together, practice together and challenge each other to be better than they were previously. I really like the Ministry of Testing #30daysoftesting challenge that ran through July, there was no prerequisites or prior learning just a set of software testing challenges that anyone could attempt. AND the great thing (for me) was that folks were encouraged to share their work.

My personal training regime is probably more severe than most people, as I have challenged myself thousands of times throughout my life to become better at pretty much everything I do – and this obviously includes software testing. I still work out almost every day to perfect my testing skills and writing this Blog is one way of doing this. Writing about some aspect of an activity forces me to think more deeply about it and analyse why I do things in a certain way. It forces me to challenge my own thinking and seek out others thinking on the same topic. This method has worked for me in all aspects of my life and there are many cross-over advantages between topics. For example, the way I train for my cycling, choosing different types of terrain (sometimes steep and difficult, sometimes fast and flat) gives me ideas on what sort of skills to develop as a Tester, including over what length of time I should dedicate to a specific skill or activity. The scheduling of specific challenges to fit in with day to day family life is another cross-over positive. Learning when to push and when to rest are among other benefits. By the way… I don’t have a professional qualification in cycling either!!

Training for anything can be arduous and tiring but the benefits endure when the chips are down and the going gets tough. My motto –
Train hard, work hard, play hard; make your worst better than everyone else’s best“.

Dateline: Bagshot, Thursday August 4 2016

Advertisements

D is for Dauntless (My A to Z of Software Testing, Part 11)

About three years ago I wrote a short series of Blog posts that changed everything in my blogging world. It was a series that culminated with My final word on software tester certification. This blog post was read over 1,000 times within the first 24 hours of publication and to this day is by far the most read and most commented on piece I have published on this Blog. The reason I bring this up is not to self-promote but to present the context within which it was written and to also provide an up to date perspective – after all, three years is a long time between drinks!!

One of my main reasons for starting this blog was to provide real world experience from a very personal perspective – wearing my heart on my sleeve, if you like. I believe I have always done this and the certification posts have certainly come from the heart. The reason I took this approach was to (hopefully) provide an insight into real-world every-day issues that people within the software testing sector face. It was never my aim to say “this is my way and it is a good way” or “if you take my advice you will….. blah, blah, blah”.

Wearing your heart on your sleeve requires a certain amount of bravery, fearlessness, resoluteness and daring; in a nutshell, being dauntless. Some of you may not see Testers as brave, fearless, daring or resolute but for me they have come in very useful on many a day spent in the quagmire that surrounds much of our technology-driven job. It takes bravery to say “I want to stop testing (our multi-billion dollar project) because our test environments are too unstable“. It requires fearlessness to stand up in front of a board of directors and tell them (the business that they have just spent millions bringing to fruition) “I think we should give away free produce for the next three months in order to prove our processes and business model“. It requires resoluteness to tell a CIO “the software won’t be good enough to launch next week, in fact it probably won’t be good enough next year!“. And it requires daring to ask the sponsors of a major logistics company rebuild that “I want to spend some of your budget buying toy trucks and model trains“.

I have done all of these things I describe above during my software testing career and all of them were accepted and each contributed significantly to successful software implementations.

My main reason for sharing these stories today and writing about being dauntless was driven by several recent blog posts that I have read where people seem to be frozen by fear or constrained by controversy. If you believe (and can prove beyond reasonable doubt) that a specific action (no matter how wacky or left-field it may be) is the best option available – go for it and be DAUNTLESS. It will give you the strength and confidence to strive to make a difference. It will show the rest of the software development structure that software testers bring a perspective that can add millions of dollars to the bottom line of a business. It will give you the strength to remain resolute and become a better Tester….

Dateline: Bagshot, Monday July 18, 2016

A is for Apathy (My A to Z of Software Testing, Part 1)

The other day I was watching a fantastic discussion on SBS TV regarding one of the fastest growing epidemics in the western world – Type 2 Diabetes. The discussion centred around claims made by UK-based TV presenter Dr. Michael Mosley, who has recently published a book based upon scientific evidence (provided by another UK based specialist) that we can now reverse the symptoms (and sometimes cure) Type 2 Diabetes. There were many Type 2 Diabetes sufferers in the studio audience and they were all asked if they would follow the dietary regime prescribed in Dr. Mosley’s book (800 calories on food per day for 8 weeks), if it meant that their Type 2 Diabetes would go away. At this point I should highlight that Type 2 Diabetes can cause blindness and limb amputation to name but two rather nasty issues. It can also lead to death at a much earlier age than expected for your socio-economic group. On top of the book/study evidence there were other audience members who had reversed/cured their Type 2 Diabetes just by changing their diet.

The body of evidence for reversing/curing Type 2 Diabetes seemed pretty damn strong to me. The option of changing ones diet (and, remember, in Dr. Mosley’s book for just 8 weeks) also seemed pretty straightforward. So, I was completely gob-smacked when the majority of Type 2 Diabetes sufferers in the audience said they would NOT consider changing their diet to reverse/cure their illness. To me, the thought of going blind, just so that I can continue to eat a MacDonald’s whenever I felt like it, seemed ludicrous in the extreme, but people in the audience (who appeared to be of, at least, average intelligence) seemed more than happy to continue along a path to more pain and suffering. Surely, the evidence was strong enough. Surely, the likely adverse outcomes were scary enough. Surely, just changing your diet for 8 weeks was worth the effort….

To me, this story is akin to hundreds of discussions I’ve had over the years with people who don’t respond to the software testing is good for you body of evidence. If an above-average intelligence human being is comfortable with going blind, just so they can continue to eat their favourite ice-cream three times a week, then what chance do we have of convincing someone with a similar belief system to spend time and money testing software.

I have spent hundreds of hours building Business Cases for software testing initiatives only to be told – “We can’t afford it” or “My business partners won’t agree to delaying the launch of our product”. I have spent even more time demonstrating likely (non just worst case) scenarios for adverse outcomes, if insufficient testing is performed, and still I get the cold shoulder!!

So, what is it that causes rational, intelligent human beings to ignore scientific evidence and obvious personal/business risk and take a punt on Lady Luck? In my experience there are many reasons, but the most common are ego and apathy. Ego rears it’s ugly head on so many levels when it comes to decision making – especially among alpha males – and there usually plenty of those of major software projects. I can usually deal with egos (in fact it’s quite easy to manipulate someone with an oversized ego) but apathy is another story. Apathy has no energy to tap into. Apathy is like a black hole in the solar system. Apathy is usually catching, in that it spreads like a fungus throughout organisations. Apathy is the half-brother to cynicism. Apathy sucks the life-blood out of people.

In my experience there are two options when it comes to dealing with apathy. The first is to just walk away and let some other poor sap waste their time and energy – I’ve certainly done this in extreme situations where my best efforts were wasted/ignored. The second option is to provide real life examples (based upon the context within which the organisation is operating) of what will happen when a specific problem is encountered. The most effective way I have found to do this is to model the business (or part thereof) and create the adverse outcome deliberately and then watch what happens when the penny drops with those present. I’ll share an excellent example of a challenge I was having with a logistics company where I was having trouble getting sign-off for a specific set of test scenarios for their delivery drivers….

We wanted to conduct a series of tests relating to the vehicles’ GPS. The client believed that the technology was solid and proven and that no specific testing was required. I then created a situation where the GPS failed at 4pm on a Friday afternoon during a completely separate set of physical tests with the delivery vans. Six drivers were on the road in various parts of London at this time and we were able to crash all of the GPS devices remotely. What happened next was priceless. Only one of the drivers (a woman) followed the training they had received and called base for instructions. The other five drivers (all men!!) tried to navigate their way to their next few deliveries before returning to base. None of these five drivers completed their delivery schedule. All of the drivers were late with the deliveries they had scheduled and when we contacted the (test) customers later all said they would have cancelled or thought seriously about their future buying intentions. They also all said that they would have accepted later deliveries if they had been warned of the problem. This example ended up being a combination of both of the issues I mentioned earlier – ego AND apathy. Ego reared it’s head with the drivers not believing that they needed to ask for help and apathy came from the head of logistics.

In truth, I didn’t expect such a spectacular fail, but from that day on I had no trouble convincing the heads of departments regarding the test scenarios that we planned to initiate.

Dateline: Melbourne, Tuesday March 8, 2016

Will my Robot be the first Non-human to gain ISTQB Software Tester Certification?

It occurred to me the other day that, if I am to get my new Robot to become an effective software tester, what better way to begin it’s development/education than to sign it up for an online ISTQB Foundation training course and corresponding ANZTB-facilitated (Foundation with Agile extension) exam. After all, almost 400,000 software testers worldwide have attained ISTQB Foundation certificates since 2002 and they tell me that is the de facto standard in software testing certification qualifications.

I chose the online option of education for a few reasons, but primarily because I believe that my Robot will get bored stiff if it has to go at the (slower) speed of it’s human counterparts. There is also the possible risk of classmates being distracted by a superior being in their midst. The exam will obviously present only a minor challenge, as multiple choice questions are the easiest assessment type for a robotic assistant to master.

I have a few of my own education tools to assist Robot; these include my world-renowned MindMap of the ISTQB Foundation Course (with Agile extension). In addition to this, Robot will be availing itself of the myriad of online content available via websites like istqbexamination.com and testingexcellence.com that provide substantial supporting materials that include sample exams and questions.

I am obviously very excited to be able to give my Robot some real world insights and experience (via the world renowned ISTQB Certification program) and will be assessing the rest of the ISTQB portfolio once I have been able to quantify the impact the Foundation Course has on Robot. Of course, Robot will be acquiring knowledge from many other sources, but I see the ISTQB Foundation offering as an excellent starting point. The next Foundation Exam in Melbourne is scheduled for October 27, so I should be able to share the results with you all by early/mid November.

If any of you know of other Robots that have completed the ISTQB Foundation training and subsequently sat (and passed) the exam please let me know as I would like to include the details in my November Blog update.

Meanwhile, in other news, Robot and I had our first outing on Melbourne public transport. Robot used it’s newly minted Myki pass. Myki is the travel smart card system we use in Melbourne and allows us cash free travel. This is ideal for my Robot, because as yet I have to agree a weekly allowance with it. We travelled into Melbourne CBD late Wednesday evening, in order to attract as little attention as possible. The bus driver was a little taken aback at first, but was more than happy once Robot was able to produce it’s own Myki card. The tram system is our next challenge and then possibly a rail journey when we attend the ISTQB Exam. I’m not so sure about air travel at the moment though, as we will probably have a few issues with the security detection systems at the majority of airports. I’m also planning on a supermarket visit to test out Robot’s built in bar coding system; 24 hour trading and automated checkout will aid us in keeping a low profile.

Meanwhile, on the software upgrade front, Robot has just been upgraded for iOS9, in order that all my “i-gadgets” remain compatible. This is crucial for links into major Siri, Safari, Mail and Calendar updates. I’m also working with our Electricity provider on Smart Meter compatibility in order that Robot can become the main interface with all our electrical appliances. An iWatch is also on the cards right now, but it’s physical range constraints may be an issue. I’d seriously forgotten how time consuming Software Release Notes can be!!
Anyway, gotta get back to coding my ASX Share Price Tracking and International Currency Exchange interface feeds. More updates soon….
Dateline: Melbourne, Thursday September 17, 2015

I’m a Software Tester Jim, Not that you’d know it

“Dear Jim,

A few years ago I became a Software Tester and being the diligent person that I am I searched for a formal qualification to cement my intentions. My manager at the time pointed me in the direction of ISTQB, citing “hundred’s of thousands of professional testers worldwide are certified by these guys”. I took this on board and attended a local Foundation-level course run by Disqover and a few weeks later I had this lovely certificate to show for my efforts. What has transpired since has me perplexed. I have been reading lately that my efforts to legitimise my professional standing have labelled me a factory tester and worse still un-thinking. Jim, what does this mean and how can I get myself back on the straight and narrow?”

Confused of Clayton

Dear Confused,

I feel your pain from the lofty heights of my ivory tower and I sympathise with your apparent plight. It can be a minefield out there. All that software to test. All those bugs to find and schedules to meet. And then there are those pesky morning stand-ups and retrospectives that get in the way of your real work. And then they tell you your certificate should be consigned to the toilet.

I think the best way for me to address your question is to tell you a short story about a friend of mine we’ll call Scotty (her real name is Brianna, but I’m using data masking software to hide her true identity).

When I first met Scotty she was a bright young thing, fresh out of one of those high-flying Consulting businesses with a three-letter acronym, a sexy logo and Nespresso coffee machines in every meeting room. Scotty was going places and she was in a hurry. She would come to my desk (if she could find me among the myriad of hot ones we inhabited at the time) with questions like “What’s the difference between a stack overflow and a memory lapse?” Boy, I still long for those doozies. I’d seen her type before. They came to our company, fresh as a daisy in spring and within 6 months they were drained of all colour by the constant 18-hour days with only pizza for company at a client site basement in the Western Suburbs.

Anyway, I digress. Scotty wanted answers and more than I could give her and so we talked about outside help. I’d heard rumours that there was a new movement afoot called a Meetup, where like-minded souls shared their experiences and provided guidance and hope. It also had a three-letter acronym, so she would feel right at home. Scotty was off like a pig in muck, googling this, googling that and coming back to me with stories of liberation, not consternation. She attended every Meetup she could find, joined online chat forums, watch countless TED videos and old Conference presentations until one day she came to me even greyer and more exhausted than ever.

“Someone just called me a factory tester in a tone that sounded like an insult. Is that a bad thing?”

Oh no, not that old chestnut I thought. So, I carefully explained to her that there were many people out there in the world of software who were sometimes a little over-zealous with their beliefs and that they didn’t mean any harm they just wanted the world to know that there is a better way. I went on to say that there will always be a better way, but that you have to find your own better way and not be swayed by zealots and evangelists. I then invoked the “when you’ve been around as long as I have” clause and explained that while they may dress up their ideas in clever language and silver bullets none of their ideas were new, they were just contextualised slightly differently. After all, I was using mind-maps and post-it notes over 25 years ago and didn’t think twice about commoditising them.

So my moral (if you’re still with me through all those mixed metaphors and blind alleys) is – be yourself, don’t follow the latest fads or trends and stick to the science. Oh, and one last thing… Don’t think because you don’t write code your value is any less.

Until next time.

Auntie Jim

Can We Predict Outcomes or are we just Wasting Money?

Many years ago I watched an incredibly funny comedy sketch in which John Cleese played the part of a merchant banker. He was busy at his desk when he was approached by a rather nervous spotty youth who asked Cleese if he would like to part with a small sum of money in exchange for a colourful metal pin in the shape of a flag. “Is it a share certificate?” asked Cleese. “No”, replied the spotty youth. “Will it provide me with a return on my investment?”, Cleese continued. “Not as far as I can tell”, spluttered the spotty one. “Will I be able to pass it on to my children, as part of their inheritance?” The youth was visibly shaking as he provided another negative response. “So, what is the point of it” asks an exasperated Cleese. “Well sir, it will help poor families in Africa have a better education”. “But what about about the education of my family….”. The sketch descends towards pythonesque oblivion, but burns itself into the hearts of millions. The irony is peerless. The timing perfect. The utter dejection of the spotty youth palpable.

For me, there is a similar real-life scenario, where seemingly intelligent people walk up to complete strangers, give these strangers a little slip of paper (with a horses name on it) and accompany said slip of paper with a random amount of cash. These optimistic souls then stand around for the next four or five minutes while a handful of horses (ridden by men with high squeaky voices) coax them into a box and cajole them into running faster than any other horse in their vicinity. The fastest horse provides those fortunate to predict this outcome with a return on their outlay. The return, though, doesn’t always live up to expectations. That’s why it’s called gambling and not investing.

I need to declare right away that I do not frequent race tracks or betting shops and I don’t apportion money to an animal that I’ve never seen or heard of, in the hope that my bank balance will grow. Having said that, I’m also very different to the John Cleese character mentioned earlier. I spent thousands of hours as a kid playing card games and learnt how to count the cards in a deck. It gave me a healthy respect for prediction vs gambling. It also helped me understand the odds of a particular outcome occurring – like the expected result of a software test I may undertake.

It fascinates me that we are so certain of software testing outcomes that we generally document a single outcome when 10 probabilities/possibilities may exist (if only we took the time for more creative thinking). If I walk up to a computer and press the ON/OFF button any one of 20 possible outcomes may occur. However, I have seen predicted outcomes confined to “computer login screen appears“.

John Cleese’ character (in the comedy sketch) wasn’t questioning the spotty kid because he was a tight ass, he was purely applying his standard risk profiling techniques before parting with his hard-earned. I think it’s far more interesting for those learning the basics of software testing to look at our challenges from a non-technology perspective. They are far more likely to remember their application and importance.

Tomorrow, those of us fortunate enough to live in and around Melbourne (Australia) will enjoy a public holiday in order that we may join around 100,000 other hapless souls at the Flemington Racecourse for “the Race that Stops a Nation”. Mind-boggling as it may seem, we really do have an annual public holiday in order to celebrate the running of a thoroughbred horse race. It is a marketing executives’ wet dream – 100,000 suited, booted, fluted (and soon to be looted) race-goers. I will not be one of several million Australians lining the pockets of a large multinational on the chance that I may double, triple, quadruple (etc) my money. Instead I will send $40 to the SIDS and KIDS charity and expect no return on my investment.

Dateline: Melbourne, Monday November 3, 2014

Dead Serious

What would you do if someone died while testing the latest software release? I mean really died. Went into the Test Lab, turned on one of the newly configured test computers and then dropped stone dead moments later….

What would you do first? Would you call an ambulance of call a triage meeting to determine if it was a User Error or a bug in the software? Would you perform CPR?

There are thousands, sometimes millions of possible outcomes when we test software, but a dead person rarely ranks as a expected result!! If the expected result was “someone dies”, who would you assign to the task? Your least experienced or your oldest Tester? Would you insist on testing it yourself? Would you train a mouse or a chimp to perform the tests?

This may all sound a bit macabre, but there are scenarios where poor software testing has resulted in a real live User no longer being a live User. Power lines are governed by switching software and if the appropriate switch is set incorrectly (when the maintenance guy shows up to fix a power line fault) he may end up fried like an onion on a barbie.

Considering the test outlined above is a simple binary (on/off) test, you’d think it would be easy enough to get it right, but the truth is, even the simplest tests can go wrong.

Let’s look at another scenario – a gondola at the local ski resort crashes to the ground (with 15 people on board) when the software driving the system fails to recognise an overweight scenario. What would you do? Sue the Programmer? Sack the Tester? Go to another ski resort?

I’d be very interested to hear from anyone who has ever written a Test Scenario/Test Case where the expected result is – “someone dies” or “you don’t want to know what happens next”….

Dateline: Tuesday February 18, 2014. Melbourne

No animals were harmed during the writing of this Blog.