As we navigate the vast number of automation tools, I’m curious to learn about your experiences in experimenting with these tools and how you share these discoveries and garner buy-in from your team.
How To Contribute
Your Tooling Story: Write a brief story about the specific challenge you faced and the tool you selected to address it. What was your approach to solving this problem with the chosen tool?
Sharing and Feedback: How did you communicate your findings and experiences with this tool to your team or peers? What strategies did you use to gather feedback and gain buy-in?
Why Contribute?
Sharing your story demonstrates your approach to problem-solving using tools, which can be enlightening for others.
Sharing your experiences can help improve your ability to articulate the value of new tools effectively.
Learning from each other’s feedback and buy-in strategies can lead to more informed decisions about which tools to integrate into our workflows.
This discussion aims to delve into the nuances of discovering, sharing, and validating the usefulness of new tools within a team setting. It’s about growing in our ability to confidently present new ideas and adapt based on team feedback and needs.
I’m excited to hear about your stories of exploring new tools, how you’ve shared the value of these discoveries, and how you’ve successfully gained buy-in from your teams.
For me tooling always comes down to a tonne of context.
Some examples of what I mean:
How big is the team / project / code base?
Is the person reviewing the tool junior or more senior and do they have experience with the product/code base?
What limitations are in place from either a finance or IT perspective?
Is their a tool already in place and what is the tech stack?
Who will be using / maintaining the tool?
Recently I have been looking at a good few tools due to negative changes that they have introduced. Examples:
Cypress - stopping use of 3rd party plugins like sorry-cypress, however, not offering a self hosted Cypress cloud option. This means we are locked at an older version.
Postman - Removing local Scratch Pad and making everything cloud hosted. Along with other numerous annoyances like collection runner restrictions.
For those examples given I listed out all the features that we currently utilized in Confluence giving a grading of high/required - low/nice to have e.g. Cypress Intercept - High. Then I added any features that would be nice but maybe aren’t included with the current tool e.g. Postman & Source Control.
I then proceeded to review alternatives via Google, ChatGBT and forums etc. I quickly went through the new tool documentation to make sure the required features are present. This usually results in only a couple of tools to review.
I then proceeded to the Proof Of Concepts (POC) stage for the tool candidates and make sure to use source control. I documented the process in confluence as I went noting down any issues or areas that impressed me. This process gets time boxed to 1-2 days.
If one of the tools has promise I tend to review it with other testers to see if I missed anything. This is where the source control is handy for getting feedback. They can pull the repo and runs tests based on the docs I have created along the way. Then I move onto giving a demo to the full project team. If the team agrees the tool is suitable then there is a Migration plan created usually in Jira for setting up the new tool.
Again back to the context, I am the one using these tools and would be maintaining them going forward long with only a couple of other testers.
I have stated in other places that my need and use of Automation Tools is minimal, but we are moving ot more modern technologies(just not yet).
This is a big reason for doing the Foundation Cert course.
In saying that, my outlook is that everything we use is a tool to manipulate and make do what we need at that time e.g. we have advocates of Agile who say we need to stick to a,b,c,d and in doing so, lose sight of what Agile is(working with Agility!!). It is a tool to fit our needs, not a methodology we need to stringently adhere to.
So my example is moving automated .Net tests from .Net Core 3.1 to .Net 8.
To do this I did the following:
Detailed the use case:
.Net Core 3.1 going out of Support
Removing 3rd Party dependencies e.g. replacing Newtonsoft with improved Syste.Text for JSON
Vastly improved Performance to assist in cutting down the time needed for test runs
General improvements in EF, Linq, Parallelism etc…
Costs. Advising there would be insignificant amount of pain and short term additional cost(additional VMs to allow the current tests to run until implementation sign off).
Audience
Created an agenda aimed at keeping details as low tech as possible.
Building in a post meeting Q&A aimed at Devs and other Automation Engineers.
Comrades in Arm
A breakdown for the Engineering manager on who would be involved to assist, mainly requiring Senior Devs for Architectural decions and perfroming PRs etc…
By being honest, getting the right people on board with you and Security being a new secret weapon to scare non technical people, you can get your ideas across, regardless of the tool or other concept you are looking to adopt.
ps… morning coffees and douhgnuts are known to help too. Sugar is amazinf at getting compliance !!!