######Black Box Testing:########
You test a system without knowing the internal implementations which includes the source code, designs or internal contracts between services.
An effective black box testing could be achieved by following following approaches:
- Understanding the requirements:
Try to understand what inputs the system expect , what are the expected output etc.
- Understanding the system
You could know more about a system through test approaches like:
Exploratory testing:
Where we navigate and use the product to learn and understand more about the 'system under test'. Here we learn about the product as we use it and also identifies possible test scenarios that could be applicable to the test context ("As testing is context dependent,all possible scenarios won't be applicable to all products")
Monkey testing:
A test approach were tester tries to break the system using random actions without much knowledge about the product. Monkey testing can be dumb, smart or brilliant, were each of this defines the product and domain knowledge level of the tester.
Adhoc testing:
A focused approach to break the system using the product design and requirements that were learned from the above mentioned approaches.
GUI testing (System testing)
A systematic approach to test the system in order to ensure that the system works as a whole after integrating all systems together. UI automation, manual test cases all come under this.
Non-Functional testing:
Testing approaches to ensure system robustness through Security, Stress, and Load testing
We can also test for usability , adaptability , etc as this doesn't requires the knowledge of internal implementation.
Happy Path Testing
Test all the valid use cases , check the system only with valid inputs. Make sure system works as expected
Negative Path Testing
Test all the invalid use cases , so its more like an umbrella term for adhoc, and monkey testing
#######White box Testing:########
Here the tester has clear understanding of how the system is implemented. He has access to source code and try to break the system with this understanding
Eg
Consider below line of Javascript code to create a sql query from user input:
query = select * from a where username='${username}' and password = '${pass}'
.
If the tester has access to this code , then he can easily know that this code is successtible to be sqlInjection.
If user passes usrname as test' or 1=='1
and pass as test' or 1=='1
then the line becomes true always and any one can get data from database.
######Grey Box:########
Here user have half knowledge of the system , like user knows we are using IIS server version 1.2xx which has a vulnerability reported but doesn't know the file path or approach to trigger that vulnerability.
Now coming to Behavior testing,
########Behaviour testing:#######
Behavior testing concentrate on the buissnes logic than the implementation.
as per cucumber: https://cucumber.io/docs/bdd/
**What is BDD?**
BDD is a way for software teams to work that closes the gap between business people and technical people by:
* Encouraging collaboration across roles to build shared understanding of the problem to be solved
* Working in rapid, small iterations to increase feedback and the flow of value
* Producing system documentation that is automatically checked against the system’s behaviour
We do this by focusing collaborative work around concrete, real-world examples that illustrate how we want the system to behave. We use those examples to guide us from concept through to implementation, in a process of continuous collaboration.
Here the test approach could be any of black box, white box , or grey box. It doesn't matter. Here, the focus is on ensuring the buissness logic works as expected.
This approach tests the behavior of the system .
For example ,
When user inputs sepcial character to a password field
Then Get error message
Is not behavior but the implementation of the behavior.
The proper behavior would be
When user provides invalid Credential
Then Proper error message is thrown
Here we ensure that system behaves the way it is intented for all invalid values. The validaitons are done internally which may or may not include special character check.
Summary:
In testing there are many terms that overlaps with each other, try view it from different levels, scopes, techniques etc .
Black box, white box and grey box are different test techinques with
respect to the scope of information available about the product. Here we can cover both functional and non functional features.
Behavior Testing is a test approach to test the behavior of a system and validating it inline with the buissness logic or requirement. This can include black /white or grey testing. The main mindset here is to make sure happy paths are working fine and functional testing is working as expected.
Update:
Thanks Niel for the comment
So for anyone who looks for difference between TDD , BDD and Behavior testing
Both TDD and BDD are test first approach with the difference that the
former tests the implementation while the later test the behavior. So TDD and BDD are development approaches and, implementation testing and behavior testing is the test approach used in this development approaches respectively.
Or you can also see BDD as a type of TDD where you test the behavir than the implementation.
https://softwareengineering.stackexchange.com/a/274586/332712
This answer gives an idea.
There are lots of overlap with terms in software testing industry.