Join Aaron Dolberg for an in-depth discussion in this video Testing core functionality, part of Programming Foundations: Software Quality Assurance.
- When you approach an application to test, you want to be thinking about simple, and discreet test cases that will validate functionality and look for conditions where the application might exhibit a bug. You don't want to be thinking about overly convoluted steps, but rather you want to be keeping it as simple as possible. A good test case should be directly transferable to a clear bug record, if you find an issue. Once fixed, you should be able to use the specific steps for creating an automated regression test.
Imagine you have a simple login screen. Here the expectation is that the user will enter their username and password. When they click the login button, the information will be sent to a server where it will be validated. If the credentials the user enters is valid, the application will advance to its next page. If not, the user will receive feedback as to what's incorrect. This is something that most of us see everyday. So, it's easy to take for granted how many different combinations there might be when you're thinking about discreet test cases.
On the surface there's the obvious. If I enter valid login credentials, this should work. It's also easy to think that if I enter an invalid username and an invalid password, it won't work. However if we're trying to break down our cases into all possible combinations necessary to fully test this login screen, we need to be systematic and we need to detail each of them. When you think about this, you need to keep in mind that it's the combination of a valid username and password that will allow the user to advance.
Everything else should fail, and we need to make sure that that statement is true. I'll need to test the case where my username is valid, but my password is incorrect. Likewise I'll need to make sure that if I have an invalid username, but some valid password, it fails as well. There's also the possibility that a user doesn't enter anything into a field. So I'll need to look at cases where nothing is entered in both fields, as well as cases where only one of the fields is blank.
In just a few minutes, I've identified seven discreet test cases that should be run to validate this functionality. Valid log in credentials result in a successful log in. Invalid user names and invalid passwords result in an unsuccessful attempt to log in. An invalid password with a valid user name should also fail. And likewise, an invalid user name and a valid password won't allow us to advance.
We also covered cases where user neglects to enter in any user name or the user neglects to enter in any password. Finally the user attempts to log in without entering anything at all. Remember, when testing, you want to be thorough and that requires the ability to break down a piece of functionality, such that you identify all possible combination of inputs that produce a result. You also want to keep in mind that when you report a bug, you want to be looking for the most basic and accurate description of an issue.
In keeping your test cases simple and discreet, is going to help you with this tremendously. You want to ensure that your developers can quickly reproduce any issue you report and address it. This starts with your approach to defining the test cases that you create and then execute. Even if you're able to reproduce a bug with more complicated steps, you want to be thinking about things in the most basic way possible.
- How to think about quality
- Incorporating black box, white box, and grey box testing into your process
- Understanding your quality goals
- Ranking issues by priority and severity
- Testing core functionality
- Testing the backend
- Using a test case management system
- Interpreting bug models
- Recording defects automatically