5 Excuses Every Software Tester Must Stop Giving

In this article, I have listed down some very common excuses that every software tester should immediately stop giving.

I have unlocked a pattern from my experience of hiring around a few hundred testers and interviewing a thousand others over a long period of time .

From all the discussions I had with fellow testers during interviews, I felt happy numerous times seeing the quality talent that we have in our community of testers.

But let me also share the other side of the story, the pattern that I am talking about makes me sad. I’ve never felt happy watching potential performers being locked into a virtual cage of responsibilities. I feel discontent seeing the rock stars performing on a controlled stage.

Excuses Every Software Tester Must Stop Giving

If you are still wondering what the matter and the baseline is, it is this – a considerably large part of our testing community is not having enough growth on multiple fronts after they start their testing career. Forget 360 degree, it is not even nearly half of that.

Sorry for being harsh, but it is real.

Who is to blame for this? Maybe awareness in the industry to some extent. Company policies and senior management too may be. But more than anything else, it is the Tester himself/herself.

Read it again, it is YOU. It is us. Because we become victims of the excuse.

Given below are a few patterns/excuses I have discovered:

5 Excuses Every Software Tester Must Stop Giving

Note: I nowhere mean that this is the case with every tester and every organization. But I have seen enough examples to say most of us are victims here.

#1) We don’t control our Test Environment, we have (read ‘very’) limited access

I often hear the statements/excuses- ‘We have just Read-only access to the environment’. Even worse – ‘We only have access to logs and nothing else’.ย  Everything else is done by either a Development team or some other team.

The work that will give us so many beautiful and fruitful insights about testing and many other technical kinds of stuff is not done by us. And maybe we are happy this way, but we should not.

Tell me one reason why you shouldn’t control your test environment and take maximum benefits of the same.

Here are a few possible benefits if you are wondering what I am talking about-

  1. You have full control over your test environment to make sure personally that it is an exact or near replica of the production environment. This will help you avoid a few surprises when your deliverables hit production.
  2. Know all involved components and all software used along with their versions for your product to function. With time, trust me you will have many insights about their work, limitations and possible failure points.
  3. You have enough access to do at least first level debugging in case there are Infra level issues. E.g.: Setup running slow, checking CPU, memory utilization and logs at every level of flow is not rocket science.
  4. You own control over the setup so you know what you are changing and what build you are deploying. You are much more confident than before while shipping the release ahead.
  5. You learn it and you learn it all. Though it is Linux based or Windows based.

Makes sense? Let me continue if you have at least agreed that there are benefits.

Now the question is what changes you can make to your team/organization to make this work. And that’s exactly how you will do it.

Well, as I don’t know your team, your leads/managers, or your organization, I won’t be able to help you with this. Sure, I can definitely share a few things that might work. Try working very closely with your Dev or whichever team owns this and see what and how they do stuff.

The way they login to the environment (server), the way they logout and everything in between. Once you gain some knowledge, you will have the confidence to say few words and give some suggestions when a similar situation occurs again or if a similar activity is to be done again.

Obviously sooner or later this confidence will be seen by your developers/leads/managers. That is the time you can ask for control. And tell me one strong reason why they won’t give you that? They should be more than happy to do so if you have shown the needed capabilities.

Believe me, they have much more work to do, so it shouldn’t be hard for them to release the control to you. I hope that is the case.

#2) We don’t deploy a build, some other team does it for us

You can come to the office on a Monday morning. You will notice there are a few issues in the build causing blocker. You need a new build from your Build repository. You can raise a request or contact your Dev or deployment team. Oh, they are busy with something. But they manage and do it after some time.

Now tell me, why all this? It is not as complex as it looks.

When to take a new build is surely something a Developer can suggest as he is the one who will be committing a feature or a bug fix. But when you simply need to trigger it and deploy it, why should you wait or depend on someone?

Recommended read =>ย Know About Release and Deployment Management Processes

Having the ability and authority to deploy whenever you want makes your work lot easier without any wait. Do you see that? This will also increase your Turnaround time for daily testing. However, we are debugging some defects with added loggers or taking the new build to verify resolved bugs. Or be it taking a fresh build and starting with testing a new feature.

Let me tell you something from my personal experience. It is not only about time. Deployment teaches you so many things that you can’t imagine. The reason is, it fails often. The application sometimes stops working with the new code. Often deployment itself fails. And every time something fails, it pushes you to debug it. It pushes you to search for something on Google or ask someone a question or the best ask yourself a question.

It makes you think.

Of course, it is not really a software testing, but it surely is testing your abilities.

I would say a large portion of my learning apart from pure software testing is from Deployment and Maintenance of environments.

  • I don’t remember how many trial and error attempts I performed for something, the count must be a few hundred.
  • I don’t remember how many times I went to check some release manual of some software.
  • I don’t remember how many times I hit that Google search button or navigated to that stack overflow link.

All I know is- it gave me a lot, taught me a lot.

The remedy for this is very similar to the first excuse we talked about.

