5 reasons why testing using Word and Excel really can’t be done anymore

Thijs Kok, 
16 December 2016

What is a bug report and why do we write them?

Excel is really useful, you can use it for all sorts. Need to make a list of actions? Quickly draw up a schedule? View financial data in a pivot chart? With Excel you can do this really quickly. If you need to make a formal letter or write a report, then Microsoft Word is your friend. Both of these programs can do just about anything, similar to a Swiss Army knife.But can you test software with Excel? Well that depends. Can you cut down a tree with a pocket knife? Eventually you will succeed. However we think that testing software with Excel or Word really can’t be done anymore. Here we list 5 reasons why.

1. Excel and Word can do everything, and anything goes with them.

Create a test script in Excel with test cases and a number of test steps and distribute this among your testers. All is going well until someone discovers that you can also add comments in a different column. All the formatting features seem to work too. This means that users have the freedom to manipulate all the cells. Before you know it your test script has become complete and utter chaos. This makes for a poor starting point for structured testing.

2. Excel is a computing genius, but it isn’t a strategist

Excel is not just a calculator but it has hundreds of functions for statistics, logic and text manipulation and much more. An analysis of your results is therefore made very simple. But what if you, as a test manager, want to know how the overall test process is going? Or if you want to know what the average resolution time is per supplier? Do you then link all your loose sheets in Excel together? What if you want to compare multiple years of results, is that possible? Excel is fine for a nice short term approach, but it isn’t a big data solution. That’s something Excel was never made for.

3. Is testing with Excel safe?

Have you ever wondered what test results give away? A screenshot of your primary system or a test phase in your work process for example? Test phases, test results and issues need to be protected, even if they have been made completely anonymous. It wouldn’t be the first time that software testing leads to a data leak. Securing this data in a Word document is not so easy. A password in an Office document is easily cracked. Encryption using Sharepoint or OneDrive is better, but is not the best solution because you can either access the document or you can’t. And after all this if you receive such a document, what’s stopping you from quickly sending it to yourself when no one is looking?

4. You always have Excel at hand, but are your test results and issues complete?

Before we had Office in the Cloud and portals for working from home all your documents were on the network drive of your organisation. Fortunately, that is not the case anymore. Yet it can be difficult to keep such documents in the right place. For example, a tester downloads the test script on their desktop because that’s a bit easier and quicker to open. A supplier writes you an e-mail about an issue because he can’t get to the Sharepoint location. Those print screens have been made but they are in a folder which hasn’t been shared with you. Information can quickly become fragmented and it’s difficult to keep track of all the different changes.

5. Auditing: every test result is safe and can be traced

Software acceptance testing is a tough job with a lot of responsibility for the accepting party. Has everything been tested? Is all the data correct and completed by the appropriate people? Was every issue dealt with properly? When it comes to tracking changes in Word documents, there are few options. “Track Changes” is convenient, but soon becomes cluttered. Maintaining a file archive is possible, but it will also soon become unmanageable: issues_20161201_final2.xls is now the latest version or was it a different document? Convincing an auditing party of data integrity and traceability is an impossible task using these methods.

A real shame?

Is testing with Word and Excel actually a real shame? No, because testing software is always better than doing nothing at all – “it’s the taking part that counts, not winning”.

A test phase can be made in 10 minutes, but you will lose out on time and make costs for the time needed to keep a grip on larger projects.

But therein lies our most import message as well as to why you should move away from these two all-rounders: a test phase can be made in 10 minutes, but you will lose out on time and make costs for the time needed to keep a grip on larger projects.

Make use of a professional testing platform and make quality truly insightful. Ask for a free trial of TestMonitor today and see and experience the difference for yourself.

Want to know more? Follow TestMonitor on Twitter and LinkedIn.

Microsoft Sharepoint, Microsoft OneDrive, Microsoft Word and Microsoft Excel are either registered trademarks or trademarks of Microsoft Corporation in the United States and / or other countries.

If you’re a newcomer in the world of testing, you easily become overwhelmed by all the testing terminology getting thrown around. In this article, we’ll try to explain some of the jargon you might encounter in your daily testing life, just to make it all a little bit more understandable.

Test Cases

So, we’ll start with test cases. Most importantly, test cases provide a series of instructions that validates some part of the software is doing it job as expected. Say, you require a contact form on your website that sends an e-mail when a visitor leaves a message, you’ll probably create a test case verifying the e-mail actually arrives when the form is filled and submitted. A test case can help you determine whether or not the software meets your requirements.

In some situations, a single test case can verify a simple requirement. However, it is more common practice to think of multiple situations that tests your feature more thoroughly. When your contact form offers an optional text field, try both filling and clearing the field in two separate test cases. Even better: try to go beyond the “happy path” and think of things the software shouldn’t do. If your contact form accepts an e-mail address, why not check if a non-valid address is accepted too?

Test cases do not merely consist out of instructions – or test steps, as we’d like to call them. For example: simply performing a few steps without explicitly telling the excepted outcome could cause misunderstandings. Should our contact form rejected an invalid e-mail address? Perhaps – or perhaps, we really don’t care. A proper test case usually comes with a predefined expected result, telling you what to expect when completing a test case. Similarly, it is common good practice to define the initial expected state when writing a test case. You don’t want to cover every piece of preparation in your test steps, like accessing a test environment, setting up a browser, enabling mail notifications, etc. These pre-conditions are usually defined as a separate property of the test case. When a condition isn’t met, there’s no point in testing the test case.

So, that’s it then? Well, there’s more. Like writing a blog post, creating test cases require certain writing skills, like imagining things from the end-user’s perspective. If you want to read more, be sure to read 7 tips for great test cases.

Test Suites

When you know about test cases, the concept of test suites should be really simple. With a growing amount of test cases, the need for categorizing them increases as well. You don’t want to throw all your books on a pile, you’ll organize them on shelves, for better accessibility. In a way, test suites are very similar to shelves, as they group test cases together as well.

In the process of planning and running tests, keeping track of hundreds of test cases really becomes cumbersome. Thinking in terms of “We need to run a performance test tomorrow” or “Next week we should schedule a test for our website” forces you to know the purpose and domain of each test case. A test suite allows you categorize test cases in such a way that they match your planning and analysis needs. Do you run functional and performance tests? Create two suites and label them accordingly. Do you test different applications and want to monitor them? Create a suite for every application. Are you still able to manage without test suites? Don’t use them! Remember, they are only there to help you organize test cases when needed.

Test Runs

Finally, we end up with test runs. They are little crossroads in your testing project, where several aspects come together. Simply put, test runs determine which test cases are tested by which user(s) at what particular time. Quite a mouthful!

Image you have created your test cases for your contact form and its about to become available to your organization for testing. Are you going to test it for yourself, or do you pick someone else? When are you going to start testing – and, when do you want to gather the results? Which test cases are you going to select – all of them, or just the ones marked “happy flow”? These questions should be answered when planning a test run.

When you have created a test run, you have reached an important milestone: people are able to run a test, using your test cases, grouped by your test suites. In one of our next posts, we’ll continue with some useful tips running tests and gathering test results.

Start with a Free 14-day Trial.

Get started with TestMonitor today! Pay monthly, no long-term contracts & cancel at any time.