If you are a project manager or business analyst, and certainly if you are a software developer or quality analyst, you will need to test lists at some point. I have an approach I use to fully exercise these lists that I refer to as the “0, 1, 2, N” test. Maybe I should call it a “ZOT-N” test?
Before I walk through this approach and why I use it, let’s first talk through how to identify where to use this test. In other words, where do we see lists? For the most part, this is straightforward. Anywhere we see something repeated on a screen we are testing, chances are this is a list. The most common examples are:
- A report-based screen showing multiple lines of data, like:
- A search results page
- A list of products on a category page
- A list of customers
- An order history screen
- A dropdown/multi select input, like:
- A geographic region selector
- A credit card type selector (I’m not sure why this is ever needed, but I still run into them.)
- A set of buttons. For example:
- A product may have options to “add to cart,” “add to wish list,” or “see more details.” If all products have all three buttons, this doesn’t fall under this list testing technique, but if a product is configurable to have the buttons added, it would.
- One the bottom of a search results screen, having a numbered page selector is an example of a list that can change based on how many pages there are.
They key here is that the data being presented is variable. That is to say it can change based on either what the user is looking for, the current state of data, or how data is setup in advance. You will get different search results based on the search term you have entered, different customers in the system will have a different set of order history data, or a set of regions in a selector could change if an administrator has the ability to add or remove regions.
When I encounter a list in a testing scenario, the first consideration is if a zero condition can exist. Here’s how I would approach some of the prior examples:
- Search results page: Certainly this could have zero results if the user searches for something that doesn’t exist.
- A list of products on a category page: Most likely the requirements dictate that an empty category isn’t displayed, but that may not be the case.
- A list of customers: Certainly you would hope to have at least one customer, but it might be worth testing this scenario.
- A region or credit card selector: Probably these would be configured to have at least one selection.
If there is a valid scenario for having no data, even if it is a far-fetched scenario, I’ll test it. Sometimes this gets overlooked by a developer and null pointer exceptions get thrown, or a display is visually broken when no data is present. Sometimes when no data is present, something different happens such as a “no results found” message being displayed.
In almost all scenarios, at least one data element is a valid option in a list, except for maybe a dropdown selector (it’s not much of a selector if only one option is available). Testing one item in a list is important since it is a list where the beginning is also the end. Visually, a list with one element is often different than a list with two or more elements. There may not be some separator or padding needed with just one element that is needed with more than one element.
I have actually had debates with developers whether testing two items is necessary. I caution on the side of testing this scenario. To me, having a list of two items is a list where there is a first item, a last item, but no middle. The developer may have coded a horizontal bar only on middle data conditions.
Finally, you should test “N” items. This will vary based on what it is you are testing. N should be a number that tests something slightly above the real world expected maximum limit, or some extreme that is feasible to setup in a test scenario. With this test, you have a situation where your list has a beginning, middle, and an end. Also, it exercises what happens when some large limit is hit. Does data not fit on the screen? Is the screen unusable or unresponsive?
To make matters more complicated, you could a have a list in a list. Consider a product category page where products are displayed in a grid format, such as three columns by N rows depending on how many products are in the category. I would test this page using the 0, 1, 2, N technique based on the number of products. I would also use this technique for the number or rows on the screen, especially if there are visual requirements for horizontal and vertical bars and spacing. So the 0 row test would be already tested when I test zero products. The 1 row test would be tested when I test both one and two products. I would use four products to test 2 rows, and then my N test would work for both the number of products and the number of rows.
Pagination is also another example of a list in a list. The list of pagination pages is dictated by the list of items.
In almost every case, it is far easier to work from 0 to N. I try to start my testing with clean or no data. I very much consider this a functional or unit type of testing that I only conduct when I initially test a page with lists. I tend not to regression test through the 0, 1, 2, and N scenarios.
Testing lists can up front feel daunting since some screens are so dynamic, but using this technique can speed up the time it takes to test the screen while ensuring proper test coverage.
