Join Aaron Dolberg for an in-depth discussion in this video Black-box testing: More than just clicking buttons, part of Programming Foundations: Software Quality Assurance.
- Black-box testing is one of the most commonly used terms when discussing quality assurance. The basic principle in this method of testing focuses on functionality without looking at the internals. It's the process of looking at your product from the user interface and interacting with it as the user would. This type of testing, by definition, doesn't have any specific concern about anything that's happening at a lower level. The term comes from the concept that if you had a completely sealed black box, you wouldn't be able to see what's inside it.
So you're only working with the exterior that's available to you, for anything that you plan to test. One common misconception is that black-box testers are only given manual tasks, where buttons are clicked to make sure that they produce a specific result. In reality, the term doesn't imply that the role is purely manual in nature. A black-box tester can absolutely possess technical skills and perform automation tasks that require scripting knowledge. The term is used to indicate each test case we'll be looking at the product from the outside.
Regardless of that these specific responsibilities are, a good black-box tester will have an understanding of how all of the pieces of your application fit together. They need to be clear on the expected output for every input. What they don't need is knowledge at the source code level. With this style of testing, there isn't a requirement that the tester has any knowledge of the internal structure of your application, only that they understand what it's supposed to do and who it's for. This is another critical element that is often overlooked.
Your black-box testers should be staunch advocates for the user. These testers often spend the most time with your application before it's released and will typically have a keen instinct for what makes sense and what doesn't from a usability perspective. Keep in mind that some things sound better on paper than in reality. This is why I previously illustrated the relationship between black-box testing and product management. In black-box testing, you should be on the lookout for more than just functional defects.
You should also be looking for critical usability issues. Your black-box testers should be seen as internal users who can give you objective feedback with an understanding of what you're trying to accomplish. Think about a basic TV remote control. If you were testing this from a black-box perspective, you would be thinking about what each button does and validating that functionality. You would also be thinking about the overall design of the remote and the placement of each button. If you were given a remote control to test that was much wider than it is long, you might immediately notice that while the design is distinct, it's not going to be very pleasant to hold onto and use.
If you were given a remote that looked like this, it might feel okay when held, and each button might function such that it produces the desired result, but the experience for the user is going to be less than optimal. You may be thinking that this is really a decision that belongs with your product manager or designer, but this is precisely why I showed that there's overlap. You want black-box testers that are thinking critically about this alongside with the other stakeholders. If you're aware of the benefits of this overlap, you'll structure your team such that whoever is responsible for black-box testing can have an intelligent conversation about the business goals and the product as it's being delivered.
Keep in mind that it should be everyone's goal to deliver a quality product. But it's all too common to ignore the voice of those who you task with assuring quality. Black-box testing should be seen as much more than clicking buttons. It's a function where it's critical to understand what quality means from a user perspective, and then work with a team to assure that those quality goals are met.
- 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