What is Black-Box testing?
Black-box testing is a testing method that involves testing the functionalities of the system without knowing its internal structures like code, architecture, etc. It is solely focused on the given inputs and the expected outputs.
Black-Box testing is acquired from previously agreed software requirements and documentation. The website, desktop application, android application, or the database itself can be candidates for black-box testing.
Types of black-box testing includes:
- Functional Testing – Functional part of the SUT- System Under Test is covered based on the requirements not knowing the internal workings
- Non-functional Testing – Covering the non-functional aspect of the SUT, including performance, visual testing, security testing, accessibility testing, etc
- Regression Testing – Performed every time after newly released features to confirm that those changes would not affect the existing ones
Ways to perform Black-Box testing
Since black-box testing only cares about the inputs and outputs, there is a process that needs to be followed in order to perform black-box testing for the system under test:
- Requirements are being reviewed and analyzed
- Acceptance criteria for all functionalities extracted
- Test cases created with predefined inputs and outputs for every case
- Separate positive and negative scenarios
- Tests executed and potential defects solved and retested
Black-Box testing techniques
One of the main black-box techniques used are:
A widely used technique to test a specific scenario. Very useful when we have many inputs for a test but we do not need to cover all of them. Only a few of them will do the trick. Let’s explain it better with an example:
There is an input field that should accept numbers from 1 to 100. Anything below 1 or above 100 is invalid. You need to create all of the test cases (positive and negative ones) to cover all of the scenarios. In order to avoid testing all numbers below 1, between 1 – 100 and above 100 we can do this:
All positive cases would be from 1 to 100 and we are putting them in a valid partition. Everything below 1 is an invalid value no matter if it is 0 or a negative digit and that is an invalid partition. Everything above 100 is also an invalid partition and every 4 digit number is also an invalid partition. The main thing here is that if we pick one number from a partition to do the testing, the other values from the same partition should have the same output.
So when you set it all up you’ll have 4 test cases to cover. Let’s say -1, 22, 159, 1020. We are covering all partitions with only 4 cases.
Using the boundary value technique allows you to test the boundaries for every partition. Since it is closely related to the equivalence partitioning technique, let’s take the same example from above.
We’re covering only the boundaries which in this case are: 0,1,100,101,999,1000. Those are positive and negative boundary test cases and with that, we’re making sure that any edge cases are covered.
Instead of following a graph or diagram, the error guessing technique solely relies on the tester’s experience in testing the software and finding bugs based on the inputs provided.
With state transition testing, we’re focusing on which states the system is in at that moment based on the specific inputs and outputs. What will happen if we have 2 scenarios of a correct password for a login page and 2 scenarios for an invalid password.
When we have multiple complex inputs for a test scenario it is often a better solution to use decision tables. Decision tables test the behavior of the system by combining different inputs in a tabular form.
|The mouse does not work
|Check the cable
|Check the USB port
What is White-Box testing?
White-box testing is a testing method in which internal structures like code, design, and architecture are known and are tested to confirm that the flow is correct and it works as expected. Testers should have knowledge of the code structure since they need to test it. In other words, the internal workings of an application are being covered.
Types of white-box testing include:
- Unit Testing – Testing one unit/component after every code change to ensure that the isolated part is working as expected
Ways to perform White-Box testing
Testing the internal structures of the system means:
- Technical knowledge for those who will perform the testing is a must
- Understanding the code is also a must
- Understanding the internal workflow in order to write unit tests
- Write unit tests to test components separately
White-Box testing techniques
This technique involves testing every single branch from the decision point in the code to be executed at least once to ensure that it is working. usually hard to achieve 100% code coverage but covering the most important combinations should at least confirm that the code works. This technique is done by the developers.
This technique involves testing every single statement in the code to be executed at least once to ensure that it is working as expected. The main goals are to cover all the possible paths, statements, and lines in the code. This technique is done by the developers.
Black-Box vs White-Box
|Testing the software without knowing its internal workings
|testing the internal code of the software
|Done my software testers
|Done by developers
|No technical knowledge required
|Technical knowledge required
|Tests the behaviour of the system based on the inputs
|Tests the logic of the system trough the code
|System implementation knowledge not required
|System implementation knowledge required
Share This Post
- Crucial Aspects Of Superior Test Code Quality
- Streamline Your Cucumber BDD Tests with Gherkin Lint: A Comprehensive Guide
- How to Test Authentication and Authorization with Confidence + Best Tips
- Exploring the Three Scrum Artifacts: Grasping Their Essence and Effective Utilization
- How do Scrum teams work effectively to deliver quality products to their stakeholders?