It is not a job requirement, but when getting hired as a software tester your creativeness will be assessed either through some interview questions or in a practical task. The funny thing is that employers should be careful what they wish for as an overly creative tester can sometimes be less productive at finding those tricky bugs.
This is because as a creative tester you need to understand that the mind plays tricks on you. It needs to do so to keep you sane. The brain is hardwired to draw conclusions of your experiences and store them for easy access, instead of recording every bit of information that your senses pick up. So you won’t remember what the layout of all the pages on a website are or what it said on page 4 of a 15 page wizard. You are a tester – you’ll build trust in the system while exploring. For the benefit of your future self and the team, write down details of your experience. Don’t let your mind draw the conclusions, as the only thing you will get is how worrying it felt when you got a 404 but couldn’t remember how you got there in the first place. Frustration ensues, another nice sentiment that your brain will store in association with the application.
Don’t over-engineer. Enthusiastic/creative testers will often attack problems straight on. This is usually how an exploratory testing session works. Your brain will brainstorm some thoughts more or less plausible and you will start choosing one and then another, linking them together in what you hope to be a good lead to a buggy area of the system. If you’ve identified a task that needs a clever solution to get it done, remember to take a step back and assess all of your options. It might not hit you straight away, but if your solution takes more than one hour to carry out then you might have to think of another one. If you still can’t find that elegant or clever or simple or just plain beautiful solution then look around for answers. You will soon find out that taking your time and discussing different options with your fellow testers might have saved you the exercise of spending almost a day on over-engineering a solution.
I can’t get enough of quoting this little phrase which has such a huge impact in understanding the world we live in:
“The brain and the eye may have a contractual relationship in which the brain has agreed to believe what the eye sees, but in return the eye has agreed to look for what the brain wants.”
[Stumbling on Happiness – Daniel Gilbert]
Now in order to avoid getting mixed feelings about the application instead of what should have been a clear and concise mental model of the system here is a recommendation:
Start out with a mind map and jot down all your creative thoughts. After finishing it, take a step back and analyze which nodes of your mind map might be too outrageous to happen or it’s not that they will never happen but let’s just say that it’s not in the user’s best interest to unplug the computer. Your rule must be “if it makes sense for the business it stays in the mind map”. Get a business analyst to help you focus and remove extraneous ideas from your mind map.
Use a tool to make notes on what you observe while testing. Your mental model of the system will need a refresh from time to time. This usually happens when you think that there are no bugs left in the system. One of the best ways to refresh your ideas is to get rid of what you’ve already covered. With a repository you will more easily remember everything you did and all the conclusions you’ve drawn along the way.
As a creative tester, you can avoid your mind playing tricks on you and experiencing the frustration. By commenting on this article, I encourage you to share ideas and techniques that you have learned to master your creativity and excel at testing. Also, join me at the Software Test Professionals Conference, October 24-27 in Dallas, Texas. I, along with Tony Bruce who is a consultant, will present the session Walk in my Shoes. Session attendees will have the opportunity to experience and share different perspectives and approaches to solving project issues. Attending this session will inspire you to see differing points of view as well as approaches that will better equip you to deal with project issues that arise.
About the Author
Adrian Rapan Adrian is a QA Analyst for LMAX (London Multi-Asset eXchange) which is building the world’s highest performance financial exchange – a platform for high frequency and algorithmic trading.
Adrian has provided quality assurance services in the medical and financial industries and has worked at all levels of the testing life cycle; from strategy to test case design. He has full project life cycle experience with practitioner experience in requirements analysis through to design, coding, and testing. While his main focus at the moment is on test automation within the Agile environment, he has worked in highly regulated waterfall projects and he has also developed solutions to aid in the testing process. He has a keen interest in the testing community in London and is attending the London Testing Gathering and the London Exploratory Workshop in Testing.