Learn it, show it and ask for it. It might work.

#3) We don’t debug an issue, we found the steps and logged it

I won’t go very hard on this as in an interview you don’t get a chance every time to discuss particular defect from candidate’s own experience and investigation/debugging done by him/her.

However, I can surely say that not all of us challenge our senses before passing on the defect to the developer.

Many times the log says it all. Often the pattern of an issue says it all. Many times it fails because some prerequisite service was down.

So in short, many times it is possible for us to get to the exact root cause or at least reach near it.

So please ask yourself a few questions, not to help developers but to make your test cycles faster and for your own growth.

You are the remedy and no one else.

#4) I don’t know why it happened. The developer resolved the issue and I simply verified it

Sorry but I get annoyed hearing this.

Every single time, it annoys me when I ask Tester a question- Why particular defect was faced or what was the RCA (Root Cause Analysis) and he/she answers ‘I don’t know’.

Have we taken the black box word this literally? How can we not ask the Developer what exactly he fixed? Why can’t we ask if authority is an issue?

I am damn sure that 99% times we don’t know the Root Cause Analysis (RCA) or fix because we don’t ask for it.

Believe me, knowing the exact fix, module in which the fix was done, whether it was in the front end or back end, whether it was injected in any feature development or some other defect’s fix, will always help you in your testing. Always.

Apart from this, this information helps you know a lot of technical stuff which may be otherwise you will never come across.

Remedy? Ask for it. Demand it. Whichever works.

#5) I didn’t get the opportunity to work on anything other than Manual Testing

This excuse may be valid to some extent considering the possible workload on you or the restricted responsibilities given, but not completely valid.

The problem here is, we say that we didn’t get the opportunity to perform non-functional types of testing, or we are not supposed to do it or we don’t have time.

Agreed, learning always demands time. But isn’t there anything you can change?

While testing that new feature or while testing that one API,

  • Isn’t it possible for you to keep a watch on the response time?
  • Isn’t it possible to ask your Business Analyst about the load this particular feature/module/API is expected to handle in production so that you can test it?
  • Isn’t it possible to at least perform basic security checks like session expiry, URL tampering or XSS handling on that website form you are supposed to test?
  • Isn’t it possible to at least say that this particular ‘Submit’ or ‘Help’ button doesn’t seem to be properly located or not easily noticeable and plays your small role in making the product more usable?
  • Isn’t it possible for you to start with something and then keep learning it more and more?

The answer is YES, small or big depending on various factors surrounding you but it is surely not NO.

If your responsibility doesn’t demand it (because there is some other team for it), no one will stop you investing extra time for your own learning. Self-learning in extra or free time is always possible I think. So find those possible extras and start doing it. Now.

Conclusion

I hope I was able to trigger some thoughts and learning ambitions in you.

Please forgive me if you find me harsh, but believe me, my intention was to be 100% clear so that the message reaches out to you with the needed seriousness. Hope it works well for you all.

I will be more than happy to know any uncovered aspects around the possibilities I talked about.

About the author: This article was written by STH team member Mahesh C. He is currently working as a Senior Quality Assurance Manager with experience leading the testing front for multiple complex products and components.

Thanks a lot for reading this article. Feel free to share your views/feedback in the comments section. We would love to hear from you.

Recommended Reading

