Testing plays a critical role in helping developers improve the overall quality of software products. It helps you locate and fix defects before they make their way into production. Thorough software testing enhances code quality and encourages engineers to adhere to...
When I enter search criteria or load a page with a large number of comments, one of the ways to display those results is through pagination. Some applications allow the user to scroll down and continually load entries on the same page. By contrast, pagination returns a set list of entries on a given page, with a series of pages to view to find particular items. How can we automate tests for this function?
Testing a pagination function requires that any test dataset returns enough entries to span more than a single page. Even with this, there are some questions we should ask:
- Is there a way to size the number of items to display for each page? Can I list items in a specific order (such as by name, date created, date modified, etc.)?
- If I delete items, can I change the number of pages displayed?
- If I have a set number of entries, can I use an API to define the specific items I want to see?
The method of pagination can vary. Here is a typical example:
| 1 | 2 | 3 | 4 | 5 | <Last
This is a common display that would be shown on the first page. Each value between the pipe (“|”) characters is a unique link to a specific page, usually a span of results for a search associated with each value. On some pages, this can be styled using CSS to display as literal tabs or other graphical representations. Regardless of how the links are displayed, once I have clicked on a numeric link, I am likely to see an expanded listing, such as the one shown below:
First> | Next>> | 6 | 7 | 8 | 9 | 10 | <<Prev | <Last
In this example, we have additional navigation items. “Prev” will likely not display on the first page, and “Next” might not display on the last page. Still, all the links are based on the potential values that are returned and how many values can be listed on each page.
Common Automation Tricks
Pagination will typically be controlled by two parameters. The first parameter is how many items I am able to list in total. The second is how many items I can list on a page. If I have an option to choose the number of listings to appear on a page, I expect to see numbers and navigation items which reflect that.
For example, assume that I enter search criteria that should return 100 items, based on a known data set. By default, each page that is displayed will return 10 results. This means I should see 10 total page listings. If I can adjust the total number of entries to display to 25 per page, then I would expect to see four total page listings. To make these tests easier to track, I can prepend the listing with a numerical value (one to 100) so that I can easily tell which numbers should appear on which page listing.
Of course, this numerical listing requires that the pages be listed in alphabetical order. If the goal is to look at pages in ascending or descending chronological order, the elements and values will need to reflect that. There are several questions I might want to ask as I determine whether f I’m displaying a correct listing:
- Do the values I expect appear in the right place if I reverse a sort order?
- Do I have a way of controlling in the URL what values I would expect to see for a particular page? If so, would I see a full listing of pages to navigate, or would I only see the one page related to that listing?
- Is there a correct number of items on the last page if there are not enough to completely fill that page? For example, if I have 99 entries, will I only see nine entries on the last page?
- When I click First, Last, Next and Prev, will I be taken to the appropriate page and shown the listings that I expect to see?
- If I create a sequence of clicks for Prev and Next (say, three clicks), can I confirm I’ve moved to the appropriate listing?
Things That Are Hard to Automate
The larger the dataset and the greater variety of ways to sort the data, the more challenging it is to confirm I’m getting the specific data I want to appear on a given page. It also may not make sense to test very large data sets.
In this case, I may instead opt for a variety of tests to look at the beginning, the end, and a few random areas to determine whether I can see the correct number of entries. Additionally, instead of trying to navigate to each page and validate the items I expect to see, I could use an API and format the URI to include the range I want to see (between two dates and times, a particular range of letters, etc.).
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 since I am likely to use them frequently.
Known Data Set
To have consistent test runs, it’s important to begin with a known data set that yields a predetermined number of results. Adding entries also needs to be taken into account to confirm that I am returning the correct number of values. Having the ability to create and destroy new entries to confirm counts is important.
User roles and permissions may have an impact on the number of results returned. My test should demonstrate that a given role can only display results appropriate to that role. Additionally, if I am doing a search or displaying items that should display zero entries, that also needs to be taken into account.
Depending on the formatting options used for navigating between individual pages, there may be a marked difference in the way the pages look on different browsers. Confirm that the elements used for verification of items on a specific page work in different browsers and that the expected results are consistent. If they are not, you may need to make conditional tests, depending on which browser you are checking.
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.
6 Strategies To Manage Your Agile Testing Life Cycle
Discover six strategies for managing your agile testing life cycle, including CI/CD, test automation, TDD, collaboration, flexible planning, and metrics
What Is Regression Testing? | Comprehensive Guide
Dive into the world of regression testing and explore techniques, best practices, and the role of test automation tools in the process.
Simplifying Your Testing Process With Codeless Automation
Codeless tools have seeped in through all the pores of digital product development; Wix and Squarespace have introduced significant changes to the way non-dev or even non-tech users can get involved in digital product development cycles.