Discipline

Discipline is hard. Discipline is being responsible for your own development. Discipline is not letting your manager or employer organise all your training needs. Discipline makes you stronger.

But discipline can be fun too.

Have you attended a weekend or weeknight testing event? I’ve attended a few weeknight events recently and they’re great training opportunity to develop as a tester. The events provide an environment where you need to think on your feet as a tester, practise testing techniques and where you need to articulate your thoughts from test planning to reporting issues you’ve found. All of this without the fear of failure as it really doesn’t matter if you miss a bug or say something stupid, no one is going to bring it up in your next performance appraisal. It’s a win-win-win situation (the third win is because it’s a fun event – #WIN!)

Here’s a little badge I drew for the weekend testers to celebrate their 50th event anniversary.

Risk Based, STC and Recruitment

Today's cartoon was first publish in The Testing Planet, issue 3.
You can see two brand new cartoons in the latest issue, which you can order from Amazon.

Just to let you know, I'm looking for a tester to work in my team, here's the job advert. Please let me know if you're interested and forward the link to other testers - many thanks!

Just looking

When I try to explain what I do as a job, I have a nagging temptation to make it sound like I'm really clever and I do complex stuff at work, something like "I test the web application’s functionality running on handheld mobile electronic devices is displayed within the device parameters and each feature is correctly implemented according to detailed requirements and strict industry regulations". Of course, by the time I've said the 2nd word "test", I can tell I've lost their interest!

Ignoring the fact that we sometimes try to exaggerate our skills and knowledge, I'm a firm believer that software testing, when done well, is hard. But having said that, sometimes you can find bugs in software without clicking any buttons. There are times that testing looks very simple, especially if you’re watching an experienced tester do some testing. The tester might come across as just looking or playing with the software - anyone could do that they’re doing!

I think this can similar to sports men and women who are at the top of their sport. Whenever they swing a golf club, kick a 40 yard ball, or spin a ball with great precision, they make it look so easy as if anyone could pick up the sport and be a pro without blinking. A professional goal of my mine is to be like these sports men and women but in the software testing world. Whenever I attend a meeting where they are asking for my advice, or where I'm performing a few quick tests on an application or I'm the main tester for a large project, I want my every interaction to look good yet easy. I want to test software and find bugs by just looking, or so it would seem to the onlooker.

That's funny

From other cartoons and following on the twitter-sphere, you may have noticed I like exploratory testing. This testing is not a technique but an approach, a mind-set to testing, it's often contrasted to scripted testing but it's not as simple as saying they are opposites. 

At my last two work places, I've introduced a more exploratory style of testing, but the fact is they were already doing it without realising. What I introduced is making the exploratory testing more visible and manageable so clients could see the testing that was performed. 

The major reason I like exploratory testing approach is that I believe it is a more natural style of testing. With scripted testing, especially the scripts which are highly detailed, the tester has to follow the script when executing them. By doing this, they may miss out on other bugs in the software since the script does not require the tester to check for this. This is specially the case for lay out and usability issues. Issues which in the past may not have been business critical but are now increasing becoming so. If you have an awkward, unintuitive software application, users will be turned off by it and look for alternatives. With good exploratory testing, the tester is well equipped and use heuristics or guides to remind them of areas to look at. 

Cem Kaner originally came up with the exploratory testing term and James Bach has developed the approach and provides training to develop exploratory testing skills. One heuristic that has triggered many bug finds is the "that's funny" heuristic. If you are ever using or testing an application and you notice something strange or you have a gut feeling something isn't quite right, then keep searching, you might find a bug!

Peeping Toms

According to Wikipedia, the fountain of all knowledge, a scientist engages in a systematic activity to acquire knowledge. When it comes to software testing, I feel this description of a scientist applies well to the day to day activities of a tester. For example, a tester, with varying degrees of structure, will systematically test the software, through these actions, the tester will learn how the software behaves, so acquiring knowledge. From this new knowledge, the tester can assess if there are any issues which he raise to the project team.

At school, during my science lessons, the teacher will ask the class to come up with an hypothesis, we would then have to test this hypothesis to confirm or reject it. Again, this isn't very different at all to testing. For example, when testing a login screen, I might come up with an hypothesis that the login screen will accept my username without a password. I would then test this out to check if my hypothesis is right (hopefully I'll be wrong!). If time permits, I could create new hypothesis and continue to learn about the software I'm testing. It might do these actions in parallel, I come up with hypothesis and test them out at the same time (a more exploratory style of testing) or I might write the hypothesis down, as in test scripts, and execute these tests at a later date. Either way, it's testing using a hypothesis to drive the testing.

Another aspect of using scientists as an analogy to testing, is the fact the they need to keep many variables constant. In testing we often do this, sometimes without being aware of it. When first testing the login page, let's say it's a web app, we would keep the browser and version constant to test the main features. If it works on one browser, we may choose to test on other browsers, or possibly try out some performance testing by adding the number of users already logged or trying to log into the web application.

James Bach came up with a short definition for testing: "testing is questioning software". By questioning and gathering the answers from using the software, we learn more about the software and where the bugs may be hiding. Here’s a definition of my own (taken from Mr Koestler), “Testers are the peeping toms at the keyhole of software”, ok, it’s not as good, but hopefully the point comes across J

Busy

I'm a person who loves the technical side of testing. When allowed, I like to get under the cover and look at the code I'm testing. Not that I can always understand it, but the code may trigger new testing ideas to investigate.

