Are you a Comfortable Tester?

Having been a tester for over a year now I am beginning to feel comfortable with the role.  But is this a good or a bad thing?  It depends what is meant by comfortable.

If comfortable means doing the exact same things in the same way every day then that is not a good thing in my book.  Perhaps you are a poor soul who has not been given the opportunity to do anything other than test scripts from which you must not deviate.  In this case I sincerely hope you are not comfortable in your role.  If you are then you are unlikely to progress very far in the testing industry.

When I say I'm getting comfortable I am not talking about things becoming easier because they are repetitive.  Of course, there are always some things you will have to do in a certain way, such as Bug reports; need to contain all the relevant information, and Gherkin tests (should always be written in the Given, When, Then format).

My comfort comes from gaining a better understanding of the product, the environment, the people, the resources, and test techniques.  That is not to say there is not still a lot to learn in all of these areas.

One prime area where complacency can easily happen is regression testing.  Our product is continually changing so we can't stick with the same tests every time, I have to adapt and update regression tests to match the product state.  Do this by removing tests no longer needed and adding new tests for newly coded areas.  Obviously this is not a black and white task.  It can be tempting to remove tests which always pass.  It is not always clear from the outside what parts of the product are interlinked so you can never make assumptions that some tests will always pass.  Sometimes it might be better to think of the product from a black box point of view as if you are a customer who has never used the product but is tasked with testing as many areas a possible.   It can be a dangerous trap to fall into to think you know the product inside out and therefore do not respect the possibility of unforeseen change.

I never want to feel that I know it all and that there is no need for me to keep learning.  I think your days are becoming numbered as a tester as soon as you start to feel this way.  I believe the test industry is one of the fastest changing industries in existence so you can never rest on your laurels.  I always want to be reading about the latest test techniques and tools and spending time with people from whom I can learn more.

So for want of a better phrase I believe to be a good tester you should always try to remain slightly uncomfortable.

The Invisible Gorilla - Book Review

I have recently finished reading 'The Invisible Gorilla' by Christopher Chabris and Daniel Simons.

It was quite an interesting read and contained many (perhaps too many) examples of where we can make assumptions and fall into traps.   This is largely because we don't analyse our views as thoroughly as we might and therefore can fool ourselves into believing we have all the information we need to make an observation or decision.  On reading this book I've realised that much of what we see and experience in life, as well as testing, is not always quite what it appears on closer inspection.  I don't think the concept of WYSIATI (what you see is all there is) is referred to in this book but it sums up a lot of what the book describes.  We must sometimes look beyond the immediately obvious visual information as what we see is not always the full picture.  One of the reasons we fall for it even when we are aware of this shortcoming is that we are right the majority of the time in our initial assessment so we have less reason to believe that sometimes we will be wrong in our judgment.  Below I've written about some of the main areas covered in the book.

Confidence

Confidence can be mistaken for an indication of the accuracy of someone's statements.  Equally, a statement delivered by an individual with low confidence can come across as less believable even if they know exactly what they're talking about.  So it's important not to base our own confidence in others statements on the confidence of their delivery or demeanor.   It's better to make a decision based on a fully informed assessment of the facts rather than the opinions of the most confident or highly ranked.

Familiarity

Another trap we can fall into is believing we know more about a subject than we actually do.  For example, if you were asked if you know how a bike works you are very likely to say 'Yes'.  But if you are asked to actually describe technically in detail how the brakes or gears work you would find this a lot harder.  This made me realise that understanding the general concept of how things work by no means makes me an expert on the subject and made me realise how much I don't know.

Memory

The illusion of memory is another area covered and describes how we often we fill in the gaps in our memory with fictional details and this is not always deliberate.  Recounting of an event may also change each time it is recalled even though we may be confident we know exactly what happened each time the story is told.

Correlation and Causation

I believe we can all be guilty of making conclusions based on associations where two events happen at the same time or one just before the other.  It seems perfectly natural or almost expected to make a link between the events where there may not necessarily be one.  Even when two events consistently happen together they may not be causal or related; there may be a third event which happens leading to the first two unrelated events to happen.  Since reading the book I've noticed that news reports will make very suspect associations such as these with very little concrete evidence.  They use phrases such as 'may be linked' or 'there could be a correlation between'.  I found myself feeling infuriated with this where before I wouldn't have given it a second thought.  Especially when they suggest questionable links in relation to health and disease, causing unnecessary worry for the public.

