estpad has a very flexible model for writing test plans (Scripts) which lends itself to pretty much however you want to approach and organise your testing. However, with this flexibility comes the power to go a bit wrong too.. it's perfectly possible to build inefficient plans and lose out on a lot of the value Testpad has to offer!

This post then is the first in a series of three providing tips on getting the most from Testpad. In time, Testpad's interface will itself be improved to nudge users in these "more optimal" directions, but until then, here are some hints towards what you might call 'best practice'.

These tips also have a side-benefit of keeping content to a sensible size, both for manageability by the user and in terms of browser performance slowing down if you've got just too much content on the screen. However, that said, you have to build an enormous script (think 1000+ rows with 100+ columns) before browser lag becomes annoying.

Spoiler alert... if you don't have time to read all the detail, the top three usage tips boil down to:

• using the Retest feature for retesting new builds as part of the same release (the subject of this post)
• copying Scripts (or whole Folders) when preparing for new releases - see the second post
• and getting Script length right; combining together scripts that are too short (very common) or splitting apart truly massive scripts (less common) - see the third post

Retesting New Builds

First up is the idea of "retesting" test runs (columns). When a Test Run in Testpad is completed, whether marked as such manually in the Test Run Details dialog, or through setting results for every test, the Test Run Details dialog offers the "Start a Retest" button.

Retests are intended for retesting e.g. a new build. You've run through your tests a first time and found a number of test fails. The developers have fixed these and issued a new build that needs another test. So you come back to Testpad to make another run through your tests.

The thing not to do at this point is click on "New Test Run" to make a new column, additional to the columns already present. This is the path to the dark side and will lead to an ever accumulating number of columns, eventually slowing down the browser's responsiveness as you get north of 100 columns (sooner if you have >1000 rows).

Instead, you want to be using the "Start a Retest" button, offered in the Test Run Details dialog for runs marked Completed.

A Retest makes a new column that takes the place of the old column. To start with, the old column is displayed beside it, but greyed out. After a page reload, or when you next return to the script, the old column is not displayed at all. (You can get old columns back on screen with a right-click on the run header, selecting "Show Old Runs").

Retests are numbered like version numbers. Test Run 1.1 is the first retest of Test Run 1. Test Run 2.4 is the fourth retest of Test Run 2, and so on.

You can optionally inherit the results from last time. Inherited results are shown slightly lighter than new results and are there if you want to e.g. only retest the problems from last time.

A Retest also takes over the contribution to the progress statistics for the script. If you keep making new test runs (the bad way!), the progress statistics are always the sum of all runs ever conducted, and so can never approach a 100% pass rate with successive new builds. But use retests, and each retest can iterate the results for that run and allow them to reach 100% when everything is passing.

That's it for tip #1. Use the Retest feature when retesting new builds and don't keep making more and more columns, stretching the page off to the right.

Any questions, please email stef@ontestpad.com - always keen to help you get the most out of Testpad.

If you liked this article, consider sharing