Explore the Differences between Smoke Testing and Sanity Testing in detail with examples:
In this tutorial, you will learn what is Sanity Testing and Smoke Testing in Software Testing. We will also learn the key differences between Sanity and Smoke testing with simple examples.
Most of the time we get confused between the meaning of Sanity Testing and Smoke Testing. First of all, these two testings are way “different” and are performed during different stages of a testing cycle.
Table of Contents:
- Sanity Testing
- My Experience
- Sanity Testing Vs Regression Testing
- Strategy for Mobile App Testing
- Precautionary Measures
- Smoke Testing
- Smoke Testing Examples
- Importance of SCRUM Methodology
- Smoke Test Vs Build Acceptance Testing
- Smoke Test Cycle
- Who Should Perform the Smoke Test?
- Why Should We Automate Smoke Tests?
- Advantages And Disadvantages
- Difference Between Smoke and Sanity Testing
Sanity Testing
Sanity Testing is done when as a QA we do not have sufficient time to run all the test cases, be it Functional Testing, UI, OS or Browser Testing.
Hence, we can define,
“Sanity Testing as a test execution which is done to touch each implementation and its impact but not thoroughly or in-depth, it may include functional, UI, version, etc. testing depending on the implementation and its impact.”
Don’t we all fall into a situation where we have to sign off in a day or two but the build for testing is still not released?
Ah yes, I bet you must have also faced this situation at least once in your Software Testing experience. Well, I faced it a lot because my project(s) were mostly agile and at times we were asked to deliver it the same day. Oops, how can I test and release the build within a stretch of hours?
I used to go nuts at times because even if it was a small functionality, the implication could be tremendous. As an icing on the cake, clients sometimes simply refuse to give extra time. How can I complete the whole testing in a few hours, verify all the functionality, Bugs and release it?
The answer to all such problems was very simple, i.e nothing but using Sanity Testing strategy.
When we do this testing for a module or functionality or a complete system, the Test cases for execution are selected such that they will touch all the important bits and pieces of the same i.e. wide but shallow testing.
At times the testing is even done randomly with no test cases. But remember, the sanity test should only be done when you are running short of time, so never use this for your regular releases. Theoretically, this testing is a subset of Regression Testing.
My Experience
Out of my 8+ years of career in Software Testing, I was working in Agile methodology for 3 years and that was the time when I mostly used a sanity test.
All the big releases were planned and executed in a systematic manner but at times, small releases were asked to be delivered as soon as possible. We didn’t get much time to document the test cases, execute, do the bug documentation, do the regression and follow the whole process.
Hence, given below are some of the key pointers that I used to follow under such situations:
#1) Sit with the manager and the dev team when they are discussing the implementation because they have to work fast and hence we can’t expect them to explain to us separately.
This will also help you to get an idea about what they are going to implement, which area will it be affecting etc., this is a very important thing to do because at times we simply don’t realize the implications and if any existing functionality is going to be hampered (at worst).
#2) As you are short of time, by the time the development team is working on the implementation, you can note down the test cases roughly in tools like Evernote, etc. But make sure to write them somewhere so that you can add them later to the test case tool.
#3) Keep your testbed ready as per the implementation and if you feel that there are any red flags like some specific data creation if a testbed will take time (and it’s an important test for the release), then raise those flags immediately and inform your manager or PO about the roadblock.
Just because the client wants it asap, it doesn’t mean that QA will release even if it is half tested.
#4) Make an agreement with your team and manager that due to time crunch you will only communicate the bugs to the development team and the formal process of adding, marking the bugs for different stages in the bug tracking tool will be done later in order to save time.
#5) When the development team is testing on their end, try to pair with them (called dev-QA pairing) and do a basic round on their setup itself, this will help to avoid the to and fro of the build if the basic implementation is failing.
#6) Now that you have the build, test the business rules and all the use cases first. You can keep tests like a validation of a field, navigation, etc for later.
#7) Whatever bugs you find, make a note of all of them and try to report them together to the developers rather than reporting individually because it will be easy for them to work on a bunch.
#8) If you have a requirement for the overall Performance Testing, or Stress or Load Testing, then make sure that you have a proper automation framework for the same. Because it is nearly impossible to manually test these with a sanity test.
#9) This is the most important part, and indeed the last step of your sanity test strategy – “When you draft the release email or the document, mention all the test cases that you executed, the bugs found with a status marker and if anything was left untested mention it with the reasons” Try to write a crisp story about your testing which will convey everyone about what has been tested, verified and what has not been.
I followed this religiously when I was using this testing.
Let me share my own experience:
#1) We were working on a website and it used to popup ads based on the keywords. The advertisers used to place the bid for particular keywords which had a screen designed for the same. The default bid value used to be shown as $0.25, which the bidder could even change.
There was one more place where this default bid used to show up and it could be changed to another value as well. The client came with a request to change the default value from $0.25 to $0.5 but he mentioned only the obvious screen.
During our brainstorming discussion, we forgot (?) about this other screen because it wasn’t used much for that purpose. But while testing when I ran the basic case of the bid being $0.5 and checked end to end, I found that the cronjob for the same was failing because at one place it was finding $0.25.
I reported this to my team and we made the change and successfully delivered it the same day itself.
#2) Under the same project (mentioned above), we were asked to add a small text field for notes/comments for bidding. It was a very simple implementation and we were committed to deliver it the same day.
Hence, as mentioned above, I tested all the business rules and use cases around it, and when I did some validation testing, I found that when I entered a combination of special characters like </>, the page crashed.
We thought over it and figured out that the actual bidders won’t in any case use such combinations. Hence, we released it with a well-drafted note about the issue. The client accepted it as a bug but agreed with us to implement it later because it was a severe bug but not a prior one.
#3) Recently, I was working on a mobile app project, and we had a requirement to update the time of delivery shown in the app as per the time zone. It was not only to be tested in the app but also for the web service.
While the development team was working on the implementation, I created the automation scripts for the web service testing and the DB scripts for changing the time zone of the delivery item. This saved my efforts and we could achieve better results within a short duration.
Sanity Testing Vs Regression Testing
Given below are a few differences between the two:
S. No. | Regression Testing | Sanity Testing |
|---|---|---|
| 1 | Regression testing is done to verify that the complete system and bug fixes are working fine. | Sanity testing is done at random to verify that each functionality is working as expected. |
| 2 | Every tiniest part is regressed in this testing. | This is not a planned testing and is done only when there’s a time crunch. |
| 3 | It is a well elaborate and planned testing. | This is not a planned testing and is done only when there’s a time crunch. |
| 4 | An appropriately designed suite of test cases is created for this testing. | It may not every time be possible to create the test cases; a rough set of test cases is created usually. |
| 5 | This includes in-depth verification of functionality, UI, performance, browser/OS testing etc. i.e. every aspect of the system is regressed. | This mainly includes verification of business rules, functionality. |
| 6 | This is a wide and deep testing. | This is a wide and shallow testing. |
| 7 | This testing is at times scheduled for weeks or even month(s). | This mostly spans over 2-3 days max. |
Strategy for Mobile App Testing
You must be wondering why I am mentioning specifically about mobile apps here?
The reason is that the OS and browser versions for web or desktop apps do not vary much and especially the screen sizes are standard. But with mobile apps, screen size, mobile network, OS versions, etc affect the stability, look and in short, the success of your mobile app.
Hence a strategy formulation becomes critical when you are performing this testing on a mobile app because one failure can land you in big trouble. Testing must be done smartly and with caution too.
Given below are some pointers to help you perform this testing successfully on a mobile app:
#1) First of all, analyze the impact of the OS version on the implementation with your team.
Try to find answers to questions like, will the behavior be different across versions? Will the implementation work on the lowest supported version or not? Will there be performance issues for the implementation of versions? Are there any specific features of the OS that might impact the behavior of the implementation? etc.
#2) On the above note, analyze for the phone models also i.e., are there any features on the phone that will impact the implementation? Is the implementation of behavior-changing with GPS? Is the implementation behavior changing with the phone’s camera? etc. If you find that there’s no impact, avoid testing on different phone models.
#3) Unless there are any UI changes for the implementation I would recommend keeping UI testing on the least priority, you can inform the team (if you want) that the UI will not be tested.
#4) In order to save your time, avoid testing on good networks because it is obvious that the implementation is going to work as expected on a strong network. I would recommend starting with testing on a 4G or 3G network.
#5) This testing is to be done in less time but make sure that you do at least one field test unless it’s a mere UI change.
#6) If you must test for a matrix of different OS and their version, I would suggest that you do it in a smart way. For instance, choose the lowest, medium and the latest OS-version pairs for testing. You can mention in the release document that not every combination is tested.
#7) On a similar line, for UI implementation sanity test, use small, medium and large screen sizes to save time. You can also use a simulator and emulator.
Precautionary Measures
Sanity Testing is performed when you are running short of time and hence it is not possible for you to run each and every test case and most importantly you are not given enough time to plan out your testing. In order to avoid the blame games, it is better to take precautionary measures.
In such cases, lack of written communication, test documentation and miss outs are quite common.
To ensure that you don’t fall prey to this, make sure that:
- Never accept a build for testing until you are given a written requirement shared by the client. It happens that clients communicate changes or new implementations verbally or in chat or a simple 1 liner in an email and expect us to treat that as a requirement. Compel your client to provide some basic functionality points and acceptance criteria.
- Always make rough notes of your test cases and bugs if you do not have sufficient time to write them neatly. Don’t leave these undocumented. If you have some time, share it with your lead or team so that if anything is missing they can point it out easily.
- If you and your team are short of time, make sure that the bugs are marked in the appropriate state in an email? You can email the complete list of bugs to the team and make the devs mark them appropriately. Always keep the ball in the other’s court.
- If you have the Automation Framework ready, use it and avoid doing Manual Testing, that way in less time you can cover more.
- Avoid the scenario of “release in 1 hour” unless you are 100% sure that you will be able to deliver.
- Last but not the least, as mentioned above, draft a detailed release email communicating what is tested, what is left out, reasons, risks, which bugs are resolved, what are ‘Latered’ etc.
As a QA, you should judge what is the most important part of the implementation that needs to be tested and what are the parts that can be left out or basic-tested.
Even in a short time, plan a strategy about how you want to do and you will be able to achieve the best in the given time frame.
Smoke Testing
Smoke Testing is not exhaustive testing but it is a group of tests that are executed to verify if the basic functionalities of that particular build are working fine as expected or not. This is and should always be the first test to be done on any ‘new’ build.
When the development team releases a build to the QA for testing, it is obviously not possible to test the entire build and verify immediately if any of the implementations are having bugs or if any of the working functionality is broken.
In light of this, how will QA make sure that the basic functionalities are working fine?
The answer to this will be to perform Smoke Testing.
Once the tests are marked as Smoke tests (in the test suite) pass, only then will the build be accepted by the QA for in-depth testing and/or regression. If any of the smoke tests fail, then the build is rejected and the development team needs to fix the issue and release a new build for testing.
Theoretically, the Smoke test is defined as surface-level testing to certify that the build provided by the development team to the QA team is ready for further testing. This testing is also performed by the development team before releasing the build to the QA team.
This testing is normally used in Integration Testing, System Testing, and Acceptance Level Testing. Never treat this as a substitute for actual end to end complete testing. It comprises of both positive and negative tests depending on the build implementation.
Smoke Testing Examples
This testing is normally used for Integration, Acceptance and System Testing.
In my career as a QA, I always accepted a build only after I had performed a smoke test. So, let’s understand what a smoke test is from the perspective of all these three testings, with some examples.
#1) Acceptance Testing
Whenever a build is released to QA, smoke test in the form of an Acceptance Testing should be done.
In this test, the first and most important smoke test is to verify the basic expected functionality of the implementation. This way, you will need to verify all the implementations for that particular build.
Let us take the following Examples as implementations done in the build to understand the smoke tests for those:
- Implemented the login functionality to allow the registered drivers to log in successfully.
- Implemented the dashboard functionality to show the routes that a driver is to execute today.
- Implemented the functionality to show an appropriate message if no routes exist for a given day.
In the above build, at the acceptance level, the smoke test will mean to verify that the three basic implementations are working fine. If any of these three are broken, then the QA should reject the build.
#2) Integration Testing
This testing is usually done when the individual modules are implemented and tested. At the Integration Testing level, this testing is performed to make sure that all the basic integration and end to end functionalities are working fine as expected.
It may be the integration of two modules or all modules together, hence the complexity of the smoke test will vary depending on the level of integration.
Let us consider the following Examples of integration implementation for this testing:
- Implemented the integration of route and stop modules.
- Implemented the integration of arrival status update and it reflects the same on the stop screen.
- Implemented the integration of complete pick up till the delivery functionality modules.
In this build, the smoke test will not only verify these three basic implementations but for the third implementation, a few cases will verify for complete integration too. It helps a lot to find out the issues that get introduced in integration and the ones that went unnoticed by the development team.
#3) System Testing
As the name itself suggests, for system level, the smoke testing includes tests for the most important and commonly used workflows of the system. This is done only after the complete system is ready & tested, and this testing for system-level can be referred to as smoke testing before regression testing also.
Before starting the regression of the complete system, the basic end to end features are tested as a part of the smoke test. The smoke test suite for the complete system comprises of the end to end test cases that the end-users are going to use very frequently.
This is usually done with the help of automation tools.
Importance of SCRUM Methodology
Nowadays, the projects hardly follow the Waterfall methodology in project implementation, rather mostly all the projects follow Agile and SCRUM only. Compared to the traditional waterfall method, Smoke Testing holds high regard in SCRUM and Agile.
I worked for 4 years in SCRUM. We know that in SCRUM, the sprints are of shorter duration and hence it is of extreme importance to do this testing so that the failed builds can immediately be reported to the development team and fixed too.
The following are some takeaways on the importance of this testing in SCRUM:
- Out of the fortnight sprint, halftime is allocated to QA but at times the builds to the QA are delayed.
- In sprints, it is best for the team that the issues are reported at an early stage.
- Each story has a set of acceptance criteria, hence testing the first 2-3 acceptance criteria is equal to smoke testing of that functionality. Customers reject the delivery if a single criterion is failing.
- Just imagine what would happen if it was 2 days that the development team delivered you the build and only 3 days are remaining for the demo and you come across a basic functionality failure.
- On average, a sprint has stories ranging from 5-10, hence when the build is given, it is important to make sure that each story is implemented as expected before accepting the build into testing.
- If the complete system is to be tested and regressed, then a sprint is dedicated to the activity. A fortnight may be a little less to test the whole system, hence it is very important to verify the most basic functionalities before starting the regression.
Smoke Test Vs Build Acceptance Testing
Smoke Testing is directly related to Build Acceptance Testing (BAT).
In BAT, we do the same testing – to verify if the build has not failed and if the system is working fine or not. Sometimes, it happens that when a build is created, some issues get introduced and when it is delivered, the build doesn’t work for the QA.
I would say that BAT is a part of a smoke check because if the system is failing, then how can you as a QA accept the build for testing? Not just the functionalities, the system itself has to work before the QA’s proceed with In-Depth Testing.
Smoke Test Cycle
The following flowchart explains the Smoke Testing Cycle.
Once a build is deployed to QA, the basic cycle followed is that if the smoke test passes, the build is accepted by the QA team for further testing but if it fails, then the build is rejected until the reported issues are fixed.
Test Cycle
Who Should Perform the Smoke Test?
Not the whole team is involved in this type of testing to avoid the wastage of time of all the QA’s.
Smoke Testing is ideally performed by the QA lead who decides based on the result as to whether to pass the build to the team for further testing or reject it. Or in the absence of the lead, the QA’s themselves can also perform this testing.
At times, when the project is a large scale one, then a group of QA can also perform this testing to check for any showstoppers. But this is not so in the case of SCRUM because SCRUM is a flat structure with no Leads or Managers and each tester has their own responsibilities towards their stories.
Hence individual QA’s perform this testing for the stories that they own.
Why Should We Automate Smoke Tests?
This is the first test to be done on a build released by the development team(s). Based on the results of this testing, further testing is done (or the build is rejected).
The best way to do this testing is to use an automation tool and schedule the smoke suite to run when a new build is created. You may be wondering why I should “automate the smoke testing suite”?
Let us look at the following case:
Let’s say that you are a week away from your release and out of a total of 500 test cases, your smoke test suite comprises of 80-90. If you start executing all these 80-90 test cases manually, imagine how much time will you take? I think 4-5 days (minimum).
However, if you use automation and create scripts to run all 80-90 test cases then ideally, these will be run in 2-3 hours and you will have the results with you instantly. Didn’t it save your precious time and give you the results about the build-in much less time?
5 years back, I was testing a financial projection app, which took inputs about your salary, savings, etc., and projected your taxes, savings, profits depending on the financial rules. Along with this, we had customization for countries that depend on the country and its tax rules used to change (in the code).
For this project, I had 800 test cases and 250 were smoke test cases. With the use of Selenium, we could easily automate and get the results of those 250 test cases in 3-4 hours. It not only saved time but showed us ASAP about the showstoppers.
Hence, unless it is impossible to automate, do take the help of automation for this testing.
Advantages And Disadvantages
Let us first take a look at the advantages as it has a lot to offer when compared to its few disadvantages.
Advantages:
- Easy to perform.
- Reduces the risk.
- Defects are identified at a very early stage.
- Saves effort, time and money.
- Runs quickly if automated.
- Least integration risks and issues.
- Improves the overall quality of the system.
Disadvantages:
- This testing is not equal to or a substitute for complete functional testing.
- Even after the smoke test passes, you may find showstopper bugs.
- This type of testing is best suited if you can automate else a lot of time is spent manually executing the test cases especially in large-scale projects having around 700-800 test cases.
Smoke Testing should definitely be done on every build as it points out the major failures and showstoppers at a very early stage. This applies not only to new functionalities but also to the integration of modules, fixing of issues and improvisation as well. It is a very simple process to perform and get the correct result.
This testing can be treated as the entry point for complete Functional Testing of functionality or system (as a whole). But before that, the QA team should be very clear about what tests are to be done as smoke tests. This testing can minimize the efforts, save time and improve the quality of the system. It holds a very important place in sprints as the time in sprints is less.
This testing can be done both manually and also with the help of automation tools. But the best and preferred way is to use automation tools to save time.
Difference Between Smoke and Sanity Testing
Most of the time we get confused between the meaning of Sanity Testing and Smoke Testing. First of all, these two testings are way “different” and are performed during different stages of a testing cycle.
| S. No. | Smoke Testing | Sanity Testing |
|---|---|---|
| 1 | Smoke testing means to verify (basic) that the implementations done in a build are working fine. | Sanity testing means to verify the newly added functionalities, bugs etc. are working fine. |
| 2 | This is the first testing on the initial build. | Done when the build is relatively stable. |
| 3 | Done on every build. | Done on stable builds post regression. |
Given below is a diagrammatic representation of their differences:
SMOKE TESTING
- This 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 or smoke. In the software industry, this testing is a shallow and wide approach whereby all the areas of the application without getting into too deep, is tested.
- The smoke test is scripted, either using a written set of tests or an automated test
- Smoke tests are designed to touch every part of the application in a cursory way. It’s shallow and wide.
- This testing is conducted to ensure whether the most crucial functions of a program are working, but not bothering with the finer details. (Such as build verification).
- This testing is a normal health check-up to the build of an application before taking it to test in-depth.
SANITY TESTING
- 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.
- This test is usually unscripted.
- This test is used to determine that a small section of the application is still working after a minor change.
- This testing is cursory testing, it is performed whenever a cursory testing is sufficient to prove that the application is functioning according to specifications. This level of testing is a subset of regression testing.
- This is to verify whether the requirements are met or not, by checking all the features breadth-first.
Hope you are clear about the differences between these two vast and important Software Testing types. Feel free to share your thoughts in the comments section below!!
Was this helpful?
Recommended Reading
-
A Complete Overview of Positive Testing: This tutorial will give you a brief introduction to one of the most prominent testing types: Positive testing. Software Testing is in the process of verifying and validating the software and confirming that it is working as expected. A software tester should have the…
-
Learn about the two important testing techniques Static Testing And Dynamic Testing and the differences between the two: Testing is Verification and Validation. We all know that it takes 2 Vs to make testing complete. In today’s article, we will shed some light on Static testing. It is also called…
-
Build Verification test is a set of tests run on every new build to verify that build is testable before it is released to test team for further testing. These test cases are core functionality test cases that ensure application is stable and can be tested thoroughly. Typically BVT process…
-
Read This Informative Article to Understand the Differences Between Manual Testing Vs Automation Testing Along with Scenarios Where Automation Can be Used: Software Testing is the process that is carried out throughout software development. It is the process of checking, verifying, and validating the requirements of the product. We are…
Hi Ajay,
Your real-time example sounds good!!! Gr8 work!!!
Hi Selvam,
is good 2 do course…..ther r giving placements also…..
hi,
i want to posible test case about insurance application.
pls give me information ab that domain.
Smoke is scripted means the set of instructions or test cases to perform this testing will be written before take action.
Sanity is unscripted means the set of instructions or test cases to perform this testing will not be written
Hi all,
Thanks a lot for clearing the difference between both the testing.
Dear All,
There was one more term Coined in Software Testing industry “Smart Regression”
Regression Testing: Regression testing means rerunning entire set of applicable test cases from existing test suites to ensure that software changes have no unintended error seeding and ensure the 100% stability of the software. Mostly this technique used for automotive testing
Smart Regression Testing
==================
Smart Regression means testing particular test cases which selected based on the bug fixes impact analysis, after discussion with relevant development team. To support this type of testing sanity check is mandatory to ensure overall is perfect / not effected.
Which will be very useful in practical situation where time matter more.
Jayakumar.N(JK)
Love All Serve All
winjayakumar@gmail.com
India
thank you so much.
hi guys,
The simplest way to do smoke and sanity check on human being. Just think the requirement tell that human should run and perform some action using hand.Then the smoke check will be just check his legs by moving that it works fine, same way for hand . So by this we can make sure that if he have working hand and leg, then he can perform the task of running and some task using hand .Then he can be sent for sanity check , which involves him to to run, do work etc.
If at starting itself we found that he does not have leg, then need not for sanity check.
hope this makes much clear.
this is very nice site where i learn lot about testing. thank you….
Can anyone give me the example of smoke and sanity check related to website testing? What parameters of website will be tested for both the testing?
thank u sir.
giving us the valuable information.
Hi Ilyas,
i’ll recommand that u get some certification from australia instead of getting from India….may be in australia it’s costy and that certification will have worth in india…
there are lot of testing certification but i recommand that u get certification in QTP (Quick Testing Professional) and some Mercury testing tool available.
very nice & easily
On one hand you say sanity is deep. Then you say it is cursory.
Those who all are having difficulty in the understanding difference between both the testing can read this. Let’s take an example of a mobile phone.
Smoke : Here, we don’t go much deep and cover major functionalities like on/off, msg, calling, internet, homepage etc..
Sanity: Here, we choose only a few functionalities like setting, contacts etc and do a deep testing.
Another example:
If you visit a doctor for a general health checkup(height, weight, blood pressure, blood test etc), then it is called as smoke testing.
But if you visit a doctor for a particular problem like fever, then it is called as sanity.
Nice explanation…but when to use what?
Thank you..!!
The word “priority” is associated with scheduling, and the word “severity” is associated with standards. “Priority” means something is afforded or deserves prior attention; a precedence established by urgency or order of or importance.
Severity is the state or quality of being severe; severe implies adherence to rigorous standards or high principles and often suggests harshness; severe is marked by or requires strict adherence to rigorous standards or high principles. For example, a severe code of behavior.
The words priority and severity do come up in bug tracking. A variety of commercial, problem-tracking / management software tools are available. These tools, with the detailed input of software test engineers, give the team complete information so developers can understand the bug, get an idea of its severity, reproduce it and fix it. The fixes are based on project priorities and severity of bugs. The severity of a problem is defined in accordance to the end client’s risk assessment, and recorded in their selected tracking tool. A buggy software can severely affect schedules, which, in turn can lead to a reassessment and renegotiation of priorities
Thank u
@ Ajay,
“If the smoke comes out, the pipe can be used as Testable pipe.( Build is testable for further testing). ”
What do we do if the smoke do not come out of the pipe? Can you elaborate more on Smoke check?
Regards, Suhas M.
Thanks vijay, GRT JOB done…i really was confused and now i am confident about it….keep it up…..sir
Hi yogesh sakhare,
we do both these testing when dont have enough of time for testing d Application deeply…its mainly for time saving…we wil test crucial functions of application & give conformance abt whether application is ready for further testing process….
Thanx a lot, Very nice explaination.
Doing a great job
keep it up.
Can any one tell, who does smoke and who does sanity?
In my prodcut, testers does smoke(soon after new version(say previous it was 8.3.1 now when 8.3.2 with new enhancements) of application is given for testing)..but never heard word sanity while testing.
Dear Friends,
This is not like Mathematics, Software Testing Definitions can be created by ourself. As far as i’m concern
Smoke :
=========== is nothing but Once a build came for testing – Before Test Engineers execute their Testcases they done a Positive Flow of Functional Test for the entire application and confirm whether the Application is “FIT FOR TESTING”. If its thru then only Test Engineers will start executing the Testcases.
Sanity:
=========== is similar to Smoke Testing but here once the Test Engineers complete their Retesting or Regression and confirm all the issues were closed. Either they will run all the testcases once again or they do functional test on positive flow on the entire application and verify whether the application is
“FIT FOR RELEASE” or “FIT FOR BETA TESTING” – after confirming that only Testing Team will certify the application for Beta Testing.
I May be wrong but i used to follow it on my own way to manage my team.
Best Regards
Nanda – 9884417981
nandakumar_snk@yah00.com
it really helped man…….thanx a lot !
Explanation is realty good and helpful too.
Hi I am a bit not agree with the sanity definition,
When developer delivers a build for testing at the time smoke comes into picture, smoke helps developers to determine Is this build is working fine and ready for testing, if it pass then it goes to testing team …now developer end is satisfy after smoke that build is healthy enough to test. once the build goes to tester end, testers perofrm sanity on it to recheck the build is healthy enough for further testing, if it pass then testers contineous on the same build but if it fails then testers revert back this build to developers in a very polite manner 🙂 ..This is all about from my end.
FYI : Might be i am wrong so do not believe what ever i written above and please put you views on it.
difference between smoke and sanity :-
SMOKE :-1) smoke was TESTED by TEST LEAD
2)smoke means testing the MAIN MAIN modules of the soft ware.whether the soft ware is working or not checking from first screen to last screen
sanity :- after real test was passed in sanity the testers can test the new soft ware in different modules whether the s/f is working r not
re-gressive test:-modifying a new soft ware with out any side effects
I’m pretty sure there’s a typo here and the word “not” (which I capitalized for emphasis) should be deleted:
“Never accept a build for testing until you are NOT given a written requirement shared by the client.”
very good and useful descriptionm…………….
Can any one provides basic Information and techniques on “Testing Metric” (what are the test metrics and how to prepare the metrics”
Thanks
Ravikumar.N
Bangalore
nmravikumar32@gmail.com
Good explanation. I cleared confusion now. Thank you.
good definitions
Nice one 🙂
NICE EXPLANATION OF SMOKE & SANITY check ..
PLZ SOME ONE TELL ME HOW TO BUILD DIFFERENT TEST CASES LIKE ROBUST..ETC
Can you tell me how to document sanity for future reference?
my mail id is – krishatreya.mys@gmail.com
hi… m a tester working in a s/w firm in mumbai..ma fresher with some months of experience bt with good communication skill and crisp knowledge on testing concepts.I need to relocate to pune can any one suggest me regarding any opening or any other source?plz do help me.my email id is “choudhurynamrata@yahoo.com”
Regards.
Hi All
thanx a lot for u all. this is right place where v can clear our doubts. thanQ ery much
Really good one….
@ Ajay,
Well done… nice example
Thnks 🙂
u have put all the points very nice..
I got correct answers for my questions..
Really superb…..
difference between sanity and retesting
Hi All,
There is no diff between both these testing. Both are same. whenever we get new release to test, We do both the testing for some time say 1 hour to test whether all major functionalities are working fine or not. It helps QA team to accept/reject new build immediatly.
Thanks You
THANX FOR THIS LUCID EXPLAINATION !!
hai, this is sagar
Severity–>Blocker,Critical,Major,Minor,Trivial(impact of bug) .
Priority—>Urgent,High,Medium,Low(how it should be fixed)
Hi, i am fresher interested to get software certification plz any one can help me regarding it
@ Yonca
you really gave a comprehensive detail about “bug life cycle” ,,thx for sharing your knowledge .
what is smoke check. when will we do it.
Can you please explain about banking domain modules and bug examples.
Wrong Explanation for Sanity Testing..It is Deep and Narrow instead of shalow and wide…
can i know more about the examples of severity and priority????
thank you so much….
Nice Explanation.
To Tuyen & Sudeepa
Smoke Test: This will de done after receiving the build. Just like browsing the application
Sanity Test: This will be done mostly after Retest (Retest will be done after fixing the bug).
This is very useful for understanding the flow.
gone thru CSTE set of questions unable to understand 1 question types of regression check? can someone elaborate?
Ajay,… I have gone throgh with such example from other website. Kindly, let us know the name of that website.. , so that all can take help from there. I am forgetting the name of that site. 🙂
It is very helpfull for me,
Thanks buddy…
Can Specify one thing ?
Who do smoke check?
Who Do the Sanity check?
Very clear and understandable explanation.. Thanks.
Hi, Smoke has to be done first and then Sanity.
Hi All,
Thanks a lot for participate…..
Its really very nice.
Really it is very useful thank you so much.
Hi Vijay,
can you please clerify me on below point ?
If we have to do sanity so should we have to write test case for sanity of specific (respective) feature ?
or we have to run same Test case ??
If i will run same Test case for sanity then it will surely take time .
and even if i write seperate sanity test case for each feature of my application it will also take time
So how to do sanity ???
can we do sanity without writing Test case (as sanity is unscripted)
or what is proper way to so sanity .
please let me know as soon as possible.
Thanks,
Sachin
which part u feel that is not understandable by u , kind high light that part, i try level my best i can give u good example thx,
If any other person wana ask any Question, plz feel free to ask………….thx
Every thing is fine, from the above definition it is clear that tester takes all the precautions & initiatives to make software bug free than why Beta testing is required. (Might be this question appears to be funny but try to thing indepth) for an example: very kiddish bugs are associated with google chrome (browser), I believe tester or developer completely left on user to find out; otherwise it could be caught very easily by putting honest effort. (saurabhmishra007123@indiatimes.com)
Hi friends i am new to testing i have a lot of interest to learn the testing tools so any one give the suggestion how can i follow the steps and improve my skills now i am in us and if anybody know the website and certification sites plz tell me
thank you
good answer…
thanks…
I have one question. What is Asile Testing.
hi all
i saw ur answers regarding testing tools i am appreciate a lot , can u help me out .
Right now i am in australia pursuing diploma in computer field but not related to PR so i am deciding to comeback to india (some family problem) and do some course in testing tools what u think , i have some knowledge about computers i have done Bsc (2005) after that i am not taken any interested in doing job in india wasting my precious time by going abroad. I am 29 now i am sorry what i have done. Can u please suggest me that its good to do testing tools on this age.But i know that its difficult for me to go form the scratch but i can do, if u suggest good reply for my future.
By reading all this u get the idea what guy i was,from the bottome of my heart i am very regret what i have done, Now i am realised that how important the career is please please suggest me what to do , i am interest in computers field.
Thanks for ur preciuse by reading this.
One important think my english also not so good .
Hi kokila,
Thanx for ur reply.would like to know whether STC giving placement assurance?????????
also i had heared that their way of training is highly theory oriented,but i am looking for practical oriented training……….
Nice one, thank you!
Hi friends I have a question ,is the smoke check can be done to check whether all main functionality are working properly after the final release .
Hi Priya,
The answer of your question is
Generally we follow release cycle in our current organization. It deals with all SDLC phases.
To get completion of release cycle we would have atmost 20 days.
why automation tools are not used for sanity check ?
cause you cannot automate 100%
Well, every project/customer uses his own terms based on his own habits.
If you refer to ISTQB glossary, both terms have the same meaning (altought I don’t necessarily agree on this point like most of you but it’s only due to my own experience).
IMHO the main difference resides in the strategy you apply to each subset of test (smoke, sanity, regression…).
If failed sanity checks doesn’t lead to any exit criteria, does it even worth giving them a name or another ?
On the other hand, if any failed test during smoke check leads to build/release rejection, then it woth defining the term and specifically follow and report the associated results.
if target of 450 cases assigned to an test engineer and the deadline of 8 hours how he can execute and finish it
this is a nice explanation i foudn on the www till now, i really liked this but one point is confusing is that you have suggested above in both type the “cursory way point”, i dont understand what exactly you mean to say.
It’s a nice artical to avoid big confusion.. thank you Vijay.
Your explaination is very concisely.
Thanks you so much
One point about the Sanity Testing says that testing is narrow and deep. Another point says that Sanity tests check whether the requirements are met or not, by checking all the features breadth-first. These two points seem to be contradictory, because checking all the features breadth-first would seem to be a wider view, not a narrow one.
Did I misread these points?
Thanks for explaining the difference. but some points are missed.
hi m amna….m recently join software testing……pls tell me detail abt regression n integration testing.
WOW !!! gr8 job. worth reading the difference… learn a lot….
hi banu,
RE-TESTING: say when a defect is raised for functionality, for that a fix will be given, so we will re-test the functionality again and close if there’s no bugs arise.
REGRESSION : say your testing phase contains 3 cycles of testing and you found 100 defects over-all for a given binary in two cycles. And you retested all the defects. You will do one more cycle considering only those defects as major functionality to ensure the binary is bug free.
@Srilaxmi,
Automation Testing: here we are giving some instructions to the tool to test the application.(whether the application is web application or window’s.)
Functionality: here we are Testing the specific field to check whether it is working correctly are not.
Thank u for clearing my doubts
hi mallik,
smoke check will be conducted twice in a life cycle,that is before developer release the build,then it will be conducted by the testers once they get build for testing…
if its wrong,forgive me..
Thanks for clearing my doubts..
now i clearly understood the exact difference between both the testing
Dear friends,
Whenever you are posting a comment, Please mention your mail address, so that it will be easier for others to contact the individuals to clarify or clear the issue.
Regards
Nanda
( s.nandakumar@sify.com )
Developers do smoke checks before releasing the build to the testing team
testers do sanity check to accept that build
testers again do smoke check (final regression Test) to send the appication to UAT
(Sanity check)
Developer——>tester———>UAT
(Smoke check) (Smoke check)
Finally smoke check can be performed to send the application into later stages. Sanity test is to accept the build from development team.
@ saroj – scripted means : there is a definite set of scripts, either given by designers, or BA’s, or by testers themselves, which are designed keeping in mind the functionality to be tested and intend to check the results in a true/false way (expected/actual). They are planned.
Unscripted means – Random and unplanned, there is no definite set of tests and tester can use his/her versatility/ imagination/ experience to think of ways or scenarios to test the functionality.
Got a handsome amount of information in testing.. Keep going…
This article is very nice and informative.
Guys,
Do enlighten me about Microsoft’s team foundation?(is it a tool, which is as simple as testdirector or quality center?)…is it more like a tool for managing defect(manual testing)…let me know asap.
well explained…..Thanks a lot
i am still confuse about smoke ,sanity and regression testing smoke means checking imp and basic functionality of application and after that we do sanity testing i got confuse here are we checking same functionality or diff on the other hand they said sanity testing check when we add new functionalty check this is stable or not so on the new bulid so here what should i do on first build
Very bad
I want to know about smoke check
Nice post Vijay keep on good articles on posting.
Hi All,
How many times smoke test is conducted throughout the life cycle?
Thnx
Really nice…….. 🙂
in the intergration level testing we have top – down approach and bottom up approach,
in the top down approach, first the parent module is created and then the child module is created. in this approach, they write some temporary programs or linking programs also callld interfaces, these temporary programs in top down approach are called stubs
in the bottom up approach the child modules are created first, then the parent modules are created.
the temporary programs written for linking the child and the parent modules are called drivers.
what is bug life cycle ?
nice article
Hi friends ,I am in USA and I don’t have any experiences in testing and I had complected my BTech in computer sciences from Kerala and I need some help
would any of you like to help me? please send me some different type of test cases and test plans and details of different automated test tool that are commonly used i’ll be very thankful…please send these details to my Mail ID :Thomasjos9746@gmail.com
Hi Thomas,
have you searched this site for test cases, test plan details? if not I’ll suggest to use our search tool located at top right corner. We have some good articles on writing effective test cases and test plans with sample templates for each.
For automation testing start with QTP or Selenium. Again we have a in-depth QTP tutorial series you may want to take benefit of.
Regards,
Vijay
Nice explanation……………..Thanks
smoke is a testing to test the major functionalties of the application for further testing
Retesting: Performing testing on the same functionality again and again with different sets of data is retesting.For EG:testing the login button with different sets of username and password.
retesting starts from the first build and can continue till the last build
Regression Testing: Here testing is performed on the already tested functionality again and again.
2 scenarios of regression testing:
1.After correcting the defects when the next build is released, checking the functionality of the defect as well as the related functionality.
2. whenever new features are added in the next build , checking the already tested and related features of the new features.
Regression testing starts from the second build and can continue till the last build
Laxmi
all I know about testing and tools + SQL…other needs.
Try it easy and free.
Senior Test Lead
Yonca
When you compare Regression and Sanity testing you say that Sanity testing is “shallow and wide”, but when you compare Smoke and Sanity testing you say Sanity testing is “narrow and deep”. Are both correct?
Clear Explanation, Thanks
Hi all,
It is really gud place to clear all our confusion……!!!
hi guys i am sayee working as a QA..if u have any doubts Regarding manual Testing please ask me ..i will give my best answer…
sai_it06@yahoo.com
Hi Friends,
Currently i am working in Non-IT field and planned to switch my career to testing.I had learned the basics of testing,and now i am very eager to learn testing practically with real time projects.
If any one interested to teach testing personally with real time projects , i will be more grateful, or else show me the right place in pune
Thanks & regards
hi amit
u r ans is good thanks for clearing my doubt
Thank you so much for all you guys helping me to understand it clearly.
What is the difference between smoke and unit testing
unit testing is generally performed by the developers. in this, they isolate each section of the code and check its correctness whether it is working fine or not.
smoke testing is performed by the testers. in this, we generally check the critical functions of the software,whether they are working fine or not. for eg, check the login functionality, verify the app launches successfully, check the gui is responsive or not.
I disagree. It has no sense to execute Smoke tests (testing of the only critical scenarios) by testers when they has been testing new functionality on more detailed level anyway. Smoke tests should be done by developer to check quickly if a new piece of solution is working or not on DEV environment and it is ready for deploy and further deeper testing on TEST environment. For example, when developer add some new function to existing invoice form then he will at least try to create and save new invoice long with usage of the new function.
vijAY,
nice copy paste from other web page answers ….
Smoke and Sanity are not the standard terms from the software world,even IEEE and SEI dont consider and define them so definion really differs on the agreement made between the stakeholders
whaat the important of smoke check in testting
thanks clear my point, but tell me what is the use of both these testing.
To Hello:
Retesting: To ensure that original fault has been removed from an application. It is performed whenever the detected fault has been fixed.
Regression testing: To check that modified system still meets it requirement. It is used whenever the software and it’s environment changed.
Its really very nice differentiate between smoke and sanity check. Its very useful for software testers.
as we used to say that testing types are black box testing,white box testing ,grey box testing,hybrid testing.Rigth.And we used to sya that testing techniques are this that ……..lots and lots techniques.But somewhere we see that functional testing,structure testing,unit testing,integration testion testing considered an main testing techniques and under these techniques lots of testing comes.So basically how many techniques are there for testing.please explain me in brief.
A very nice post and very helpful comments
thanks for good explanation
thnx
Its a fine to clearing the doubts…
hi, can you tell me about , why testing is nessary
Nice … very nice
finaly i got the difference
thanks
hi all
i saw ur answers regarding testing tools i am appreciate a lot , can u help me out .
Right now i am in australia pursuing diploma in computer field but not related to PR so i am deciding to comeback to india (some family problem) and do some course in testing tools what u think , i have some knowledge about computers i have done Bsc (2005) after that i am not taken any interested in doing job in india wasting my precious time by going abroad. I am 29 now i am sorry what i have done. Can u please suggest me that its good to do testing tools on this age.But i know that its difficult for me to go form the scratch but i can do, if u suggest good reply for my future.
By reading all this u get the idea what guy i was,from the bottome of my heart i am very regret what i have done, Now i am realised that how important the career is please please suggest me what to do , i am interest in computers field.
Thanks for ur preciuse by reading this.
One important think my english also not so good
u can contact them…
I have doubt for when will do smoke and sanity check?can any one clear my doubt and give me example and perfect description for sanity check?
before we understand what is sanity / smoke, we need to understand what is Build Acceptance Testing.
Build acceptance is a type of testing in which the test engineers would perform testing on the application, before accepting it for a detailed testing.
they would observe if the application can be installed on the test environment.
if they able to navigate through the pages of the application.
if the features of the application are working fine.
however there is a contraversy, saying BAT ( Build acceptance Testing), smoke and sanity check are all the same.
people also say that there is a small difference between both the testing.
smoke check is done by developers or white box testers, before releasing the build.
Sanity check is done by the test engineers before accepting the build.
Thanks for explane about both the testing.
Manish Kumar
Smoke check is done by developers before the build release or by tester before accepting a build for futher testing. Sanity check is mostly done only by the tester.
A very nice site for testers
What does it mean by narrow regression in sanity ?
great explanation.
It is great site to clear doubts.
can any one explain me hw to plan the testing process or procedure in the company
Difference betwwen Smoke and Sanity check
Take an example:
Consider a hollow pipe and you have to check whether it is good for
circulation process or can it be used for the supply process:
Smoke check:
First we have to check whether the pipe allows to flow from end to
other end. Pass the smoke to the pipe and check whether the smoke
will come out of other end.
If the smoke comes out, the pipe can be used as Testable pipe.( Build
is testable for further testing).
Sanity check:
Now allow water(liquid) to flow in the pipe, and check whether there
is any leakage in the pipe.If the water comes out in the between the
pipe, so detect the leakage and assigned to developer for fixing it.
So Smoke Test should be applied first, and then comes the Sanity
Testing.
Please correct me if you are not satisfied with answer.
Very good explanation… Thanks
Great insights there and thanks for sharing them!
It’s clear to me that smoke testing is entirely subjective and there’s a broad-range of how to interpret it.
If we go back to what smoke testing means for electronic products, it means turn the power on for a few seconds. Watch to see if the magic smoke comes out of the device. If it does, the device is effectively trash.
I have so many concerns around interpretations of the kinds of tests we have. What is a smoke test, what is a functional test, what is a system test, etc. The lines are blurry. What makes it even blurrier is when a test can be any combination of those kinds of tests.
To keep things simple, for me a smoke test is as simple as “if I can start the service, and it can reach the database and endpoints it needs to, then we’re good”.
A sanity test is more along the lines of “If I go through a specific user-journey, do the important data items have the right values?”
A functional test is “when I do x, do I get y back”?
There’s also Contract Testing which checks that the interface between two systems are consistent from a consumer’s perspective.
While I think it’s great that we can classify all these tests, I think it’s more important to ensure that our automated tests provide value. When they’re flaky (sometimes pass, sometimes fail), then there’s something the code is doing which we don’t understand. Pay attention to these ones as they are identifying very subtle idiosyncrasies in the implementation, or the test itself!
Smoke tests should be light on execution time. Sanity tests should be relatively light on resources.
There’s no right or wrong way, but I think being smart what needs testing where takes great care, skill and planning. Otherwise it will become a mess.
I have one more question “What is meant by scope of test plan and how to decide the the test plan scope .
Thanks,
Ravikumar
You said sanity is “Done on stable builds post regression.” I am sorry! But this actually contradicts understanding created above the article. “Post regression” is actually confusing. Regression is done after sanity is done.
Hi it’s very useful.
Are smoke and sanity lies in Black box?
Correct!
Smoke! Sanity! BVT! BAT! Ahh, well… Here is a testing story, which I had written almost a year back that tries to clarify these terminologies. Anybody, in case interested can take a look here
Happy Testing…
-Debasis
I think u hav solved the problem of confusion….
Very nice……thank u very much.
the smoke and sanity check is functional or non functional testing
hello author i am esteem reader of your tutorilas .plz provide a sample application and then provide testcases for smoke & sanity check, regression testing,retesting. so that we get realtime experience
what is operational testing?
1) code based
2) logic based
3) function based
4) fault based
confirm if option 3 is correct or not
Thank u Jyothi for clarifying post 100.
Veena.
Thanks
for this nice explaination.
now i clearly understood the exact difference between both the testing
Other than the subject expertise you provide in your posts, what I especially appreciate is the level of editing leading to idiomatic and error-free content that is a delight to read.
We in india often neglect this as can be seen all over the web wherever users create content.
Keep up the good work.
Dear Kavitha,
SDLC-S/w Development Life cycle
This cycle includes the complete phases involved in s/w developing.
The phases are:
Requirement Phase
|
Design phase
|
Coding Phase
|
Testing phase
|
Implementation phase
Requirement Phase—–Here we gather requirement for the project…by preparing URS\BRS,etc.
Design—–Once SRS is prepared then we start with design phase ,,we wld prepare detail design..SDD doc.
Coding—-we wld do coding for that design document.
Testing—Testing the application to find out the adherence of standards and requirement of the client.
Implementation Phase—Here the application goes live…End user wld start to use the application..User manual wld be prepared.
I hope ur doubt is been cleared nw…if need to knw more ..pls let me knw..
smoke is a testing to test the major functionalties of the application for further testing
It is done by testers but somebody i mean my Trainee explained me some times smoke check is performed by Developers and sanity check is performed by Testers and what is sanity check
please explain Difference between smoke and sanity
santhoshhe60@gmail.com
Hi ,Vijay
I have a question ,is the smoke check can be done to check whether all main functionality are working properly after completing all testing and after the final release .
Your explaination is very clear&crisp.
Thanks you so much…..
@ Manoj – Very good explanation friend, Thanks.
hi,
very nice answer…..but still some confusion…….
thankyou sir..
thanks for the valuable explanation . But can someone plz explain what is scripted and unscripted
thanks in advance
verification: It is a process of checking conducted on each and every role in the organization, right from the starting of the process till the end of the process in order to confirm whether all of the roles are working according to the company’s guidelines. Done by Quality assurance team.
validation:validation is a process of checking conducted on the application or its related parts in order to confirm if they are working according to the requirments. Done by the blackbox and whitebox testers.
wow how nicely u have explained everything here.
Severity :- On 29th Feb 2012, system gets crash but we have time to fix this issue though system is getting crash. Defect will consider as severe defect but it’s proirity is low.
Priority :- Client’s company name is mis-spell on first page. Though System is not getting crash so this issue is not severe defect but It has to fix on first priority since it will give wrong message to client.
it is easily understandable
hi,
could you please give any example
smoke is a testing to test the major functionalties of the application for further testing
It is done by testers but somebody i mean my Trainee explained me some times smoke check is performed by Developers and sanity is performed by Testers and what is sanity check
please explain Difference between smoke and sanity
This is good article but i have one question in mind.
I have read that now smoke and sanity checks are mix and they become the one test.
Is it True.
Please Clear my doubt
Hi All,
I have Mentioned What is Smoke and Sanity check as well as difference between Smoke and Sanity as given below:
I have gathered a few points about the difference between smoke and sanity check from the responses of two software testing groups. I have added the points below.
However, my experience of executing both these testing has been the following:
Smoke check:
When a build is received, a smoke test is run to ascertain if the build is stable and it can be considered for further testing.
It can be done for testing the stability of any interim build.
It can be executed for platform qualification tests.
Sanity check:
Once a new build is obtained with minor revisions, instead of doing a through regression, a sanity is performed so as to ascertain the build has indeed rectified the issues and no further issue has been introduced by the fixes. Its generally a subset of regression testing and a group of test cases are executed that are related with the changes made to the app.
Generally, when multiple cycles of testing are executed, sanity testing may be done during the later cycles after through regression cycles.
Smoke
Sanity
1
Smoke check 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 check is a shallow and wide approach whereby all areas of the application without getting into too deep, is tested.
A sanity check is a narrow regression test that focuses on one or a few areas of functionality. Sanity check is usually narrow and deep.
2
A smoke check is scripted–either using a written set of tests or an automated test
A sanity check is usually unscripted.
3
A Smoke check is designed to touch every part of the application in a cursory way. It’s is shallow and wide.
A Sanity check is used to determine a small section of the application is still working after a minor change.
4
Smoke check 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 check 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 check.
5
Smoke check is normal health check up to a build of an application before taking it to testing in depth.
sanity check is to verify whether requirements are met or not,
checking all features breadth-first.
Thanks,
Suresh
bsuresh7282@gmail.com
hai all,
iam raghavendra and i hav done the software testing in bangalore and i hav completed diplomo in computer science (10+3),and my friends are telling that i need to hav the graduation for eligible to hav the software testing job but iam persuing the BCA graduation and can u please let me know whether i need to hav the graduation for eligible to hav the testing job or diplomo will be eligeble can u please let me know that…
thanks a lot guys pls send me req am learning testing v can chat if v hav quries on testing
tis site is very helpful thanks a lot
my fb name is—– Rahul Bajaj
Thank u 🙂
Please can any one tell me in detail about the sdlc cycles???
Can any one tel me about “risk analysis”……
Hi Selvam and ilyas,
s/w testing training center is good 2 do course…
@Rakesh
Thanks Rakesh,
I have tried to explain in terms of terminology used -> Smoke and Sanity check
nice answers..
Thanks so much
Hi, All
I have mentioned Difference between Regression check and Re-testing as given below:
Regression: We can conduct the test on a modified build to ensure the bug fix work and occurence of side effects in that build.
Retesting: We can do the test on a build to ensure the correctness of the modified functionality.
Thanks,
Suresh
bsuresh7282@gmail.com
please help me to know what is the differences between regression and re-testing
I have one question for this topic:
When do we use smoke testing? And when do we use sanity testing?
Hi,
I was shifted from dev to testing right now i am in Automation side could u pls suggest me what skills are required for me to learn fast .thanks
This site is very good. i got each and every answer very detail.
Hi friends
what is tress structure,
what is the difference between functional testing and automation testing ,functional automation testing ,when we use,and advantages
could u pls give example
Hey Unknown,
Just FYI: Its a good platform to get understand about different things. Its not about the copy rights.
Whenever we post any articles, the source could be any of the standard books or web sites or from our past experience.
Hence, I would suggest you to pick the knowledge rather discussing about copy rights.
Don’t take it otherwise.
Regards,
VijayD
very nice explanation
@Vardhan,
hello vardhan,
i heard smoke & sanity are same.
if suppose it differs the definitions which u given are right , but u given smoke definition to sanity and sanity to smoke, i think so. sorry if im wrong.
Thanks…Now I understand the difference between both the testing
Smoke :-
*This is the first testing conducted on build we get.
*What we do-
Run basic set of test cases that should be passed before that product goes for further testing.
*Black box testing
*Tester/QA.
Sanity:-
*Test the readiness of the s/w.
*When we do this testing–
Once the developer develops the source code,before putting into the source depository.
*What we do-
Basic requirements of project are tested.
What is the difference between priority and severity?
Hi Jyothi Please let me know what is smoke check
Thankyou everyone for their excellent opinions.
Really good.
Thankyou.
Can anyone please get me a job in Software Testing?
I am really very good at manual testing.
I am trying from past 1month for job, not a able to get.
Please help me….
Hi, I watched one of the videos on smoke and sanity check by softwaretestinghelp.com. This article and that video have contradictions.
What is the major difference between sanity and regression testing? ?
We use the term “sanity” when de app es ready, tested on Dev server and loaded on Production server. Is this term right or have another meaning? i can see Sanity check is just a subset of regression test. Thanks for the article.
Very Nice explain.
Hi sunny,
ple explan me with example.i Didn’t understand u’r comment
thnx to all those who r all posted answers
SMOKE IS BEST
Nice copy paste !!!!
Its short, to the point, and not boasting and copyright.
This is a very simple and thoughtful explanation that got the point across in a number of paragraphs. Include me amognst those that has benefitted from your clarity of writing and though process.
Cheers Vijay and please keep it up
Lucifer Wingz PhD
6 Month experience software evaluation
very good explanation, i was searching for this answer. i am thankful to you people for giving this answer for me.thank you ……..
Please include…. when we do smoke check; when we do sanity check.o
.
..
what is the diff between interface testing and integration testing?
and
what is the exact diff between functional testing and system testing and UAT testing?
Thank you.
what is bug life cycle ?
Software Testing – Contents of a Bug
Complete list of contents of a bug/error/defect that are needed at the time of raising a bug during software testing. These fields help in identifying a bug uniquely.
When a tester finds a defect, he/she needs to report a bug and enter certain fields, which helps in uniquely identifying the bug reported by the tester. The contents of a bug are as given below:
Project: Name of the project under which the testing is being carried out.
Subject: Description of the bug in short which will help in identifying the bug. This generally starts with the project identifier number/string. This string should be clear enough to help the reader in anticipate the problem/defect for which the bug has been reported.
Description: Detailed description of the bug. This generally includes the steps that are involved in the test case and the actual results. At the end of the summary, the step at which the test case fails is described along with the actual result obtained and expected result.
Summary: This field contains some keyword information about the bug, which can help in minimizing the number of records to be searched.
Detected By: Name of the tester who detected/reported the bug.
Assigned To: Name of the developer who is supposed to fix the bug. Generally this field contains the name of developer group leader, who then delegates the task to member of his team, and changes the name accordingly.
Test Lead: Name of leader of testing team, under whom the tester reports the bug.
Detected in Version: This field contains the version information of the software application in which the bug was detected.
Closed in Version: This field contains the version information of the software application in which the bug was fixed.
Date Detected: Date at which the bug was detected and reported.
Expected Date of Closure: Date at which the bug is expected to be closed. This depends on the severity of the bug.
Actual Date of Closure: As the name suggests, actual date of closure of the bug i.e. date at which the bug was fixed and retested successfully.
Priority: Priority of the bug fixing. This specifically depends upon the functionality that it is hindering. Generally Medium, Low, High, Urgent are the type of severity that are used.
Severity: This is typically a numerical field, which displays the severity of the bug. It can range from 1 to 5, where 1 is high severity and 5 is the lowest.
Status: This field displays current status of the bug. A status of ‘New’ is automatically assigned to a bug when it is first time reported by the tester, further the status is changed to Assigned, Open, Retest, Pending Retest, Pending Reject, Rejected, Closed, Postponed, Deferred etc. as per the progress of bug fixing process.
Bug ID: This is a unique ID i.e. number created for the bug at the time of reporting, which identifies the bug uniquely.
Attachment: Sometimes it is necessary to attach screen-shots for the tested functionality that can help tester in explaining the testing he had done and it also helps developers in re-creating the similar testing condition.
Test Case Failed: This field contains the test case that is failed for the bug.
Any of above given fields can be made mandatory, in which the tester has to enter a valid data at the time of reporting a bug. Making a field mandatory or optional depends on the company requirements and can take place at any point of time in a Software Testing project.
The main purpose behind any Software Development process is to provide the client (Final/End User of the software product) with a complete solution (software product), which will help him in managing his business/work in cost effective and efficient way. A software product developed is considered successful if it satisfies all the requirements stated by the end user.
Any software development process is incomplete if the most important phase of Testing of the developed product is excluded. Software testing is a process carried out in order to find out and fix previously undetected bugs/errors in the software product. It helps in improving the quality of the software product and make it secure for client to use.
What is a bug/error?
A bug or error in software product is any exception that can hinder the functionality of either the whole software or part of it.
How do I find out a BUG/ERROR?
Basically, test cases/scripts are run in order to find out any unexpected behavior of the software product under test. If any such unexpected behavior or exception occurs, it is called as a bug.
What is a Test Case?
A test case is a noted/documented set of steps/activities that are carried out or executed on the software in order to confirm its functionality/behavior to certain set of inputs.
What do I do if I find a bug/error?
In normal terms, if a bug or error is detected in a system, it needs to be communicated to the developer in order to get it fixed.
Right from the first time any bug is detected till the point when the bug is fixed and closed, it is assigned various statuses which are New, Open, Postpone, Pending Retest, Retest, Pending Reject, Reject, Deferred, and Closed.
(Please note that there are various ways to communicate the bug to the developer and track the bug status)
Statuses associated with a bug:
New:
When a bug is found/revealed for the first time, the software tester communicates it to his/her team leader (Test Leader) in order to confirm if that is a valid bug. After getting confirmation from the Test Lead, the software tester logs the bug and the status of ‘New’ is assigned to the bug.
Assigned:
After the bug is reported as ‘New’, it comes to the Development Team. The development team verifies if the bug is valid. If the bug is valid, development leader assigns it to a developer to fix it and a status of ‘Assigned’ is assigned to it.
Open:
Once the developer starts working on the bug, he/she changes the status of the bug to ‘Open’ to indicate that he/she is working on it to find a solution.
Fixed:
Once the developer makes necessary changes in the code and verifies the code, he/she marks the bug as ‘Fixed’ and passes it over to the Development Lead in order to pass it to the Testing team.
Pending Retest:
After the bug is fixed, it is passed back to the testing team to get retested and the status of ‘Pending Retest’ is assigned to it.
Retest:
The testing team leader changes the status of the bug, which is previously marked with ‘Pending Retest’ to ‘Retest’ and assigns it to a tester for retesting.
Closed:
After the bug is assigned a status of ‘Retest’, it is again tested. If the problem is solved, the tester closes it and marks it with ‘Closed’ status.
Reopen:
If after retesting the software for the bug opened, if the system behaves in the same way or same bug arises once again, then the tester reopens the bug and again sends it back to the developer marking its status as ‘Reopen’.
Pending Rejected:
If the developers think that a particular behavior of the system, which the tester reports as a bug has to be same and the bug is invalid, in that case, the bug is rejected and marked as ‘Pending Reject’.
Rejected:
If the Testing Leader finds that the system is working according to the specifications or the bug is invalid as per the explanation from the development, he/she rejects the bug and marks its status as ‘Rejected’.
Postponed:
Sometimes, testing of a particular bug has to be postponed for an indefinite period. This situation may occur because of many reasons, such as unavailability of Test data, unavailability of particular functionality etc. That time, the bug is marked with ‘Postponed’ status.
Deferred:
In some cases a particular bug stands no importance and is needed to be/can be avoided, that time it is marked with ‘Deferred’ status.
What is a Bug Life Cycle?
The duration or time span between the first time bug is found (‘New’) and closed successfully (status: ‘Closed’), rejected, postponed or deferred is called as ‘Bug/Error Life Cycle’.
(Right from the first time any bug is detected till the point when the bug is fixed and closed, it is assigned various statuses which are New, Open, Postpone, Pending Retest, Retest, Pending Reject, Reject, Deferred, and Closed. For more information about various statuses used for a bug during a bug life cycle, you can refer to article ‘Software Testing – Bug & Statuses Used During A Bug Life Cycle’)
There are seven different life cycles that a bug can passes through:
Cycle I:
1) A tester finds a bug and reports it to Test Lead.
2) The Test lead verifies if the bug is valid or not.
3) Test lead finds that the bug is not valid and the bug is ‘Rejected’.
Cycle II:
1) A tester finds a bug and reports it to Test Lead.
2) The Test lead verifies if the bug is valid or not.
3) The bug is verified and reported to development team with status as ‘New’.
4) The development leader and team verify if it is a valid bug. The bug is invalid and is marked with a status of ‘Pending Reject’ before passing it back to the testing team.
5) After getting a satisfactory reply from the development side, the test leader marks the bug as ‘Rejected’.
Cycle III:
1) A tester finds a bug and reports it to Test Lead.
2) The Test lead verifies if the bug is valid or not.
3) The bug is verified and reported to development team with status as ‘New’.
4) The development leader and team verify if it is a valid bug. The bug is valid and the development leader assigns a developer to it marking the status as ‘Assigned’.
5) The developer solves the problem and marks the bug as ‘Fixed’ and passes it back to the Development leader.
6) The development leader changes the status of the bug to ‘Pending Retest’ and passes on to the testing team for retest.
7) The test leader changes the status of the bug to ‘Retest’ and passes it to a tester for retest.
8) The tester retests the bug and it is working fine, so the tester closes the bug and marks it as ‘Closed’.
Cycle IV:
1) A tester finds a bug and reports it to Test Lead.
2) The Test lead verifies if the bug is valid or not.
3) The bug is verified and reported to development team with status as ‘New’.
4) The development leader and team verify if it is a valid bug. The bug is valid and the development leader assigns a developer to it marking the status as ‘Assigned’.
5) The developer solves the problem and marks the bug as ‘Fixed’ and passes it back to the Development leader.
6) The development leader changes the status of the bug to ‘Pending Retest’ and passes on to the testing team for retest.
7) The test leader changes the status of the bug to ‘Retest’ and passes it to a tester for retest.
8) The tester retests the bug and the same problem persists, so the tester after confirmation from test leader reopens the bug and marks it with ‘Reopen’ status. And the bug is passed back to the development team for fixing.
Cycle V:
1) A tester finds a bug and reports it to Test Lead.
2) The Test lead verifies if the bug is valid or not.
3) The bug is verified and reported to development team with status as ‘New’.
4) The developer tries to verify if the bug is valid but fails in replicate the same scenario as was at the time of testing, but fails in that and asks for help from testing team.
5) The tester also fails to re-generate the scenario in which the bug was found. And developer rejects the bug marking it ‘Rejected’.
Cycle VI:
1) After confirmation that the data is unavailable or certain functionality is unavailable, the solution and retest of the bug is postponed for indefinite time and it is marked as ‘Postponed’.
Cycle VII:
1) If the bug does not stand importance and can be/needed to be postponed, then it is given a status as ‘Deferred’.
This way, any bug that is found ends up with a status of Closed, Rejected, Deferred or Postponed.
any one can give the definition of Priority and severity as well as example.
if any changes is done is any module then what should be the sequence of testing(smoke,sanity,regression, retest)?
The explanation is very nice
i request one thing that, if explanation given with an example then it is very effective
Excellent Post!
its really a very good blog to get actually a testing concepts
very happy by reading.
but ,recently from few days ,i am very upset ,i completed my testing certification but i didnt find the job yet ,
pls suggest me any vacancies,in mumbai
thanks and regards
ghanshyam.mishra
Hi,
I am priya, I am new to testing and have one query, can anyone please tell me
What is the Model/Process do u follow in your Organization for Testing?
Regards
what is silk test?with example?
help me pls
lol lot of copy paste, bullshit and english grammar sh!t, especially the “artical” thing lol
All ur concepts r concisely….
it is very easyful to us who r having interest in software testing…….
@ basha
as per what i know………
sanity check is like sample testing, it is done whenever a new code is released to test environment to ensure that application is working and performing main function, this is done before starting functional testing,. it takes 1-3 days like that……
abt smoke testing i didnot understand
Thanx
Great insights and thank you very much for sharing it!
plz tell me what is the diffrent between re-testing and reggression testing. and verificationand validation.diffrence between stab and driver.
difference between saveority-priority.
and plz give me a format test case design and defect template
It is nice explanation in this link… good to go throu all answers and make ur confusion far away..
Can anybody tell me about nonfunctional testing and how to create test senarios and test cases with some examples
good explanation. I don’t really get why people keep confusing the two…
Hi,
Iam Tejeswar Reddy. its very gud qtns and great answers its very usefull. Thanks to all.
Sanity : It means to test the flow of an application and concentrate on the showstopper issues while doing sanity. If any showstopper issue comes, will reject the build. Every build should be followed by sanity Tcheck.
Smoke : This is similar to sanity but difference is “should validate the application before release”. Once Smoke is passed, the application releases to UAT.
Any concerns, let me know.
Cheers,
Vardhan
QA Engineer.
@ Khushboo
Types of Testing:
1. Unit
2. Integration
3. System
4. UAT
Methods of Testing:
1. Black Box
2. White Box
What an explanation
Hi Friends,
Currently i am working in Non-IT field and planned to switch my career to testing.I had learned the basics of testing,and now i am very eager to learn testing practically with real time projects.
If any one interested to teach testing personally with real time projects , i will be more grateful, or else show me the right place in chennai.
Thanks & regards
Great explanation. Precise and concise.
hi ppl i have a confusion with difference between retesting and regression check please help me out regarding this
Thanks for clearing my doubts..
I think everyone has given their opinion based on the other website. Till now none of you have not tried to resolve the confusion of the people by providing realtime project example of difference bn smoke and sanity. I sm asking you why smoke is scripted and why sanity is unsripted. simply you are using some words narrow, deep, shallow, wider. has any one one you ever tried with complete example, no, right?
Hi Friends,
Currently i am working in Non-IT field and planned to switch my career to testing.I had learned the basics of testing,and now i am very eager to learn testing practically with real time projects.
If any one interested to teach testing personally with real time projects , i will be more grateful, or else show me the right place in chennai.
Thanks & regards
selvam.ba@rediffmail.com
very nice explanation… thanks to all
how to write test scenario and test cases for regression testing??
please help me
It was Superb. Nice one!
Difference between Smoke and shake down testing
smoke check don at developer side which means developed application is eligible for testing or not is called smoke check
sanity check is nothing but testing side test the application whether the application is eligible for furhter testing is called the sanity check
Which need to start first? Smoke or Sanity?
Smoke testing needs to start first. This is the first testing on the initial build. You always accepted a build only after You had performed a smoke test. Smoke testing is normally used for Integration, Acceptance and System Testing.
Sanity testing is a subset of regression testing .Sanity test should be done only when you are running short of time.
·Smoke check- When build is received a smoke test is run to ascertain if the build is stable and considered for further testing. Smoke check is normal health check up to a build of an application before taking it to testing in depth.
@Ajay Gupta,
well said Mr.Ajay, but as per your example smoke and sanity are same right?
even in some companies will tell smoke and sanity are same.
* let me know if im worng*
@anuradha,
Load testing: Testing the application by giving Maximum Request.
Stress: Testing the application by giving more than Maximum Request.
Secruity Testing: It is done to conform that the Matter is (kept/sending/receving) in secured manner or not.
the wt ever matter we are sending it will be converted in Encrypted form and sent to the other person.
the matter is converted into Encrypted form by using SSL (Secured Socket Layer).
*Let me know if im wrong*
Hello abhishek ,
There is difference between the Sanity and smoke, we use script for Smoke but we dont for Sanity. We use smoke when a product is new and sanity for releases but smoke is used when the changes in the product have greater impact on its functionality.
awesome
Hi ilyas,
Dont regret for anything.bcoz we cant do anything by regretting.first u hav to decide ur interest..if ur interest is in s/w testing field means,u can go ahead..
some s/w testing training centres in chennai r giving training & placements effectively.so need to worry…
u can do training at australia itself…bcoz most of the younger’s dream is flying to abroad only…so think once again before u start ur journey to india…
Thanks
Most ridiculous explanation!
Smoke check looks okay but so much contradiction in sanity check.
Line one says:
A sanity check is a narrow regression test that focuses on one or a few areas of functionality. Sanity check is usually narrow and deep. (NARROW and DEEP)
Line 3 says:
Sanity check 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.
(HERE Cursory TESTING, just opposite of DEEP)
Line 5 says:
Sanity check is to verify whether the requirements are met or not, checking all features breadth-first.
(HERE Breadth first – Opposite of NARROW)
How people commenting above got their doubts clarified based on jumbled up English?
Hi all…
i m doing manual testing of web applications in a pvt company for 2,3 months. Unfortunately i have no senior to guide me…
I need some practical test scenarios & Test cases (for guidance purpose).
would any of you like to help me? plzz send me some test cases on the following id…i’ll be vry thankful…
abrar.ste@gmail.com
not much clear, can u please explain with one easy example?
there is no difference between both the testing,
smoke check done by qa team to accept the build or not by testing major test cases (i.e. means major testcases should be passed).
sanity check done after the completion of system testing to test the major functionalities are working properly or not to push the application into the production or not based on major functionalities.
hello, the writer has mad an extremely confusing contradiction.
Statement 1: In the Regression vs Sanity table: “This [sanity testing] is a wide and shallow testing.”
Statement 2: “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.”
Statement 2 is correct, sanity testing is Narrow and Deep, while statement 1 must be accidentally referring to Smoke Tests which are Shallow and Wide, not Sanity Tests.
Hi,
Very Gud Article 2 Learn the Differnce Between both the Testing
Smoke check is done by developers,
Sanity check is done by testers,
Before involve into full testing process., some of the main modules are tested, this is termed as sanity and smoke check
@ramya: narrow regression means, Regression testing on the Impacts of the application where the Changes cause
Both these testing techniques are same.Different organization call them differently.
hi,its nice in clearing concepts in software testing. its a good explanation from suresh……
hi,
Above information is too helpful, i would like to know much more about these software testing, GUI testing, sanity, smoke and regression testing, so can you please suggest me material to study about these concepts, thank you in advance.
hi friends its very confusion of sanity and smoke check some r told that smoke check is done by developers and sanity is done by testers what exact one i have more confusion in real time who r done both the test plse give explanation and regresion and retest also confused one plse explain both in easy way thank u
Author, please, provide the source of this explanation. According to what standard or document is it? May be it is not actual anymore?
Very nice and clearly explained. Thank you 🙂
Excellent. Very precise information.
5n
Very informational doc. Thank you.
please specify thing in brief detail along with real-time example
Helps for freshers……………. thanks to all
clear my all doubts really good description
Thanx Pradeep for explanation and clearing my doubt.
can u plaease give me a simple example for load ,stress,volume,bvt,sanity,smoke,and security
Hi Vijay,
What is the aim of big bang approach in software testing?
1) Testing all critical areas.
2) Spending all efforts in testing phase
3) Both 1 and 2.
4) None of the above
kindly confirm if option 4 is the right answer or not
@Priya
Models are used to Develop the Product/Application.
to develop Prototype every company follow RAP model (Rapid Application Development)
and for Developing the Application it differs from company to company.
some use RUP, & some use VV like it differs.
im nt a real time employ. let me know if my Answer is wrong.
Hi All,
Can any one clarify my doubt i.e Does smoke test is conducted by development team or testing team.
Firstly it is conducted by QA lead, if not then it is conducted by tester.
Hi, this is a fantastic place to get all the things clarified.
Thank you.
” these two testings are way “different” and are performed during different stages of a testing cycle.” how come they different? Smog goes to Implementation Cycle, Sanity to Conclusion? Correct me if i’m wrong
Hi Veena,
U r right that smoke check is done by tester whn a new version/build is prepared.
Similarly, when retesting/regression testing has to be done then we do sanity testing.That means the application is tested in depth to check the complete functionality has met the requirement.
This we do it everytime in the project but we may not call it sanity check.This is also done by tester.
I have one question for this topic:
When do we use smoke testing? And when do we use sanity testing?
Hello guys,
Good to read so many comments. Sorry but am still not able to get an idea about where and when i should use sanity and smoke ?
If would be good if any one can provide a real life simple example please.
what is the Scope in Test Plan, plz give me one ex. of it.?
Thnx…….
thank you sir!!!
Hi,
I have been done software testing course last year.
but now i am not working in as a tester in my company, but now i want to switch from that field to tester. so how can i do this.
Plz give me the suggestion
Pls tell me what is smoke check? when will we do it.
Hi
I think there is no any difference between Sanity and smoke check Both are equal
It depends upon the Work conditions
Thank u… Good example
Thank you so muchhhhhhh. Really u r clarifying my doubts. thank q
Very nice
Thanks