Smoke testing is an integration testing approach that is commonly used when “shrink-wrapped” software products are being developed. It is designed as a pacing mechanism for time-critical projects, allowing the software team to assess its project on a frequent basis. In essence, the smoke testing approach encompasses the following activities:
1. Software components that have been translated into code are integrated into a “build.” A build includes all data files, libraries, reusable modules, and engineered components that are required to implement one or more product functions.
2. A series of tests is designed to expose errors that will keep the build from properly performing its function. The intent should be to uncover “show stopper” errors that have the highest likelihood of throwing the software project behind schedule.
3. The build is integrated with other builds and the entire product (in its current form) is smoke tested daily. The integration approach may be top down or bottom up.
The smoke test should exercise the entire system from end to .end. It does not have to be exhaustive, but it should be capable of exposing major problems. The smoke test should be thorough enough that if the build passes, you can assume that it is stable enough to be tested more thoroughly.
Smoke testing provides a number of benefits when it is applied on complex, time-critical software engineering projects:
• Integration risk is minimized. Because smoke tests are conducted daily, incompatibilities and other show-stopper errors are uncovered early, thereby reducing the likelihood of serious schedule impact when errors are uncovered.
• The quality of the end-product is improved. Because the approach is construction (integration) oriented, smoke testing is likely to uncover both functional errors and architectural and component-level design defects. If these defects are corrected early, better product quality will result.
• Error diagnosis and correction are simplified. Like all integration testing approaches, errors uncovered during smoke testing are likely to be associated with “new software increments”—that is, the software that has just been added to the build(s) is a probable cause of a newly discovered error.
• Progress is easier to assess. With each passing day, more of the software has been integrated and more has been demonstrated to work. This improves team morale and gives managers a good indication that progress is being made.
Comments on Integration Testing:
There has been much discussion of the relative advantages and disadvantages of top-down versus bottom-up integration testing. In general, the advantages of one strategy tend to result in disadvantages for the other strategy.
The major disadvantage of the top-down approach is the need for stubs and the attendant testing difficulties that can be associated with them. Problems associated with stubs may be offset by the advantage of testing major control functions early.
The major disadvantage of bottom-up integration is that “the program as an entity does not exist until the last module is added” . This drawback is tempered by easier test case design and a lack of stubs.
Selection of an integration strategy depends upon software characteristics and, sometimes, project schedule. In general, a combined approach (sometimes called sandwich testing) that uses top-down tests for upper levels of the program structure, coupled with bottom-up tests for subordinate levels may be the best compromise.
What is a critical module and why should we identify it
As integration testing is conducted, the tester should identify critical modules. A critical module has one or more of the following characteristics:
(1) addresses several software requirements,
(2) has a high level of control (resides relatively high in the program structure),
(3) is complex or error prone (cyclomatic complexity may be used as an indicator), or
(4) has definite performance requirements. Critical modules should be tested as early as is possible. In addition, regression tests should focus on critical module function.
UNIT TESTING PART TWO
UNIT TESTING PART THREE
GUI TESTING
WINDOWS COMPLIANCE GUI TESTING PART ONE
WINDOWS COMPLIANCE GUI TESTING PART TWO
WINDOWS COMPLIANCE GUI TESTING PART THREE
WINDOWS COMPLIANCE GUI TESTING PART FOUR VALIDATION TESTING
WINDOWS COMPLIANCE GUI TESTING PART FIVE CONDITION TESTING
WINDOWS COMPLIANCE GUI TESTING PART SIX GENERAL CONDITION TESTING
CONDITION TESTING
TESTING CONDITIONS PART ONE
TESTING CONDITIONS PART TWO
TESTING CONDITIONS PART THREE
TESTING CONDITIONS PART FOUR
SPECIFIC FIELD TESTING
USABILITY TESTING
INTEGRATION TESTING
INTEGRATION TESTING PART ONE
INTEGRATION TESTING PART TWO
INTEGRATION TESTING PART THREE
INTEGRATION TESTING PART FOUR
INTEGRATION TESTING PART FIVE
INTEGRATION TEST STANDARDS
INTEGRATION TEST STANDARDS PART TWO
No comments:
Post a Comment