Field Notes in Software Testing

9 min readSep 26, 2022

Being a test engineer (QA) for a decade «I’ve seen things you people wouldn’t believe», I’ve tested enough web applications to accumulate experience that can be shared.

Field Notes in Software Testing: «I’ve seen things you people wouldn’t believe»

I collected tricky test cases which somehow led to bugs and hacks to perform unusual checks. They are sorted by logical blocks in no particular order. Enjoy!

General cases

Divide by zero wherever it is possible;
Plug in a real mouse to notebook — it can affect scrollbars, which may be hiding in the case of touchpad;
Click on disabled buttons (controls) — sometimes they can just look like disabled, but actually be clickable;
Open links and click buttons by double-click;
Repeat the action multiple times, like clicking on the same button 10 times in a row;
Click on all arrows pointing downwards ∨ or upwards ∧ — something must open or close:
Open pop-ups and dropdowns near the edge of the screen — they can be cut off by viewport;
Open long dropdowns and suggests near the bottom of the screen — they can be cut off by the viewport if the developers have not provided a scroll for that element:

Fig. 1. The height of the suggest does not have a maximum value and therefore goes off the screen

If there is a countdown timer on the page, you must check what happens when it stops. For example, I saw NaN and the continuation of the countdown with negative values;
Try a leap day (February 29) in a date input. Rather, a wrong leap day (29.02.2021) is more important. Almost every popular frontend and backend frameworks handle this case, but it is a constant trip for custom ones.

Non-general cases

Use the tested website after an idle (after a few hours or a day of inactivity) — it can affect sessions with expiring cookies or other timers;
Flip the monitor in portrait mode and then open the tested website — it can affect layouts that are not designed for narrow and long resolutions. For example, in this case, the width of a 23-inch monitor will be only 1080 px;
Check the print version of the tested website:

Fig. 2. Printing is an outdated case for most modern websites, but for documentation, long reads, maps, and tickets, it is still valid and valuable

On coordinates

Double check geographic coordinates: the values of latitude and longitude should NOT be mixed up in places — surprisingly, it is quite a common bug because some APIs operate lat/long, but others long/lat (and there is a special place in hell for developers using ll parameter for positioning);
It is recommended that the latitude be indicated in the first place because latitude-measuring techniques were invented earlier than longitude, and latitude coordinates are listed first for positioning in the sea and marine charts;
Latitude and longitude ranges are not the same (again, surprisingly, such bugs occur):
• latitude range is from -90 to 90, and
• longitude range is from -180 to 180.
Latitude and longitude can be 0 — it’s a perfect edge case and Null Island on Earth;
Watch out for coordinates in exponential format, like 4.4816236e+1, 2.0460467e+1 instead of regular numbers;
Carry on the coordinates’ precision. Unlimited precision may cause unnecessary calculations; therefore, slicing or rounding the coordinate value may have advantages. Eight decimals are already nearly 1 mm in accuracy.

On opening URLs