In relation to testing, all of the points made in the book are relevant and it is a very good idea to keep them in mind when making observations.  This is important not only of software but also of other people and also to be aware of our own assumptions and interpretations of events.  I highly recommend this book to software testers as it should make you think differently and make you take your time rather than relying on your first impressions.

Personas

Rather than testing in the same way every time it can be a good idea to use the product in the way a certain type of person would.  For example, use a website as someone who only uses the keyboard to navigate, so all actions have to be done without the use of a mouse.  Or as someone who always changes their mind, so keep using the back button to revisit pages.  The first is likely to reveal accessibility/usability issues and the second could reveal innaproproate caching issues.

I realised the other day that if you can fully get into character then you can really experience and act out how certain users would feel using a product and thus reveal flaws or bugs which you otherwise might not discover.

What follows is a description of my findings when I adopted a persona to test a website without even realising it.

Last Tuesday I wanted to order 2 pizzas from Pizza Hut for my wife and I and I wanted to do it as soon as possible, in whatever way possible, and as cheaply as possible.  I was very hungry and when I'm hungry my patience is severely reduced and any small frustrations are magnified.
So I wanted to get my order in as quickly and easily as possible.  Was Pizza Hut online going to be up to the challenge?

So the first thing I did was Google Pizza Hut.  Up came a link to the Pizza Hut menu. Clicking this took me to a menu for all their pizzas which seemed like a good start.  However, although I wanted Pizza fast I also wanted a good price and that meant getting the best deal I could.  On the page there was no clear indication of any offers available.  I didn't know where to find the deals so I gave up (remember, I was not in the mood to spend time searching around) and clicked on the 'Order Pizza' button, this took me to a page to select whether I want to Order for Delivery or Order for Collection.  I chose delivery and selected the delivery time.  Then I was taken to a page where I could select DEALS, Pizzas, Sides and Dips and Desserts and Drinks.  Why did I have to get this far before I could find out that any Deals were even on offer??  So I clicked on Deals where I was presented with 11 different deals, including Buy 1 get 1 half price, £21.99 Medium Super Saver - 2 medium pizzas and 2 sides, £25.99 Medium Full Works for 2 medium pizzas, 2 classic sides, 2 desserts and 1 drink, Two'sday Tuesday - Buy one pizza get one free.  Luckily for me, and for Pizza Hut, it was a Tuesday so I could get the best deal of 2 pizzas for the price of one.

So I chose a large Stuffed Crust Cajun chicken Sizzler for myself.  This showed the Total cost of £17.49 in the 'Your Order' section of the screen.  I then ordered a large Stuffed Crust Super Supreme at £19.49 for my wife.  The only problem was the total for my order now showed as £36.98  'How much??' I said out loud, 'Where's my 2 for 1 deal gone?'  'You've just told me I'm getting a 2 for 1 deal and now where has it gone??'  Maybe I'd pressed the wrong button or missed something so I pressed the browser back button a couple of times.  I was hoping this would take me back to the page where I could restart my order and empty my basket.  I was back at the menu page but my basket still showed £36.98!  'How do I empty my basket!!'  By this point I was really getting annoyed and losing the will to live so I clicked the Checkout button below my basket total.  This took me to another page where miraculously my deal was taking effect and a -£17.49 showed that I would only be paying for 1 pizza.  'Why couldn't they give me a clue I was doing the right thing on the previous page??'

Anyway, from here I managed to pay with my debit card with no disasters and my pizza even arrived on time.

From a testing point of view I found the 3 issues below:

Caching my choices and keeping them in my basket
Back button did not take me back to the original page
Price with offer was not shown until checkout button pressed

I'm not sure if any of these would be classed as a bug but it depends who's definition you use.  I would include Cem Kaner's definition of a bug as 'something that would bug someone that matters', i.e. the customers.

The number of customers these issues bug and the financial impact associated with potential loss of sales is probably the more important question.  Also, does the cost of fixing these issues outweigh the financial gain of keeping the sales?  Product managers are the ones paid to answer these sorts of questions but they are interesting nonetheless.

