Testing for non-testers: Five letters than will change your life
By Carly Street
People often hear about “testing” but might be unaware of what “testing” actually involves, and what testers actually do. Testers (in our case, Test Analysts) analyse and compare the work done by the developers to the requirements signed off by the client, and report their findings so stakeholders can make informed decisions. If testers find issues they log them for fixing, and when they’re fixed, they test the work again to make everything's as it should be. Our Test team is a vital part of our agency, helping everyone work together to assure quality throughout all of our web projects.
“What are your top three pieces of advice about testing?”
I’ve been asked this question enough times that it warrants writing it down and sharing with people. I know if I had this advice when I started as a tester in 2012, I would have been jumping for joy - and I hope non-testers will find the information useful in different ways too. In this series, I share my top three pieces of advice about testing, in three bite-sized posts. First up is N.N.E.B.S.
This acronym isn’t very nice to look at, but the order of the letters can be as important as the words they stand for; Normal, Negative, Error, Boundary and Special. These words form the basis of nearly every piece of testing I do. They cover most tests that need conducting for every feature, and what isn’t covered here is either covered by very specific tests, or exploratory testing.
- Normal is how the feature is expected to look and function, and is sometimes known as the “happy path”.
Example – The user attempts to create a new account with valid credentials, and the account is created successfully.
- Negative is how the feature reacts when it doesn’t have some of the information, or content that may or may not be required.
Example – There is a non-mandatory image field, and it shows the fallback image when the user doesn’t choose a file to display.
- Erroneous is the expected outcome of what the feature should not do.
Example – The user attempts to create a new account with invalid credentials, thus validation error messages show, and the account is not created.
- Boundary is where the feature is pushed to its limits, both minimum and maximum. This is normally done via character limits, or file sizes and isn’t applicable to every feature.
Example – The user attempts to create an account with the minimum/maximum characters for the password, and is successful.
Example – The user attempts to create an account with the minimum minus one or maximum plus one characters for the password, and is unsuccessful.
- Special is how the feature reacts to an unexpected interaction. These situations are less likely to happen, but still need to be taken into consideration.
Example – The user attempts to create an account with an emoji in the username, and is unsuccessful.
Example – The user attempts to create a password using wingdings, and is unsuccessful.
Example – The user uploads a .gif file to an image field, and the gif shows on the feature and displays nicely.
This method can be used to test features, develop features, and define features. It should be in everyone’s arsenal, not just testers, and helps everyone ensure each feature is developed with quality in mind.
N.N.E.B.S. is just one approach our Test team takes to ensure quality. Next up in the series will be a piece on behavioural-driven development and how we use it to structure work and ensure everyone understands the requirements. Be sure to check back if this sounds of interest.