esting is all about learning and providing information; learning about the state of the product, informing stakeholders, and therefore making informed decisions – which often boils down to asking and answering ‘are we ready yet?’. To do this repeatedly, reliably, it’s a great help to have a plan, to have something written down to guide the testing and make sure you remembered to take a look at everything. This is where test scripts come in.

But there’s ambiguity in the term “test script”, with different teams using it for different things particularly, the manual side of the software testing process– the testing that you do by hand. We’re also here to encourage you not to overthink test scripts (test planning), prioritizing pragmatic action rather than superficial process.

What is a test script?

Essentially, test scripts are a list of tests to carry out during the testing process. This might be executed by some software as part of automated testing, the test script being the piece of code that defines a series of checks to make. In manual testing a test script is simply a list of instructions for a human to follow. It’s these lists of manual instructions that we’re focusing on.

Test scripts (for humans to read and follow) come in many flavors. Some simple. Some overly complicated. It all depends on the context and what the software team wants to achieve, with what resources, at what cost and in what timescale.

For example, you may want to verify that a “forgot password” link works as designed or an edit button actually allows users to edit. Your test script for the testing around these components could then vary between being:

• a very detailed collection of exact steps to take and precise descriptions of expected outcomes
• a short list of simple statements reminding the tester of the main aspects to take
• a look at the original user scenarios or product features that the developers used when designing and building the software
• a collection of ideas that the testers should experiment around

…or anything in between.

Having a list of prompts is helpful in all the ways checklists are helpful. As such, test scripts:

• Keep your testing organized, which is especially beneficial if you have a diverse and complex set of features.
• Reduce the risk of missing (not looking at) aspects of functionality and letting mistakes slip into production.
• Decrease cognitive load, allowing testers to focus on execution rather than trying to remember what to test.
• Enable progress tracking: the team and stakeholders can see what’s been looked at and what’s still to go.
• Promote accountability, making it clear who is responsible for testing what, when, and how.

Why start with manual test scripts?

So why are we talking about manual test planning here, why not just skip straight to automating all your tests so that a computer can run them in seconds every time developers make the smallest change?

Well, it’s not that simple. And we’ve got a whole article on not only automating your testing. But the jist is, it’s usually much much easier to get started (you just write them down), much easier to add or edit (you can do so on the fly), and much easier to understand whether you’re testing the right things (a real person has deduction skills and practical experience).

That's not to say you can’t convert some of your manual test scripts to automated tests over time, but you need to remember automated tests aren’t the same (think fixed programmed checks versus an inquisitive intuitive human hunting for problems), and that automated tests are themselves more code that can be expensive to develop and come with its own testing and maintenance overhead.

What’s the difference between a test plan, a test script, and a test case?

As we’ve just covered, a test script (in manual testing) is a list of stuff to remember to do when testing — however detailed or not said “stuff” is defined.

A test case, on the other hand, refers to one test description. Usually, test cases are well-defined and come with common structure including:

• Title
• The environment or pre-conditions
• Specific steps to execute
• Expected outcomes
• Optional extra metadata, such as priority, user roles, etc.

But — and there’s always a but — a test case could just be a single sentence, very much like a test script.

A test plan can also mean different things to different teams. Test plans sometimes refer to the strategic document that sets out how the test process will be conducted, including high-level objectives, resources, scope, what tests to run, how they will be carried out, and in what timescales.

But a test plan can be (and often is) just a list of things to test, i.e. a complete test script!

At the end of the day, it’s all semantics. What really matters is whether or not you actually get some testing done, learn about the state of the product under test and make informed decisions.

How to write a test script … it’s easier than you think

Producing a test script does not have to be difficult, or require hours of analysis. If this is your first go at writing test scripts or planning some tests, then keep it simple and try the following ideas as a place to start.

1. Make a list of user stories or main features

If your engineering team is taking an agile approach to feature development, there’s a high chance a list of user stories exist.

User stories are often in the format ‘Fred, who has an admin account, should be able to do X when Y,’ which makes it fairly easy to come up with a list of tests.

It’s actually perfectly sufficient to just list each user story (or feature, or requirement statement) as your test script. You would then be expecting your testers to dig into each user story, experimenting and exploring, looking for issues.

You might also have a quick think about each user story and list out several ideas for aspects of each to take a look at. For example, for the Fred user story, you could test whether:

