Quantcast
Channel: Testpad Blog
Viewing all 42 articles
Browse latest View live

Growing Customer Base means Bigger Servers

$
0
0

This Spring has seen a signficant increase in traffic due to a growing customer base, to the point of prompting server upgrades that were just completed this weekend. The new servers have increased Testpad's capacity and reduced page loading times; with the upgrade process itself proving the convenience of technologies like MongoDB for seamless database replication and Amazon EC2 for command-line control of servers archicture.

Whilst Testpad's customers have been busy, Testpad has been quiter on the development front. However, with these latest upgrades, and further improvements around the corner, it's set to be a busy Summer. In the short term, look for improvements to tag filtering, followed later on with the publication of much needed user guides and documentation.

The rest of this post has a strong engineering bias. Read on if you're curious about Testpad's hosting, or get back to your testing, which should now be snappier than ever!


MongoDB + AmazonEC2 = Upgrades with Zero Downtime

The upgrade saw the main application servers moving from Amazon's older generation of servers (m1) to their latest (m3) servers. As well as newer CPU architecture, the m3 servers come with SSD storage, providing a big increase in database IO performance.

Thanks to the convenience of the Amazon EC2 management interfaces, and robustness of MongoDB's replication technology, these upgrades were performed with zero downtime.

Just to be safe, the upgrade was timed for the weekend when traffic is quieter than during the week, but nevertheless, the logs showed continuous usage before, during and after the upgrade, with no interruption to service.

Broadly, the upgrades were achieved by modifying one database (MongoDB) replica and application server at a time. Once a database replica is shutdown, the live service is maintained by the surviving replicas, thus freeing that server for maintenance. As all Testpad instances have their Linux root partition on an EBS volume, the upgrade itself is as simple as using AmazonEC2 controls to Stop the instance, edit the instance type, and Start it again. When the instance boots up, it is now running on bigger and better hardware! The database folder is then moved from its previous mount point on an EBS volume to its new home on the SSD drive. Once restarted, the MongoDB replica contacts the other replicas and catches up with all the changes that happened during that server's upgrade. Seamless.


Hourly Database Snapshots

Readers familiar with AWS might spot that m3 instance SSD drives are 'ephemeral' devices that do not persist if the instance is stopped or otherwise lost. Testpad therefore still runs replicas with the data volume stored on EBS drives, which continues to enable Testpad's backup strategy of hourly snapshots and archive to AmazonS3.


More Info and Feedback

Please get in touch if you have any feedback or would like to know more about the details of this upgrade - just email stef@ontestpad.com.



Improved Filter Controls

$
0
0

This weekend saw lots of small improvements for Testpad, the biggest of which is an upgrade to how tagging and filtering works.

Filter with OR logic

Test Runs (columns) have a Tag Filter field that defaults to "ALL" which means that run will include all the tests. If you change this to e.g. "WIN", then that run will only include tests that are tagged "WIN", and the rest will be drawn greyed out.

Multiple tags can be supplied, and as before, if separated by a comma or space, will be applied using logical AND. For example, a run with Tag Filter set to "WIN HI" will only include test rows that are tagged with both WIN AND HI. If the desire was to include all rows with either tag WIN or tag HI, then that didn't used to be possible. However, with this release, you can now use the '+' character to achieve this kind of additive filtering. E.g. a run with the Tag Filter "WIN + HI" will include all tests tagged WIN OR tagged HI.

A note on precedence: there's no support for brackets or parentheses for complex expressions, instead the space/comma (for AND logic) takes precedence over the + for OR logic. So a more complicated Tag Filter of "A B + C D" will be including all tests tagged A AND B along with all tests tagged C AND D.

The minus prefix '-' still works to negate the match, e.g. the Tag Filter "A + -B" will include all tests tagged A along with all tests NOT tagged B. Note again that because parentheses aren't supported, there's no way to negate a group; the minus prefix can only be used on a single tag at a time.

Setting and Viewing Tags

