Wednesday, October 9, 2013

Motivation for Software Testing

Motivation- a text book definition- is a psychological feature that arouses an organism to act towards a desired goal and elicits, controls, and sustains certain goal-directed behaviors. It can be considered a driving force; a psychological one that compels or reinforces an action toward a desired goal.

Software Tester/ Software Quality Assurance Engineer/ Firmware Test Engineer etc all these are not that easy as it sounds. Software Testing can be a boring, repetitive task. Many people may not find it interesting enough to continue their career in this field. Many people would think it as 2nd level job (in terms of opportunity and ~20%-30% less payment from others) in software industry. A job that usually comes in shorter months (3 months, 6 months+ etc). It’s very hard to motivate him-selves in job like this and produce quality work. Testers who are motivated are more likely to strive for higher quality outcomes, achieve objectives and work in a more efficient manner and vice versa.

Think about a simple situation- you are working with a device, for example medical device. Medical devices are critical. They are used on patients, not on ordinary people. When you engaged with such job, and you have tested the firmware/ software of that machine, when it comes to the critical time, you know that machine will work; you know you tested it well. It can even save a life and opposite can happen if you are not self-motivated enough, not being able to understand the importance of your job

Or think about another scenario- in August 2005, Malaysia Airlines Jetliner, Flight between Perth, Australia and Kualalampur, Malaysia zoomed 3,000 feet upwards. A defective software program had provided incorrect data about the aircraft’s speed and acceleration, confusing flight computers. For a software bug, think about how many people’s life was at risk!

I have chosen to be a software/ firmware test engineer. To me it’s a challenging one. Every time a code is released for testing from the developers, we get a chance to break it, tear it down into pieces. To me it’s interesting, fun and I enjoy doing testing. It does always make feel good to developer's reaction after finding something; developer never thought about it- that's my primary motivation.

Real life experience
I would like to share one experience of mine how I tried to motivate the QA team, i.e. the whole software development team 

Around 2003, I joined as a member of the QA team which had 4 members. There were 15 developers and 4 testing team members. We had a QA team leader who was an expert of databases. They had all the procedure and tools for the testing team in places. From screening codes at the very early stage of software to recording bugs in Bugzilla. What I had experienced during my tenure was, somehow I felt that testing team member were not motivated enough to proactively do something. I felt like, they treat themselves as weaker than the development team.

So, based on that feeling, even though I was just a member of the testing team, I felt like I had to do something in this regard. So, I initiated few internal meetings with our QA team about the existing procedure/ bugs that we had. After that meeting I found the weaker point. QA team was lagging of one main thing – “Quality”. I looked at few bugs and realized why developers used to treat them so lightly. The quality of the bug reporting was poor, not enough description, not enough logic to support that it was a valid bug. Then decided to shared my experience with them, how to write a good bug and standardize the procedure. I noticed that, developers started to like it. Because it helped them, it helped them to duplicate the issue which saved lot more time.

Observing the good response from the development team, I looked the issue to motivate the QA team to keep them reporting the quality bugs. I started another approach for the QA team and later with the development team. That was something that I started to use 10 years back from now, nothing unique about it. It’s the "Rewards" system. Here, I will try to explain how on each phase Reward system how it worked and not any specific score card system.
I started to publish the statistics of QA team in terms of reporting bugs on the notice board, like the top ten chart. That was intended to motivate the QA team and it did! Not to praise myself, but I was top on that chart :). It actually started to work, when developers acknowledged my bugs. My other QA team members actually started to post more and more bugs after that. It became a sort of competition and following weeks numbers were different then the first one.
Reporting more bugs it-self does not generate good reputation for the testing team. As they were reporting issues, if they did not report legitimate bug, it was getting negative response from developers. So, to balance that issue, I put some weight-age on the bugs. What I did was, for each good bug of P1, which was accepted by the developer/lead, gets 10 points. Then for P2 accepted bugs, 8 points, P3 -6 points, P4 -4 points, P5- 2 points. To ensure that QA team would not report everything for higher score, I had used the negative marking as well. For each bug that gets rejected by developer reduced the -5, -4, -3, -2, -1 points. At the end we had a sum of all the numbers. Based on the number it was ranked. The good thing about negative marking was, when a QA team person reported 10 point bugs, when it gets rejected by the developer, he lost points. So they were careful about reporting it. That's one part of the solution- motivated the QA team.
Then comes the other part. As of then I had more bugs on board, developers need to fix them. It was outside of my scope. So approached to our Project/ Engineering Manager- who manages the whole Software Development team. With his permission, then started to introduce another section on my chart for the development team regarding the bug found/fixes. Followed the same positive and negative point system for them as well. Ranking of developers in terms of most issued bugs. When I published that, now developers were more serious about getting those issues fixed. So it helped in both ways, to report bugs and to had them fixed. After a while when I published the score card again, I had seen major changes on the chart.

It worked! Simple old fashion Reward system worked. It was a whole team effort to make that system actively working. Reward technique for this project worked well. But it may not work well with other project/ infrastructure. We can introduce different techniques like this which will be suitable for the project/ infrastructure. Motivation differ from person to person. Money may be the prime driving factor, but something like this small reward system can also motivate some group of people.

Few common barriers of Software testing can be easily handled in a different way. Software testing is not a repetitive job anymore. We can minimize it by engaging the automated testing. As a testing team member/ manager, we should establish/ follow a process of systematic testing, setting the goals for the testing team members, making sure they are clear about their goals and boundaries. Managers can provide training for the test team members if necessary, can have few motivation sessions with test team members. When necessary, don't feel shy to play the leadership role. Develop a good relationship with development team. That can help you to understand any issue with more detailed information (DO NOT get Biased though- it's important).

Lastly I would like to say, we are test engineers. We test things. Developers have an option to fail and we will catch it. But, if we fail, there will be no 2nd level. It will directly go to the end users. And the cost is real high when it fails on Releases.

Be a passionate test engineer!!! 

No comments:

Communication - it's very important in recruiting people

One of the common part of our professional life is we get mails from recruiters time to time regardless whether you are looking for job o...