48 thoughts on “5 Excuses Every Software Tester Must Stop Giving”

  1. Above mentioned all 5 points are valid and most of testers faced in the starting of career… its time to learn and change our-self.

    Nice Article..

    Reply
    • Glad that you liked it @Krishna. Happy Testing.

      Reply
  2. So well explained .I have followed some of the points which you have mentioned in 3,4,5 .Of course not excuse one but the learning phase .I believe get known for the RCA ,helping me to increase my technical knowledge behind the particular feature and its functionality flow .Some times if you know the root cause of the issue and log it with the RC explanation it helps Dev team to find out the problem easily as they have lots to do in their stack. I will try to learn build and deployment process.

    Reply
    • Thanks @Krunal. All the best.

      Reply
  3. Great article. However, what is the point of it? Can a tester be blamed? Yes, if the tester can set all rules, especially regarding development process, in other cases it will be a responsibility of test lead and tester just as a person who is doing its job. Agree 100% with a root of the defect.

    Reply
    • Hello @Muxa, even Test lead is a tester right? ๐Ÿ™‚ Sorry if I wasn’t clear but this article was for every tester. We as a community needs to understand and adapt few things.

      Reply
  4. Nice one !!

    Reply
    • Thanks @Shankar.

      Reply
  5. Its nice article. If you want to journey along with the industry near future we have to incorporate what author pointed out. Its very good article!!.

    Reply
    • Thank You @Ravindra. Happy Testing ๐Ÿ™‚

      Reply
  6. Well written article. It all boils down to being ‘curious’. The more curious we are, the more we learn. It reminds of the following equation from Thomas Friedman’s book “The World is Flat”

    CQ + PQ > IQ

    where CQ = Curiosity Quotient
    PQ = Passion Quotient
    IQ = Intellectual Quotient

    Reply
    • Absolutely agree with you @Vinod.Thank you.

      Reply
  7. Fantastic Article !!

    I will share this article with guys who are giving such excuses ๐Ÿ˜‰

    Reply
    • Thank you @Gaurav

      Reply
  8. Really so simple words, but very helpful

    Reply
    • Thanks @Ahmed.

      Reply
  9. Everyone should follow this…nice article!!!

    Reply
    • Thanks @Sindhu for kind words.

      Reply
  10. Well put.Its all about doing it. Uncover the unknown and see the difference it makes. Testers shouldnt draw boundaries and restrict themselves.

    Reply
  11. Very well said @Harish. Happy Testing ๐Ÿ™‚

    Reply
  12. Solution oriented article.really helpful

    Reply
    • Thank you @Priti.Happy Testing ๐Ÿ™‚

      Reply
  13. Awesome, thought-provoking and motivational article. Not harsh at all, just true. Thanks for writing it.

    Reply
    • Glad that you liked it @Irisa. Thank you.

      Reply
  14. Its a very motivational article , 1 or 2 points are there in my daily task list but want to push all of above you just mentioned in your article. Thanks Keep motivating us.

    Reply
    • Glad that it helped and motivated you @Sanjeev. My pleasure. Good luck.

      Reply
  15. Great article! Thank you Mahesh!
    The challenge that I encountered in my work is typical testing environment issue. Devs are trying to stable the testing env but not very successful. I was intention of using the local env on my local machine to do testing, but was told that the result might not be reliable. I am in the middle of waiting for a more stable testing env and occasionally using my local machine for a fairly simple verification. I will raise up this question in Retro soon and be confident to gain more accessibility to our env.
    Thank you again for your great article! Looking forward to reading more.

    Reply
    • @Diana Thank you. Glad that it helped and motivated you.

      Reply
  16. Hii..
    Very nice blog,You are providing wonderful information about software testing,It is very good article useful to every software tester,
    Thank you very much for sharing.

    Reply
    • Thank you @Vishnu. Happy Testing.

      Reply
  17. Looks like only hindu guys read this article. Employees?

    Reply
    • @Random Reader Thanks for pointing the typo. And yes, I will be more than happy even if only Indians read it:)

      Reply
  18. You have a grammar error in #1 – Even worst- โ€˜We only have access to logs and nothing elseโ€™.

    Worst should be worse.

    Reply
  19. Great article, and i agree with the RCA thing

    Reply
  20. great article.

    I think any tester working in an agile software development environment would have consciously or subconsciously done all you have mentioned above.

    Reply
  21. Good one Mahesh C, I’m totally agree with your article. But not all testers are luckiest as you mentioned because depend on the company also. I’ve done all you have mentioned above. As a tester, you should able to learn the max from BA,Developer or any of the project team member. Be a proactive tester ๐Ÿ™‚

    Reply
  22. This is a nice article and 100% true. agree with all the points. Thanks for sharing your experience.

    Reply
  23. Hi Mahesh,
    The points that you have brought are completely valid ones. Yes the testing engineers should be aware of these points.Hope the newbies coming into testing industry would work on the above mentioned points.
    One thing I felt is the tone of writing interrupting with the content that you are trying to explain.No offense, just a friendly feedback.As this is a public and open forum thought you would also consider the wide range of audience coming to this site.Hope you would look into it.
    Thanks
    Raj Kumar

    Reply
  24. Nice Article and needed for this time

    Reply
  25. Hi Mahesh,

    Excellent article. Really runs through the real and genuine testers problem for excuses. I must say, i have faced exactly the same problems during one of our product release. We took it as a learning from it, and right at the development kickoff meeting of our new product listed what is expected from testing team. The management was delighted as the entire testing team debated for better product release mechanism and management of test activities.

    Reply
  26. Great article.

    Reply
  27. Very informative article. It gives me a lot of curiosity to learn more on these testers. Thanks for highlighting the points

    Reply
  28. It’s really nice and valid topics which you are covered.
    Thanks for sharing !!
    It’s very useful !!!

    Reply
  29. Nice article. I will add it to my checklist. Thanks for sharing.

    Reply
  30. Hello, Thanks for sharing this Article. This is very Helpful and easy to understand. The information you provide about all the 5 Excuses Software testing. Information about all 5 points are very helpful for every tester who all are faced in the starting of career information regarding development process and what are the responsibility of test lead. And agree with the root of the defect.

    Reply
  31. 4th Point is an often we see in our Testing Cycle. Developer sometimes fix the Defect but sometimes in deployment they miss the files where bug was fixed or they unknowingly upload previous file. As a Result this point occurs a lot of time .

    Reply
  32. Nice article. Really made me think what extra things a tester can do to deliver a quality product.

    Reply
  33. This is great list of Qa Testing Blog, i am Reading regular bases regarding Software testing.

    Reply

Leave a Comment