We have a new home!... testpad.com

As of today, Testpad is now hosted at testpad.com after over a decade at the similar but always somewhat confusing "ontestpad.com".

Impact on customers

The switch to the new domain is automatic and happens either when you change page within Testpad (if you were already logged in), or simply when you return to the main website to login again.

If you were logged in, and go to change page in the app somewhere, you will find yourself having to login again. This happens because your session is tied to a cookie, and your cookies are tied to your domain. So when we changed up the domain on you, you won't have a session cookie anymore and therefore have to login again to continue. Testpad does remember where you were trying to go however, so it should be as seamless as remembering your password!

Links to reports etc

Any existing links that are "out there" will obviously have the old domain in them and should seamlessly redirect to the new home. There's no time limit on this redirection, we'll simply support old links indefinitely.

Similarly for guest test invitations, new user invitations, account sign-up verifications and so on: they should all seamlessly redirect.


All Testpad emails are also switching over to use the new domain, so please expect Testpad emails to come from "support@testpad.com" from now on. Of course, the old email addresses will still work, so again, no rush to update.


Testpad always wanted to be hosted on its brand name .com of course, but when I started Testpad in 2010, it wasn't available. I could have started the business with a different name, but despite trying hard, I couldn't come up with a name that so perfectly encapsulates what Testpad is all about. So I went with Testpad and settled for the domain "ontestpad.com".

Why "ontestpad.com" in the first place? Well, when you signup and get an account, your account is hosted on a subdomain, giving you a Testpad address of "yourname.ontestpad.com"... "yourname".. on Testpad... geddit?

However, while that appealed to the nerd in me, I'm not sure how many folks out there also appreciated it. And of course, for people looking for this testing tool they've been told about called "Testpad", there's always the question when they find "ontestpad.com" of whether they've found it yet or not.

Fast-forward to 2022 and, with the help of our friend Adam at Lumis, we finally managed to engage the previous owner of "testpad.com" and negotiate its purchase. I'm not publishing numbers here, but let's just say it wasn't cheap. A cool simple two-word .com like "testpad" was never going to be cheap! But it was a great investment and secures the brand name for the great things we have planned for 2023.


All except for this blog that is!

The blog is staying put at blog.ontestpad.com until the launch of our new marketing website in early 2023.

As ever, any issues with this domain change, or anything else, please don't hestitate to email us on support@testpad.com. Happy Testing!

API Project Update and Early Overview

As a reminder, if you are interested in early access to the beta version of the API, to both get started with it but also help test it in real scenarios, then please register your interest and enthusiasm with support@testpad.com.

The API will be presented in two parts

  • a collection of endpoints for making calls to, and
  • a collection of events for subscribing webhooks to.

The project has now implemented all the endpoints and webhooks, along with the UI settings to control access keys and configure webhooks etc. Remaining work includes our own testing (!), reviewing the documentation, and the server/networking deployment of the API servers so as to protect the availability of the rest of Testpad in the face of buggy/runaway code flooding the endpoints with requests.

The rest of this post is to give you a teaser/taster of the API and what it will look like. The syntax presented here is not final, but do write in if any of the choices being implied here raise questions for you.


Full documentatation will be released alongside the beta of the API, but the general goals of the endpoints are to enable:

  • injecting test results from external systems (such as automated testing and CI systems), with options for doing this whole script at a time, whole test run at a time, or just individual results one at a time
  • creating new folders to post new scripts into
  • extracting result and progress statistics at the folder, script and run levels

Example, injecting whole script of tests and results

For example, to create a new script in project 5 in folder f2, populated with tests, header fields, test runs and results, you would send an HTTP POST:

