Bad practices for a Software Test Engineer

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:

1. 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.
2. 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.
3. 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.
4. 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. 
5. 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.
6. 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. 
7. 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. 
8. 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.
9. 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. 
10. 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.
11. 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.
12. 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.
13. 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.
14. Never try to discredit someone if their role/contribution was lesser than yours, remember a team wins if all in the team wins. 
15. Never confront someone rudely if there is a disagreement. Rather discuss peacefully with open mind. 
16. 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.
17. 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. 
18. 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

Why you need to be prepared before starting as a test engineer in agile environment?

Why do you need to prepare before exam? Why do you need to preheat oven before baking? Why do you warm up before exercising?

For all of the above questions the answer is same so that you are better prepared and ready for what follows.

In the same way you need to be prepared when you are going to get started as a software test engineer in agile environment. Agile environment and agile development or testing methodology is fast paced and competitive.

If you miss a deadline, if you leak a defect or if you fall behind a task then whole product life cycle can change and sometimes can have drastic effects on future and upcoming projects which are in the pipeline.

So the best way to get ready is know and be well prepared to perform as expected and even surpass the expectations set on you. In Silicon Valley and globally too there is has been a trend where work culture has evolved from being easy to tough, and cut throat competitive.

Every day more and more qualified engineers are coming in the job market and some of them are toppers, some of them have more skills than others etc. Also there is already a pool of experienced software testing professionals in the market who compete to get the best job, best salary, best role, be benefits and best of everything.

So think if you are not prepared and jumping in agile testing or agile development and you don't know how work is done in this methodology. How you will cope with it, what are the tips and best practices you need to follow to succeed and grow. What terminology it is based on, what processes are being followed, how testing is done, how work is assigned, and many more such questions. How do you plan to get answers for them. Do you plan to work and learn that is good strategy but it is all catching up rather being in the action and performing at your best.

So if you feel what this is all about and if you think you wish to learn. In order to get your learning back on track and be prepared to win in agile testing please read my book available at link below:

http://mayankmohansharma.blogspot.com/2017/04/my-first-book-published.html

Mentoring in Software Industry

Many times people think that mentoring is just training people and making them learn certain skill set by giving few classes and the jobs' done. Rather it has all of these things like tutoring, knowledge transfer or knowledge sharing etc engulfed in itself.

Mentoring is lot more than just training and advising people. It is actually you as a Mentor taking responsibility and ownership of making sure that whoever you are mentoring becomes successful and learns how to use certain skill set or knowledge for personal and organizational growth.

Mentoring means following up regularly and monitoring the progress closely. It means making people understand technical topics easily and ensuring that people remember these things without much revision.

For example: if you tell a person that bash_profile is a file that saves certain paths and configuration settings on your mac and this file gets loaded before your terminal loads shell environment etc. Then it will be very difficult for someone to understand this. But if you tell them that a bash_profile can save short forms or aliases for certain commands that you use or type usually, and it can also be used to save path to a certain directory under a shortcut or can be used to save certain access keys etc then the person will remember this for long and can easily know what the practical application of the bash_profile is.

Mentoring helps a Mentor to understand judge his/her capabilities and also lets them know that how well they communicate. Another important aspect of mentoring software engineers is that we need to keep track of all the mentoring/training sessions with proper documentation. This helps people to easily follow the steps and follow the instructions when they need to recall something in future.

1. Make fear go away: Make sure that you infuse confidence in your mentees that coding or learning a new tech tool or programming language is not difficult and they have nothing to fear as you are always available to help them
2. Go easy with sessions: Plan sessions to go easy on the mentees. Make sure the initial sessions are short and are precisely pointing out the ways by which it will help them.
3. Always have practical exercises during sessions: Remember only theory never helps unless your mentees are armchair detectives. A little bit of practical session will always help them retain the knowledge for long and will give them opportunities to ask questions and explore.
4. Document as you go: Document each session as you go along giving training sessions. This will help in future by providing references and create a central knowledge repository to share and expand.
5. Test and Analyze: Regularly take frequent quizzes so that you can judge the level of understanding that mentees are holding.
6. Encourage: Give kudos to good mentees so that they are motivated to do even better.
7. Give space to explore on their own: Give them time to explore certain problems on their own so that they can develop self-exploratory and problem solving skills.
8. Continue the above cycle: Proceed with the above points until all the desired skill sets are developed.