To help with the new tag filtering, tags for test rows are now displayed as labels to the right of each row. As space is limited, tags are shown in fixed width labels that show the first 5 or 6 letters of the tag, and Testpad will only attempt to show the first 5 tags for each row.

Tags are set using the Test Details dialog, which can be opened in a number of ways: double-clicking on the row ID, clicking on the small corner triangle on the right-hand end of the row, or typing Alt-T.

Tags applied to outdented (parent, or title) rows will affect all their indented child rows. This is very convenient when you want to include/exclude whole sections of a script for a particular run; it saves on having to set a tag on each and every test.

User Interface Tweaks

In addition to the tag filtering improvements, a few UI improvements were also included in this release:

  • blocks of test rows can be selected and copied even if the Script has been locked for editing (remember Copy/Paste works between pages/tabs)
  • test run emails no longer CC the sender, instead they set the Reply-To field; this is to help with testers hitting Reply on these emails and inadvertently emailing Testpad Support instead of their test manager!
  • new option for the Auto Advance setting when running a Test: OFF simply turns off auto-advance so that the focus stays with the current test

As always, feedback on these changes is very welcome; please email me at stef@ontestpad.com

Coming Soon: Folders, Permissions and Docs

$
0
0

The blog has been quiet this Summer, so I thought I'd post an update as three big improvements are afoot, but not quite ready for release.

First up will be folders to offer more flexibility in how scripts are organised within projects. Many customers, and indeed Testpad's own testing, are using Projects to model Releases; a new Project is started per Release, with the set of Scripts copied (by drag'n'drop with CTRL held down) from the previous Project/Release. This would work better if Testpad had folders within Projects so that, say, each Folder could look after a Release instead of the whole Project.

Next up will be a big extension to the permission model. Admins will be able to assign Users to one or more Groups, and then Projects can be restricted to be only visible/accessible to members of defined Groups. This will be of most use to the many consultancies using Testpad who wish to keep visibility of client-confidential material limited to just the teams working on those projects.

And in parallel with the above, Testpad's much needed documentation is in the works, covering all the features of Testpad and giving examples of good ways to deploy the testing process.

Timescale? I'm going with a non-committal "soon" :)

By all means email me at stef@ontestpad.com if you want to contribute any ideas in the folders, permissions, documentations areas - this would be an ideal opportunity to incorporate suggestions from the Testpad community.

Reordering Test Run Columns

$
0
0

Today we introduced an oft-requested feature to provide for rearranging the order of test run columns. Work is continuing with the bigger ticket items of folders and permissions, but the re-ordering of test run columns has been requested by so many customers that we took a short break to push this smaller update.

CTRL-LEFT and CTRL-RIGHT

Typing Ctrl-Left or Ctrl-Right will move the currently selected test run one column to the left or right.

Where a test run is a retest of older test runs, the older test runs (when shown) will always stay with their latest retest. Remember you can show old test runs by right-clicking on the test run header and selecting Show Old Test Runs.

ALT-LEFT/RIGHT and CMD-LEFT/RIGHT

For some users, Ctrl-Left/Right will have other window-related actions, so Alt-Left/Right and Cmd-Left/Right are also provided as alternatives. Have a try and see which key combination works for you.


Infrastructure Updates

And in the background, we also took the chance to upgrade the versions of Django, MongoDB, and Linux that Testpad runs on to pick up the latest security updates. Thanks to the flexibility of Amazon's Web Services, together with MongoDB's seamless clustering, these updates were performed without any break in service.


Any questions on test run reordering, service updates or new feature requests, please email stef@ontestpad.com

Coming soon: image uploads and folders for scripts

$
0
0

The blog has been too quiet for a couple of years, so here's a quick update to say hello.

Testpad has been live since 2011 and has enjoyed steady growth year on year, now with thousands of users who have collectively recorded over 250,000 test runs totalling millions of pass/fail results.

