These two types of testing are not directly related.

A smoke test is a quick system test with the purpose of finding major flaws in a software artifact. For example, a test might deploy a web app to a test server, validate that it deploys and starts up, and the server can service simple requests. This would validate that the application file (e.g. WAR file in Java) was built correctly and is not missing anything important.

The expectation here is that QA will need to perform much more in-depth testing to validate the system. But if a build process breaks and the delivery artifact is unusable, why waste anyone’s time testing if the application will not even start?

Black box testing is really a category of testing, not a specific type of test. It is any test that assumes no knowledge about the inner workings of a module of code.

One good real-world example of black box testing was many years ago when IBM dominated the PC market. Other manufacturers wanted to break into the (then) lucrative hardware market. The issue was IBM’s BIOS was locked down and they would not license their chips to competitors. Several competitors performed black box testing to figure out the inner workings of the BIOS, and made their own clones.

Unit tests are also ideally a form of black box testing. A good unit test is written to the interface of a class or method, not the implementation. This helps developers avoid “coddling” their code, i.e. avoiding input values that might break it. Good unit tests are black box tests because they are impartial and try to break the code in any way possible.

Basically, in smoke testing you turn on the system, especially for the first time ever, and see whether it starts to emit smoke… which would be a sign that something is very wrong with it. It doesn’t tell you anything beyond that, but it can still be valuable to avoid further effort on something that is obviously not going to work at all.

According to Wikipedia, the words “smoke test” originated from plumbing, where smoke was forced through pipes to find leaks. Electronics engineers began using the term to identify a basic power-on test; if the equipment didn’t smoke, it passed the test. Software engineers use the term to identify tests that confirm basic functions of the software. The term is meant to be somewhat humorous.

Black-box testing is simply testing something from the outside, via its API, with no information (or while pretending not to have any information) about the implementation. The two terms are not related in any way; “black box testing” refers only to software. Compare White Box testing, which tests internal structures or workings of an application, as opposed to its functionality.

The term “smoke testing” can be thought of as a sanity check. These are quick tests to get a quick, overall view of whether or not the system seems to be working. It isn’t careful, methodical testing. For example, smoke testing might catch things like obvious freezes or obvious integration problems.

Black box testing is a completely different category. Black box testing means that the testers should have no idea of the implementation of the application, and should be using it from the point of view of an end-user. Now, that could encompass smoke testing — it would be like an end-user’s sanity check of the system. Or, black box testing could be a software testing methodically trying to stress the system through use to find where its operation may break down.

What would be an example of something you would not do with black box testing? You would not, for example, manually enter bad data in a back end database to see how the system handles such data. That is not testing from the point of view of an end-user: meaning, via the application’s interface. If you could somehow get bad data into the database by entering it via the interface, that would be black box testing.

White Box Testing

Is a verification technique software engineers can use to examine if their code works as expected.

There are six basic types of testing: unit, integration, function/system, acceptance, regression, and beta. White-box testing is used for three of these six types:

Unit testing: Unit testing is important for ensuring the code is solid before it is integrated with other code.
Integration testing: Test cases are written which explicitly examine the interfaces between the various units. These test cases can be black box test cases, whereby the tester understands that a test case requires multiple program units to interact. Alternatively, white-box test cases are written which explicitly exercise the interfaces that are known to the tester.
Regression testing: As with integration testing, regression testing can be done via black-box test cases, white-box test cases, or a combination of the two. White-box unit and integration test cases can be saved and rerun as part of regression testing.
Black Box Testing

Is a software testing technique in which functionality of the software is tested without looking at the internal code structure. Also known as (Behavioral Testing).

This method is named so because the software program, in the eyes of the tester, is like a black box; inside which one cannot see.

This method attempts to find errors in the following categories:

Incorrect or missing functions
Interface errors
Errors in data structures or external database access
Behavior or performance errors
Initialization and termination errors
It can be done on the basis of the software requirements and specifications. Applying different inputs and comparing the output with the expected result.

Black Box Testing Techniques:

Equivalence Partitioning- Here we consider which cases are valid/invalid into a feature.

Boundary Value Analysis- Here we consider the primary case of each partitioning.

Decision Table Testing- Different conditions for a feature. With help of a table with rules(test cases) and actions(inputs).

Failure (“Dirty”) Test Cases- Evil evil evil 🙂

Smoke Testing

Is preliminary testing to reveal simple failures severe enough to reject a prospective software release. A subset of test cases that cover the most important functionality of a component or system is selected and run, to ascertain if crucial functions of a program correctly work Important here: The Functionality

When? Before a sprint release