In conclusion I found it very interesting looking back on the persona I had briefly adopted.  It really changed the way I approached the website, which on another less hungry day, would have caused me no angst at all. More importantly it would possibly not have lead to me noticing any or as many issues with the way the site worked.  I will aim to think up other personas for future use with my testing because, as demonstrated here, it will help find new and interesting software quirks which could otherwise be overlooked.

Context Switching and Multitasking

Although not specific to testing I feel that software development, particularly in an agile environment, can lead to a lot of inevitable priority changes, sometimes several times a day.  Depending on the urgency of the new priorities this may mean people have to immediately stop focusing on whatever task they are currently involved with to start working on the latest precedence.

This change of attention from one task to another is known as context switching.

The Wikipedia definition of Context Switching refers to computers rather than humans but I feel the definition below can equally apply to people.

A context switch is the computing process of storing and restoring the state (context) of a CPU so that execution can be resumed from the same point at a later time. This enables multiple processes to share a single CPU. The context switch is an essential feature of a multitasking operating system.

Wikipedia also has the following definition for human multitasking:

Human multitasking is the best performance by an individual of appearing to handle more than one task at the same time. The term is derived from computer multitasking. An example of multitasking is taking phone calls while typing an email. Some believe that multitasking can result in time wasted due to human context switching and apparently causing more errors due to insufficient attention.


The notable word in the paragraph above is 'appearing' as I think multitasking, by definition, means one cannot devote 100% of one's attention to more than one task at a time.  As I write this I happen to be watching Match of the Day 2 and I know that this blog is taking a lot longer to write than if I was not looking up every time a goal is scored!  A perfect example of how not to multitask.  In my opinion multitasking is rarely effective, where a focus of attention is required, in achieving time saved and a better quality of work, than working on the same tasks sequentially.

A very important aspect of context switching is not the fact that what you are doing changes, but the fact that some amount of time is used up in getting your mind into a state of focus and readiness for the new task.  In testing, this may extend to getting your environment set up for the new task as well as having to start thinking about something new.  With several context switches per day this wasted time can soon add up.

Interruptions can come in many forms such as meetings, background conversations, questions, lunch, phone calls, and e-mails to name a few.  There are measures you can take to minimise these interruptions such as wearing headphones and turning off e-mail.  Some people use The Pomodoro Technique so they should be left alone for at least 20 minutes at a time.

Personally, I feel  there are positives in having at least two things to work on (but not at the same time) so that if what you're working on becomes blocked then you can start work on the second.  The key is to remain in control of this switching so as to limit the time 'wasted' in re focusing on the new task.

One of my weaknesses (if it can be seen as such) is that I find it difficult to say no to someone who asks me to look into something for them.  Sometimes I even welcome the interruption if I happen to be stuck in a rut with what I'm currently doing.

Going forward I feel I need to be more aware of my own context switches and I will be trying to reduce these only to those which are absolutely necessary or beneficial, and I would urge everyone to do the same.

Are Two Testers Better than One?

This sounds like a rhetorical question but the answer is not quite as obvious as you'd think.  By better I mean more productive in terms of doing more useful testing, uncovering more bugs and getting more product coverage.

A more interesting question I'd like to ask is 'Are two testers working together, i.e. pairing, better than two testers working independently?'  I often see it working for developers in helping each other avoid mistakes so why not do the same with testing to increase the numbers of mistakes/bugs found?
For example, if there are a set of regression tests which need to be run, would it be more effective to split up the tests between two testers or have both testers work together?
From a time perspective it seems counter intuitive to believe that there is any chance that the tests will be completed in less time if the testers work together.  If two people's time is occupied by each test then surely it could take just as long as if a single tester were used, thus doubling the cost of getting the work done.

The answer to the question depends on several factors:

How experienced is each tester?
What product knowledge do they each have?
How quickly/efficiently do they work?
Do they work well together?
Are they good communicators?
Are they familiar with the tests?
Do they think and work differently and use different methods from one another?
Do their skills complement one another?

Up until recently I have been doing all regression testing for the area I'm responsible for by myself and, to be frank, it can hard to keep it interesting and different each time.