Servers and infrastructure have been upgraded in the last year to keep ahead of the growing demand and development continues on new features. I'm hoping to make a significant update to Testpad next month introducing several features that have long been asked for...

  • folders to organise scripts within projects, with drag'n'drop organisation for simpler release management
  • file attachments to tests for images, PDFs, docs etc in support of what to test
  • file attachments in results for screenshots etc in support of describing problems

More next month. As ever, any questions, please email me at stef@ontestpad.com.

New Features - Images, Folders and Reporting

$
0
0

This weekend sees the release of several updates to Testpad. These will be described in more detail in subsequent blog posts, but can be summarised as follows. Also scroll down for a detailed list of UI changes that could require minor changes to current process.


Image Attachments

Images and files can be attached to test descriptions and to test results by drag and drop.

Files in support of test descriptions go in the Test Details dialog, which is accessed by any of: double-clicking on the row ID, clicking on the triangle icon at the end of the row of text or typing the shortcut Alt-T.

Screenshots etc in support of test results go in the Test Run dialog which is displayed during a test run.


Folders

Scripts can be organised into folders for improved release management and general grouping of tests.

Scripts and Folders themselves can be organised by drag'n'drop, with CTRL held down to make copies instead of moving items.

Right-click on Script names and Folder names for more options, including accessing reports per folder.


Reporting

Reports are now all presented using the all-in-one printable HTML page and displayed in a new tab/window.

Reports can be accessed using Folders (right-click on the folder name), or via the "view report" button that is displayed when a project has no folders.

Configure the contents and sharing of reports by opening the report and then clicking on the settings button in the top right-hand corner.


Tag Colors

Tags can be displayed using custom colors, configured in the Project Settings tab. For now, custom tag colors need to be configured per project. If there is demand, an Account level default setting could be added, as for how the Bug Link setting works.

User Sorting

The Users view now offers some sort options to help customers with their long lists of users.

Emails case-insensitive

Emails for login etc are finally case-insensitive as they should have been all along. Some customers own multiple accounts and use different spellings (patterns of upper and lower case) of their email addresses to identify these different accounts. For backwards compatibility, these different spellings of their email addresses will continue to work as before, but new accounts will not be able to use this trick.


UI Changes

Most of the changes in this update are additional to existing functionality and as such should not present any process problems. However, there are some minor changes, which are summarised:

  • Reporting is now accessed via the View Report button (for existing projects without folders) or by right-clicking on folders and selecting the 'View Report' option. The 'browse' report (also called 'live' in some places) has been deprecated as it was both redundant and under-used.
  • Sharing of reports is now managed in the report itself. Open the report, click on the Report Settings button in the top right-hand corner, and use the Enable/Revoke Guest Access button.
  • Folder reports do not have the Report Comments field that Projects used to have. Existing projects (without folders) continue to have a Report Comments field (but moved to the Settings Tab) for backwards compatibility. For newer reports, based on Folders, there is a new feature to insert Notes within the list of Scripts. These Notes can be used for small comments and are included in the summary sections of reports.
  • The Show All/Hide All Details button in the project view has been moved into the SCRIPTS menu item in the header bar. The FOLDERS menu has a similar option for expanding/collapsing all folders.
  • The project progress bar is now only displayed for existing projects that do not contain folders. As soon as folders are added, progress is displayed per folder.
  • Project level reports are still available via the View Report button, but this is only available until Folders are used, after which each Folder should be used to access reports within that Project. If this becomes a problem, please contact support@ontestpad.com for a workaround.
  • The sort order of scripts used to be alphanumeric and this was updated automatically when new Scripts were created or renamed. This automatic sorting is now replaced with manual sorting via drag'n'drop. If you would still like to sort Scripts alphanumerically, there is an option in the right-click menu for Folders to sort their contents.
  • Templates can be used to make scripts by drag'n'drop onto a Project name. Either single Templates or whole Folders at a time can be dragged onto a Project to make one or more Scripts. There's no longer a menu option in the Project view to create a script from a template.

With the number of changes to Testpad there are bound to be some early issues. If you have any problems or questions, please do not hesitate to email support@ontestpad.com

