There are many different kinds of software testing, but functional testing is probably the most important. Functional testing answers the all-important question and details of “what does it do?” Sound complicated? You bet it is, but there are categories inside that broken down into easier to understand pieces.
Whether you have a tiny web service, an application, a website, a smart device or a whole computer system, a big part of it is entering information and seeing what happens. Maybe you get information back, maybe you are propelled deeper into a user session, or maybe you log out. You want to cover all of the different things (or categories of things) that might happen to make sure that what’s expected occurs. This may involve typing in a number or code, making a move in a game, adding something to your shopping cart, or adding to your social media. Whatever is supposed to happen, there is a clear expectation with specific details.
Likewise, there is a safety rail up that should keep you from being able to do certain things, and error handling is part of the game of functionality testing. Your flight should not get in before it leaves. You can’t by tickets for seats that have already been purchased. Your birthdate can only go back so far, and should not be in the future.You can’t enter a negative quantity in your shopping cart. Required fields need to be filled out.Calendar dates must be dates that really exist. Passwords usually must have certain types of character types and minimum lengths. You can’t upload a filename that points to nowhere or a directory name or (often) to a full pathname that exceeds 512 characters. You can’t save to a filename with wildcard characters. Focusing on values that are at the edge of acceptability is called boundary testing.
Then there’s the edge cases, which I like to call the weirdo things. If you are supposed to get a reminder a year later, what happens if use the application on February 29th? If person A wants a seat but hasn’t purchased it yet, what happens if person B tries to get it, and will person B get their chance once person A releases it? What happens if you enter a really long value if you’re asked for something that’s typically much shorter? What happens if you enter Unicode characters instead of ASCII, or letters where a number is requested? What happens when certain special characters or reserved words are part of input text in a form that gets used in a SQL query?
Hearing all of this might make you ask, “Well, then what ISN’T part of functional testing?” Non-functional testing consists of things like performance testing (how fast is it, what happens when usage is heavy) and security testing. Those are important too but historically, unless the speed is exceptionally slow, functional testing has been the main concentration of defect hunting for software builds.