Smoke Test Plan
Can someone advice me or if you have a plan for Smoke Testing......
I have been asked to devise a smoke test plan but i have no idea .... Please Help
Re: Smoke Test Plan
Smoke testing is basically bash testing or look and see testing.
The idea of doing smoke testing is to see if you bother doing the real testing at all. If a product can't cope with me hitting it for a couple of hours then I won't pass it on to a test team.
The type of testing is horizontal and focused on core functionaility. Tests should not drill down too deep and should be desaigned for quick execution.
Re: Smoke Test Plan
A smoke test should be good enough to catch “show stopper” defects, but not disregard trivial defects. The definition of “trivial” is up to the individual project, but you
should realize that the goal of a smoke test is not the same as the goal of the overall quality assurance process.
The scope of the test need not be exhaustive. It should test basic functions, and simple integrationissues. Ideally it should be automated so that there is little cost to do it. The Smoke Test should notreplace deeper integration testing. A suite of unit like tests can form the basis for the smoke test ifnothing else is immediately available. Most importantly, these tests should be self scoring. They shouldreturn a test status and not require manual intervention to see if the test passed. (An error may well
involve some effort to discover the source.)Developers should run the smoke test should be run manually prior to committing a change. It can also be run as part of the build process in concert with more through tests, when the build is to be a release
Running a Smoke test with each build does not remove the responsibility for a developer to test hischanges before submitting them to the repository. A smoke test is most useful for bug fixes, and for looking for inadvertent interactions between existing and new functionality. All code should be unit tested by the developer, and where reasonable, run through some scenarios in a system environment. When you add new basic functionality to a system, extend the smoke test to test this functionality as well. But do not put exhaustive tests that better belong in Unit Tests or Regression tests. Having a Smoke Test as part of a Daily build is key to establishing Named Stable Bases, which form
the basis for workspaces.
A smoke test should be:
• Quick to run, where ‘quick’ depends on your specific situation
• Self scoring, as any automated test should be.
• Provide broad coverage across the system that you care about
• Be runnable by developers
The hardest part about a self scoring test is to determine input/output relationships among elements of a complex system. You don’t want the testing and scoring infrastructure to be buggy. You want the test to work with realistic data exchanged between parts of the system.Canned inputs are fine as long as they are realistic enough. If your testing infrastructure is too compli-cated, you add risks around testing the test.
A Smoke test is an end-to-end test, more black box than white box.
Hope this Helps