I was in an environment where it was clear some of the testers were struggling with the idea if comparing Excel workbooks: either as actual Excel files or CSV files that were imported into Excel. Expensive automation tools were being used to try to handle some of this. What I immediately thought of is simply: this is why testers do need to have some technical skills in the programmatic arena.

What testers often have to do is pick the right tool or create the right tool. In terms of the latter idea, choosing the right language for the problem you are facing and the environment you are facing it in can and should be one of the first steps. In the particular environment I’m talking about, this was largely a Windows-based testing environment and the output files from the application were Microsoft Excel files or CSV files that were then imported into Excel.

There was a desire to have a “simple Windows script” of some sort that would do a comparison. I brought up the idea of VBScript. Do I normally use VBScript for things? Honestly, not really. But it does have it’s uses and here was a perfect example of that. The environment I was in did use the QTP automation tool. QTP utilizes a VBScript-like language. Further, Excel itself uses VBA (Visual Basic for Applications) behind the scenes for macros and scripts.

I realized that I could write a simple .vbs file that contained the necessary logic to compare two Excel workbooks (whether actual Excel or CSV). This script could be run directly from either a Windows command line or via a simple UI put in front of the script. This script could also be used directly in QTP. Further, most of the logic could be put into a VBA macro if desired. The point here is a solution in VBScript made a lot of sense given the environment. Could I have done this in Ruby or Python? Sure. I could have done it in Java or C# as well. But a VB-like language simply made the most sense.

I think this is an important skill for testers to have. Testers these days have to have enough familiarity with development languages to know which one they can use in a given situation to satisfy a given need given a certain set of operational or environmental considerations. Sometimes this will be Ruby. Sometimes it will be C#. Sometimes it will be Visual Basic. The ability of testers to do this most definitely broadens their career options as well as makes them a more powerful contributor on their team.

Incidentally, if curious here is the script I ended up with:

This could be executed with the following command:

compareXLS.vbs AccountsReport_1.2.csv AccountsReport_1.1.csv

The script will compare the first file against the second and will color the differences in red so that you have a visual indication of what has changed.

Even looking at this original version right now, I realize there are many ways to make it a bit more robust. But it was good enough for what it was for at the time and it forced me to reintroduce myself to a language I don’t play around much in anymore. In fact, it did make me investigate how to do this same thing in other languages and I suppose that can be something that spurs on any tester. Figure out a solution for something that needs to be done and then say, “Okay, what would this look like in Java?” or “What would this look like in {whatever language you want to learn}. In an early post I talked about spiking to learn automated testing tool languages. As I’m showing here, you can do the same thing in any context where you are writing a tool solution.