This is how I perceive and try to mentor software engineers. Feel free to provide suggestions/feedbacks. Thanks for the read!

Later on we can deep dive in to how it actually works but the first step is to make people understand the need or application of the thing we are trying to tell them about

How to approach participating at Hackathons or Innovation Weeks

Nowadays Hackathons or Innovation Weeks are organized in almost every company. The goal of these type of competitions are to bring out the hidden talent or ideas from employees which otherwise remains hidden. These talents or ideas or concepts remains hidden because first of all there is always lack of time. Second thing is that the priority of actual work is always greater than any other thing for an employer. 

So when you get time to do something you have always wanted to do at your workplace in terms of being creative and floating and trying out new things then this is your time to show what you have it in yourself.

Here are few points to consider when you are planning to work on something in the upcoming Hackathon or Innovation week:

1. Try to find solution to a problem that is related to your work and your boss also agrees with you that it should be solved. 
2. Be clear of scope of the problem on which you will work on as sometimes can be very huge to solve and you cant get whole of it covered.
3. Make sure you have the right and balanced team with you. 
4. Building a team and working with your team is very important for those professionals who feel and have got feedback that they are not very good team players.
5. Have a pitch ready that clearly states your problem statement and what is your approach. A point or two stating that how this problem has been a bottleneck will strengthen your case.
6. Work by enjoying this time with your team don't stress out too much.
7. Be focussed on the minimal viable product approach and do not try to put much in at first go.
8. After the MVP is done make a brief plan on how you would like to go with it in future. 
9. Provide estimate of how much time it would take to make the final product ready for deployment.
10. Make the final presentation representing your ideas plus points and present it with passion like it is your startup idea.
11. Enjoy the win with team as there is no one actually loses when all work together for good.

Thanks for the read!

Get my book on Software Testing and Agile Environment from here!

Get and Read my book "How to start as a Software Test Engineer and be Successful in an Agile Environment" from the below given links:

It is available at below given links:

My Amazon profile as an Author: amazon.com/author/msharma

Audible, Kindle and Paperback edition: https://www.amazon.com/Mayank-Mohan-Sharma/e/B06Y3G4R75

Indian Paperback Edition: https://pothi.com/pothi/book/mayank-mohan-sharma-how-start-software-test-engineer-and-be-successful-agile-environment

Amazon India Kindle Edition: Amazon India Kindle Edition Link

Amazon India Paperback Edition: http://www.amazon.in/dp/9386503131

Flipkart India Edition:https://www.flipkart.com/start-software-test-engineer-successful-agile-environment/p/itmeuaq5acrhnggv?pid=9789386503138

Paytm India Edition: https://paytm.com/shop/p/how-to-start-as-a-software-test-engineer-and-be-successful-in-an-agile-environment-9789386503138_24933

Tips to be better as a Test Engineer in Highly Agile and Complex Environments

Test Engineers already are great and do their best to keep bugs and defects aways from products and services. Here are some tips I have learnt over the years that will just help them to be better. If you already know them then make sure you tell them to a Test Engineer you meet/talk with to make him/her also succeed. 

So here are the tips:

1. In daily scrums just don't listen the updates but think what you have on your plate for the day. Make it clear if something is ambiguous.
2. Adding a leaked defect to test suite does not help alone. A post-mortem of the cause of defect leakage for sure does.
3. Integrate Test Reporting with IMs for instant and hassle free report viewing.
4. Create bugs for any doubtful functionality or behavior.
5. Be proactive in communicating problems, achievements etc.
6. Estimate story points for each Testing Ticket so that you get ample time to test it.
7. Before automating or testing make sure your test data is accurate and can be prepared easily when needed. First apply effort in making test data creation faster and reliable.
8. Always communicate the test coverage to all stakeholders regularly.
9. Discuss with senior engineers and leads out of your immediate team also to find out ways to improve processes, tests, infrastructure etc.
10. Make a point to learn one new thing per day.
11. Be bold and speak out any thing that needs to be known to the team or stakeholders.
12. Build documentation with the code in form of inline statements etc. 
13. Take opportunities to mentor new team members.
14. Remember planning and strategizing is always welcome even if the time provided is minimal. Prioritization can make your life much easier here.
15. Fast and close communication with Devs is the fastest way to get a bug resolved.
16. Think retrospectives as the time when you are playing judge of the process/project and have to suggest improvements and tell about shortcomings fluently.
17. Give advance notice of personal time off etc for team to plan ahead. 
18. Mark your absence as "OOO" next to your name in present day messaging systems like Slack, Hipchat etc.
19. Create personal notifiers or bots that notify you when something related to your area of expertise is being talked about at Instant Messaging Systems.
20. Enjoy and do team outings! Make Testing Fun!

