How Would You Automate This: Page

When an application allows content creation, such as wikis and documents, page capabilities — using the format of create, read, update and delete — are essential to the usability of that application. However, they are also the most volatile of interactions. How can we automate this?

Depending on the application, the interface to create content may be as simple as a text box with no additional formatting mechanisms beyond a submit button. On the other end, a full editor with numerous formatting capabilities may be available. Moreover, there may be options to include content that rely on external interactions or services to be available.

Before trying to automate any of these situations, map out as many of these areas as possible and consider their interactions. I would ask the following questions:

• How many ways are there to create new pages?
• What methods exist to duplicate pages?
• Can I rename the page?
• Can I move the page to another location?
• Can I determine who can see, edit or duplicate pages?
• How much control over the editing process do I have? Are there toolbar options included with the editor? To that end, are there ways to test these interactions without physically using the toolbar?
• Is there an alternative mode of editing the document?
• Does my page permit users to insert or import media?

Once I have an idea of what features are available, I can make a determination as to which areas are most important to my users and prioritize which ones I want to automate first.

There are still other aspects of pages that I need to consider, such as tagging and searching. I encourage you to look at my previous blogs on automating tests for searches and tags.

Additionally, there are steps that I consider a foundation for any series of tests, such as creating a prologue and epilogue using a known good data set and organizing those pages into “families of information” so that they can be compared and referenced in tests.

Common Automation Tricks

Depending on the application, there may be many ways to create a page. Let’s consider a simple page creator widget that can be accessed by filling in a title, an overview and initial content in simple text boxes. Entering this information and clicking the Save button will create a page.

To keep track of the pages being created, it’s a good idea to append a value to the title. I use ${starttime} so that any pages I create have a similar value that I can reference for later updating and deletion of pages.

Using this simple example, I will want to not just look at ways to successfully create a page, but also ways in which a page creation might fail. For example:

• What happens if I create two pages with the same title?
• What happens if start a page creation process, change my permissions midway, and then try to complete the page creation?

Another challenge is required fields. In contrast to a profile page, which may have many required fields, a page creator or editor may have far fewer required fields. Still, for each required field, make sure that an error message is displayed or there is some other way of alerting the user that they cannot proceed until that section is filled in. The more required fields I have, the more tests I have to create to deal with them.

Once a page has been created, the simple page creator widget model will not be applicable to viewing, editing or deleting the pages I create. To that end, I will need to have variables that I track to ensure that the pages I create appear in the expected locations, that I can open those pages for viewing, that I can further edit the pages and review my changes, and that I can delete the pages.

Here are some good questions to ask at this point:

• Can I define a predictable location for the files I create?
• Can I confirm that the page has a recognizable title as well as recognizable content?
• Is there a difference between the way a document is viewed versus the way a document is edited? Can I just view a page as is, without opening the editor?
• If I do open the page within an editor, what do I need to do to place focus on the area to edit the contents?
• What do I have to do to save the page?
• What do I have to do to exit that page?
• How do I delete the page I have created? How do I verify that the page has indeed been deleted?

Things That Are Hard to Automate

When it comes to creating pages, the more options that are available in the toolbar, the more challenging it is to exercise all of them. Without going into an exhaustive list, a standard text editor application will likely contain icons that represent:

• the ability to cut, copy and paste
• the ability to search and perform a spell check
• the ability to upload content
• the ability to insert or import media
• the ability to format the text in the document, ranging from simple actions (such as making text bold, italic or underlined) to more advanced formatting features (allowing for a variety of markup features to handle heading, indentation, ordering, color coding, etc.)

For each of these steps, I will have to move focus from the text space to the toolbar, perform the action, and then move back to the text area to confirm that the text has been modified correctly. One way to do this is to switch to a different editing mode — if the option is available. By switching from a rich text editor to an HTML or markdown editor, I can search for text strings that use the formatting tags I would expect to see.

Common Themes

In this series, there are going to be some familiar patterns and areas that need to be considered for effective testing. Several of these are areas that could be combined into modules, considering I will likely use them frequently.

Known Data Set

It is helpful to start with a collection of existing pages to compare and contrast with. By creating a set of pages, I can create variables that will allow me to access pages by title predictably as well as to examine existing formatting inside pages. Additionally, by creating pages with an assortment of formatting and content options, I can use them as a way to review and compare newly created pages against pages that already exist, as well as to ensure that previously created content can be displayed and accessed within an updated editor.

Permissions

In addition to being able to create, modify or delete pages, I also need to see that I have the rights to do that and to confirm that I cannot create, view, modify or delete pages when I don’t have the appropriate permissions.

Testing for Previously Created Content Interactions

This goes along with the known data set theme, but specifically, make sure that options to view previously created content will still work with updated builds and releases. For example, you will want to test to ensure that:

• Code segments, if allowed to run, are able to run and display the expected output
• Media files, if present, can be accessed and played
• Formatting is consistent and a page created with the original known data set and a newly created page match
• Different language options (localization) are maintained—for this test, vary the use of characters with diacritical marks used in Roman alphabets, and create sections that use different alphabets (Kanji, Hangeul, Cyrillic, etc.)

Cross-Browser Tests

Older versions of Internet Explorer have proven to be a challenge when it comes to displaying media files or the way pages are formatted. I take this into consideration both with the way I design tests as well as the ways I run tests. It’s possible that there will be known incompatibilities with certain browsers. In some cases, creating tests that use different files for different browsers makes sense. Having flow control options depending on the browser agent being used will help with keeping the total number of tests I need to run to a manageable number.

Download your risk-free, full-featured version of Ranorex Studio now to experience the power of test automation.

Michael Larsen has, for the better part of his 20+ year career, found himself in the role of being the “Army of One” or “The Lone Tester” more times than not. He has worked for with a broad array of technologies and industries including virtual machine software, capacitance touch devices, video game development and distributed database and web applications. Michael currently works with Socialtext in Palo Alto, CA.