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!

Best Practices for Mobile Test Automation

Best practices learnt by experience for Mobile Test Automation are:

• Scope decision for Mobile Test Automation in highly agile workflow should be based on the following priority levels i.e. Top -> Smoke Tests, Medium -> Regression Tests, Low -> Features Related Tests
• Which Test Automation Tool Programming Language has to be used? This decision should be made on the following: 

1. Does automation of smoke tests or basic functionality require any API/Backend support that is designed in some specific language (hence that preferred should be used for test automation preferably to easily extend or reuse the existing architecture)
2. Does novice testers needs to be trained for automation which have manual testing exposure or comes from non-engineering background? In this case natural language based or record/play type of tools and supporting languages should be used. (Don't want to quote specific examples here)

• Which test automation tool to be used? 

1. This decision depends on several factors that a combined decision or understanding can answer this. For example how big is test automation requirement if it is not huge and apps are completely native plus no specific requirements are on the design patterns to be used then native UIAutomation tools can be used. One advantage in using native UIAutomation tools is that they get direct support from the mobile platform owners and is usually robust. 
2. If there is large number of tests to be automated and the application is relatively complex then the tests should be based on a design pattern and can use pretty advanced third party test automation tools
3. In case the test automation has to be parallelized and integrated with Continuous integration systems then we should use design patterns, third party tools and also cloud based test automation environments along with a solid CI solution which is difficult to find currently but yes whatever is available solves the purpose

• An effective test automation tool should always have a solid reporting mechanism based on the organization requirements.
• Test Automation Coverage should also be tracked in order to derive useful metrics and efficiency/productivity derivations.
• Tests should be independent of any device/simulator and should have conditions to tackle runs on all types of mobile test environments.
• All test automation should majorly focus on two aspects first is to help in shipping faster and secondly reduce manual test dependencies.
• Tests should always avoid explicit waits at any point and have sufficient retries and conditions to avoid these.
• 3 phases of test automation should go in parallel for a highly agile workflow else test automation is bound to fail i.e. development, execution and maintenance. In order to avoid failure prioritization and scope has to be define in pretty solid terms beforehand.
• Page Object Pattern is generally the most efficient design pattern for mobile test automation.
• Agile process should include suitable workflows for inclusion of test automation enabling accessibility labels/ids.
• Reusable methods/functions should be designed to reduce redundant test steps as much as possible.
• Use of human readable function/variable/method/class/abstract method names should be used. 
• Code with complex logic handling be marked with suitable justifying comments to avoid fellow test automation QAs understand your logic.
• Tests should be written such that failure of one does not affect any other test running in parallel to fail. Sequential test run model should be avoided unless absolutely necessary. Parallelization is the key to test automation success!
• Each part of a test should be configurable for user/data inputs. No hard coded values are appreciated in the real coding world.
• In the end all genuine code review comments should be acknowledged and be used as learning points for future test designs.
• The best teacher for test automation is your self do as much as you can and you will see that you are innovating and passing all hurdles with ease.

Thanks all for the read, I will keep sharing the goodness as and when I will learn more by experience and by hands-on!