13 Reasons Why: You are not a good automation tester

So in my flight from Bali to Jakarta last month, I was thinking about how can I ask my team members to become better in automated testing so I opened my Keep notes app and started writing, below article is a result of that.

Please note, everything I mentioned here is my own opinion. I try to give some of the reasons here using real-life similarities I see so if you don’t like these similarities then you are free to suggest some real-life examples in comments.

1. Functional Testing has become your Ex-Yes this is the biggest reason I see these days with the new automation testers, they don’t love functional testing anymore and if you ask them to do some functional testing task then they feel they are wasting their time. No people never forget your first love which is “Testing” and just because automation offers more salary and more technical skills, it does not mean you can’t become better in functional testing. You won’t become a great automation tester if you don’t know how to create/execute the functional test cases, The whole point of having the automation team in the company is to find functional testing bugs otherwise if only automation was needed then the company could have just asked their Development/DevOps team to do that part.
2. You don’t talk to your Ex(Functional Testers): No matter how many automated tests you have written if you are not talking to the functional testers before and after creating the tests then you are not creating a test based on their expectation, therefore, your tests have no value at all. You need to take a sign off from functional testers and product owners on your automated tests so that they can trust the automated testing and leave the regression testing to automation rather than doing that themself.
3. You don’t want to increase your friend circle(tech stack): Ok,You have made a very good friend by learning java+testng+maven+selenium but you don’t want any new friends like python+pyunit+selenium+pip or js+protactor/cypress+jasmine/chai js because you are comfortable just roaming around with your best friend. You are wrong my friend because life/career is much better and beautiful if you have multiple friends in your life/multiple tech stacks in your career.
4. You fall in love with looks and not with the inner beauty(You love doing UI automation and not the backend automation): Just like in life, initially, you may feel attached to a person based on looks but in the long term you only love a person when you get to know about his/her nature similarly you may think UI automation is enough for automated tests but in the long term you will find out that most of the automated tests are useful if they are written for backend logic tests. Backend tests are faster, reliable and more loyal than UI tests.
5. You are living your life without any milestones(You are writing automated tests without assertions): When you are living your life, you have certain goals/milestones right, maybe you want to buy a home before 35 or want to have a car within next 2 years or start an NGO for poor folks, without goals/milestones you would not feel motivated to do anything similarly your goal as an automation tester should be to verify each and every action and element behavior on-screen /API without them your tests does not add any value to organization. Every test script code should have at least 2-3 validation (maybe more based on requirement) . I review many hiring assignments where test scripts have no to very fewer assertions for elements, titles, and steps. Try to add as many assertions as you can in your tests even when it is not mentioned in functional test cases/assignments.
6. You think you are the best(Your automation tests are the best): If you think you are perfect as a person in life and there is no improvement needed in personality then you are completely wrong, As a person, we meet someone better every day and learn from them similarly you need to improve your automated tests regularly by taking inputs from peers/developers/testers/product managers/new members.
7. You are a jack of all trades but master of none( You know bits of many automation tools but did not master anything): Yes it’s good to learn new things but you need to at least have one skill where you have an advance level knowledge otherwise when your juniors will ask some advance level help and you are not able to help them then they will stop asking for your help and may lose respect for you and this can become a very bad thing.
8. Your monthly budget is more than your salary[You choose paid/costly automation tools rather than based on team budget]: Just like in life you choose household items based on your budget/lifestyle, As an automation tester you need to choose automation tools based on company budget. When I was working in bigger companies such as Cvent/G4S I used paid tools such as SoapUI as it was easier and faster to implement and company budget allowed me to use paid version too but when I was in EngineerAI(start up) company budget was so small so I used rest assured because it was open source but may need more time compared to SoapUI.
9. You like writing duplicate code-Do you like to do duplicate activities in real life no right then stop writing duplicate code in your test scripts, I see many new/mid-level automation tester using duplicate code in their scripts, for example, an application has multiple buttons and so they make click method in page classes for every button click, rather than creating a new method every time how about creating one method which can click on any button based on button text parameter? or how about any kind of element so as a good automation engineer you should always think about writing less/generic code that can do more things.
10. You like to remove assertions/change assertions from tests just to make your reports green- I see many automation engineers where they just remove the validations or change the step actions if the test behavior is not consistent/they are not able to find the failure root cause. Management pressure plays an important role here but will you do the same thing in your life too? just to please someone will you agree on their terms and conditions? I leave the answer to you.
11. You don’t like to do an investigation of failed tests- Suppose in real life you see a message of 50000 bucks are deducted from your bank account and you are not sure who deducted it, what do you do? You immediately see bank statements, see the details of the transaction and if it is unknown /suspected transaction you report this to the bank but do you do the same when suddenly your test cases start to fail even though there were no changes made in development codebase? if the answer is no then you may need to improve this skill to become a better automation engineer, do not assume anything, find the exact root cause of failures by doing proper root cause analysis. Every test script code of yours should be traced through logs in report/logfiles.
12. You believe in “Jugaad”(temporary solution) rather than a permanent solution– Jugaad is such an Indian word but after working with us and Indonesian automation engineers I see that this is a global thing. In real life too we can see short term benefits of a temporary solution but you need to understand any solution that is temporary is not a solution at all, would you trust a driver who has a temporary license to drive for you in mountains? No right you will wait till he becomes an expert/learns to drive in the mountains and then you will be able to trust him. As an automation engineer you can use hard wait, hardcoded data and absolute xpaths for a temporary fix but will it be maintainable for the long run? No right so stop using these temporary fixes and always think about a permanent solution.
13. You think that you have no role in defect leakage- No, if any defect is coming in production related to regression testing then you are more accountable than functional testers. It’s your responsibility to automate tests in every aspect even if functional tester forgot to add them in test cases. You are a second or third reviewer of test cases and if you are saying that automation coverage of a particular module is 95% or 100% then you would be accountable for any missing test case too. Just like in real life taking accountability of your failures is a good thing.

Do you agree or disagree with my thoughts? let me know in the comments.