I have seen this coming up in multiple places and wanted to make my own comment. While Excel and spreadsheets in general are fine tools, they are NOT documentation or testing tools.
I know it's become the norm to create test cases and even test plans and publish them as spreadsheets so they are easily shared. But to be honest, it pains me to no end.
Excel is fine for making a basic checklist, or listing ticket numbers associated with a project and handing it over to the client to or to someone in the business so they can check the progress at a glance, but using it to store API data, SQL queries, write elaborate steps that someone should follow to perform an action, color coding dozens of columns, creating dozens of sheets filled to the gills with test permutations, or using it to backlog tickets, sends me into a terrible frenzy.
Simply put, there are far better tools out there for handling that kind of data, they are called Task Managers. If you need more than that, look for a Project Management tool.
I use Excel or rather LibreOffice to create a summary list of what I am working on for the client. But it's not something I actually work from. I use 2Do to create my own task list and keep track of my progress. I use DevonThink to track requirements documents, credentials and page links for my own personal benefit. I use Jira and Confluence for bug tracking and sharing test information.
I have seen too many cases where everything is stuffed into Excel because that's the tool someone has available and the only tool they know how to use. There are dozens of tabs filled with color coded data, lines going in all directions, screenshots plastered all over the place, and all sorts of bug descriptions.
To this I say no. It's a terrible idea. Bugs should be tracked in the correct bug tracking tool, whether that is Jira or something else. Screenshots need to be attached to the ticket or the requirements document. Simply put, the correct data should be listed in the correct place, not stuffed into an Excel spreadsheet someone made.
It also leads to the problem of data hoarding. It's far to easy to store everything inside a spreadsheet in a way that only makes sense to you, that is stored in a folder on your machine, that isn't shared and takes multiple steps to make available to someone else.
I'm a huge fan of Excel. I used to support it. It can do marvelous things. But just because it can, doesn't mean it should.
I have run into far too many spreadsheets that are stuffed to the gills with data that isn't listed anywhere else. The bugs aren't being tracked correctly. The testing data is locked away where other team members can't get to it. And in a recent case, so much crap was hoarded in spreadsheets, that not only are there dozens of them that don't make any sense, but dozens of them weren't actually shared after said person left. We are literally missing documentation because it was more important to be in control and use Google Drive than to share test data in a meaningful way with the rest of the team.
Yes, some of that is a personnel problem, but in my opinion, there is too much reliance and emphasis on using Excel as a testing tool. It can be used for a lot of things, and it has a lot of convenience, but I have a hard time believing spreadsheets are the best way to share testing information with team members.
Other articles of interest:
- Some new tools to tackle the job in 2019
- 2Do for Task Management
- Tracking the next phase of my automation development with Project Office
- CopyLess and PopClip Jump Aboard the Party Barge
- Handling Tasks with TaskPaper
- RightNote – A $15 replacement for Word and Excel?
- Tools for the QA Engineer
- Call the same Test Case twice with a Custom Keyword
- QA Regression Suite coming together
- Adding entries to an open Excel spreadsheet during runtime