People mostly talk about the good and the best practices but it is also important to know the worst or the bad practices which a Software Test Engineer must not follow or practice. At times people don't know what they might be doing wrong unless they are being shown the right direction.
So as a software test engineer we should not follow the below given bad practices:
- Do not start working on tickets which are not properly defined or described. Unless proper description or methods are provided to test a certain functionality, one should not immediately jump on it. Rather a software test engineer should communicate proactively to find the details with the product manager or developers and then then put those details in the ticket and then start working on the same.
- Do not test too many things at one time. If there is time crunch then one should only focus on testing the basic functionality first and then test cases with medium or low priorities can be tested.
- Do not automate all the test cases from day one. This is the worst practice and mindset to follow when one has started writing test automation. First only the highest priority tests should be automated, monitored, fixed for bringing in stability. Once a test engineer feels that the tests are stable and the test environment and other requirements are stable enough to be relied on with confidence, then only medium and low priority tests should be automated.
- Do not work quietly and be secluded from the team. Please do interact with everybody in your team and treat all as if they are your friends. Be open in expressing your views and yet remain professional. Remember a good communication, friendly and healthy team relationships are always valued everywhere.
- Do not discourage any team member if someone is giving some ideas or suggesting some new process or solutions. First listen patiently and then be a part of healthy discussion. Blocking or not letting someone speak or straightaway rejecting suggestions indicates you are no team player and nobody would like to work with you by their own will.
- Do not try to show or boast that you know everything. This kind of behavior is not social rather you should be like a mentor and humbly show the right solutions or directions.
- Do not be too descriptive or too short in test documentation. Too much of data is also boring and not interesting. Less information or data also is not welcome as it proves to be useless then. Be accurate and be precise.
- Do not try to hide reports, breakages, defect leakages and outages/incidents. This will bring you bad impression and will hamper your rapport. These things are caught sooner than later and then does more harm than benefit. Instead be transparent and humbly accept the mistakes, ensure that you will work to make sure they don't happen in future and provide full analysis on the current or arrange a post mortem session for the same.
- Do not avoid putting too many nitpick comments while reviewing a peer's pull request. Rather be a bit generous and only point out genuine issues with the code. Never try to delay or stop progress if you personally don't like the colleague. This is most common occurrence in places where the work culture is very competitive and everybody wishes to succeed faster.
- Do not be slow in responding to emails or direct mentions on Slack etc. If one is fast and active it generally makes the Devs and managers feel that as a test engineer you are always on your feet and ready to deal with any type of situations.
- Do not stop communicating with higher management regularly. Make sure you meet at least a product manager, or an engineering manager or a technical program manager from your team once a week. Make sure that you know what they expect from you, what are their problems and try to solve them or suggest ideas or solutions. This will make them see you as a valuable resource and will help you grow.
- Never stop helping other Test Engineers, Devs or Managers. The more you help the better you understand things and the better relations you establish in and out of your team. Being a part of team and helping others succeed, helps you succeed too.
- Never feel shy to learn even from someone you don't like much. Like and Dislike are just emotions rather the larger goal is to acquire knowledge. So bury the hatchet and bring forward the friendly and cheerful side of your personality.
- Never try to discredit someone if their role/contribution was lesser than yours, remember a team wins if all in the team wins.
- Never confront someone rudely if there is a disagreement. Rather discuss peacefully with open mind.
- Never work overtime on things that you could do in a much shorter span of time if you could have managed your time properly or could have done those activities in allotted time slots per day. Like creating a test report of last night's failures. If you would work on the same at the time of your daily sanity testing then you could apprehend what would happen. So make sure you do the work that is required in desired time slots and manage your time better.
- Know when to stop trying and when to ask for help. If there is test case to automate on which you have spend a day already and there has been no success. So do not waste more time on it and ask for help from someone. Also the point here is to not straightaway ask for help if you will do that then you will never learn and always go asking for help.
- Never hesitate to escalate the situation to higher management if the work is not progressing and is dependent on someone. This should not be done in bad intention but only when you are waiting for a dependency for your testing to complete but the progress is not being made or is being delayed without any appropriate communication.
I will bring more light into such bad practices in upcoming blogs but in case you wish to learn GOOD Practices and wish to be successful in an Agile Test Environment. Please take a moment to read my book Click Here
