My Toolbox – 2013

On my bike ride to work today, I was thinking about my current toolbox – the tools I use on a daily basis to get my job done (or to help me get my job done). Or, to be perfectly honest, I’ve been thinking about my toolbox for a while – I just thought about writing about it on my commute today.

This isn’t going to be a typical list – that’s for two reasons. One is that I’m not typical. The second is that I use some internal tools that may be helpful…but since nobody outside of the Borg can get to them, aren’t that interesting to share. But – what’s listed below covers most of what I use on a day to day basis.

Stuff I use for Testing

This list could go on for a while, but I’ll stick to tools that I use every day, are free to anyone, and find great bugs.

  • Application Verifier – AppVerif is a dynamic analysis tool (a lot like the old boundschecker tool). It’s easy to set up, the bugs are easy to debug, and its false positive rate is near zero. If you test a windows app, you should use it.
  • Driver Verifier – DV is (IMO) the biggest blue-screen remover I know of, or can imagine. It finds driver faults way, way before they ever manifest in a system crash. If you test drivers, you have to use this tool (literally, as I think the driver certs require that you run it).
  • Static Analysis Tools – we use an internal version of the Code Analysis tools from Visual Studio. I’ve never actually used the VS versions of the tools, but from what I can tell, what I use daily to help guide me to product issues is almost exactly the same as what we ship to developers.
  • Kernel Debuggers – When you work on an operating system, you need a kernel debugger, and the debuggers from MS are great (I could just be used to them, having used them for years). Windbg (I pronounce it wind-bag) looks a bit like a throwback (IOW, it’s not a pretty debugger), but it’s a powerful debugger.

Command Line Goo

I spend a lot of time at the command line (our build system uses a lot of command line tools, and I’m comfortable there). Many years ago, I used NDos/4Dos, but I still prefer the standard cmd.exe shell to the currently available Windows shell alternatives.

But the command line is much more than a terminal – it’s the way you use it that makes it useful.

  • Macros – I don’t know about you, but I always forget complex command lines – especially for commands I don’t use often, , so I use a lot of doskey macros. I have a network accessible power supply hooked up to my consoles, so I have a macro that reminds me of the commands to reboot, and connects to the ip address (that I always forget) –doskey netpower=echo Run rb num to reboot console num$Tsleep 2$Ttelnet %powerip%
    I have 40 or so of these, and scanning through the list, I use nearly every single one on a daily basis.
  • Grep / Findstr – I’m always looking for stuff, and findstr is my partner. Need to find every instance of a file containing the text ‘f’’ that does not have the text ‘bar’ on the same line: findstr /sip foo * |findstr /vi bar.

Other Tools

Tools I use every day include:

  • Notepad++ – This is my primary editor. Since I build from the command line, I don’t need anything except an editor that launches quickly and makes it easy for me to read and write code quickly. Notepad++ also has macro support which is great for those times when you need to make the same change across hundreds of lines.
  • Notepad2 – This is my backup editor. Sometimes, I want a file to load in a single window (notepad++ loads multiple documents). For example, I have a bunch of output files I need to look at every few weeks, and I never got around to writing something to get the output I need from the file. So, when I’m ready to look at the files, I run for %f in (*.txt) do start /w notepad2.exe –g –1 %f
    That launches notepad2 for each text file (waiting until I close it before launching the next one), and automatically puts the cursor on the last line of the file.
  • Visual Studio – I do a little bit of coding in VS, but I mainly use it for work item tracking in TFS
  • Leankit – I keep my life in order (including my work life) using personal kanban, and leankit is my tool of choice. It keeps me sane.
  • Others – I use Excel, a few different mind-mapping tools, scripting languages, and terminal server frequently as well, but the use cases are probably less interesting.  Other Office apps (Outlook, OneNote, Word, etc.) also get extensive usage, although less directly related to software development or testing.

[Preemptive comment: yes – I know that the brain is your most important tool as a tester (or programmer) – but this is true for all knowledge work. You need to use your brain to know when to use tools like these, and recognize when they will help you. Consider brain power noted.]

Comments

    1. I should, but I’m cheap. I’m not actually cheap, mostly, I’d just have to take the time to learn it, and I’m currently perfectly happy with notepad++.

  1. This is a really useful topic. Tools I use in test are (in addition to notepad++):
    BeyondCompare
    Dia
    OneNote (for overall collaboration and documentation)

  2. Thanks for the information. I have gathered some more info like LeanKit and will use it definitely.
    Excel is a great test supporting tool ;-). Apart from that I am using, NotePad++, SoapUI, XMLSpy, Beyond Compare 3.

    I found OneNote is a great tool for testers (at least for me). When I am in a testing flow and found a bug I keep a screenshot and related details in OneNote and once I get to a logical break then I log all the bugs into TFS. Also OneNote helps me a lot while I am doing an exploratory test.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.