Attaching Images, Screenshots and Other Files

$
0
0

Testpad now supports uploading files and images in support of tests and results. Files are uploaded using drag'n'drop onto areas in the dialog boxes for test details and test running.


Images for Test Descriptions

Test descriptions can have images and files attached by opening the Test Details dialog and dragging files onto the Attachments area

The Test Details dialog is available for each row in a Script and is accessed by any of

  • double-clicking on the row ID
  • typing the shortcut Alt-T
  • clicking on the small triangle icon at the end of the row of text
  • if files already attached, clicking on the file thumbnail at the end of the row of text

For Chrome users, files can also be Pasted (Ctrl-V) from the clipboard when the Attachments area is focussed and highlighted.

Files and images can be viewed in a File Viewer dialog by clicking (or right-clicking) on the thumbnails in the Test Details dialog.


The File Viewer will stay open during testing, and will auto-update to display the files/images associated with the current test.

Right-click on thumbnails (in the Test Details dialog) for more options such as download and delete.



Images for Test Results

Test results can have images (presumably screenshots) and files attached by dragging files onto the Attachments area of the Test Run dialog. The Test Run dialog includes the Pass/Fail buttons and is displayed during a test run.


Again, for Chrome users, images can be Pasted (Ctrl-V) from the clipboard. This makes it very easy to attach screenshots when using system shortcuts such as Cmd-Opt-Shft-4 on macOS.

When images are attached to results, they are represented in the results grid as Comments and displayed when the mouse hovers over the footnote dagger icon beside the relevant result.

Attached images are displayed as clickable thumbnails in the Comments section (below each result grid) of reports.



Storage Limitations

Individual files cannot be larger than 6MB.

Files are not part of the account/project/script exports and cannot be bulk downloaded from Testpad. Testpad is not a general purpose file storage facility!

The general idea is that uploaded files are simply copies of originals already in the user's possession and can be uploaded for the convenience of running tests or recording results.



As ever, any questions or problems, please email stef@ontestpad.com.


Folders for Simpler Release Management

$
0
0

With the recent success of the new folders feature, here's a usage pattern that lots of customers have adopted to handle releases. In essence, this pattern avoids using Templates and instead uses the previous release as an on-the-fly template for the new one:

    Duplicate the previous release

  1. Right-click on the folder for the previous release and select Duplicate
  2. Edit the new folder name to reflect the new release version number
  3. Update the tests

  4. Edit the new copies of the Scripts to catch up with the latest features in the product; adding new Scripts as required, and deleting any unneeded Scripts
  5. Archive the old release

  6. (optional, depending on how tidy you like your Project view) Right-click the old release folder and select Archive; this puts the old folder in the Project's Archive tab. Note that this is different to archiving a whole Project which you do by right-clicking on the Project's name in the list on the left.
  7. Do the testing

  8. Within each Script in the new release folder, and when the product is ready for testing, make the first test runs for the release, collecting lots of passes (hopefully) and a few fails (inevitable)
  9. Share the progress

  10. Start sharing the folder report with stakeholders: from the Project view, right click on the folder name and select View Report. This opens the report in a new window. The contents and verbosity of the report can be configured using the button in the top-right corner, which is also where you can find the Enable Sharing button to get a share link. Alternatively, the whole report is easy to SaveAs because it is a single self-contained HTML document that can be archived as-is in your own systems (file sharing, wiki attachments, emails etc).
  11. Retest new builds

  12. If a new build is coming, create ReTests of the complete Test Runs. Prepare ReTest columns using the prompt when a run is first completed, or by opening the Test Run Details dialog (hover over a Test Run header and click on the Edit icon that appears), sliding the slider to Complete if it's not already, and then clicking "start a retest".
  13. A ReTest is different to simply pressing "new test run" in that the new column takes the place of the previous run, both visually and in the progress stats. Thus you don't clutter the screen with more and more old test runs (unless you like that!), and the progress bar for the Script (and in turn, the Folder it is part of) can approach 100% pass as the fails get re-tested as working.

    You can get old runs back on the screen with a right-click on the header of the latest test run.

  14. And repeating step 7 as many times as new builds need re-testing to ship the release.
  15. Ship it!


