Tuesday, March 3, 2015

De-motivating factors in Software Testing

People does not like reading negative stuff by nature. I'm not that happy as well writing about it.  I'm not the expert guy, nor I have seen all sorts company within this related industry, still, while working in this profession, I came to list few things that actually work as negative input for software testing.

Little background of writing this. Ever since I started this blog, many people around the world tries to access my blog contents. Some tries to read it for pleasure, some tries to find standards/ templates and some tries to motivate themselves in this Software Testing. From my blog statistics, I can get few ideas about those people who are looking over here. Few of the search criteria, actually, made me to write this new topic. For example, one person searched with "I feel useless in Software Testing". I felt little upset/concerned  about this. Why anyone in this field would feel something like this. That means, we have some factors that led us to have feelings like this. If I'm not that capable person in software testing, I would have find some other job. When anyone is searching with a topic like that, that means s/he wants to be in Software Testing and want to be good about it. 

So, going back to the main topic....What is causing us to feel like that? Following would be some of many factors that I was able to identify.

1. Person's Mentality- THIS I felt to be the first most factor for de-motivation. Not all people actually come from same background, nor mentality to accept negative things about themselves/ their work. We software tester are, by profession, bound to find negative things about the software. People who are building software, managing the software and testing the software must all have the mentality to accept negative comments about their creation ("Baby"). Developers must know that we will be working to find issues and not necessarily we will find everything. When we find something, trivial or critical, they should be honoring our task. Software tester works without the inner knowledge of the software. So, instead of criticizing them for not being able to find bigger issue than the one they reported, honor them by fixing their reported issues (as assigned/ prioritized by Manager). We work with the highest risk. We double check Developers creation. So they have a bit relaxed position that someone else will be picking up their mistakes.  QA person does not have that. Whatever he verifies goes to user and if anything happens in the field, QA will have to take the heat. 

QA person should also be sense-able about their task. They will have to use their brain to make things easier for the person who will be fixing this. 


2. ProcessNot every company has a structural process that follows the standard/ steps of SDLC. What method of SDLC used entirely depend on the company. At least some process of software development has to be followed. Company who produces software only, may have more proven structured process than the one who uses firmware on devices or a bank who developed/ maintain their banking software. I have mixed experience working on two types of those companies. I have seen a common pattern. Process is always hard to follow. Process make more side work and it may be less flexible. If we all follow the process, there will be less miss-communication

My experience tells me that people involved in this process, sometimes tends to work outside the process. And when people see that management is not that strict about it, it becomes more of a practice. For example, I have been assigned many times to test software and not to record them as official process (no entry in bug tracking system, verbal communication, email, word doc list etc.). Why I have been assigned like that in the first place is a different question. My point is, my management allowed developer to have that out of system work. For the sake of the product deadline, I did not argue about this. 

Another experience is, I tested one product, entered all the bugs in bug tracking. Seat together with management and developers. Assigned and Prioritized the bugs. Everything was looking promising. Then after a while, due to shortage of man power, priority of bug fixing became lowest and rhythm is gone. Personally, I like to pursue the bugs that I reported (no matter whether anyone likes it or not). I reported bugs and I want it to be fixed or at least my indication that someone will work on it.  

Not all the companies have complete specs to begin with, which actually leads to all miss-communication. If the gray area is not defined properly, then it makes some useless communication whether identify the reported issue as Bug or Issue or Enhancement. Think out all the possible scenarios or at least when testing team comes with those scenarios make a decision with involving developers. 

3. Environment - people, mentality, process, top management and other relates things makes the environment. When the environment does not understand the significance of testing, it starts to create all sorts of problem. Some examples below:

A quote from management "What is the status of the software?" asked in a meeting. Answer was given discussing the status with developer. Development is near to complete. So the top management getting the idea its complete and they were discussing the release/ marketing plan. I felt like I do not exists! Nobody cares whether that developed software is usable or not? Whether its tested or not! That's what I have seen multiple times in multiple companies.

Another example, another quote from management "Do not worry. You don't have test it to death. Nobody will be killed with this software". I do not test it just the shake of testing. I know and understand deadlines. I test the software so that people has less chance to get hurt. People may not get killed but they can be hurt by the software and those people even may sue the company for that. So, it is DAMMMN important to test the software even no one will be killed. 

4. Industry  - 20% less salary. and Its project basis mostly (3/6/12 months). 

I have seen companies who does not prefer to hire full time tester as according to them we don't have work all the time through out the entire SDLC. Philosophy is when you have some software build, then tester can work. Else he will just be a idle resource. Hence they don't need a full timer.

At the very end, it's more about  money than anything else. I'm sorry to say it this way, but that's the truth. Having the same background of education and experience in software industry, just for the demanded role, other people (especially in development) gets more importance, security and money. 

As a tester, when I have to give same effort and time, if I have to think about other things - job tenure/ security it automatically diverts myself from concentrating on testing. I'm not saying other people does not have to got through this, they does; it happens more frequent to us than others.   


I have not worked for Google or Microsoft or Facebook etc big companies. I do not know how they work. But I'm quite sure that no one from those companies will every search with "I feel useless in QA". Its the small to medium sizes, where most of us work and gets the feeling like this. I would not say i have seen many/ everything... these are some of my experience in this field. 


Okay, too much of negative words. At the very end, I would like to share one story ....
There was a company who build different devices, and usages software/firmware to run those equipment. It was a small company. Did not have that many employees. They had a development team working on.  Some people were testing their product as an ad-hoc basis. After a while they decided to hire a "Tester" as a contractor to see how it goes for 3 months as an experiment. They interviewed and hired a person. That person came from a different part of the world. That tester proved himself and company decided to hire him full time as "Test Engineer" before his contract end. Then after 3 years of that he was promoted to "Sr. Test Engineer". The job that started with a 3 months one did not end up there, it continued. 

Don't feel bad/ down, if you can prove yourself, you will be rewarded. 


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...