Software Testing is not about - just - finding bugs. Certainly it is important to catch them. But, at the end of the day, the most important aspect is to have a useful software for your end-user. Business is about having customers consuming your product, right?
So, always keep in mind that when you are testing (or building) software, some functionally can look obvious to you or to how you use it, but not to the end-user.
What is black box?
It is a system that produces results without the user being able to see or understand how it works. - Cambridge Dictionary
In a testing perspective, it serves us to check how an app works from a non-technical end-user point of view, so basically, how a user is actually USING it or how it was SUPPOSED to be used.
The tester checks the software functionalities without any concerns of internal details or implementation strategies. They simply provide the input (by initiating different user actions) and observe the output (response time, usability, reliability) generated by the system.
That's why it's important for the tester to know the end-user, maybe have a talk with them. A solid knowledge about the end-user is key.
The tester doesn't need to be part of the development team if he knows what are the system specifications and requirements of the app to work.
This test can cover a lot of aspects but the primary intention is to check the
outputs without considering what's happening after the inputs.
I highly recommend someone that at least knows what is going on with the product or have a certain experience using it, just knowing the specifications may be harmful in some situations when the system is an ERP, for example, and even the customer uses just a few functionalities inside it in a day-to-day basis.
From my perspective, not knowing anything and going completely isn't ideal, since perceived errors are prone to happen when actually it wasn't an error after all, "Hey I am not sure if clicking here was supposed to open this window instead of that one".
When to use it?
A black-box test incorporates different forms, The most common ones are testing its functionalities, how is the user interface in a variety of platforms, with user-eyes and focusing on its usefulness... so, functional, UI, usability and ad-hoc tests, technically speaking.
They help building a complete coverage and eliminating possible risks on the app, checking boundaries and simulating real-world scenarios.
Techniques
Black-box testing employs some techniques to have a great test coverage. Mentioning a few:
Equivalence partitioning
Input is categorized into partitions of valid and invalid values.
Example: When checking if a user is older than 18, it is enough to test using a birth date that's under that, and another older, covering both scenarios.
Boundary value analysis
Check the boundaries of input ranges.
Example: When selecting a product, the quantity should be between 1 and 100. So the test cases should revolve around values inside the range and outside it, such as negative values or greater/equal than 100, and of course valid inputs inside the range.
Decision table testing
A technique that captures various input data combinations and their corresponding behaviors in a tabular format.
Let's consider authorization of user when entering e-mail and password.
Correct e-mail | Correct password | Message |
---|---|---|
Yes | Yes | Success |
Yes | No | Incorrect password |
No | Yes | Incorrect e-mail |
No | No | Incorrect credentials |
This is a conditions table, which helps covering all the possible cases.
Some others include: State transition testing, exploratory testing and guessing.
Conclusion
This pretty much covers the essential parts of a black-box testing and its implementation. Please feel free to add any comments and correct me if necessary.
Top comments (0)