Smoke Vs. Sanity Testing

1. Smoke testing originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch fire and smoke. In software industry, smoke testing is a shallow and wide approach whereby all areas of the application without getting into too deep, is tested.

A sanity test is a narrow regression test that focuses on one or a few areas of functionality. Sanity testing is usually narrow and deep.

2. Smoke testing is done by developers before the build is released or by testers before accepting a build for further testing.

The sanity test is done mostly by Testers.

3. A smoke test determines whether it is possible to continue testing.

Sanity test determines whether it is reasonable to proceed with further testing.

4. A software smoke test determines whether the program launches and whether its interfaces are accessible and responsive (for example, the responsiveness of a web page or an input button). If the smoke test fails, it is impossible to conduct a sanity test.

In contrast, the ideal sanity test exercises the smallest subset of application functions needed to determine whether the application logic is generally functional and correct (for example, an interest rate calculation for a financial application). If the sanity test fails, it is not reasonable to attempt more rigorous testing.

5. A smoke test is scripted--either using a written set of tests or an automated test

A sanity test is usually unscripted.

6. A Smoke test is designed to touch every part of the application in a cursory way. It's is shallow and wide.

A Sanity test is used to determine a small section of the application is still working after a minor change.

7. Smoke testing will be conducted to ensure whether the most crucial functions of a program work, but not bothering with finer details. (Such as build verification).

Sanity testing is a cursory testing; it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing.

8. Smoke testing is normal health check up to a build of an application before taking it to testing in depth.

Sanity testing is to verify whether requirements are met or not,
checking all features breadth-first.

9. Both sanity tests and smoke tests are ways to avoid wasting time and effort by quickly determining whether an application is too flawed to merit any rigorous testing

Stubs and Drivers in Software Testing

Stub in software development is a piece of code used to stand in some other functionality.

A stub may simulate the behavior of the existing code (such as procedure on a remote machine) or a temporary substitute for yet-to-be-developed code.

Example

BEGIN

Temperature = ThermometerReadIn()

If Temperature > 40 THEN

PRINT “It’s Hot!”

ENDIF

END

BEGIN ThermometerReadIn()

RETURN 40

END ThermometerReadIn

The above pseudo code utilizes the function “ThermometerReadIn” that returns a temperature. While the function “ThermometerReadIn”, would be indented to read some hardware device, this function currently does not contain this function correctly does not contain the necessary code. So, “ThermometerReadIn” does not in essence, simulate any process, yet it does return a legal value, allowing the main program to be atleast partly tested.

Stubs are dummy modules that simulate the low level modules in the top approach

Drivers are the dummy modules that simulate the high level modules in the bottom-up approach

A Stub is a piece of code that simulates the activity of missing component.

A driver is a piece of code that passes test cases to another piece of code.

Stub is a skeleton of function having function header. This function can have actual simple statements which can be replaced with the actual code.

Driver is a small program used to test a function. Drivers are dummy lines of code, used in Bottom-up approach calling programs. Drivers helps to test the function which is being tested by the driver calls another function then that function is called stub.

For further reading:

Link1, Link2, Link3

Difference between Bug, Defect and Error:

Bug – When the software does not perform as expected.
Defect – When the software has a undesirable feature.
Error – When the software deviates from the correct value.

Bug:
- Things the software does that it is not supposed to do.
- Something the software doesn’t do that is supposed to do.
- A fault in the program which causes the program to perform in an unintended or unanticipated manner.

Defect
- A product anomaly.
- Non-conformance to requirements.
- A quality problem discovered after the released to end user.

Error
- A discrepancy between computed, observed or measured value or condition and the true, specified or theoretically correct value or condition.
- A quality problem discovered by the S/W engineers (or others) before the software is released to the end user.

Click here for further reading