However, for the last couple of regression tests I have sat side by side and worked with another tester and worked together on what are normally our own separate set of tests.  I looked forward to trying this as, at the bare minimum, I'd have someone to talk to whilst testing.  It was only once we began that I realised the various other benefits of pairing.
One of the main benefits I noticed first was in learning more about the area of the product in which my fellow tester specialises.  I am generally responsible for one area of the product and although I know a lot about the other areas they are not my primary focus, so it was interesting to see how much I could learn from my colleague.
Another advantage was the amount of communication which went on between us so we knew what each other was doing and we could complement each other rather than duplicate the work.
Also, we avoided carrying out unnecessary testing which had already been covered as part of earlier feature testing and bug fixes.  Without this interaction this time saving information would not have been imparted and regression testing would have taken longer than necessary.

There are several advantages I see to pair testing:

• Increased creativity
• More efficient testing
• Time saving
• Improved communication
• Keep regression testing interesting
• Bounce ideas off one another

Other ideas this subject brings to mind are:

• Pair with different testers to mix things up and bring out new ideas and ways of working
• Try pairing on other areas of test such as bug fixes and story features
• Test with 2 or more other testers (may be impractical)
• Pair when doing exploratory testing

In conclusion I highly recommend trying pair testing even if only as an experiment; what is the worst that could happen?

Purposeful Regression Testing

Regression testing is a term that all testers ought to be familiar with but does it mean the same thing to all of us?

My view of regression testing has gradually been changing since I started as a software tester 8 months ago.  When I first started out one of the first things I was introduced to was the regression tests we run for every new kit.  This was a good place to start as it helped me build up my knowledge of the product and also get familiar with quite a wide coverage of tests.  With each run of the regression tests I became more and more confident and found I could run through the tests quicker each time and with less of a need to read the test steps word for word.  Although this was all good and positive I could also feel myself getting a bit too comfortable and did not feel I was putting enough thought into my regression testing.

It felt as though this testing was gradually turning into checking but at the same time I thought this must be the nature of the beast.  However, running the same manual tests time after time is not what I'd call fun.

So what can we do to change things?
Of course, automation is one tool we can use to reduce the number of regression tests we run manually. Automation is especially useful when the tests are literally run in the same way following identical steps every time and the results are simple enough for a computer to understand.
Some of the tests cannot be automated, or if they were automated they could not be interpreted reliably by a computer.  This may be due to timing issues in running the test or audio quality assessment of the output which we cannot (yet?) trust a computer to make a valid judgement on.

However, as well as these special cases, I believe that there will always be fundamental manual tests that must be carried out by a human to ensure confidence that the kit has the basics right, before moving on to the 'more interesting' testing.

Every tester knows that it is not possible to run every test variant on a product of any reasonable size, let alone get close to this with every set of regression tests.  For this reason regression tests need to be carefully chosen to be of maximum use specifically to the kit in question.  To continue to be useful I believe several factors need to be taken into account when selecting what tests to run as part of a regression suite.  I would include the following in my areas for consideration:

• Recent new product features - Areas of the product which have recently been created.  Even though they may have had a thorough testing, in general, I would still want to focus on a new area rather than an older one.  I would expect more bugs to be found lurking there as they are likely to have had less exposure to as many different variants of input as opposed to more established parts of the product.
• Customer impact - If I had to choose between testing only area A and area B and was told both were of equal size and that area A was considered essential to 70% of customers and area B only important to 30% I would choose to test area A.  
• Time - We can obviously only perform a finite amount of testing within whatever time frame we have.  So, looking at the example above, in simple terms if I had 100 minutes to test I would spend 70 minutes on area A and 30 minutes on area B.
• Bug fixes - Even when bugs have been fixed and successfully retested I still like to focus on these areas as they are effectively newer areas of code now so the same principle applies to that of new feature areas.
• Refactoring - Again for the same reasons as new features and bug fixes.

Targeted and meaningful regression testing should include the core tests which cannot be automated but also take into account all of the factors above.  The examples above are obviously very simplified so deciding what to test and for how long is not straightforward.  I think part of the skill of being a tester is to weigh up all the factors and choose one's tests wisely rather than blindly following a regression test script.  I'd like to think that's how regression testing is done in the majority of companies but I fear it may not.

Thinking, Fast and Slow - Book Review

Over the past few weeks I have been reading a book called Thinking, Fast and Slow by Daniel Kahnemann.

