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:

=CONCATENATE(B1,"
",B2,"
",B3)

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:

=CONCATENATE(B1,"
    ",B2,"
    ",B3)


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:


=CONCATENATE(B1,"
    --",REGEXREPLACE(B2,"\n","
    --"),"
    => ",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

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.

Simples.




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.



Mobile


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.


Testpad's new UI sees 1m results in 3months

It's now been 3 months since Testpad's UI saw a big upgrade in look and feel, and, judging from customer emails (keep 'em coming), Testpad has never been so popular.


And it's not just the positive feedback - since June, the new UI has been used to record over  1,000,000  results, taking Testpad's total to over 15m. Sadly for the dev teams out there, not all of those have been 'passes', but at least the bugs are being found in testers rather than customers hands!

Looking ahead, Testpad's next big upgrade over the coming months will be a much-requested API. The API work is still early days, so don't hold your breath just yet. Although please do get in touch if you have specific requirements or ideas for how you'd use an API. The more input at this early stage, the more useful it will be.

If you're new to Testpad, please don't hesitate to get in touch for help... video demos, importing existing tests, usage patterns etc.., just email support@ontestpad.com.

Testpad Tips - don't make Scripts too short

This is the third post on usage tips for Testpad and is about getting the most from a Script. Actually there are lots of aspects to using Scripts well, but this post is all about avoiding a common mistake: making scripts too short.

It's very tempting to treat a script as a single test case, and thus put as few as 5-10 rows in it that only collect 1 or 2 meaningful results. While this works, it's not what the UI was designed for and it will quickly become annoying navigating to and fro from the project view.

Aside: it is also possible to make scripts too long, but a) this is way less common, and b) Testpad tries to protect you from yourself by limiting scripts to 2000 rows. In fact, too long only becomes a problem if you've got 1000+ rows combined with 100+ columns, but see the first post in this series for tips on fewer run columns.


Before we get into it, here's a screenshot of the top of a well-formatted script. This one happens to be test-case inspired in terms of specifying steps and expected outcomes separately, but the ideas apply equally to exploratory style guides and simple checklists of terse test prompts.



The formatting in this example is pure convention. There are lots of possibilities, but the general aim is to make good use of the hierarchical structure and keep each cell to a single row of text.

This example also makes use of Link Shortcodes defined in Project Settings, for convenient linking to e.g. User Story documents.


Short Scripts

The main issue with short scripts is in missing out on the power/efficiency of the script-editing page, with its progress bars, indentation structure, inline styling, keyboard-driven UI etc etc. It also overloads the Project view, as any reasonably sized project will have several hundred cases to test, and hundreds of scripts in one folder is just annoying to manage.


What does a short script look like?



Or worse...



When instead you can have lots of tests in the one script:



Which then lets you do things like collapse the rows for convenient overviews of your test coverage (collapse buttons hiding at the very bottom of the browser window):



Or even:



And here's another example in the BDD/Gherkin syntax format, which Testpad will auto-highlight when it spots rows starting with keywords like Given, When and Then:




Refactoring: Joining Scripts Together


Lastly then, if you find yourself with lots of short scripts and want to combing them, here are two ways of getting that done...

COPY/PASTE BETWEEN TABS

Open Script A and Script B in separate tabs in the same browser.

In Script A, make a multi-row selection and press Ctrl-C (you should get a message saying "N tests copied").

Switch tabs to Script B, select (but don't focus on, as in you don't want the text edit cursor visible) the last row, and press Ctrl-V. You should get a message saying "N tests added".

If successful, head back to the Project view to delete Script A (right click on its name).


EXPORT/IMPORT

In Script A, use the Script Menu → Export → Tests As Raw Text.

Select and Copy the text in the text export dialog box.

Navigate to Script B, and use the Edit Menu → Import.

Paste in the copied export from script A and click on Import.

The tests from Script A should have been added to the bottom of Script B.


Refactoring: Splitting Scripts Apart


Similarly, if you have a script that's too long and haven't started collecting results yet, then you can use either of the above methods to copy a subset of tests out of one Script and paste them into a New (empty) Script. You then head back to the long script and delete the rows you just copied out. Be careful though, if you delete the wrong rows, you've only got Undo while you're on the page... as soon as you navigate away or reload, the Undo history is lost.




As usual, don't hesitate to email support@ontestpad.com if you have any questions, or even just to discuss your own test formatting in Testpad.

Testpad Tips - make copies to go from release to release

This is the second post on usage tips for Testpad and is about a great way to organise tests when going from release to release. The first post was about using retesting to go from build to build within a release.


Use a Folder per Release

The simplest way to model releases is to use a whole new folder for each new release, and to populate the new folder with copies of the scripts you used last time.

When scripts are copied, all the tests and run headers(*) are copied, but the results are left behind.

A copied script is therefore like an on-the-fly template for the next release.

(*) If you hold the ALT key down when copying (either via the Duplicate menu item, or when drag'n'drop+CTRL), then the scripts are copied without the run headers too.



Example first, details below

Suppose you have a product called SlicedBread and you've just finished testing v1.0.



Prepare for v1.1 by right-clicking to Duplicate the folder.



Finally, rename the new folder to e.g. SlicedBread 1.1 and it's ready for testing the next thing since SlicedBread.





In a bit more detail


// Copying the whole folder

You can copy a whole folder with a right-click on the folder name, and selecting the Duplicate option. Or you can drag'n'drop with the CTRL key held down. Either way, you get a new folder with all the contents from the previous folder copied.

// Or copy the individual scripts

Alternatively, make an empty new folder for the new release, and selectively drag'n'drop+CTRL each script you want a copy of from the previous release.

This is useful if you only want a subset of the scripts from last time. If you want all of them, it's going to be quicker to just copy the whole folder as above.

(Additional detail: if you also hold down the ALT key, you get copies of scripts without the run columns.)

// Or copy templates instead

Some much more complex projects, typically those involving custom configurations of components that are different from release to release, might instead look to populate a new release folder with scripts taken from a Library of Templates. Templates are nearly the same as scripts, except Templates never collect results, and only ever exist to be copied to make a script from.

Use templates (or folders of templates) by dragging and dropping onto the Project Name (over on the left) that you want the template copied into. Then go to that Project and move the new scripts (which are created at the top of the project) into the right folder.


Keeping a record of the previous release

The whole point of making copies for new releases is to leave intact the tests and results from last time.

Tests need to be updated in step with each evolution of a product, and it would be a shame to lose the consistent record of what was tested and with what results if the old scripts were then edited to add new features etc.

Instead, by working on new copies, the old tests and results are left alone, and the new copies can be edited as much as required to bring them up to date for the latest version of the product.



Archiving old Releases

And to keep the interface tidy, it helps to archive away old releases once they're only needed for their reports.

Archive a folder by right-clicking on its name and selecting the Archive option.

Find archived scripts and folders via the Archived Scripts link at the bottom of the list of scripts and folders for a project.

This is archiving within a project, and is most relevant for archiving old releases. Which is not to be confused with archiving a whole project (right-click on the project name over on the left and select Archive) for when you don't need a whole project to be around anymore.



Please get in touch if you need any help with how to apply these ideas to your projects... just email stef@ontestpad.com.

Testpad Tips - use the Retest feature to go from build to build

Testpad 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 for great usage patterns.

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 rendering the 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.