Hello and welcome to Day 26 of the 30 Days of Tools challenge. You’ve probably got some stories to tell and experiences to share with those who are new to using testing tools. Now’s a great time to share your advice.
What advice would you give someone new to using testing tools?
What do you wish you knew when you first got started using testing tools?
How can you share your advice in a helpful way without overwhelming someone new to testing tools?
What would help someone take a tool-aware approach?
The tool that people use isn’t always the right tool or when people suggest a tool it’s mostly based on.
Before diving in the tool, try it out on a different application, play a bit with it and see if it fulfills your projects needs! If it doesn’t fulfill your needs, look for a tool which does.
Write basic documentation, understandable for anyone technical & non-technical.
Start at the start, sometimes people write documentation without the install options, which might be confusing for people who are new to the tools and want to try it out and follow your docs.
That you don’t always have to use the tools that you are given. If you find a tool that you think is better than a tool we already use, then demo it to your colleagues and make the recommendation that we should try it out. Anyone should be able to introduce a tool to a team or organisation.
However, you must always be prepared for rejection. Sometimes, an existing tool is already well used and moving to another tool will be too costly. Its also likely that your colleagues will not share your enthusiasm for the tool.
I think the best way is to step back and let them experiment with the tool themselves. Don’t set any expectation, just let them try it out on their own without someone looking over their shoulder. I would provide some basic activities that they could do, but keep these vague and open to interpretation. They might discover someone new about the tool that even you didn’t know about.
Don’t control the tools that the team uses. Let them try out alternative options and encourage them to make suggestions. A tool-aware approach cannot exist unless the person has the freedom to actually try out other options.
That tools should be learned on a nerd-to-know (I borrowed this term from a YouTube fellow called Stefan Mischook, I really like how he thinks) basis, no need to spend a lot time learning specific tools unless you have a use for those tools.
For most tools you don’t need to become a world-class experts to use it effectively, this is especially true for tools with a lot of options, for instance, IDEs like Visual Studio, 90% of the time you will only be using maybe around 10% of the features a tool has to offer.
As with learning anything, not just testing tools, find some means of documentation, and a mentor. As such, learn when to stop beating your head against the wall (think about if you were physically doing that and how fast you would stop lol) and as for help.
Tools are an invaluable way to assist us in doing our work in a deeper or more efficient manner. If they aren’t then you should think about why you are even using them. I’ve gone through so many note apps on my phone from Evernote to now Joplin. There will always be a new one, and if you can’t find one, think about making, or asking someone to make it.
Have you seen the amazing schedule and registered for Test.bash();?