After making necessary changes, such as fixing a bug/defect, the software should be retested to confirm that the problem has indeed been fixed. Listed below are the types of testing to be done after installation software, to confirm that the application is working or that the defect has been corrected:
- Smoke testing(Smoke testing)
- Regression Testing(Regression Testing)
- Build testing(Build Verification Test)
- Sanitary testing or consistency/health check(Sanity Testing)
concept smoke testing came from engineering. When commissioning new equipment ("iron"), it was considered that the test was successful if no smoke came out of the installation. In the field of software testing, it is aimed at a superficial check of all application modules for operability and the presence of quickly found critical and blocking defects. According to the results of smoke testing, it is concluded whether or not the installed version of the software is accepted for testing, operation or delivery to the customer. To facilitate work, save time and human resources, it is recommended to implement automation of test scenarios for smoke testing.
Regression Testing is a type of testing aimed at verifying changes made to an application or environment(fixing a defect, merging code, migrating to another operating system, database, web server, or application server) to confirm that pre-existing functionality works as before (see also Sanitary testing or consistency/health checks). Regression can be functional, so non-functional tests.
As a rule, test cases written at the early stages of development and testing are used for regression testing. This ensures that changes in new version the apps didn't hurt existing functionality. It is recommended to automate regression tests to speed up the subsequent testing process and detect defects in the early stages of software development.
The term “Regression testing” itself, depending on the context of use, can have a different meaning. Sam Kaner, for example, described 3 main types regression testing:
- Bug regression is an attempt to prove that a fixed bug is not actually fixed.
- Old bugs regression- an attempt to prove that a recent change in code or data broke the correction of old errors, i.e. old bugs started to play again.
- Regression side effect(Side effect regression)– an attempt to prove that a recent code or data change broke other parts of the application being developed.
Sanity Testing or Consistency Testing (Sanity Testing) – this is a narrow test, sufficient to prove that a particular function works according to the requirements stated in the specification. It is a subset of regression testing. Used to determine the health of a particular part of the application after changes have been made to it or the environment. Usually done manually.
The difference between sanitary testing and smoke testing. Some sources mistakenly believe that sanitary and smoke testing are the same thing. We believe that these types of testing have "movement vectors", directions in different directions. Unlike smoke testing, sanity testing is directed deep into the tested function, while smoke testing is directed in breadth, in order to cover as much functionality as possible with tests in the shortest possible time.
Build testing(Build Verification Test) is a test aimed at determining whether the released version complies with the quality criteria for starting testing. According to its goals, it is an analogue of Smoke Testing, aimed at accepting a new version for further testing or operation. It can penetrate further into the depths, depending on the quality requirements of the released version.
Installation Testing - is aimed at verifying the successful installation and configuration, as well as updating or uninstalling the software. At the moment, the most common installation of software using installers(special programs that themselves also require proper testing). In real conditions, there may not be installers. In this case, you will have to install the software yourself, using the documentation in the form of instructions or readme files, step by step describing all the necessary actions and checks. In distributed systems where the application is deployed on an already running environment, a simple set of instructions may not be enough. To do this, often, a deployment plan (Deployment Plan) is written, which includes not only the steps for installing the application, but also the rollback steps (roll-back) to the previous version, in case of failure. The installation plan itself must also go through a testing procedure to avoid problems when released into actual operation. This is especially true if installation is performed on systems where every minute of downtime is a loss of reputation and a large amount of funds, for example: banks, financial companies or even banner networks. Therefore, installation testing can be called one of the most important tasks for ensuring software quality.
It is this integrated approach with writing plans, step-by-step installation verification and installation rollback that can rightly be called installation testing or Installation Testing.
Means a minimum set of tests for obvious errors. The "smoke test" is usually performed by the programmer himself; It makes no sense to send a program that does not pass this test for deeper testing.
Examples
- Installation Errors: If a software product is not installed, it will most likely not be possible to test it.
- Errors when connecting to the database, relevant for the client-server architecture.
Story
This term was first used by stove-makers, who, having assembled the stove, closed all the plugs, flooded it and watched so that the smoke came only from the right places.
The repeated "birth" of the term occurred in radio electronics. The first switching on of a new radio-electronic device that came from production takes place for a very short time (less than a second). Then the engineer touches all the chips with his hands for overheating. A chip that has become very hot during this second may indicate a gross error in the circuit. If the first switching on did not reveal overheating, then the device turns on again for a longer time. The check is repeated. And so on several times. The expression "smoke-test" is used by engineers in a joking sense, since they try to avoid the appearance of smoke, and hence damage to parts of the device.
Automation
Smoke Tests easier to automate than more in-depth and intelligent testing. Automation reduces the number manual labor and therefore allows these tests to be performed more frequently. The more often the tests are run, the sooner the problems identified by these tests become known. The sooner a problem is known, the easier it is to fix. Test automation is often done with continuous integration tools.
Write a review on the article "Smoke test"
Links
- on Jargon File
- msdn.microsoft.com/en-us/library/ms182613(VS.90).aspx - Microsoft Quick Test Rules.
An excerpt characterizing the Smoke test
All day she lived only in the hope that at night she would see him. But now that the moment had come, she was terrified of what she would see. How was he mutilated? What was left of him? Was he like that, what was that unceasing groan of the adjutant? Yes, he was. He was in her imagination the personification of that terrible moan. When she saw a vague mass in the corner and took his knees raised under the covers by his shoulders, she imagined some kind of terrible body and stopped in horror. But an irresistible force pulled her forward. She cautiously took one step, then another, and found herself in the middle of a small cluttered hut. In the hut, under the images, another person was lying on benches (it was Timokhin), and two more people were lying on the floor (they were a doctor and a valet).The valet got up and whispered something. Timokhin, suffering from pain in his wounded leg, did not sleep and looked with all his eyes at the strange appearance of a girl in a poor shirt, jacket and eternal cap. The sleepy and frightened words of the valet; "What do you want, why?" - they only made Natasha come up to the one that lay in the corner as soon as possible. As terrifying as this body was, it must have been visible to her. She passed the valet: the burning mushroom of the candle fell off, and she clearly saw Prince Andrei lying on the blanket with outstretched arms, just as she had always seen him.
He was the same as always; but the inflamed complexion of his face, the brilliant eyes fixed enthusiastically on her, and in particular the tender childish neck protruding from the laid back collar of his shirt, gave him a special, innocent, childish look, which, however, she had never seen in Prince Andrei. She walked over to him and, with a quick, lithe, youthful movement, knelt down.
He smiled and extended his hand to her.
For Prince Andrei, seven days have passed since he woke up at the dressing station in the Borodino field. All this time he was almost in constant unconsciousness. The fever and inflammation of the intestines, which were damaged, in the opinion of the doctor who was traveling with the wounded, must have carried him away. But on the seventh day he ate with pleasure a piece of bread with tea, and the doctor noticed that the general fever had decreased. Prince Andrei regained consciousness in the morning. The first night after leaving Moscow was quite warm, and Prince Andrei was left to sleep in a carriage; but in Mytishchi the wounded man himself demanded to be carried out and to be given tea. The pain inflicted on him by being carried to the hut made Prince Andrei moan loudly and lose consciousness again. When they laid him down on the camp bed, he lay with his eyes closed for a long time without moving. Then he opened them and whispered softly: “What about tea?” This memory for the small details of life struck the doctor. He felt his pulse and, to his surprise and displeasure, noticed that the pulse was better. To his displeasure, the doctor noticed this because, from his experience, he was convinced that Prince Andrei could not live, and that if he did not die now, he would only die with great suffering some time later. With Prince Andrei they were carrying the major of his regiment, Timokhin, with a red nose, who had joined them in Moscow, wounded in the leg in the same Battle of Borodino. They were accompanied by a doctor, the prince's valet, his coachman and two batmen.
Smoke testing (there are names intake test, build verification test) - testing carried out at the initial stage (for example, after a new build) and primarily aimed at checking the readiness of the developed product for more advanced testing, determining the general state of product quality.
This is a short test cycle that confirms (denies) the fact that the application starts and performs its main functions. This type of testing allows at the initial stage to identify the main quickly found critical defects. Based on the fact that these checks are almost always the same and rarely change, it would be advisable to automate them.
Smoke testing example:
If we take the DI Tool STAR project for example, then this type of testing will include testing the following functionalities:
Login form (login with valid data)
Log out form (button click)
Property selection (checking that the functionality is there and it works)
Property Lists (what they are, without saving/deleting)
Proceed to STAR
Menu (click)
View switching
Drawer (switching tabs, switching buttons inside tabs)
Export (button firing)
Header property selector
Favorites (checking that functionality is and it works)
We need to determine what tasks need to be achieved thanks to our application, what are the obvious steps to achieve the task, what important requirements we must comply with and in what sequence.
To do this, we create a set of tests. A test suite is a grouped collection of test cases that are related in some way (for example, by functionality).
Smoke tests are designed to test core functionality and should be an integral part of the testing process. They might include something as simple as “Can I check in?”. Smoke testing requires YES / NO answers and all test cases must be passed with a positive result.
Smoke tests should be fast and lightweight so that they can be run frequently. Depending on the specifics of the project, a smoke test can be completed in a few minutes or a few hours.
It should be understood that this type of testing is a type of product testing in depth, and not just a type of test testing. As mentioned above, this type of testing determines whether the product is suitable for further, more comprehensive testing. If it does not pass smoke testing, the product must be sent for revision.
Be sure to record the results of the test. This is necessary in order to keep a record of what works and what doesn't. You can divide the results into passed and failed.
Passed: everything works fine.
Failed: Doesn't work.
What is Smoke Testing?
Smoke testing is defined as a type of software testing that determines whether the deployed build is stable or not. This serves as confirmation of whether the QA team can proceed with further testing. Smoke tests are a minimal set of tests run on each build. Here is the cycle where smoke testing is involved
Smoke testing is a process where the software build is deployed to QA environment and is verified to ensure the stability of the application. It is also called as "Build verification Testing" or "Confidence Testing."
In simple terms, we are verifying whether the important features are working and there are no showstoppers in the build that is under testing.
It is a mini and rapid regression test of major functionality. It is a simple test that shows the product is ready for testing. This helps determine if the build is flawed as to make any further testing a waste of time and resources.
The smoke tests qualify the build for further formal testing. The main aim of smoke testing is to detect early major issues. Smoke tests are designed to demonstrate system stability and conformance to requirements.
A build includes all data files, libraries, reusable modules, engineered components that are required to implement one or more product functions.
In this tutorial, you will learn-
When do we do smoke testing
Smoke Testing is done whenever the new functionalities of software are developed and integrated with existing build that is deployed in QA/staging environment. It ensures that all critical functionalities are working correctly or not.
In this testing method, the development team deploys the build in QA. The subsets of test cases are taken, and then testers run test cases on the build. The QA team test the application against the critical functionalities. These series of test cases are designed to expose errors that are in build. If these tests are passed, QA team continues with Functional Testing .
Any failure indicates a need to handle the system back to the development team. Whenever there is a change in the build, we perform Smoke Testing to ensure the stability.
example: -New registration button is added in the login window and build is deployed with the new code. We perform smoke testing on a new build.
Who will do Smoke Testing
After releasing the build to QA environment, Smoke Testing is performed by QA engineers/QA lead. Whenever there is a new build, the QA team determines the major functionality in the application to perform smoke testing. QA team checks for showstoppers in the application that is under testing.
Testing done in a development environment on the code to ensure the correctness of the application before releasing build to QA, this is known as Sanity testing. It is usually narrow and deep testing. It is a process which verifies that the application under development meets its basic functional requirements.
Sanity testing determines the completion of the development phase and makes a decision whether to pass or not to pass the software product for further testing phase.
Why do we do smoke testing?
Smoke testing plays an important role in software development as it ensures the correctness of the system in initial stages. By this, we can save test effort. As a result, smoke tests bring the system to a good state. Once we complete smoke testing then only we start functional testing.
- All the show stoppers in the build will get identified by performing smoke testing.
- Smoke testing is done after the build is released to QA. With the help of smoke testing, most of the defects are identified at the initial stages of software development.
- With smoke testing, we simplify the detection and correction of major defects.
- By smoke testing, QA team can find defects to the application functionality that may have surfaced by the new code.
- Smoke testing finds the major severity defects.
Example 1: Logging window: Able to move to next window with valid username and password on clicking submit button.
Example 2: Userunable to sign out from the webpage.
How to do Smoke Testing?
Smoke Testing is usually done manually though there is a possibility of accomplishing the same through automation. It may vary from organization to organization.
Manual smoke testing
In general, smoke testing is done manually. It approaches varies from one organization to another. Smoke testing is carried to ensure the navigation of critical paths is as expected and doesn't hamper the functionality. Once the build is released to QA, high priority functionality test cases are to be taken and are tested to find the critical defects in the system If the test passes, we continue the functional testing. If the test fails, the build is rejected and sent back to the development team for correction. QA again starts smoke testing with a new build version. will get integrated with old builds to maintain the correctness of the system.
- Smoke test on Jargon File
Wikimedia Foundation. 2010 .
See what "Smoke test" is in other dictionaries:
smoke test- noun A method of testing for leaks in drain pipes or chimneys by introducing dense smoke, often by using a smoke bomb Main Entry: smoke … Useful english dictionary
smoke test- Test made to determine the completeness of combustion … Dictionary of automotive terms
smoke test- 1. noun a) A test for leaks involving blowing smoke into a tube or pipe. b) A preliminary test on a newly constructed piece of electronic equipment, consisting simply of the application of electrical power, to make sure that no egregious wiring… … Wiktionary
smoke testing- is a term used in plumbing, woodwind repair, electronics, computer software development, and the entertainment industry. It refers to the first test made after repairs or first assembly to provide some assurance that the system under test will… … Wikipedia
smoke testing- bzw. Rauchtest ist ein Begriff aus dem Englischen, gebräuchlich im handwerklichen Bereich (z. B. in der Klempnerei, Elektronik oder beim Bau von Holzblasinstrumenten) wie auch in der Softwareentwicklung. Es bezeichnet den ersten… … Deutsch Wikipedia
Smoke- is the collection of airborne solid and liquid particulates and gases [SFPE Handbook of Fire Protection Engineering] emitted when a material undergoes… ... Wikipedia
test suite- In software development, a test suite, less commonly known as a validation suite , is a collection of test cases that are intended to be used to test a software program to show that it has some specified set of behaviors. A test suite often… … Wikipedia
smoke bomb- A smoke bomb is a firework designed to produce smoke upon ignition. While there are smoke generating devices that are dropped from airplanes, the term smoke bomb is used to describe the three types of devices:# A smoke ball is a hollow, cherry… … Wikipedia