Skip to main content

One Tester Left Standing........

Now you may have found yourself in the same situation as me, the only tester working on a particular project with the usual aggressive project timelines. Although this may seem daunting at first there are a few things I have found that can help.

NOTE: In this post I try and called what testers would traditionally call defects, problems. I have done this after reading this:


Keep Test cases simple
Being the sole tester on a project you often do not have the luxury to spend a long time planning your testing. If this is the case keep you need to keep test planning simple but with enough detail so you know exactly what you want to test. A great tool for this is mind maps, which allow you to capture key tests in a quick and easy way without having to go into lots of detail. How you structure you mind map is up to you so long as
a)     It can be read and understood by another person
b)     If you have to go back to it, it is clear what the testing was

If you don’t use exploratory testing, Mind Maps can help you document all your tests without the odious task of having to create an Excel monster document than details each test. If you do use exploratory testing then mind maps can quickly help plan what areas needs testing and as you explore the system and find new tests these can be added with a few mouse clicks.

Build a good relationship with the developers 
This is something that I cannot highlight the benefits of enough. It is something that can benefit a tester in multiple ways. It is something that will take time and will require a bit of give and take on both sides but the rewards to both developer and tester are well worth it. In my experience having a good relationship with developers can benefit the tester and project in the following ways:
  • Developers willing to spend time explaining certain system behaviors. This helps you as a tester understand some more in depth detail about certain features and also helps the developer see how a tester may look at a particular feature if the tester asks some questions.
  • Tester and developer can look at potential problems together informally. Again this helps the tester understand how a particular feature works and also can enlighten the developer as to how a tester uses the system by looking at how they encountered the problem. This in turn could lead to the developer writing system tests to cover any scenarios that he/she may of missed to help mitigate risk.
  • Developer may help Triage client problems. Maybe not an ideal situation but means that problems can get investigated earlier than anticipated. This may due to the tester not being able to triage them for various reasons (Holiday, Sickness etc..)
  • Don't have a them and us mentality By building relationships with developers you create a more 'us' mentality than a them and us mentality. A whole blog post could be written on this but I’m sure you can see why this is a good thing.
Use all available resources 

Your place of work may be full of resources such as Books, Users Guides and other items that can help you on various aspects of the project you are working on. Although these artifacts are useful the most helpful resource you have is..... People. If you are surrounded by colleagues and need some help, then use them. They are full of information and at times when you need to know something they will probably be your best bet for help and support. So if you find yourself having issues setting up a test environment - ask the support team for help, if you are having issues understanding a document..... Ask the author. When project pressures have you wishing for an extra 5 hours in a day remember that any time consuming problem could potentially be solved a lot quicker by asking someone for help rather than trying to figure it out all by yourself. Pick your timing well as disturbing a people at the wrong time may not get you the help you need and also remember that Doughnuts, Biscuits, Cake and other treats probably help :) Obviously you’re also a potential resource to other people so remember it works both ways and you never know when you may need someone’s help.

Write Notes up at the end of the day
Being a lone tester in my experience requires the ability to recall various aspects of testing and project related information frequently throughout the day. One technique I use to help with this is at the end of the day to email myself any notes I have made during the day. By doing this I have to re-read my notes as I type out the email which helps to re in-force any important bits and when I come in the next day the first thing I do is read these notes  which jogs my memory as well as enabling me to answer questions quickly about yesterday’s activities to anyone who may need to know.

Testing Focus
Focus your testing. Always try and test the high priority items first as these are the ones that the clients view as the most important, therefore fixing any problems in these areas should be a priority and getting sight of them as early in the test cycle as possible is essential. For example if you have 2 weeks of testing and you  spend the 1st week testing that spelling mistakes and field labels are correct any problems that are found in the second week on the higher priority items developers have less time to try and fix. Most clients will want the high priority items working due to there added business benefit and will not worry so much about spelling mistakes and incorrect field labels.

Use Session Based Testing
This is something that I have started using recently and have found it to be useful to focus my testing and me getting the most out of the time that I have to test a particular feature. For those who do not know what session based testing is, it is basically breaking testing down into sessions and using these sessions to explore any charters/areas that you may want to investigate. I do not use charters (for various reasons) so I use hourly sessions, and in these I explore a particular feature of the software I am testing. In my experience to get the best out of this you need to have an undisturbed hour to really get fully immersed in the feature you are testing. Now this can be difficult in a busy office. I tend to put some headphones on and listen to music or just put headphones on with no music playing so you have less chance of being disturbed.

There you go, hope you found some of these tips useful. If you have any more please feel free to comment. 

Comments

Popular posts from this blog

How to deal with pauses and timeouts in specflow

So this blogpost is in response to the weekly Specflow blog posts and challenges that have been written by Gojko Adzic. This weeks challenge was how would you rewrite or rephrase the below scenario: Given a user registers successfully When the account page reloads And the user waits 2 seconds Then the account page displays "Account approved" My initial though was something like this: Given a user registers successfully  When the account page reloads   Then the account page is displayed within a satisfactory time period     And the account page displays "Account Approved" Now the problem with this scenario is what defines a satisfactory time? You could add it as a comment or in a scenario outline but over time the time a user waits could change and if this is updated in the code behind but the scenario outline or comments are not, then what the test does and what is described do not match - this would potentially cause issues in the future. My next ide

Testing and Mindfulness

How aware are you? Do you live in the here and now or is your mind always somewhere else? This blog post is about Mindfulness. Mindfulness is a simple meditation and is defined as (According to Wikipedia): "The intentional, accepting and non-judgemental focus of one's attention on the emotions, thoughts and sensations occurring in the present moment" Now Mindfulness has become more popular in the west in recent years as it has shown to have benefits for people who are suffering from Depression and Anxiety. It has been around for a while and is often thought to of originated from Buddhism and some people believe it started thousands of years ago. Now modern life is hectic and I’m sure we all have lots of things going on in our lives that keep our Brains busy and trying to focus on one thing at a time can be a challenge. I can't remember the number of times I've been doing something and my mind is somewhere else entirely. Mindfulness helps you focus on

Building a test strategy for a new team

Teams, we have all been on them. Some are good and some are bad. Some we never wanted to leave and others we probably couldn't wait to leave. Now most of the time (well in my experience anyway) you tend to get put into a team that already exists. Maybe you are a new hire or maybe you have asked to change to a different product team.  When you do this, more than likely there will already be a testing strategy in place. It may be that you adapt it and change it in any way you see fit to improve the testing. But imagine if everyone on the team was new? How would you decide your testing strategy? This post will go through some useful things you can do to help a new team develop a test strategy. Table of Contents ๐Ÿ“ˆ What is a Test Strategy? ๐Ÿค” Where should I start? ๐ŸŽฏ Understand the company and their goals ๐Ÿ’ช Play to the teams strengths ๐Ÿ‘️‍๐Ÿ—จ️ Understand what quality looks like ๐Ÿ“ Understand Scope ๐Ÿงช Understand the type of tests you need ๐Ÿ“Š Measure your success ๐Ÿค Collaborate ๐Ÿ“ Summar