Defining Black Box Testing
According to Techopedia, black box testing is a software testing technique that focuses on the analysis of software functionality, versus internal system mechanisms. Black box testing was developed as a method of analyzing client requirements, specifications and high-level design strategies.
Some of the benefits of black box testing include simple facilitation, conservation of resources, flexibility, and faster testing/bug identification.
Modern and Legacy/Vendor
Most modern software solutions implement unit tests as part of their development and build practice. It is common practice to replicate repetitive tests that perform the basic functions and behavioral tests of your software but what if you have a legacy system or a vendor package that doesn’t allow you to go deep into the product and perform unit tests on individual components? This is where black box testing becomes useful and effective.
In order to understand and use black box testing, you need to create a full system test environment where the configuration is as close as possible (or a copy) to the target system (production). You must make sure that all the components are set to run as closely as they would when run in real time production system. If any of the components contain differences, there is no guarantee they will work in production. Take for example a default value for a new object state. We know new orders should always have a new state when created. If this is a configuration option it must match production so that when you test a new order creation you should get the same default behavior as in production.
Each test or test scenario must have a basic set of data to perform with; the data should replicate specific scenarios or data state. For example, if you are testing the changing user password feature, you should know the old password and test the application. You should ensure that the application only allows you to change the password when you give the correct old password for validation. Setting the correct data is critical especially when testing a complex test scenario consisting of many objects such as testing order creation with multiple items and providing a final order sum. in this case you need to have all the items you plan to Lastly, you need to be able to create the same test data every time you run the test. It must remain consistent. If the data has changed since the last test was completed it will fail because the data will not match anymore. The process of cleaning up and reloading test data is critical.
So far, we have addressed the pre-conditions for black box testing. Test automation is the “meat and bones” of the process because it defines the actual test performance. The black box must have an API that can be triggered remotely by the testing harness. It also must allow the agent to load records, input new data, trigger functions and retrieve results (so it can monitor the results). The most common way to do this is by using the system API like SOAP or REST, or use older style HTTP requests. If the system black box does not provide any API there are ways to use the user UI but it is more complex and harder to automate. Another way of monitoring the results is to at the database state after a test, this is a less common practice but can be done in the cases above when an API is not provided.
When building an enterprise solution the most important stage is testing. The more complex the solution, the more important it is to automate the tests and make sure new releases or changes are not breaking any existing functionalities or behavior. Automating these tests is one of the key practices you can adopt and having a black box solution should not keep you from taking the steps and making the effort to thoroughly test your solution.