Blog Archives

The software testing can be dividing into four levels (unit, integration, system and acceptance). In each level, different approaches are used and different characteristics are tested, if you want you can check V-model.

In this post I will only give you an short overview about the level, I will introduce more details in a future post.

Before I start explain the level, I need to point that test level are represented using a pyramid because for healthy software testing approach you need to respect  balance between the tests.

Unit test

The unit tests have the purpose of finding faults in units of software. The units can be a class, a function, an object, or even just a method or procedure.

This is the first level of the test to be executed in the application, in which the white-box method approach is usually used.

Integration test

The integration tests are intended to test the internal interaction and communication between the various components of the Software.

At this level of testing, the most common errors found are related to the transmission of data between these components:

• Interface misuse: Bad interface usage of a component calls for another component and makes an error in the use of its interface
• Interface misunderstanding: The component sends the request and misunderstands the specification of the interface of the component receiving the request and makes assumptions about its behaviour. The called component does not behave as expected which then causes unexpected behaviour.
• Timing errors: These occur in systems that use a shared memory or data. When a system requests data, it can be outdated or inexistent.

The integration tests are mostly black-box but sometimes can be white-box.

System tests

The system tests test the system as a whole, where the hardware and software are integrated. The main objective of this level of testing is to ensure that the system behaves according to specifications.

In this level, for the first time, the non-functional requirements of the product are tested.

These tests are black-box.

Acceptance tests 

Acceptance tests are the last tests to be conducted before it is sent to production. The application is tested in an environment where it will be used.

These tests are black-box.

Idea:

The most common approach in Software testing is the black-box and white-box as they are very easy to distinguish.

White-box

Other known names

• Structural testing;
• Clear-box testing;
• Glass-box testing;
• Open-box testing;

Objective:

• Test the internal behavior of components of the applications;
• Design the test cases to cover maximum number of paths;

Orientation:

• Test oriented to code structure

QA Access level:

• Entire source code

Black-box

Other known names

• Functional testing

Objective:

• Test the interface;
• Find incorrect functions;

Orientation:

• Test oriented for functions of application;

QA Access level:

• Inputs, outputs, pre and post condition

I have explained using bullets, so that it can be easier to read.  I hope I haven’t forgotten anything.

Ok, now we know the difference between both techniques but what type of bugs can only be discovered in white-box?   The answer is easy, bugs like un-used variables.

Grey-box

Grey-box (gray-box) testing isn’t easy to define because there isn’t an official definition. Some people defend that you have access of the code but you cannot read the entire code, only some parts are known. For me, this is cheating, how can you know that the parts you read are the important ones?, and what is the benefit of reading only part of the code?

Others defends that you have access to the technical manual and algorithms, which is true, but in agile development sometimes there isn’t enough documentation or the documentation is not up to date.

Ok, now you are wondering what definition I agree with, well, I believe in two different definitions:

1. Using the white-box approach your code uses a third-party control (without access to the source code). In other words you cannot know the entire code because you don’t have access of the third party code.
2. When the code is unknown you ask the developer for some details about the code. When the information is received, the Grey Box method is applied.

If you use the grey-box approach you can sometimes reduce the number of tests. But you can hang in there for more details when I will cover that in a future post about testing techniques.