This book was recommended to me by a good friend of mine who works as a software tester for another company.  He told me that it would change the way I think about how our minds work, and indeed it has.

As the title suggests, Daniel Kahnemann describes how our minds are split into two main systems which we use when we think and make decisions.  He refers to these as System 1 and System 2.  System 1 is described as automatic and subconscious.  So when we feel we are acting on our instincts, gut reactions or hunches, we are said to be using our (fast) System 1 to make these decisions.  When we act on instinct we do not take a step back to analyse the situation before coming to the decision we make, we just feel that it's right.  Often, this is exactly how we want our minds to work.  For example, if someone throws a ball in your direction you need to make a quick decision as to whether you're going to dodge or catch the ball.  Not a lot of conscious thought is going into the decision as there is not enough time to think about what action you will take.

There are other situations where taking your time before acting is much more appropriate.  For example, if you're looking to buy a new car you won't make a quick choice based on looks alone, you will want to know think about many aspects such as performance, economy, mileage etc.  Therefore, before making your choice you will have to use your (slow) conscious System 2.

It is the occasions where we don't feel a decision requires a great amount of thought which can lead to errors of judgement.  Something may seem simple and obvious on the face of it but only when you really apply conscious time and thought do you see things more clearly.  This is a good point to bear in mind, especially when testing software.

One of the mistakes we are prone make is to let our own personal experiences of events bias our view of the probability that those events will happen in the future.  For example, if you have a family history of heart attacks and you are asked what percentage of deaths nationally are caused by heart attack then chances are you will overestimate the likelihood when compared to someone who has no personal experience of heart attacks.  This is known as the Availability heuristic, since instances which come to mind (are available) lead us to think that events are more common than they are in reality.
When we have personal experience of a subject we must not let that influence our view of the facts, however, this is easier said than done.  Another similar idea which is related to the Availability heuristic is the acronym WYSIATI, which stands for 'What you see is all there is'.  We each have our own view of the world and everyone's view is different.  We often don't look or investigate any further than what we've seen personally as we don't always believe there is more to see.
We need to train ourselves to think about the bigger picture as there is often a lot more going on that we don't realise just because we haven't paid attention to it.

Below I've briefly described a few of the many ideas Daniel talks about in the book which are useful to bear in mind, especially when applied to software testing.

Sample size
One way in which it can be very easy to arrive at an incorrect conclusion is when judgements are made based on a small sample size.  The sample size should be large enough so that natural fluctuations in results do not skew the overall result.  For example, if you toss a coin 1000 times, as well as being very bored and worn out, the percentage of times you see heads should not be far from 50%.  However, if you only toss the coin 10 times, you could quite easily see 7 heads out of 10.  We all know that the probability of seeing a head is 50% but when we don't know the probability we need to choose a sample large enough to eradicate the influence of natural fluctuations in results.

Answering an easier question
When you are trying to answer a difficult question or one that you do not have much knowledge about it can be natural to give an answer based on what knowledge we do have about something linked to the question.  For example, if you are asked the question 'How happy are you with your life?' you are likely to give an answer based on how you feel about things right now rather than thinking more objectively about your life as a whole since birth.

Regression to the mean
Sometimes people can misinterpret a correlation between events happening as causal just because they both occurred at the same time.  Daniel explains that it's important to bear in mind that measurements of a particular category tend to create a bell shaped curve (see below) over time.  So there will be fewer results at the extremes with the majority falling somewhere between these two extremes.  Due to this fact there is a general regression to the mean, or average result.
This can explain why, more often than not, punishment of a bad result or low score is followed by an improvement, and rewarding success is followed by a worsening in performance.  This phenomenon can result in the misbelief that it was the punishment that caused the improvement or the reward that lead to the deterioration.  This is a great shame as many employers are not aware of regression to the mean and believe that their punishment of poor performance is always responsible for the subsequent improvement, so they have no reason to change this behaviour.

Since reading Thinking, Fast and Slow I've found myself thinking about real life situations where I can apply the principles described.  Even when you have read the book and have the knowledge of how our minds work it still seems unavoidable to fall into a lot of the traps which our brains appear hardwired to make us susceptible to.  But to have the knowledge about how our minds work and the flaws that exist can be empowering and should lead to more comprehensive testing.