Tips to succeed in Highly Agile and Complex Environments

I have got opportunity to work in all types of software development methodologies from waterfall to v-model to rapid prototyping to agile. I have been very grateful to all companies and people I worked with who have helped me learn so much in such a vast and highly technical industry. 

Today I would like to share few tips which might help fellow test engineers in getting successful while working under a highly agile testing software development methodology. But first I will tell what is agile methodology and how work is planned under it. 

• An agile testing methodology has usually one or two weeks sprints or cycles in which a product manager/program manager, engineering lead/manager, engineers, test engineers, designers come together to plan out their work for the upcoming week or 2 weeks. This is basically called Sprint Planning.
• Work is usually measured by story points or effort required which in turn is given weights using Fibonacci numbers i.e. 1, 2, 3, 5, 8, 13. 
• Work usually includes new features and products but could include backlog of work and bug fixes. 
• All the work is tracked by tickets (most favorable tool at least in Silicon valley is JIRA). 
• All the people sit together and create/update/assign the tickets. Doubts are clarified and any deadlines/priorities are discussed openly. 
• Once the sprint/cycle ends all people again come together to do a retrospective of what went well, what could have been done better, who gets the applaud for outstanding contribution. This meeting also targets on getting feedback most importantly on how everybody can work more efficiently and how the processes can be improved further. It is a fun meeting and very important part of agile process. 
• Also important part of agile methodology is daily scrum. When all the team members come together every morning to discuss planned work for the day. Any hiccups/hurdles/dependencies  are discussed. It is also used to give heads up for any planned or unplanned release that might happen during the day. 

So this was agile methodology in short. A highly agile work environment would have all this done in short sprints with multiple releases and very limited time to automate or test.

In such work highly agile work environments here are some tips to be successful:

1. Managers/Leads: Create a release calendar which could be updated every day for any unplanned releases and have planned releases visible on them for transparency.
2. Devs: Mention tickets as QA or noQA so that test engineers need not waste time on figuring things out.
3. Devs: Mention steps to test particular ticket.
4. Test Engineers: Mention steps to reproduce bugs with screenshots and related metadata.
5. Product Managers/Program Managers/Project Managers: Set a kick-off meeting for any features etc for clarification of work, related doubts and dependency on other teams.
6. Raise alarm or incident immediately in order to avoid further delays.
7. Test Engineers: Write test automation first for the highest priority tests only in case of newly developed features in testing.
8. Test Engineers: Run nightly jobs for test automation so that build health is checked daily.
9. Share knowledge of testing and build environments with everybody in the team to debug and report issues without any dependency on any particular engineer.
10. Most important have documentation/Readme(s) for every work/repositories.
11. Set time to transfer knowledge, clarification of doubts or do group testing as and when required.
12. Team-Bug-Finding Exercises: Invite all engineers/managers/design team/product managers of a team to find bugs/defects in a new feature. This will help in building more collaboration, share knowledge of product with all the team members, and any doubts etc could be cleared instantly. 
13. Get the test plan reviewed by product manager and engineering lead/manager for making sure the coverage is proper.
14. Publish achievements to larger audience when the product is ready and released for visibility and work recognition.
15. Write technical papers/white papers on something that could benefit whole industry.
16. Work for the success of the team if that happens then individuals automatically succeeds.
17. Interact regularly with team mates and managers to find out pain areas and try to work on solutions.
18. Enjoy work and happy hour both :)

Thats all thanks for the read once again. I hope this helps!