Any questions, problems or feedback, just email stef@ontestpad.com


Writing BDD Test Scenarios with Gherkin Syntax

$
0
0

Testpad now has built-in syntax highlighting for writing tests in the "Given, When, Then" style.




Behavior-driven development (BDD)

Behavior Driven Development is a software development process that is based around the desired behaviors of a system; defining a framework for collaboration that is both precise enough for developers/QA and human-readable enough for business stakeholders and non-technical team members.

Requirements are framed as user-focused scenarios (effectively acceptance criteria), composed in plain English with a descriptive grammar in the form: Given [some initial conditions], when [something happens], then [something should happen].

Scenarios often use one or more concrete example values to help define the behavior.


BDD Automation frameworks, e.g. Cucumber, jbehave

The controlled structure of BDD requirements lend themselves to test automation. Frameworks like Cucumber and jbehave start with Scenarios defined in the plain "business-readable" language and then structure the test code in and around it.

As the developers of Testpad, a tool to help you manage your manual testing, it's perhaps not obvious that we promote the idea of automating as much of your testing as is humanly/reasonably possible. If you're not automating any testing yet, stop reading and get on it!

But you can't automate everything, and probably have lots of tests that you haven't got around to automating yet... in which case, despite wanting to automate everything, you have plenty of manual BDD testing to organise. Which leads us nicely onto the new support in Testpad for writing test plans as collections of scenarios in the Gherkin syntax...


Gherkin syntax - Given/When/Then - a business-readable domain-specific language

The Gherkin language is a formalisation of the Given/When/Then style of test definitions, as used by most prominently by the Cucumber automation framework amongst others.

Testpad now automatically looks for this formatting and colors the keywords if it finds them. If Testpad doesn't recognise your way of formatting Given/When/Then, you can force ON the syntax highlighting. Equally, if Testpad is thinking you're using Gherkin when you're not, you can force it OFF.


Formatting options to suit your style of Gherkin Syntax

By default, every row in Testpad, that isn't a title row, is a "test" that will collect a result i.e. Pass, Fail, Blocked etc, along with optional Comments, Screnshots and Bug Numbers.

When importing (or writing) BDD tests, this means rows that begin GIVEN and WHEN will also be regarded as tests looking for a result:


For lots of customers, this is just fine, and recording a "Pass" against a GIVEN statement can just be interpreted as "yep, set that up, no problems", and a "Pass" against a WHEN statement can mean "yep, made that happen, no problems".

For other customers, there is a preference to only record results against the THEN statements that define what should (and therefore might not) happen. To this end, Testpad offers a couple of options:

  • Use the new comment prefix -- which acts just like the // comment prefix, making a row a non-test row, except that the -- characters are hidden for a prettier display
  • Use cascaded indentation to make title rows out of every non-test statement

Combining Exploratory Testing with BDD/Gherkin

Whilst Testpad's free-form layout can be used for almost any test process, Testpad excels in writing plans that are guides (whether high-level or detailed) for Exploratory Testing. The idea of exploratory testing is that you don't follow prescriptive instructions for what to test, but instead leave the human brain free to be inquisitive and tenacious in hunting down unexpected behavior. Test plans for exploratory testing are therefore "guides"; checklists of features that you don't want to forget to take a good look at.

However... BDD/Gherkin tests, on the other hand, are more proscriptive, defining in significant detail what needs to happen given/when/then this or that happens. This is of course great for Acceptance Testing; proving that the stated requirements have been met. But alone, this is then less useful for having confidence that the system is bug free.

So why not have your cake and eat it?

Copy/paste your Gherkin tests into Testpad, tweak the formatting if required, and then extend the tests with ideas, details and edge-cases to explore in and around the given scenario.


