Be a defect hunter!

Photo by Gratisography from Pexels.

It’s me, Joise Mathew, I have been working in manual and functional testing roles for the past 6 years. My professional experience was strengthened by working at Oracle, Temenos, and LTI. I enjoy working at Tester work as a freelancer.

If you have a project proposal document in your hand, imagine that every single line from the product owner gives you a chance to find a defect. When you read the client requirements multiple times, you double or triple the chances to find a defect. As a tester what else you would do, nothing else other than logging defects and killing the developer’s sleep. Hahaha…! Raise bugs and disturb your developers always. I would never say that the developer is a friend in this war, treat him as an enemy and each bug is your weapon. Yeah, testers, it is war in the testing field and you must win for your customer. Cheers to all of you!

Let me speak about setting up the war field, you have to be very well familiarized with the project proposal as that is the bible of a tester before you kick off the war. You may or may not consider that a product owner knows everything about the product, still, you should do a 360-degree analysis of the requirement of the client. Please believe and understand that how you receive client requirements will decide your fate. As I said, before entering the war, you should wear and try on the shoes of your customer, developer, and product owner. You should start thinking from the customer’s point of view to understand what they need and how a developer is going to make it. Whenever you receive a project to be tested and delivered to the client in a bug-free state, you have to realize the importance of the client’s expectations. Try to foresee and fulfill customer satisfaction with your dedicated effort. Are you not irritated by seeing issues on the applications you use in your daily life? Absolutely yes! Hence, you must understand the relevance of bug-free software. Imagine that you are facing an issue during your payment on flight booking and not getting your ticket, how are you going to feel? We cannot even think about something happening on the payment gateway, right? Yes, that is it. We can’t let our application throw an error at any stage. In the same way, we should not let any issues happen with the application that we test in our work environment. Be the original customer of that application and start testing it from your end. Yes, as I said you don’t get to wear your shoes in the testing field. Just get in and wear the client’s shoes and start thinking from their perspective, assume that you are using it as an end-user, and do a post-mortem of the software.

You should be hungry enough before starting your testing process, kindly do a bird-view from the top (called sanity testing in the professional language). Just listen to your product owner’s words again and again. You should make sure to take up and initiate discussions with the developer and product owner as teamwork will get you the victory. I might say that rejected defects never state your ability as a tester, it just shows how involved you are with the software. If you feel so, raise it and sit back. As per my experience level, I see that a defect will always lead to another development or a fix for sure. Even though the perception level is different from person to person, still finding something that is not right should be raised.

I believe that agile methodology in testing is controlling software releases across the world. If you are new to the testing field, have you ever wondered what that is? I can simply describe that agile methodology as pure teamwork of doing something together by having great interaction between all parties involved until you deliver. You never wait for the complete software to be built and released, whatever is built by the developer will be tested by the QA team immediately.

As I stated earlier, we should expect to see an issue with what is being developed in the system. I strongly believe that if the software is delivered without having a defect, then something is not right. You should have defects that will enable you to test the software again and again. So, your primary target is to have defects in place for entering the war, once it is raised, you declare the war official. Fight further again and shoot towards finding more defects. Hahaha, developers should have nightmares after seeing your testing tactics.

Join our community today!

Become a tester