Box testing

- One way to model testing is to think about it in terms of a box. that can be performed so that there is a holistic approach to testing an application. First, there is black box testing, which means that the box is completely concealed and it is not possible to see inside of it. Each test scenario here examines the product from the outside. It allows input to the box and gets output from the box. This means that there is no knowledge needed about the internals of the application, such as what the source code is doing or how the system is working. The focus with black box testing is to perform an action in the user interface and expect a certain result from that action. Black box tests include manual testing and UI automation testing, both of which will help uncover issues with functionality and usability. QA engineers are responsible for this level of testing. Next up is gray box testing. Here the box is semi-transparent. Test scenarios here examine the interaction between the outside and inside of the box. It requires QA engineers to have a deeper understanding of the application. Gray box tests include integration testing, which examines how components of the application work together. They can trigger some action in the UI and see how the code responds. Typically QA engineers and developers are responsible for these level of test. And lastly, there is white box testing. Here the box is completely transparent and focuses on the internals of the application and what is happening at the code or system level. It tests specific functionalities in the code and verifies the result. White box testing includes unit and system testing. Developers are responsible for these type of tests and write them alongside development. Take for example a shopping cart on an e-commerce web application, items can be added and removed from the shopping cart and a total is displayed based on the quantity of items in the cart. For this feature I'll want to think about the type of testing that can be done to ensure quality and confidence that the application works as expected. At the white box level of testing I'm starting from inside the box. Examples of test scenarios here that can be executed at this level are that the quantity can be increased and decreased successfully, and the calculation of items is performed correctly. These tests are written by calling functions in the code that can increase, decrease and calculate the total. Different values are provided to the functions and expect an exact result to be returned. At the gray box level of testing and the results a server or database returned. I want to know that the box as a whole works well rather than one specific component. A test at this level I might write would be to add an item to the cart and confirm form the API response that the item was added and the cart price was updated. Tests here start from the client, which sends a request to the server, and the server responds with details which I can verify. For black box testing in this example I'm focusing on what input I provide to the box and what output I receive. An example of a test here is to add an item to the cart using the UI and see the cart quantity and price update. To write this level of test I manipulate web elements in a browser to click and add items to the cart and navigate to the cart. I can also get the value of web elements and confirm the output is what I expect. and confirm the output is what I expect. So that's how you can model testing as a box. The whole idea is about looking at a box, The whole idea is about looking at a box, or whatever application is under test from multiple angles to provide thorough test coverage. from multiple angles to provide thorough test coverage.