Common mistakes of Fresher Automation Test Engineer

In this post I would like to list out some common mistakes that a Junior Automation Test Engineer can make. I have been reviewing code for many fresher Automation Test Engineers for years and myself also started at Fresher level, so these mistakes are the mistakes I made in the past as well.

Hope it can help you avoid these common mistakes. (still Updating !)

I. CODING

• Not follow naming convention and coding standard.
• Reinvent the wheel, not using a built-in function or common libraries.
• Write duplicated code, not check if there is a existing code that do exactly the same function.
• Write code for something they think will be used in the future but not being used anywhere at the moment.
• Not do self-review his/her own code before assigning to reviewer.
• Overuse branching or use it in a improper way, e.g. unnecessary if-else, branch nesting, wrong condition logic, iF condition always True so never go to ELSE code, …
• Write new code in a class/module/package which is not related to what the code is about.
• Write too long method or class. it should be split to some small ones.
• Over-complicated the code. The code should be simple and concise. You don’t need to use fancy tricks and avoid over-complicating things.

II. Automation Testing Mindset

• Focusing on quantity but quality of the tests. Not check enough test coverage for the feature. It is easy to make the tests passed, however the more important thing is how good is your tests, can they ensure the quality of the product ?
• Automate everything, write as many tests as possible.
• Too many assertions or test many things in a single test case. Not design isolated and atomic test scenarios so that some tests may be failed when running in parallel. 
• Missing important assertions in the test such as the expected properties, business logic. It makes the test not reliable.
  • e.g. an API test to verify updating user profile, only assert 200 OK status code but not checking if the updated property is really changed or not
• Always try to fix all broken tests instead of ensuring the quality of functionality. Make sure you give the team a feedback asap about the quality of product. If there are some broken tests related to any development changes, only fix it if it does not take long, otherwise, if the broken tests are too complex, try focusing on checking functionalities manually and fix the broken tests later. Also , try to detect the broken tests early in SDLC, don’t wait until the release date to run all regression tests, daily regression tests can catch this.
• Fear of ask questions to clarify or confirm the requirement. Make assumption for unknown/ambiguous things like requirements. It may cause a rework later and wasting effort to fix things.

III. Selenium

• Locator Design: use only Xpath, include some dynamic attributes, locator is too long, locator is not unique.
• use thread.Sleep() instead of dynamic Selenium Waits.
• Wrong Assertion/verification is used. It can cause bugs escape in production environment (false-negative).
• Incorrect Explicitly wait Condition: e.g. to click a button, wait element exist instead of waiting element clickable.
• Overuse Click element by JavaScript: you should try to avoid using this as it is simulating real user behavior.