• Fred can log in as an admin
• Scenario Y exists
• Fred can do X when Y

Prompts for these test scripts could be written down as formal test cases with criteria around them, but they’re arguably more useful as just a list of one-word features or user scenarios to test, like the bullets above. You should choose what type to use based on the context of your team's needs… which leads us to…

2. Add some context

When you’ve got your list of features or user stories to test, optionally with additional ideas per item, you’re nearly there and might already be ready to start testing. But you might want to pause for a moment and consider who your tester will be, what their experience is with the product, and how much instruction they’ll need.

For someone less experienced, a one or two-word test may be far too vague. “Check ABC” may mean nothing to them if they don’t know what ABC is or how it’s supposed to work. While writing out step-by-step instructions for multiple test scripts is tedious, doing so will help train new testers and lead to more accurate testing results.

On the other hand, detailed guidance is probably too cumbersome for a knowledgeable tester if they’ve tested a feature a hundred times before. And if a feature changes, revising all the detailed test scripts is a huge pain.

In general, we encourage teams to keep it simple. It’s faster to write, less to maintain, and means you’ll probably come up with many more tests and ideas. And remember, if concerned about giving enough guidance to a new tester, if they’re staying on your team, they’re only new once, so consider not overly documenting your tests for their first time and instead just help them the first time.

Here are two test script examples to draw from

Say we’re testing a note-taking app. Your script could be as simple as these bullets:

Test Script Example 1

• User interface
• Authentication
• Create/edit/ delete
• Search function
• Device compatibility

Someone who’s been testing that app for a while would know what all that means and can explore as necessary.

But for a test team that needs a bit more guidance, we could iterate the above starting point with a few more ideas per topic.

Test Script Example 2

General UI

• Check all the buttons, menus, and icons to ensure they are visible and functional
• Ensure the text input area is correctly aligned
• Test the app’s accessibility features, such as screen reader support and keyboard navigation

Authentication

• Verify that login and logout functionalities work correctly
• Test password protection and recovery mechanisms

Creating notes

• Create a new note and make sure it saves
• Check formatting options – bullets, numbers, links
• Verify that auto-save works
• Add tags for specific categories

Viewing notes

• Confirm that previously created notes display in list form and can be clicked into
• Make sure you can sort them by date, title, or category
• Try using different keywords to make sure the right notes appear in search results

Editing and deleting notes

• Verify that the edit button works and you can make updates to notes
• See if changes save correctly after editing
• Confirm that notes can be deleted and are removed from the list of notes

Compatibility

• Test the app on multiple devices (tablet, mobile phone, laptop, desktop)
• Test the app on multiple browsers (Chrome, Firefox, Safari, Edge)

At this point, if you’re keen on going as far as building a collection of detailed test cases to form your test scripts, you could then, per item, come up with individual test cases (titles, steps, expected outcomes) detailing exactly what to test. However, the over-specification of what to check will miss out on all the inquisitive, intuitive exploration testing that a human could otherwise give you per topic… which we think is a better direction to go.

Our advice when it comes to test scripts? Just start.

Doing some testing is better than doing no testing at all. Start with what you can and then improve the process and go more into detail, slowly creating test scripts and modifying them over time.

A good way to adopt this iteration approach is to write and store them in a centralized location, like a spreadsheet or testing tool. The unified view keeps everyone organized and makes for easier progress reporting down the line — especially as your testing complexity develops.

So when it comes to choosing a tool for your test scripts, you have a lot of options to choose from. Really, anything will do, it doesn't have to be complicated (post-its, spreadsheets, whiteboards.) Testpad, which has been designed with exactly this simple and pragmatic kind of test planning in mind, would also be a good place to start, and yes, we're rather biased here.

We’ve kept it super lightweight - It feels like using spreadsheets but without the formatting headaches.

• We’ve made it easy to learn and use- you don’t need qualifications in testing or training courses.
• We’ve made it easy to define tests with hierarchies, folders, tags, and filters.
• We’ve got simple fast reporting for at-a-glance progress and result visualization, showing what is against what isn't.

If you’re in the market for a new testing tool or you’re looking to enhance your test script planning, give Testpad a try. You might as well — our trial is free for the first 30 days.

If you liked this article, consider sharing