Self Motivation in Software Testing

Self-motivation is a key factor of quality the Software Testing. Software testing is monotonous, working with same interface / screen over and over could be a boring at times. One will have to find out a way to avoid that scenario where they will feel bore about it and that would be the end of testing. Once  bored, one will find fewer issues about the software and the quality of the software will be compromised. There are many outside issues/ problems that can cause the frustration for the person who will be testing the software, but just being with one software/ product for a longer period of time, can affect largely finding software issues. So, we will have to find/ apply different techniques (no hard and fast rules) to keep ourselves motivated. Following  I’ll be trying to share my experience which worked for me in many projects to keep myself motivated in software testing. 

Testing Approach- Any software that I’ll be testing, prior to look into the software, I usually try to learn/study the details of the software/ product. Even if it’s written on the Specs, I try to get info from different related people through questionnaires. This gives me broader idea of what was supposed to be built, what was designed, and how it supposed to behave. Then I can double check my testing procedure (Test Plan, Test cases) whether I planned to cover most scenarios. 

Perform a Smoke Testing on the software before starting the testing according to the test cases.  Smoke testing actually gives the idea whether this software is ready for testing or not. If I find issues that Software does not run or crashes now and then, I ask for a rebuild of the project and then a newer version. This saves my time and effort to start the formal lengthy testing procedure. 

Prior starting the formal testing procedure, I start with light things like the User Interface stuff- alignment issues, correct text, correct icons on different states, and clean UI etc. No matter how silly, non-functional, less important issue it would be, User Interface is the first thing that User will look at. That’s the first impression user will get about the software. So, it’s important to have a good, clean, simple, understandable UI and my job is to make sure of it. When I find issues, I write them down (leaving the priority of the issue as blank). 

The next thing I do is another easy task, field validation-valid, invalid inputs, min-max checking of each field, tab orders(if applicable), size etc. Whatever Issue I find, I write them down. Most of the time, these issues gets the low/ lowest priority. 

At this point, if I have a good understanding & access to the developer, I can send them the issues so far I have found. If agreed, they can fix the low priority issues while I will be concentrating for main/ major issue findings. From my experience what I have seen is, at the initial stage after releasing the software for testing, developers have some time that they can use to look into low priority/ UI issues that they will not have the time later when I start to find the major issues. Finding major issues takes time. So for an optimum use of resources, I try to keep the developers busy (if agreed among all concern parties) fix those issues. If not, then I start recording the issues, prioritize them consulting with concerned parties.  

While I have few issues on board, I then start to follow the formal steps.  This may look like informal testing procedure, may go beyond my teams boundaries, but I have found it useful in-terms of optimize use of resources. For the formal steps, it’s quite common among the software industries. So I’m going to describe them here. 

One Important thing I have learned from my experience in software testing, as team member and/or as team lead is....

At no point of time, one should wait for another person to finish some task. For example, testing should not wait for the development to finish. Development and Testing should go side by side. This sometimes becomes a demotivated factor for the Testing Team members. They should be engaged in testing through out the whole SDLC. 

Some Suggestions -  During this process, like any other human being, I also get bored about the software after a while. I try to take different measure to keep myself motivated during this testing process. Few things I do (works for me, may not work for others) and suggest are:- 

• Primary motivation comes from finding and reporting Issues. When I starts to report issues, in those easy areas (mentioned before), the number it-self motivates me. When I see I have like 20 issues already on board, it gives a good feelings and I get motivated enough to increase the number by finding more issues.  I use some numbers as Milestone - 25, 50, 100 number for reporting issues. The more I find issues, the more the number gets increased and I feel like i'm on right track. (I usually try to report quality issues, not just issues to reach milestones). 

• I frequently take breaks out of this testing procedure. Looking at the same screen time after time makes me more familiar with the screen. Once I get too familiarized, I started to feel that everything is as it should be. So, when I take a break, when I come back I can get a fresher look at the screen and sometimes I find issues from that. Btw, do not lose your focus/ concentration with the break.

• When I feel like I’m running out of testing idea’s I go back to my drawing board and review all the things I was supposed to do and what I have done so far. Sometimes I find idea that I didn’t planned for before using the software. I update my document as well when I find things like this. 

• Another thing I do when I run out of ideas, I intentionally plan to talk with developers to get more inner knowledge of the software. Black box testing is basis on without knowing internal knowledge. When I talk with them, little chitchat about how did they develop one particular features, or what conditions they used to plot a graph line etc. helps me to think of different testing ideas. And when there is broader area, more chances to find issues and number will increase. 

For example, software supposed to plot a line graph based on a test result and date. On a date, a test can be performed, or can skipped but recorded. If there are test results for two dates, the line goes straight on the graph. If more than two and test performed on each day, then it connect all three points using curve line. If first day has a skip, then for next two day results will be a straight line, and there will not be any line drawn for first two points. If there is more than 10 points for multiple days, then logic is different then others. In short, there were different logic used for different case, single point, multiple point - 2, 3, 10, 11, 12 etc data set. Before knowing these logic, I was just testing it for few test data. When I came to know these logic, I started to layout different technique to test these scenarios.  

With the ideal world, these things can be handled or tested on the white box testing level, but as an end user tester, I don’t believe what other did. I don’t assume even that this was tested at unit level. Caution: do not get biased developer.

• Sometimes, when I feel that something is not right, may be it's according to the specs, I usually report it as Enhancement/ Observation just to avoid any further objection. And I support my findings with logical arguments from a user point of view. Enhancement is category where I actually can contribute my idea for the improvement of the product. Observation is something that I noticed, may be its working as designed, but something to discuss it further. I may not be the person who will take the final decision about the changes, at least, contributing ideas as Enhancement / Observation would definitely feel happy!

Feel free to test anything and everything. Do not care the limit, do not care what you were not supposed to do it or not. Free your mind. Play the role of different level of a user. Find the things that you feel it can motivate you for testing. Use those techniques.

Automating our testing is okay, helps us not to get monotonous/ bored. It’s the human being that designs the automated testing script. If you feel bored, it will affect you writing and updating scripts. Scripts can only do what you think about. If the thoughts are bounded by the tiredness, then it won’t help whether we use automated testing or manual testing.

Lastly, to keep yourself self motivated in software testing, don't just test a software that is given to you, feel the ownership of the software. Have fun in Testing!