How To Test Pagination In Web Applications

Pagination in web applications is one of those things that requires a lot of test cases. Although, all of these test cases seem basic it is easy to overlook something. The number of test cases is indefinite as testing is not exhaustive. I find that this testing principle is most visible in simple functionalities we are all familiar with. This is my answer to how to test pagination in web applications.

First tests

I always start with the easiest test to perform. This is context dependent. Sometimes it can be a negative test case and on other occasions it can be “happy path”. However, in this situation the easiest is to visually inspect if the pagination matches the design. Some pagination components have just next page and previous page buttons, while others have more buttons like specific pages. Some pages contain also input fields as a go-to-page options. A part of the pagination component can also be selection of items to show on the page. Don’t forget that pagination is also followed by a label along the lines “Showing xx items of xxxx”. Identifying if the design matches the expectations is the first test.

Functionality

When it comes to functionality of the pagination, I think there is very little open for interpretation. There could be something unclear, but not much. Clicking on next page should load the next page of items. The same way, clicking previous should load the previous page of items. Naturally, if there is no next or previous these buttons should be disabled. Clicking specific page number takes the user to the specific page. Now, the label should change accordingly. For example, on Amazon pages there are 24 items loaded per page. If I click on page 3 I expect the label to display “49-72 of over 100,000 results”. Changing pages should update the label with the correct numbers.

If there is an option to change the number of items per page, then the label should again change accordingly. The total number of pages should also change. If there are buttons for last page and first page, they should do exactly as their name says – take the user to the last or first page.

Now, with the input fields is a bit more interesting. There should be a validation that should ensure that only valid page numbers were entered. You should not be allowed to enter letters, special characters, large numbers, negative numbers, etc.

Special cases

You should pay specific attention to cases where you can mark some of the items on the page. For example, some pages offer comparison of specifications for items. In this case, you can select item from page 1 and item from page 3. To test this successfully, the item selection must remain when you change pages. The same applies in case of table paging, where you can select multiple rows from different pages of the table.

Another special case is behavior of the paging after sorting or filtering. All of the test cases from previous section should be performed after filtering and sorting. The behavior of the system must be consistent in all of the scenarios.

Here is one other thing you can try to break the paging. If you see a page number in the URL, try changing it and see what would happen. Change it to a non-numeric value, leave it empty, send null value or really high number. All of these have to be handled somehow, either by redirect or some meaningful error message. The application must not crash.

Speed

Paging is one of those things that should be strategically planned. The team needs to plan how many items the page will show to make it an optimal experience for the user. Too few items and the user will have to click through pages more often, too many means performance slowdown. To understand better the impact on performance we need performance tests with various number of items. Sometimes, these tests will show a performance bottleneck on the 10th page because the database is clogged with requests or maybe memory is leaking. Perhaps, the pictures for the items are too large in size and you need to optimize them. One way of finding out is performance test using Lighthouse. Another way is to check server side performance with some of the performance tools when you load the application with large number of users.

Conclusion

The pagination seems like part of the website we are all familiar with, yet it can become increasingly difficult to test. This is a consequence of a cognitive bias we all have about the familiar things. Simply, we don’t challenge ourselves to think about things we consider to be known. This bias is a cause of many testing failures. Because of it I decided to document all these testing cases and show how to test pagination. This can easily be an interview question. It is simple enough for anyone to understand it, yet complex enough to check someone’s thinking process.