POST /projects/5/folders/f2/scripts
  "name": "Automated tests for rain predictor",
  "fields": ["(weather)", "build", "date"],
  "runs": [
    ... run definitions ...
  "tests": [
    ... test definitions with results per test...

Example, extracting a folder progress summary

For example, to fetch the current progress statistics for folder f3 in project 4, but without also drilling down in the contents and progress of each contained script, you would send an HTTP GET with parameters:

GET /projects/4/folders/f3?progress=terse&scripts=none

Generating a response along the lines of:

  "data": {
    "folder": {
      "id": "f12",
      "name": "Release folder 3.2",
      "progress": {
        "pass": 31,
        "fail": 42,
        "block": 0,
        "query": 1,
        "total": 87
        "summary": "Pass:31 Fail:42 Block:0 Query:1 Total:74/87",


Again, full documentation to follow, but the general goals of the webhooks are to enable external URLs to be called in response to test run events arising in Testpad. Further events will be added in time, but the initial collection of subscribable events are mainly designed for:

  • individual results being set, filterable for e.g. just failed results (which you might connect up to the automatic creation of a JIRA ticket, assuming you want the possible duplication this will entail!), and
  • run-level events such as test runs being started and completed

Example, subscribing to results set to fail

To connect an external action, such as a Zap in Zapier or some custom integration with JIRA or AWS Lambda, you would configure a webhook using the Testpad interface (API endpoints to subscribe webhooks won't be in v1, but certainly could be added if there's demand in the future).

Configuring a webhook means telling Testpad that you want your URL, e.g. https://hooks.zapier.com/hooks/catch/345678/abc34, to be called (by Testpad) whenever the event result.fail occurs.

For now, events will be generated for all projects in an account, however we anticipate providing for project-level filtering fairly soon after the initial release (and again, feedback welcome on this).

When a result.fail does then fire, your URL would be called with an HTTP POST:

POST https://hooks.zapier.com/hooks/catch/345678/abc34
... HTTP headers for signatures and content meta data

    "_event": {
      "topic": "result.fail", 
      "id": "bb8f5cba-17b73e73688", 
      "ts": { ... various timestamp formats ... },
    "result": {
      "comment": "", 
      "issue": "", 
      "result": "fail", 
      "url": "https://stef.ontestpad.com/script/3657/#2/1.2"
    "context": {
      "account": { ... }, 
      "user":    { ... }
      "project": { ... },
      "folder":  { ... },
      "script":  { ... },
      "test":    { ... }, 
      "run":     { ... }


Our most frequent support email these days (besides requests for old invoices - sorry folks, and ahem FastSpring) are customers asking when the API will be out. Having long got this wrong, I'm not promising a specific date. However, the project is mostly complete and the hope, but not promise, is to have this out early next year.

Meanwhile, if you are in the crowd itching to integrate your other tools with Testpad, I hope the above details are exciting and thank you for your continued patience!

Any questions or feedback, please do write in to support@testpad.com

Release notes for minor update (4.1.110)

This weekend, we upgraded Testpad with a collection of small updates and tweaks. Some bug fixes. Some customer suggestions. Some adjustments to keep Testpad running smoothly.

Reporting: new option to include old test runs

The report config settings (found at the top right of a report page) have a new option to include Old Runs. Old test runs are test runs that have been superseded by a newer retest. See using retests to go from build to build for more details on what retests are.

Previously, old test runs were only accessible on the script-editing page with a right-click on the test run header and selecting the Show Old Runs option. But now you've got the option to also include old runs in reports.

So if you use retesting a lot, and want a report that captures the history of how you got to the final status, open a report, head up to the top right config button, and turn Old Runs to ON.

Throughout your reports, if included, old runs will be shown as greyed out to indicate their "old" status. This includes in the summary section at the top of folder reports, in the grids of test run columns per script, and in the comment summary sections below each script.

Reporting: new option for XL column widths

And in another tweak to the report config: an XL column width option. If you ever use long values in your run headers, and if you don't have too many run columns, you can now set the display width of the test run columns in script reports to be extra wide.

This option is really only useful if you've got a wide display. If the browser gets too narrow (e.g. by making it small or viewing on a smaller device) then the XL setting will be ignored and Testpad will do its best to display your data with the space available - as before.

Mobile: attach images during testing

You can now use the mobile UI to view and attach images to test results. Support for this will depend on your mobile and browser, but modern iPhone and Android devices should work.

If you're not familiar or aware of the mobile UI, it's a really neat way to run your testing. From your desktop, you can display a QR code for one of your test run columns, scan it with your mobile, and then instantly begin running that test run on your mobile.

New subscription option: the "Team 15" plan

We've added a new subscription option for a 15-user team that sits between the existing Team and Department plans.

If your Testpad team grows above 10, you now don't have to make the big jump to paying for 25 users when you only needed e.g. 12.

We haven't updated the pricing page on the website, but the new plan is listed as an option in the app on the Subscriptions and Billing page.

New keyboard shortcut: ALT + for new test runs

By popular request, we've added a new keyboard shortcut for making new test runs. Hit ALT = (but think Alt-Plus) to create a new test run column.

As for the normal way to make a new test run (clicking the New Test Run button), you might be interrupted with a prompt checking you really do want a new test run. And this is because you might want a Retest instead. Again, see using retests to go from build to build for more on what retests are if you're not familiar.

This shortcut joins a big collection of keyboard shortcuts that make editing and running scripts possible almost entirely from the keyboard. Look for the help popup on keyboard shortcuts in the menu in the top right of the script-editing view, or indeed, use the keyboard shortcut for the keyboard shortcut help popup ALT ?.

Bug fixes

Finally, we included some bug fixes in this release:
  • attempting to send test run emails to an assignee or guest would sometimes fail depending on the values of the test run header fields
  • more protection against weird and wonderful filenames in image attachments that caused the upload (or subsequent download) to fail. But top tip: please try to use simple file names for attachments; every part of the internet is much happier if you do
  • you can now have more than one markdown-style link in a test row
  • copy/pasting multiline text in a test row now repaints the edit box properly

As ever, any questions, feedback or suggestions, please don't hesitate to email Testpad support.

As one customer said this week... "I never realized how effective the feedback button was" :)

Email addresses don't have to be unique anymore

As part of preparing the groundwork for the new API and webhooks, Testpad now let's you re-use your email address in different team accounts. Until this weekend, Testpad required all users to have a unique email address - once an email address was used in one account, it couldn't be used again anywhere else. But that's now changed. Like other popular tools (e.g. Slack!), Testpad now let's you register the same email address against multiple team accounts (often called workspaces in other tools).

This means you can sign up your own trial account, and if you later decide to subscribe to a paid plan, but on a new "official" corporate account for your team, you can simply add yourself to the corporate account without having to use a different email address or delete your own trial account.

Or for those on the Custom plan who're running multiple team accounts, you no longer need to use a different email per account that you want to be added to. (If that's not you, but it sounds like something you'd want to do, please get in touch to ask more about how Custom plans work.)

How does this work?

Just sign-up for new trial accounts, or add new users, or change email addresses, with whatever email addresses you like!

When you come to login, providing an email address and password to identify yourself, Testpad will check for whether those credentials match one or more accounts.

If the credentials only match one account (which will be the norm for the vast majority of people), then, as you're probably used to, you'll get taken straight into your account to get on with your test planning.

But if the credentials match more than one account, Testpad will log you in to all the matching accounts and prompt you for which one you want to proceed to. At that point, you can use the new "switch to a different account" option in the user menu (the menu in the top-right corner).

Note that if you set different passwords for different logins (on the same email address), then you obviously won't access the other accounts for that email address. Access is only granted to an account when the correct email address and password are supplied.

Login to more than one account at a time

And not just re-using emails, as part of this update, Testpad now also allows you to be logged into more than one team account at once (in the same browser). Use the user menu in the top right corner to access the new "login to a different account" to go back to the login page without logging out of the account you were in. If you provide good credentials (email and password) for another account, Testpad will keep you logged in to both accounts. You can switch between them via the same menu option, which becomes "switch to another account" once more than one account have been logged into.

But Testpad still complains "address already in use"?

So, whilst you can use the same email address in different team accounts, you still can't use an email address more than once within any one account. Otherwise, how would Testpad know who was trying to log in?

If Testpad stops you using an email address with the message "address already in use", then this means that email is already being used by someone else in that account.

Custom plan subscribers running multiple accounts

For those customers on the custom plan and running multiple team accounts, with their users using unique email addresses per team account: the existing email addresses and passwords will obviously continue to provide access to the relevant account. However, if you want to now migrate to instead re-using the same email address, then simply use the Manage Users page (and the relevant Edit Details option per user) to update the email addresses to the desired address. Note that all changes of email address still have to be confirmed by clicking on the link sent to that email address.

Case-sensitive email addresses (only relevant to long-term account holders)

For those accounts that pre-date 2017 and were using different "case" spellings of the same email address to differentiate accounts, these logins will now be treated as having the same email address. When you login, if your email (regardless of case) and password match multiple accounts, then you'll be prompted for which account you want to proceed to.

Any issues, please send your questions and problems to support@ontestpad.com.

Importing spreadsheets of tests into Testpad

The quickest way to get up and running with Testpad is to import existing tests, but the simplicity of doing this depends on the current formatting and layout of your tests, especially when you're copy/pasting from spreadsheets.

Read on for details of how this works, or simply skip ahead and take a close look at these Spreadsheet Import Examples.

This article concentrates on importing test cases from spreadsheets, but it should still be relevant to importing any source of table data into Testpad, including User Scenarios, Feature Definitions, or even existing checklists.

But if you're starting from scratch, writing new tests in your own style, then you don't need the help in here - instead, just get on with writing simple prompts of things you want to remember to test and go from there!

Per Script, use the Import Dialog to copy/paste text

Testpad's main document is a Script, and importing happens a Script at a time. Make a new empty Script and look to the Edit Menu -> Import option to open the Import Dialog.

Copy/paste your text for import, select a format option, and hit the Import button.

The goal for import is a single column of text

If you paste a simple block of text into the Import Dialog, on its Plain Text setting, then it will treat each line of text as a new row in the Script. For example:

Valid user name and password work
User can login immediately after changing password
Username with unicode characters works
User can login immediately after changing username
Invalid user name is rejected
Invalid password is rejected
Blank password is rejected
Blank username is rejected

will produce:

Use indentation to give tests structure

Any leading spaces or tabs (i.e. indented) rows will be spotted and used to form title rows with blocks of (indented) content underneath. At a higher level, this is ideal for grouping tests by topic. At a lower level, it's ideal for grouping rows to describe richer test cases - more of which later.

Normal login
   Valid user name and password work
   User can login immediately after changing password
   Username with unicode characters works
   User can login immediately after changing username
Bad login
   Invalid user name is rejected
   Invalid password is rejected
   Blank password is rejected
   Blank username is rejected

will produce:

Use the Spreadsheets format option when copy/pasting from spreadsheets

If you copy/paste from a spreadsheet, the format is typically quoted (to encapsulate cells, especially when multiline) with cells separated by Tabs.

The Import Dialog can deal with the quoted cells, but you need to specify the Spreadsheets formatting option. If you try to import a copy/paste from a spreadsheet using the Plain text format setting, the " quote characters won't be removed, and you're likely to get a bizarre looking layout.

Testpad only wants one column from a spreadsheet

When copy/pasting from a spreadsheet, you need to start by only copying a single column. Tests in Testpad are essentially a single column of test descriptions, with only results (not additional test data) appearing in multiple columns.

So what about when your spreadsheet of tests, like most test plans, has tests defined in rows across multiple columns? Maybe you've got one column for the title, another for the Steps of the test, and yet another for the Expected Results.

How do you import two or three columns into Testpad's one column?

Well... the answer is that you don't! Instead, you need to play with your spreadsheet a bit to build a new (single) column that is some aggregation of the other columns.

This is best done by creating a new column, and starting in the first row, start building up a formula that will put together the other cells into a "Testpad-friendly" single cell.

For example, if we have three columns, something like this:

TitleStepsExpected Results
Basic login 1. Load the /login page
2. Enter valid user name
3. Enter valid password
4. Press enter
Login succeeds and user's dashboard is displayed.
Rejected login 1. Load the /login page
2. Enter valid user name
3. Enter an invalid password
4. Press enter
Login is denied with message saying wrong username or password.

Then the trick is to create a fourth column, and fill it with formula like:


The table will then look similar to:

TitleStepsExpected Results
Basic login 1. Load the /login page
2. Enter valid user name
3. Enter valid password
4. Press enter
Login succeeds and user's dashboard is displayed. Basic login
1. Load the /login page
2. Enter valid user name
3. Enter valid password
4. Press enter
Login succeeds and user's dashboard is displayed.
Rejected login 1. Load the /login page
2. Enter valid user name
3. Enter an invalid password
4. Press enter
Login is denied with message saying wrong username or password. Rejected login
1. Load the /login page
2. Enter valid user name
3. Enter an invalid password
4. Press enter
Login is denied with message saying wrong username or password.

Now if we select the 4th column, and copy/paste that into Testpad, we get:

But we can do a bit better if we add in some indentation to better structure the new test column.

Consider a modified version of the formula from above:


Now our table's fourth column looks a bit different:

TitleStepsExpected Results
Basic login 1. Load the /login page
2. Enter valid user name
3. Enter valid password
4. Press enter
Login succeeds and user's dashboard is displayed. Basic login
   1. Load the /login page
2. Enter valid user name
3. Enter valid password
4. Press enter
   Login succeeds and user's dashboard is displayed.
Rejected login 1. Load the /login page
2. Enter valid user name
3. Enter an invalid password
4. Press enter
Login is denied with message saying wrong username or password. Rejected login
   1. Load the /login page
2. Enter valid user name
3. Enter an invalid password
4. Press enter
   Login is denied with message saying wrong username or password.

This isn't quite what we want, as only the first step has been indented. So getting a bit more clever with the formula, replacing newline characters for newline+spaces fixes this:

    => ",B3)

Now our table's fourth column looks tidier on the indentation

TitleStepsExpected Results
Basic login 1. Load the /login page
2. Enter valid user name
3. Enter valid password
4. Press enter
Login succeeds and user's dashboard is displayed. Basic login
   --1. Load the /login page
   --2. Enter valid user name
   --3. Enter valid password
   --4. Press enter
   => Login succeeds and user's dashboard is displayed.
Rejected login 1. Load the /login page
2. Enter valid user name
3. Enter an invalid password
4. Press enter
Login is denied with message saying wrong username or password. Rejected login
   --1. Load the /login page
   --2. Enter valid user name
   --3. Enter an invalid password
   --4. Press enter
   => Login is denied with message saying wrong username or password.

This latest version of the formula also inserts some "--" prefixes which Testpad interprets as "comment" (i,e. non-test) rows.

Whether you want to use comment rows depends on whether you mind collecting results for "steps". My own preference is it's fine, when I record a "pass" against a step, I'm recording a result to the effect "yes, did that, no problems". But lots of people like to make steps just comments and only record results against the Expected Outcomes.

And when this modified 4th column is copy/pasted into Testpad, we get something much more workable:

And getting more complicated...

Of course, your spreadsheet might have many more columns. Take for example something like this:

Which can be imported, as above, with a new column that aggregates (with modification for prefixes and indentation), to produce:

How did that work?... check out the collection of Spreadsheet Import Examples for more detail.

These examples all illustrate multiple test cases per import - it's a common misuse of Testpad to only have one test case per script - you definitely want to put multiple test cases into each script, making good use of the indentation structure to form logical groups.

Copy/paste two or three columns to set Tags and Notes

Testpad will actually accept two or three column imports, but it uses them for it's own purposes... if present, Column 2 will define the Tags to include for a tow, and Column 3 will define Notes.

Tags are part of Testpad's tags and filtering feature, where test rows can be tagged with labels that Test Runs can filter for - useful for defining subsets of tests for certain test run conditions.

And Notes are for the notes field that is "behind" every test row, displayed in the Test Details dialog. You can access the Test Details dialog by clicking on the small doc icon, or double-clicking the row ID, or typing Alt-N. These Notes are wiki-formatted and can be displayed during testing if required using the little checkbox in the Test Run execution dialog.

The Notes field (third column in multi-column imports) is another option for where to put imported test content. For example, if most of your testers are familiar with the product, then you might want to "hide" the Steps in the Notes field and only display the things to Verify in the main part of the Script. New or less experienced testers can then open the Details dialog to get the extra instruction when needed, but for everyone else, the Script is more compact and can be read through and executed more quickly.

To populate the Notes field during an import then, you need your copy/paste to span three columns, where the first column will be the main test text, the middle column empty (assuming you're not trying to tag anything yet), and the third column for the notes. This is all best achieved by adding three new columns to your spreadsheet, and setting up formulas to aggregate/copy the relevant cells into the first and third of the new columns.

Again, have a look at the Spreadsheet Import Examples for an example of a multi-column import.

CSV (Comma-Separated Values)

And lastly, a note on CSV imports. These work exactly the same as spreadsheet imports, except that the cells are separated by commas instead of tabs.

Just as for copying from spreadsheets, you need the first column to be the main test text as described (at length!) above, the second column for tags, and the third column for each test's Notes field.

Want some help?

If this is all still not making sense, or you have existing tests that you'd like some help with how to import, then don't hesitate to email some example tests and questions to support@ontestpad.com - always very happy to help.

Simple ways to include links to User Stories, Feature Specs, Issues and more

This post documents the several simple and flexible methods that Testpad has for including links to third-party content.

Why link to anything?

It's very common when writing tests to want to associate the tests with why they exist. This usually means linking the test in some fashion to the User Story (or feature spec, or requirement definition etc) that scopes what the tests need to check is working.

In other scenarios, it's common to want to provide the tester with additional resources in the form of links to help documentation, or other further context on the where/why/what of the topics under test.

Simple clickable links

As usual, Testpad doesn't try to be complicated with making such connections to third-party material. Instead offering a variety of methods for including clickable links that simply load up the referenced page in a new tab... basically what the hypertext in http means!

To include links in your tests, choose from:

  • Plain links
    https://ontestpad.com displayed as https://ontestpad.com
  • Markdown-style links
    [TestpadHQ](https://ontestpad.com) displayed as TestpadHQ
  • Wiki-style links
    [[https://ontestpad.com | Testpad]] displayed as Testpad
  • Short-codes for common link patterns
    e.g. automatically recognising something like US:123 as a link to say https://my.requirements.com/story/123 and displaying it as say User Story 123

NB don't forget to enable links in Project Settings

Include links wherever they're helpful

Testpad lets you include links in most places that accept text input:

  • Test text titles
  • Test text comments
  • Embedded in test text
  • the Notes field behind every test
  • Script Description blocks
  • Note Items in Folders that sit beside links to Scripts
  • Comments against individual results

Plain Links

Whenever you include an obvious link (starting http:// or https://) in some text, Testpad will recognise it as a link and display it as a clickable link opening in a new tab. If the link isn't too long or complicated looking, this method is basically just for free and happens without even reading up on the details!

Markdown-style Links

If you go to Project Settings for your project, you can enable Markdown-style Links (they're off by default), which means any time you include a link with the pattern [Title](link), the "link" will be displayed as the clickable "Title". Useful for longer/complex URLs that otherwise confuse the text they're appearing in.

Wiki-style Links

Similarly, in Project Settings, you can alternatively enable Wiki-style Links, so that any time you include a link with the pattern [[ link | Title ]], the "link" will be displayed as the clickable "Title".

Short-codes for common link patterns

Lastly, and perhaps most powerfully, Testpad includes a link pattern generator which is great for when you want to include lots of links to very similar URLs. For example, if every test block needs to link to the User Story item in JIRA that it pertains to, it would be tedious to include the full JIRA path in every test title.

The Project Settings page lets you define short-codes that map a prefix:code pattern onto a link pattern. This is probably best explained by example:

The definition:

is defining a short-code "story", such that whenever some text includes "story:ABC123" (i.e. "story" followed by a colon followed by some characters), the short-code will be replaced with a link to "https://some.website/issue/ABC123" that's displayed as User Story ABC123.

Guest Testing - anyone can help when the pressure is on

This article is about a powerful feature in Testpad called "Guest Testing". It does what it says on the tin: you can invite guest users to help make test runs, testing your software as prompted by your test plan and recording results.

Guest testers don't need logins to your Testpad workspace. You invite them by email, and a special link gives them time-limited read-only access to just the test plan (script) that you've invited them to help test.

And with Testpad's near instant learning curve, anyone you do invite can immediately get on with that testing, without formal training or induction to your tool chain.

OK. So why is this so great?

Guest Testing is helpful in many scenarios, each of which deserves its own article (watch this space!), but including

getting extra help at release time from outside the test team: developers, managers, business stakeholders, friends...

involving clients in testing fantastic for de-risking delivery and building trust

user acceptance testing involving clients again, but the more formal (or not) version where the test plan is being used explicitly to prove (or not!) the software is ready

restricting visibility of test plans containing sensitive content

Preparing for Guest Testing

1. Test Runs

Test results in Testpad are recorded in columns to the right of test prompts. Each column is to record a different set of results against the same prompts (although filters could be used to vary the subset that's actually tested). Columns are mostly used to establish test runs against different environments such as different browsers for webapps, or different phones for mobile apps. Columns can also be used for the same environment but for different testers (you get a higher chance of finding bugs if different brains can look at the same test ideas).

2. Assigning to Guest

For guest testing then, you initiate the process by assigning a Test Run (column) to "Guest".

Test Run assigment is managed in the Test Run details dialog which you open by any of:
- creating a new test run (which auto opens the dialog for the new test run)
- right clicking on the header of a test run column and selecting edit details
- hovering over the header of a test run and clicking on the pencil icon (edit)

Test Run assigment is only available for Test Runs that are still "IN PROGRESS" (as opposed to "COMPLETED"). So if you can't see the assignment drop-down box, that'll be because the test run is already completed! In which case, why would you be trying to assign it to someone else? :)

When the dropdown box is used to select "Guest" as the assignee, a button below appears for composing and sending an email. Use this button to address, and optionally edit the contents of, an invitation email that will give the recipient a link they can click on to make the test run.

3. Email Invitation

The recipient of the email will get a link, like a document sharing link, that gives them some restricted access into your testpad account. Specifically, they get read-only access to that one test plan (script) to record results against that one test run (column).

For practice, you can send guest test invitations to yourself to see what the experience is like. Though note that clicking on a guest link will log you in as Guest... which means logging you out as your normal user.

Top tip: for practicing with guest testing, open the guest test links in a different browser. That way you can stay logged in in your usual browser.

4. Performing guest test runs

This doesn't really need description - which is the whole point!

1. Click on the link you received.
2. Follow the test prompts.
3. Record appropriate comments and the pass/fail status.


Well, OK. The simplicity here will depend on your test prompts and the complexity of your software under test. Testpad does it's bit to not add to the complexity however, reducing the task to prompting and recording results.

If your prompts are more exploratory in style, i.e. they're not full of detailed instructions to do this, then that, then that, then expect exactly this and that; but instead suggest looking at e.g. unicode input in the login page, or forgotten passwords for returning users, then they will need the Guest Testers to engage brain and be imaginative in what they actually test.


Lastly, don't miss that Guest Testing links can be opened on mobile devices as well as desktop devices. On most tablets and mobile phones, you get a mobile version of the testing interface. Being prompted for and collecting results on a separate device can be very practical; it saves the tester from constant context switching on their main screen between the app under test and the test mgmt tool.

So that's it for now. Any questions about how any of this works, please don't hesitate to contact support@ontestpad.com.

Happy (guest) testing.

PS. Guest Testing is a premium feature available from the Team Plan and upwards. However, it is available in the Free Trial, so give it a go and see for yourself how convenient it is to bring in extra, or even external, help when the pressure is on to make a release.