Test plans in Testpad are a free-form checklist document. So whilst you can structure your requirements using Gherkin syntax, there's nothing to stop you adding further lists (sub-checklists) to each BDD Scenario.

If bugs crop up in the field after Release 1.0, go back to your Scripts (checklists) in Testpad and add tests/ideas/notes to the relevant scenarios to protect against regressions next time.


Any problems, questions or further suggestions to improve these ideas, please email stef@ontestpad.com.

New Release: Testpad 4

$
0
0

New Look and Feel

Testpad just got a major update to its look and feel. The whole design of the app, and the branding of the marketing website, has been updated with a fresh look.


The functionality remains nearly identical, with only a few menu options moving around. Everything you could do before you should still be able to do in the new version.


New Pricing

At the same time, Testpad also updated its pricing. This is the first time prices have been changed (yes, raised) since Testpad launched in 2011, so a change has been well overdue for some time. The four existing plans have been replaced with three user-limited plans (for up to 3, 10 and 25 users respectively) along with a new kind of bespoke plan for enterprise customers.

Existing customers who were paying automatically either monthly or annually may continue on their current plans at their current pricing.

If you have any questions, or find problems with the new version, please don't hesitate to contact stef@ontestpad.com.

Performance Tips - keeping Testpad fast from build to build

$
0
0

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.

Performance Tips - keeping Testpad fast from release to release

$
0
0

This is the second post on performance 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.


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.

// 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.

Performance Tips - don't make Scripts too short

$
0
0

This is the third post on performance 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 50+ 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.

Checklists. For bringing home Apollo 13. And software.

$
0
0
Image from Heritage Auctions

“Houston, we have a problem” is what everyone remembers. What happened next was Commander Lovell got out a checklist for Lunar Module Systems Activation, pictured left, and used it to ensure Apollo 13 made it safely home - and if you want to own the very checklist he scribbled his notes on, it’s going up for auction on Nov 30th here.

Everyone knows what a checklist is. The diligent (or forgetful) amongst us probably even have one for what to pack to go on holiday. You just can’t argue with their ability to make sure you’ve remembered everything.

When it comes to shipping software, deploying a website or submitting an app to the App store, you similarly want to ensure you’re remembered to check everything. Now this, of course, is the domain of software testing, and many methodologies abound, all sparring for a medal placing on the podium of Best Practice.

But why make such a meal of it?
Why not just whip up and maintain a checklist?

A checklist is really the same as a “Test Plan”, but it just sounds simpler, somehow more approachable. It’s also inherently adaptable to a light or heavy touch when it comes to the degree of control you want to assert or complexity of the software you’re testing.

Checklists can start really simple. Just list the main features that you want to check are working. Then add more detail as time and resources allow; extend it with bugs you missed last time; fold in more detailed scenarios; or concentrate on areas you know are more risky or problematic.

You can treat checklists as a guide to steer Exploratory Testing (formalized ad-hoc testing), as a charter in Session Based Testing, or as a fully scripted Test Plan. You can even layer on a risk model like Google’s recent Attributes-Components-Capabilities approach. Whatever suits your situation.

It was with this thinking that we built Testpad. If these ideas resonate, you should definitely give Testpad a try! The hope is that it will get more projects doing their testing that bit better, and without succumbing to procrastination for fear of having to choose a complicated-sounding methodology.

As Cmdr Lovell appreciated, apart from having to do some trajectory math 200,000 miles from Earth in a cold, cramped, and oxygen-depleted environment, having a ‘simple’ checklist to follow was a lifesaver.

It’s not rocket science.... usually.

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

$
0
0

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.


Guest Testing - anyone can help when the pressure is on

$
0
0
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.


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

$
0
0

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.

Importing spreadsheets of tests into Testpad

$
0
0

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 login1. 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 login1. 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 login1. 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 login1. 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 login1. 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 login1. 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 login1. 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 login1. 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.

Email addresses don't have to be unique anymore

$
0
0
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.

Release notes for minor update (4.1.110)

$
0
0
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" :)



Viewing all 42 articles
Browse latest View live