Thoughts of a new(ish) Software tester


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.


Leave a comment

Variety is the spice of Test

One of the reasons I decided to get into software testing was the appeal it had as a job which would keep me interested and not become repetitive and boring, as so many jobs can be.  I think software testing can be as interesting as you want to make it, within reason.  My main caveat would be that you have a much better chance of achieving job satisfaction if the company you work for has the right attributes of a forward thinking company, such as one which adheres to as many of ‘Deming’s 14 Points’ as possible; which can be seen at the following web page (

One of the main factors I’ve found in maintaining interest in is continual reading around the subject of software testing, including not only books specifically about testing, but also books covering wider subjects such as the industry you’re in or books about how our minds work.  Although not directly related to testing, the knowledge gained from many other areas can be useful to have in the back of your mind when testing.  One example is Thinking, Fast and Slow, by Daniel Kahneman, which is a book about how we appear to have two distinct ways of thinking about things, the instinctive gut reaction (thinking fast) and then secondly the more conscious considered approach (thinking slow).  I intend to write about my thoughts on this book in a future blog.

I started using Twitter about 6 months ago and have found it a great way to access lots of current thoughts, trends and blogs from people who have vast experience of software testing.  There is no shortage of views and ideas and twitter has become part of my daily routine.

Although testing our product is classed as my main role, there are lots of interactions with other areas of the company necessary to fulfil my role as a tester.  As we’re all based in the same building those interactions are usually immediate and face to face so feedback loops are short and progress is made quickly.  We also release new kits on a regular basis and constantly add new, and improve existing features.  So although we have a stable product, we as individuals and as a company are in a constant state of progression in terms of continually improving and polishing our skills and our service.  This goes not only for myself and the test team but everyone in the company; we are all pulling in the same direction.

So my job not only involves testing, it also involves meetings with the product owners to discuss upcoming product enhancements and planning how best to test them.  It also involves working closely with developers to get visibility of the features as they are created first hand and as early as possible.   That way I can find out how they intend to code the requirements, with an eye on testability and automation of tests where possible.  The more of the predictable, repetitive tests that can be automated the better as that leaves the more unusual scenarios, which only a human tester can carry out and/or interpret.  That is the sort of testing I want to be doing as it engages my mind and allows me to be creative.

It’s this variety which keeps my job interesting and I hope any non testers who read this can take it from me that getting into software testing is well worth the effort.