In the mind of a tester

A couple of weeks ago I’ve tortured one of our testers with lots of questions. The goal was to understand how he thinks: besides learning some tricks, knowing how people work makes me a better team player. Also, I believe developers should be respectful of whomever comes after them. Besides final users that includes quality assurance and other roles down the line. In other words, having the safety net of a QA is not a valid reason to be sloppy. Not to count the fact that technical debt or issues found by testers will create a ton of problems most of the times.

What follows is some of the wisdom I’ve gathered from the conversation. I hope other people will find it useful and get inspired to talk more with their colleagues.


There are two types of testing: exploratory or structured. The first one, as the name suggests, is employed whenever it’s not clear what the application is supposed to do and exploration is the only way through. In other words, testing is done in a breadth first fashion. The second one, comes useful whenever the application is better known or documentation is available. In fact, in this case, it’s possible to devise a testing strategy beforehand instead of just exploring. In other words, testing is done in a depth first fashion.
Of course, testing is not black and whites, therefore testers apply the appropriate strategy for the situation at hand. Sometimes, this means using a mix of the two techniques mentioned.

Before testing, the author of the code can be interviewed to get to know what are the scenarios at hand. This should be done avoiding too many details to elude bias. The investigation can be extended by checking how other people are solving the same problems. For example in case of payments, Amazon and Ebay can provide a lot of insight. On top of that, it can be useful to check how a specific technology works. The format of a credit card number or the length of the CVV are good examples.

Testing should take into account UX, therefore it should be done with the customer in mind. For instance, a payment page should feel trustworthy.

Taking notes is important to keep tracks: pen and paper are a great tool. Also, screenshots can be useful, for example before submitting a form to be able to backtrack in case it’s needed. In case of a complicated bug, a screencast can be recorded to avoid incomprehensible explanations.

Whenever testing form inputs, autofill should be avoided because it encourages laziness and issues could be missed. Some cases to test inputs with could be: empty, valid, too long, symbols or special characters.

Testing too much is a waste of resources. For example optional form fields can be checked less or combined with mandatory ones. Also, edge cases are not worth being tested most of the times. As a matter of fact, a bug that never occurs is harmless. In some situations it’s even better to skip testing and take action later on in case a user encounters a bug.

In case of a web application, use incognito mode to avoid extensions, cookies or other variables to influence testing. Furthermore, cross browser testing is better done at the end of the project. As a matter of fact, this type of testing is time consuming. That’s why it should only be concerned with issues generated by the use of different browsers (e.g. styling) and nothing else. In fact, the backend shouldn’t be affected much by this.


This post has been written as part of my 6-week experiment on blogging. In other words, I’ll publish one post a week trying to timebox as much as possible the time needed to write. Therefore, please let me know what I’ve fucked up completely and what else I’ve just fucked up slightly. I’d be grateful.