Join Aaron Dolberg for an in-depth discussion in this video Identifying possible user scenarios, part of Programming Foundations: Software Quality Assurance.
- Thinking about discreet test cases is a great start when you're breaking down a product into the individual building blocks that make it up. It's important to make sure that everything is working properly as you put them together. However, you need to be thinking about the product from a higher level at all times, especially when you're focused on front-end black-box testing. You need to make sure that you have a sharp focus on your intended users and everything that they may do with what you're building. This should go beyond the obvious and cover every aspect of your product.
If you keep this in mind when you start to develop your test plans, it will go a long way to make sure that you have all of your bases covered. Let's say that you were planning to test a text editor. It's easy to think about some of the core functionality that you would need to test and what you might include in your plan. You would need to make sure that users could actually enter text. You'd need to be thinking about work flows that included cut, copy and paste. They'd probably need to save files and then be able to open them again. You would likely allow them to change font or the size of their text.
Depending on how complex your editor was, there are likely a variety of formatting options that you would support, such as the ability to make your text bold or italic. These are the most basic of the things that users would expect to function properly. I also want you to keep in mind that this list would likely be much longer for an actual product. But what I want you to be thinking about is the exercise of identifying each feature that you intend to test before you start testing. When you think about how to test, you should be thinking about acting as the user, and approaching the product through their eyes.
When you spend all of your time focused on discreet test cases that look at just one isolated piece of functionality, it's easy to miss bugs, or even critical usability issues when you put them all together. This is why you want to dedicate some of your time to actually using the product as a testing exercise. That's often referred to as scenario, or ad hoc testing. Now one pitfall that people can be vulnerable to, is only thinking about the way they would approach a product on a daily basis.
To test effectively, you shouldn't just be thinking about yourself as a user, but every user you expect to benefit from your application and every way they may make use of it. You also need to take into account some things that are easy to overlook when you're accustomed to a daily routine of just grabbing a new build and jumping right into the areas that you're most familiar with. Let's think a little bit about the areas that don't jump out as quickly when you think about a basic text editor. Your users are going to need to get your application onto their local system or device, so you want to be thinking about install scenarios and every option that will be available to them at install time.
You're also going to need to look at some basic uninstall scenarios. Since people may want to remove it without any negative effects to their machine, where core system components were accidentally removed. You also may be targeting a user base with disabilities, or going after contracts that require software that's accessible, meaning that you're planning on implementing alternative ways to access parts of the application other than the standard keyboard, mouse or monitor. It's more than likely you'll be targeting users in different countries and you may have test cases that are unique to your application that's translated into a specific locale.
There may be conditions that only occur in environments outside of your workplace. Don't forget that frequently our companies provide us with powerful tools to get our jobs done, that the equipment provided by your company may be significantly better than what the majority of your users will have. So you want to be doing some testing on more average systems, or perhaps in situations where your network bandwidth isn't as good. When you think about scenario testing and using a product through your customers' eyes, you want to make sure that you understand who these customers are, and everything that can influence their experience, so that your testing is as comprehensive as 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