Black-box methodologies

- When you envision the core objectives of a quality test, you are envisioning black-box testing. Black-box test is an evaluation of what you can see. The reason we have the name black box is because it's about viewing the software itself without knowing what's going on inside. Think about a product's behavior and how it's supposed to work. This is the focus of black-box testing. Evaluating the interface, data entry, output, and design of the application. What is a software's purpose? When product teams create a software application to solve a particular problem, it's the black-box testing that measures how effectively the product achieved that purpose. It measures whether it meets the design specification on every level. From the smallest input field to the overall objective of the software, black-box testing is measuring the full software from an outward approach. Effective quality tests speak with data from every viewpoint. There is no room for opinion, subjectivity or emotion. The obligation of a quality team is to deliver information to the team about the overall performance of the product. Black-box testing takes this approach by allowing testing to speak with data. Much of the focus of this testing is very binary in that it reports whether it works or doesn't. The problem here is that while the software won't be emotionally traumatized by the issues you discover, your product team might be. Delivery of this data needs to be focused on factual results pulled from your black-box testing techniques. Presenting the data delivers an inarguable report of the flaws of the software. You could show where, when, and how any failures were discovered. And through these test techniques, you are creating repeatable issues. Functional testing aspects of black box are the primary tests employed to assess the performance of a product. You are using techniques to see if each button press elicits the right response, you are checking to see if the fields do what they're supposed to do, and you are measuring that the overall application meets the design specifications. The techniques selected to execute are the tools you choose to help meet these needs. Nonfunctional tests in black-box testing evaluates the software from the external pieces connecting to the application. It's not focused on how the software works, but on how well the software works. Things like reliability, usability, and performance in different environments are all assessed to ensure that the product operates to the requirements of the design in the world where it operates. Every software testing lab does black-box testing. It's what quality labs are designed to do. The focus of every black-box testing is to assess an application on its merits and design. However, which techniques and the strategies implemented by every test team differ significantly because no two applications are the same. However, there are some core techniques that most teams use to ensure that the product works. We don't think about an application or its underlying operation while we use it until something doesn't work. Entering data into fields, clicking buttons, and getting the desired results is all magic until an error appears. The goal of black-box testing is to look at that software from the outside and prevent those errors, sustaining this illusion of magic. The techniques of black-box testing are numerous and diverse. I will cover in our next chapter the most notable approaches to testing and those you'd expect to see in any lab. You'll quickly discover that these rudimentary tests become a lot more complicated at the moment we begin to add data and design a test plan. The techniques are simple solutions to testing, but they increase in intricacy in proportion to a software's complexity. All software serves a purpose and black-box testing helps ensure the software delivers on that purpose. The more complicated the software, the more advanced testing is required. When you begin to spell out your test techniques in your test cases and build out a plan, it's easy for it to grow out of control. The one constraint that limits all of these techniques is time. That's why most techniques are focused on as much testing as possible within a limited timeframe. Time is the true challenge for any test team. If a quality team had unlimited time, we'd inevitably be able to build the most comprehensive and thorough test plan imaginable. It's not reality. In this day and age of Agile and DevOps project management, the emphasis is on speed and delivering the product. Therefore, most techniques are scalable and optimized to accommodate these tight schedules. Anyone watching this course will likely wonder why I cover some testing and ignore others. It's a good question and really techniques aren't about good or bad. I'm not ignoring anything, but rather including tests that any project will need at its core. You'll likely find that what is in here in this course is in the foundation for most of your test cases. However, you will also discover that you'll want to do a whole lot more.