A Test Engineer’s Toolkit

Just like a developer, every test engineer needs a bunch of tools. But like any craftsman’s toolkit, the tools in the toolkit should adhere to the following rules -

- Every tool should have a specific purpose.

- Every tool should be indispensable.

The toolkit I propose here is my toolkit for test engineers. That means it has tools that I think are indispensable. But you may tinker with this kit to come up with your own. Note that it’s not the toolkit that can make me a better test engineer. The tools are there just to help me do my job efficiently. If I can do the same with another collection of tools, so be it. In short, the purpose of this write-up is to try to make you think about your own list of tools.

Shell Scripting

I would dare call it BASH scripting. For someone working on Windows software testing, it would be Batch scripting. But shell scripting is one of the most basic tools for testers.

Python/Perl

Choose Python (my preference) or Perl and learn it. The reason I have selected these two is their simplicity and wide adoption. You may select another scripting language but stay away from anything more than sequential programming. It means you avoid writing procedures. You must also try to minimize the usage of conditional statements like if, for, while, etc. While these constructs are to be avoided if possible, I would recommend you to strictly keep away from writing classes and other advanced programming constructs.

Keep in mind that unlike developers, language is not the most important tool in your kit.

CLI tools

This is more of a grey area and I am sure every tester would have his collection of CLI tools. Here are some which I reckon should be in everyone's toolkit.

curl - for anything related to http

awk/sed - for some nifty quick text manipulation

grep - for so many things I can't decide where to start with

and common unix commands (power shell for Windows)

Selenium

For WebUI testers, it requires no introduction. But I would be committing blasphemy, if I don’t include it in the toolkit. In any case, try to use Selenium with the language available in your toolkit (like Python).

Gherkin

This is something that is not necessarily recommended (but anyway used) for all types of software development setups. But I would advise you to make this your default choice of test scenario writing. You may disagree with this advice, but you are welcome to have your views.

Wireshark

A Swiss knife for anything involving a network, Wireshark (or TCPDump on linux) is a good tool for testers. It is fairly easy to use as long as you need the basic capture-and-show-packet functionality.

Text Editor

If you use Vim (which you probably don’t), you don’t need anything. For other editors, see if your editor can show file data in hex format. If not, get a lightweight hex editor.

Containers

Containers (Dockers etc) are the new age workbench for testers. But like any new tool, they need to be learnt; not just how to use but also when to avoid. For a test engineer, knowledge of packaging and using containers is generally sufficient.

AWS

This is one tool (if we can call it so) that I am least happy suggesting. But I can’t ignore the way technology is moving. Cloud-based infrastructure is common today. Test engineers are likely to test software systems that rely on cloud infrastructures like AWS. So, a basic knowledge of it is helpful. Specifically, I would suggest you get comfortable with AWS cli interface. If you are explorer type, you may dirty your hand with a little bit of Boto (Python interface of AWS). An AWS account of your own won’t be such a bad idea in such a case. You may replace AWS with GCP or Azure or similar depending on your preference or need.

This toolkit is a generic one. If your domain is a niche, your toolkit may look very different. In any case, your toolkit will keep changing with time. While some tools will get added, some others will lose their sheen. But one thing that would frequently try to creep into your toolkit is a new programming language. Every new language would come across as a genuine need. Unless you are strict about keeping only one language in your toolkit, you will end up with a messy toolkit. I know this is a very controversial suggestion. I expect it to be met with a barrage of counterarguments. But be as it may, it is very deep-rooted advice. Try to stick and you won’t regret it.

Now that you have your test toolkit, Happy Bug Hunting.