Open URL with / and without / at the end (https://medium.com/ or https://medium.com) — opening the page can depend on the app’s routing or server’s settings;
Open URL with encoded characters (Dvo%C5%99%C3%A1k instead of Dvořák);
Keep in mind that in some cases, space can be transformed into +
If there is pagination in the URL’s path, then open 0 or negative page (-1);
Try to request an HTTPS page by HTTP — it can depend on the server’s redirect rules.

On search inputs (applies to any input fields)

Search for a space;
Search with a space before and after the request;
Search for an empty request — it can affect inputs with blank field validation (read more about client-side form validation);
Search for special characters: ! * ‘ ( ) ; : @ & = + $ , / ? % # [ ] < > .
Search for special characters through mnemonic entities, for example: « » instead of « »
Search for : — it can affect Python’s backends, especially if the search is performed on the clickhouse database;
Search for сyrillic ё or any non-latin letters or hieroglyphs. There was a bug in iPhone with the Telugu character జ్ఞా
Search for text in different encodings;
Search for [object Object]
Search for %, by %%, and by % with combination of special characters;
Search for XSS — actually, it is already a part of security testing;
If there are a few inputs, then put XSS values in several inputs at once;
If a test page has custom hotkeys, then use these keys when filling in the input;
If a tested page has a video, then: [Play] it → [Pause] it → and try to search on a tested page through the browser’s search; do not forget to use [space] — it can affect paused video, because [space] is a common hotkey for pausing;
Input a long unbroken text — it can cause page overflows and other artifacts (very long Wikipedia links usually break layout). For instance: Eximperituserqethhzebibšiptugakkathšulweliarzaxułum
Try to find a limit on the number of characters in the search request — at least there must be some kind of restriction. Otherwise, the users can load our backend with monstrous requests;
How is the filled field cleared?
Remove multi-character emojis: paste family emoji in the input field and then hit the backspace — if the input field can handle multi-character emojis, you will delete family members one by one:

On usernames

Register account with space before and/or after a username: augustdvorak
Register account with lower-case and upper-case letters in a username: AugustDvoraK
Register account with XSS in a username, something like: <img/src=’x’onerror=alert(august)>
Register account with a username in angle brackets: <augustdvorak> — it can affect both frontend and backend. If escaping works too strictly, the whole username can be erased;
Register account with . or — in a username: august.dvorak оr august-dvorak — in some cases . and — can behave as the same symbol.

On mobile version of the websites

Open mobile version of the site on 480x800 px resolution and/or on a 4-inch screen or less;
After opening the page, the insertion caret (that blinking input cursor) should not stand in the input field (of course, if it is not provided by the documentation) — this causes the keyboard to open automatically and may irritate the users;
Try to request a desktop version of the site in a mobile browser:

If the layout of a tested website is based on media queries for responsive design, try to slowly resize the width.

On crossbrowserness

In all projects, I adhered to the principle:

For browsers over 5 % — the layout must match the design mockup;
For browsers between 5–1 % — the layout may be broken, but the functionality should work;
Do not support browsers less than 1 %;

Of course, there may be exceptions for each case. For example, in one project, we turned off an outdated functionality for 0,5 % of users, but it was more than 12 000 daily users!

Further reading about cross browser testing.

On browser behavior

Back to the previous page by [Back] — it can affect SPA websites and websites which use History API;
Switch to another tab by [CMD]+[NUM_KEY] or switch to another application by [ALT]+[TAB];
Search on a tested page through the browser’s search: [CMD]+[F] — it can affect pages with pop-ups, modal windows, dynamic loading scripts and infinite scroll;
Navigate by keyboard [TAB] — actually, it is already a part of accessibility testing;
Hard refresh the browser: [CMD]+[SHIFT]+[R] — the browser will clear the cache on refresh, but the URL’s path should remain unchanged;
Check Safari’s Console in DevTools, because additional CSP errors can occur in this browser;
Make the browser window fullscreen — most likely, nothing will break, but who knows?

On browser settings

Try to use a tested site in a private (incognito) mode;
Try to use a tested site with blocked third-party cookies;
Try to use a tested site with tracking protection:

*Set privacy.trackingprotection.enabled = true at about:config*

Try to use a tested site with HTTPS-only mode;
Change (increase) default font size and/or zoom on the page — it can affect the layout of any kind, but only less than 4 % of the users have such a setting (this number is based on private statistics).

On network settings

Try to use a tested site with network throttling (DevTools setting);
Try to use a tested site under VPN from another country;
Try to use a tested site under VPN from another country with a different time zone.

On arrow controls

If a web application supports control by arrow keys (like driving or docking simulators in a browser), it is very easy to put the software keys into the sticking state. This common issue has a lot of cases of reproduction.

With the arrow keys ⬆️ ⬇️ ⬅️ ➡️ clamped down, try to do:

A lot of frequent/short clicks on the arrow keys;
(For Mac) Press [CMD] and release the pressed arrow keys;
(For Mac) Press [FN];
(For Mac) Open Spotlight by the button on the touch bar;
(For Mac) Move the cursor to the menu bar;
(For Mac/Linux) Press [WIN] key on the extended keyboard;
(For Windows) Press [WIN];
Press [CTRL] or [ALT] or [SHIFT] or a combination of them;
Press [ESC];
Switch to another program by [CMD]+[TAB] (for Mac) / [ALT]+[TAB] (for Windows);
Switch to another program by mouse click;
Switch to another browser tab by mouse click;
Switch to another browser tab by [CTRL]+[TAB] or [TAB]+[{NUM}];
Move the mouse away from the active browser’s tab/window;
Make right-click (Right Mouse Button) and left-click (Left Mouse Button);
Reconnect the network (the loss of internet connection).

On odd utilities

Run a «crawler» or link checker to find broken links on the pages of your website. There are plenty of apps for that, or you can program your own HTML parser.
The best way to check access (connection) to the resource is by using telnet — any sysadmin will appreciate a stack trace from it rather than a report «the site does not work». Unfortunately, telnet does not run out of the box, so you have to install it (for the Mac, it can be done through Homebrew). The command is like: telnet {domain} {port}

You can find out your IP address through the terminal by curl request for ifconfig.me or ipinfo.io: curl ifconfug.me or curl ipinfo.io
If your test environment requires you to use third-party browser extensions to work with (for example, permanent headers modification as a workaround to bypass CORS), it is a potential problem to miss a bug.

How to find out the user-agent through the browser console?

console.log(navigator.userAgent);

console.log(navigator.userAgent); — *User-agent*

How to change user-agent without addons?

This trick works only in Chrome browser:

Open Command menu: [CMD]+[Shift]+[P]
Type «network conditions» and select Show Network conditions;
In the «User agent» section, disable the «Use browser default» checkbox;
Input a desired user-agent:

How to add a cookie through the browser console?

document.cookie = "key=Value";

How to add data to localStorage through the browser console?

localStorage.setItem("foobar_popup", "1");

Further reading about interacting with localStorage from the Console.

How to prevent auto closing (hide on unhover) panels/pop-ups/menus?

It is always inconvenient to write autotests for panels/pop-ups/menus thet show on hover and close on unhover — how to find out the classes of hidden elements?

Open Debugger in Firefox DevTools (Source panel in Chrome DevTools) — there is a [Pause] button;
Open desired panel/pop-up/menu;
Hit the pause’s hotkey: [F8]— JS execution on a page is stopped, none of the elements will hide automatically, and you can inspect them with no rush.

The article will probably be updated in case extraordinary test cases are discovered in the future.