Have you ever built a tool list?
Yes? Me too. I don’t any more. And in this show I explain why, and what I do instead.
This podcast has also been uploaded to facebook:
Original twitter thread: https://threadreaderapp.com/thread/1098198817726517248.html?refreshed=yes
The Observatron tool
Exploratory Testing Chrome Extension
Rapid Reporter, exploratory notetaking
Exploratory Test Assistant - autoit script for making notes while engaged in exploratory testing - eviltester/exploratoryTestAssistant
I like tools that augment my process and work together. So I use multiple proxies to observe, interrogate and manipulate HTTP traffic.
I use FreePlane for mind mapping, because I can write Groovy Scripts that allow me to output the information in different ways. Here’s an extract to markdown script that I use regularly when creating conference slides and other written material
Simple scripts for use with Freeplane. Contribute to eviltester/mm-script-repo development by creating an account on GitHub.
I write most of my logs as text in markdown format so I can use multiple tools for reporting in different ways, and it is easy to parse for custom tools I write.
I often write scripts to augment my existing tools, or extract information from them, or combine information from multiple tools together. Rather than look for a new tool. Often these are tactical, and just for my use.
I sometimes wonder what other tools I don’t know about, but I don’t maintain a tool list any more. I tend to use a combination of tools, and only look for tools when I have a gap in my modelling, observation, interrogation or manipulation abilities.
It was only as I was writing this extension that I stumbled across @bugreplay which is a commercial cloud tool that captures similar information as the extension I’ve written bugreplay.com
Do experiment with multiple note taking approaches and tools to find a way that works for you, based around the process and the software that you test. Caution: spend more time using the tools, than augmenting and looking for new tools. (I’ve fallen into that trap too often)
Actually I wrote it around 2004,2005,2006 but only released it to github in 2012
And I only found it because it was mentioned in the testersio.slack.com channels
- Don’t try to find “The one true tool”
- Don’t build a list of tools
- Learn to search well
- Every list of tools you find will be incomplete and out of date
- Look at native, built in OS functionality first
- Learn to search in places where your tool might appear - e.g github, slack channels, forums etc.
- Think like a marketeer - how would the ideal tool you need be marketed? search for that
- make sure you understand your model of how you work
- I have a meta-model for my work that uses Modelling, Observation, Interrogation, Manipulation as high level categories
- I look for tools within those categories when I identify gaps in my ability to implement those categories for different technology
If I am not observing a particular attribute of a specific technology. Then I go hunting. And my search is more specific.
When choosing a tool:
- Don’t evaluate, experiment: you know what gaps you want to fill When given a choice between tools:
- look for tools that can be combined e.g. ffmpeg, automator
- pick tools that can be augmented e.g. work with their files, APIs, plugins etc.
- we want tools & utilities, not frameworks or funnels
- pick tools that make it easy to work with - cross platform, cloud storage
- do you have to make a choice? identify what they do well, use it when it works best