On a similar vein, I enjoy using test automation, I particularly like to write code for automation. In my current post, I've been given the opportunity to learn Selenium, an open source web based test automation tool, I'm using C sharp and nUnit to drive the testing. It's been fantastic! I love it! It gives me great pleasure to see lots of checks flying through the web app under test. I say 'checks' because that's what they are, lots of checks. If I code a check for the title of the web browser, it will check the title of the web browser, not anything less nor anything more.

You may already know that test automation would never replace the testing capabilities of a human being, especially a human being who knows how to test. This is something I need to be reminded of on a regular basis. Since I love test automation, I could spend days writing code for a sharp looking automated regression test and forget to spend a reasonable amount of time testing new functionality, highly used features, critical areas of the software.

As a tester, it's important I continually assess the benefit of the work I'm doing. Is what I'm doing the best thing or should I be doing something else right now? A problem with automation is it can provide a false sense of achievement. Like I said, it's just checking, and often doesn't find as many defects compared to manual testing (the last sentence was an understatement). Michael Bolton was the first person to highlight and describe the differences between checks and tests. You can read more about the differences on his blog posts.

Become your enemy

In the world of software testing, there are many testing techniques. The primary objective of a testing technique is to help the tester do some actual testing. Every technique has its strengths and its weaknesses. Some techniques can help decide who does the testing (e.g. unit/user/beta testing), other techniques can help identify which areas to test, but not one technique can help in every way.

One technique that gets a lot of air time in the software testing industry is Risk Based Testing (RBT). There are two ways that RBT is used and described. One is where you have a set of tests in mind and you use a risk approach to prioritise the tests. The higher the risk, the higher the priority and the sooner you execute the test. The second way is when the tester (or project team) generate a set of risks that may apply to the application under test, and then they test the application to see if the risk does apply (please Google RBT if you want a longer and better description). The thing that annoys me about RBT is that some people think it’s the be end and end all. It’s not, it’s just a technique, an approach, it has its strengths, but it also has weaknesses. For example, it’s not very easy to get a reliable idea about feature or code coverage using RBT. You might have good coverage on the risks, but you may be concentrating on one area of the functionality. The risks themselves are heavily influenced by the people or testers analysing the risks, so you could end up with a narrow focus (tunnel vision) of the risks. Another weaknesses is that RBT doesn’t tell you how to actually do the testing – should it be heavily scripted or use a more exploratory approach. Also, who’s to say the risks are realistic, maybe the risks are too farfetched.

With that in mind, I want to introduce the perfect software testing technique. As far as I know (and I know a lot), this technique has no weaknesses, it is pure strength! The technique is called “Know your bugs” © 2011.

With this technique, the tester images or visualises how a bug could appear in the application (the tester becomes the bug). With this in mind, the tester executes a test to confirm or reject the bug exists. Pretty simple really. And please don’t confuse this technique with RBT, it’s totally different.

Anxiety

"Why didn't you find this bug?", "Why didn't you test that?" These questions can drive a tester to madness with worry, stress, fear, the sort of feelings that often get tagged as negative feelings, the ones to avoid. But feelings aren't negative or positive in themselves, is how you react to them.

As a dad, there are times when I worry for the safety of my children. Some of these worries can seem very real, and the worry quickly changes into a fear. Typically, this changes how I act or react as a father. I would hold on to my child a little more tightly. I would keep an eye on them a little bit longer. I would instruct them a little more clearly. All this is good, in fact, is in our genes. As parents, we want the best for our children, This includes their safety, as well as their education, security, etc. The trick, and it's a very hard trick to get right, is knowing where the parenting stops and the independent child is set free! That's something I will need to learn.

In software development, the worries and fears are altogether different to parenting, but worries and fears they still are. There is no excuse for a toxic working environment, where management in-still a blame culture. But even in healthy working environments, testers, including myself, can feel worried that, once the product is in Live, a bug will pop its ugly head when it could've been spotted during development. It's how we react to these thoughts that will indicate how we're going to survive as testers. Are we going to be down-and-out testers? Or live-for-another-day testers?

When you start your next test project, when preparing the test planning or attending the first project meeting, ask yourself "how do you want to feel the moment the software is put Live?" My response is "A modest confidence I did my best as a tester". From here, I would go and learn about the application, ask questions, be a team player, do my upmost to find important bugs quickly and communicate my findings to the project team.

My final point goes to those who don't ever feel worried: one day you might wake up… just saying…

Fishing Tales

Hi one and all,

Once again I’ve failed to update this blog.

I wish I had a good reason for it, but I don’t.

As a way to get your favour back, I’ve decided to post a totaly brand new set of cartoons on this blog. The plan was to print them in an e-book and sell it through Amazon but I changed my mind!

The new cartoons are based on the experiences of cats trying to catch mice. The Cats and nice is an analogy of testing where testers are trying to find bugs, but please note, I’m not calling all testers cats nor all bugs mice. It’s an analogy, it only applies to a point. Most cats are cute, most testers are… well, you get the message.

With each cartoon I have added a quote that I think relates to testing. I got the idea of using quotes from a Twitter hashtag – #ihatequotes !!

Like all previous cartoons, feel free to use the new cartoons in presentations, but please contact me if you plan to use it in merchandise or magazines.

Alongside the cartoons, I will share some of my experiences in testing. I hope it comes in useful.

Over the coming weeks I’ll be posting the Cat and Mouse cartoons, stay tuned :o)

Before all that, here’s one of my favourite cartoons, it was printed in the Testing Planet at STC. I like this because of two reasons: One, it took a number of drafts before I was happy with it; two, it’s an area  in testing I feel I need to improve on – selling the testing tale!