estpad saw some big updates today with a whole new UI for grouping scripts into projects. Previously, Testpad had a "manage scripts" page that was a flat list of active scripts. This worked fine for testing single products but became a naming-convention headache for anything bigger. Many of you pointed this out and today, I'm happy to announce the release of this major feature.

So how does it work?

In Testpad, a Script is a list of tests structured as an outlined checklist. Scripts can be used as an outline of functionality to guide exploratory testing, a suite of test cases, or just a list of items you don't want to forget during testing.

A Script also collects its results, which are themselves organised into columns called Runs. So a Script is its tests and the results of those tests.

A Project then, is a set of Scripts, and can be used to make a logical group for tracking and reporting. A Project Report is the collection of reports for its individual scripts. Project reports can be shared internally and externally as required, and as before, both as an interactive HTML page or an HTML-snapshot that can be printed and/or attached to emails whole.

Using Projects to manage releases

To keep things tidy, old stuff can be archived.

Scripts can be archived within Projects, if that makes sense for your workflow, or whole Projects can be archived. This allows for considerable flexibility in how to use Projects. I'm thinking a common convention (and this is how Testpad itself is using them) will be to setup a Project per release of a product. E.g. I've got a project called "Testpad 2.0.1" that is a collection of several scripts covering its different functional areas. When a release is completed, I setup the next release as a new Project (Testpad 2.0.2 say), and copy-forward all the scripts from the previous release. You can copy scripts by dragging them onto their new project with the Ctrl/Cmd key help down.

Copying a script in Testpad has the effect of copying everything except the results, i.e. it treats a Script as an on-the-fly template for a new one. So the new script inherits the tests and the pattern of required test runs. As the scripts evolve with the product, I can edit away in each release, knowing I'm not spoiling the consistency of old tests and their old results.

The old project (release) is then archived as a whole. Report links for archived projects continue to work, so archiving projects just helps to keep things tidy from release to release, without cluttering up the list of active projects.

Also new, libraries of templates

Templates (basically scripts without any results; patterns of tests to be re-used in new scripts) are also grouped - into Libraries. Libraries are just the Testpad equivalent of projects but for templates instead of Scripts. A Template can be dragged onto a project, and a new script will be made from that template (no need to hold down the ctrl key this time).

Libraries of templates are useful for teams who like to pick and choose different sets of tests for different products, e.g. with a customisable and modular product, a subset of templates might be selected from a library and used to prepare a Project that has a set of tests adapted to the set of modules in use.

More control for linking to bug trackers

Projects can have their own bug link pattern, overriding the system default which comes from the account setting. These patterns let you make working links out of the bug numbers in test results.

Big UI changes

The concept of Projects has had quite a bit impact on the management UIs of Testpad, pretty much only leaving the Script-editing page 'unscathed'!

With the right-click context menus and extensive drag'n'drop, it's really efficient to shuffle scripts into place and keep your testing organised.

So check it out if you haven't seen it yet (https://ontestpad.com/) and as ever, please send me your thoughts and feedback: stef@ontestpad.com.

If you liked this article, consider sharing