April 14, 2014
Tech is full of innovators. The IT industry spends a huge amount of time and effort determining the most efficient way to accomplish various tasks....
If you guessed “The Microsoft Office Suite,” you’d be right. Don’t get us wrong – some of these programs are completely apropos in software testing. You’d be hard-pressed to find a more convenient program for bug reporting than Microsoft Excel, for example. However, not only are some of them completely off-base for the uses testers subject them to; even the appropriate ones are often used in maddeningly inappropriate ways.
Not only are some tools completely off-base for the uses testers subject them to, but even the appropriate ones are often used in maddeningly inappropriate ways.
As far as word processing goes, it doesn’t get much better than Microsoft Word, and there are a handful of other testing processes which can successfully make use of the program. However, we have two big pet peeves for Word: using it for imaging, and for transporting code.
Word is not an image editor. That means that anything in regards to screen shots or creating diagrams can be done with much more accuracy and ease by making use of other products which were actually designed for these concerns. Similarly, transporting code in Word is a huge, unnecessary headache compared to using a plain text editor (Word’s fancy features, like spell check and auto correct, are great for writing letters or essays, but can just get annoying with code). This is particularly true because computers that have Word preinstalled probably also come with Notepad, a plain text editor which is much better for coding. Beyond that, most coding languages have their own dedicated IDEs which are far preferable to any other option.
Like we said above, Excel is awesome for defect management. We have no qualms with using it for bug reporting – in fact, most of our testers do. However, there ARE tasks which aren’t appropriate to use Excel for. For example, text editing is one of those things that Word works great for, but it doesn’t translate well at all into Excel. We’ve gotten memos that were typed entirely in the first cell of an Excel spreadsheet, for really no specific reason, which is a bit of an extreme example, but isn’t uncommon and can be a bit annoying.
Additionally, lots of testers perform the defect management process on the same Excel spreadsheet they reported the bugs on. This looks unorganized and unprofessional, and gets really confusing really quickly as well. Instead of letting a bug report devolve into chaos, use a specific tool that will help keep traceability, history, and all the other pertinent information uncluttered.
To be honest, we can’t really think of a time during actual software testing where PowerPoint would be relevant. We sometimes see it used for diagramming or screen shots, but again, there are dedicated programs which are much better bets for that. However, we CAN think of some times in the testing process in general where PowerPoint may come into play, such as when, you know, actually presenting information to shareholders, or to educate your testing team on a new product or process, for example.
Programs We Prefer:
So we’ve discussed what you shouldn’t use and why, but what would be a good replacement for these inappropriate programs you’ve grown used to? To answer that question, here’s a list of the more apropos tools that you can pick up for these processes- and most of them are free, too!
- Transporting code: Either Notepad or preferred IDE
- Screenshots: Paint, GIMP, or Snagit
- Diagramming: Publisher or Visio
- Defect management: SpiraTeam, JIRA, QMT
Have any testing tool misuse pet peeves?
So that’s what annoys us. How about you, testing world? What test tool misuses really grind your gears?