Performance Tips - keeping Testpad fast from build to build

Testpad has a very fast interface for script editing that's javascript powered and uses asynchronous communication with the server in the background. However, there are limits, and if scripts and result grids are allowed to get too big the interface can get laggy, especially on older computers.

Most examples I see of scripts getting too big are through unintended mis-use of the interface. So this is the first post in a series of three that shares some tips on how to best use Testpad, and in so doing, keep scripts to a useful and sensible size.

In summary, these tips boil down to:

  • use Retests for retesting new builds as part of the same release (the subject of this post)
  • copy Scripts (or whole Folders) when preparing for new releases
  • and ideas for refactoring scripts; joining too-small scripts or splitting apart big scripts


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.