Tuesday, November 22, 2016

Black-box vs White-box Testing | David Tzemach

תוצאת תמונה עבור ‪black box vs white box testing‬‏

Black Box Testing (BBT)

White box testing (WBT)


A software testing approach that is used to validate the software based on the preliminary requirements and specifications (There is no need to access the source code of the application).

This testing approach does not require the tested to be familiar with the internal code, design and code structure of the application that's being tested.  

In white box testing, we will need to understand the internal architecture of the software, this knowledge should include the methods, code design, code integrations and many other components that may help during the tests.

As such, the person who runs the tests should have the relevant permissions to access the code.
Performed by
Test teams, developers, end-users, and any other resource that can work with the application and report for an incident.

Usually made by developers, but in some cases, there is a dedicated QA team that can handle this type of tests.
Programming knowledge
In my personal opinion, every tester should know at least a single coding language, but for this theoretical post, the answer Is no.

Must have, that’s the main reason why it’s made by developers J.
Testing level
Used on the later phase of the testing effort (System, End-to-End and Acceptance).

Run on the earlier phases of the testing effort (unit, Component, and integration).
Test Flow
We will test the End-to-End flow of the system.

We will test a single function each time.
To run this type of tests, we will need to use a running application, that will allow us to run the test flows.

There is no need to use a running application, the tests are created in earlier phases of the application lifecycle
Defect reporting
Each bug is reported in a dedicated bug reporting system.

Defects are not reported; the developer will remove them instantly.
Defect Complexity
In some cases, the defects are very complex and involve many integrations between the code parts, but in some cases, it will be an easy UI defect.

Remember that we test a small part of the code (UNIT), therefore when a defect is found it will be easier to remove it.
Test Design
Bases on requirements and specifications

Based on the detailed design of the internal structure
Test Techniques
  • Error guessing
  • Boundary value analysis
  • Equivalence partitioning
  • Exploratory testing
  • Decision tables
  • Loop Testing
  • Data Flow Testing
  • Condition testing
  • Statement coverage
  • Path Coverage Branch coverage

Black Box Testing (BBT)

White box testing (WBT)

  • Conduct by many types of resources that may have different perspectives (Testers, Developers, etc.).
  • There is no need to access the internal code.
  • Easy to design and execute. 
  • Involve the entire flows of the application. 
  • Allow the testers to test large complex applications.
  • The method involves both manual and automated test execution.

  • Very efficient in finding defects and logical errors.
  • Allowing the developer to concentrate on a small part of the code.
  • Will optimize the code structure and performance.
  • Allow the Developer to re-run the tests over and over again.
  • Uncover errors in the earliest phases of the SDLC.
  • Unit tests provide both the reliability and stability in the code. 

  • Does not allow to run all test scenarios (Limited tests are performed). 
  • The testing quality can be inefficient due to the resource-limited knowledge in the internal structure of the application.
  • Very hard to maintain the tests during the time. 
  • Regression tests are the worst enemy of tester happiness. 

  • Limited view on the code integrations.
  • Requires the deep and high level of knowledge of the application design and structure.
  • Time-consuming and Expensive. 
  • Unit tests are very fragile in any case of code modifications. 

No comments:

Post a Comment

My Presentations