It's Testing - How hard can it be?

It was said in jest whilst I was walking to my car after work. Me and a developer were having some tester/developer chat at the end of a hard day and he said jokingly : "Its testing - how hard can it be". That got me thinking........ how hard is testing? What challenges do we have testers have to face that can turn a great day into a 'should of stayed in bed' day. Here are some reasons why testing is not always easy and how you can make it a little easier and enjoyable.

Just a 'Button Presser' Perception

Unfortunately some people have the perception that testers are just people that press buttons and make a few mouse clicks. Yes I'm sure there are testers out there that do this but any tester worth their salt would object to this stereotype.

For a 'context' driven tester (by context driven, I mean a tester who sees them selves as part of the context driven testing community) these button presses and key strokes have come after some cognitive processing that results in a way of testing that provides useful information to stakeholders. If someone thinks you are one of these testers then you may find that they treat you in a certain way, one which can to say the least be patronising. Trying to convince these people that you can add some value can be difficult but not impossible. (For adding value see "Please let the adults speak" below)

You can release it but I wouldn't advise it

Project managers and other stakeholders can look to you for whether a release should go out or not. Now this can be a tough decisions for a tester and one that you may not be comfortable in making. Now, you tested as well as you could with the time you had but what about that area you didn't really have time to look into? Would you be happy in making that decision knowing that that areas was not tested as well as it could of been? Now any good team will succeed and fail together, nothing good ever comes out of a blame culture. Making that release call can be hard but thinking logically and making people aware of the risks should help you feel at ease with your decision. 

What do you mean have 1 week to test a complete system
One of the biggest gripes in testing is the amount of time you have to test. Not having much time to test can make testing difficult and you may feel under lots of pressure to get the testing done in a smaller timeframe than your originally envisaged. Being squeezed on time means you have to prioritise your testing and this will mean that some areas (admittedly usually lower priority ones) may not get the attention that they should. By prioritising you are making sure that you start testing the areas that give the most value to your stakeholders or areas that are more susceptible to errors. Finding out what these areas are before you start testing means that the key areas of the program are covered and if any issues are found they will hopefully be in areas that are not critical to the daily function of the software.

Please let the adults speak

Where I work testers are not viewed as second class citizens, they are respected and are a key member of any team they are in. If you are in a situation where testers are viewed this way it can be difficult to get your voice heard or feel that what you are doing is appreciated. With the importance of testing and the benefits of a context driven approach, the modern day tester offers so much more than the traditional 'test from a spreadsheet' one. Being flexible and adapting your testing approach makes a tester a valuable member of any team. If you do find yourself being  treated like a second class citizen you need to add value to the project you are working on. Now there is one thing you can do as a tester to add value and that is......... Ask questions. I will caveat this by saying they need to be relevant. Ask questions about the code, the specification, the user stories....... the old saying goes "There is no such thing as a stupid question" - and I agree. By asking questions you could uncover an unforeseen scenario or help the users question their processes. In these scenarios you have potentially stopped a bug from being present in the system and helped your end users improve their process. This should be appreciated by the everyone on the project.

Pantomime season

"Its not a bug.
Oh yes it
oh no it isn't!"

Now its not pantomime season yet but sometimes it can feel like that when discussing with a client whether something is or isn't a  bug. A client may be adamant that  this issue is a show stopper.... "THE TEXT IS NOT PINK IT CANNOT GO LIVE" . This can make testing difficult as you spend hours in meetings discussing the issue and it takes time away from your actual testing. This scenario often requires some skilled negotiation as well as some tack. Yes the clients are under pressure to get theirs change out or they may want everything perfect but common sense should always prevail. (easier said than done). Demonstrating that fixing the bug will add no real value or showing how a bug will effect the application on a daily basis are usually sufficient to help you convince clients of the right course of action. 

E=Mc2
Testing has so many variables that there is no correct way to test a program or particular feature. Here are just some of these variables:

* Personas
* Operating Systems
* Hardware
* System Architecture

Now trying to test a program and covering all of these is often impossible. As a tester you need to try and workout what ones you should focus on. What happens though if you don't focus on a Persona and an end user who matches that persona interacts with the system and the system crashes? You cant cover all the known variables and knowing what variables you should focus on can be difficult. You can mitigate this by finding out as much as you can about different variables that are applicable to the system you are testing. You can then select the most popular and test on these. By doing this you are covering the majority of combinations and this is all you can do unless you are given till the end of time to test, and even then you will probably miss something :)

So yes testing is challenging but as testers we can develop our skills and continuously try to improve ourselves to make it a little easier.

If you have anything to add please feel free to add a comment.