Smoke Testing

*** SMOKE  TESTING or SANITY TESTING or DRY RUN or SKIM TESTING or BUILD VERIFICATION TESTING or Skim Testing or Confidence Testing *** (Very very important interview question)

Testing the basic or critical features of an application before doing thorough testing or rigorous testing is called as smoke testing.

It is also called Build Verification Testing – because we check whether the build is broken or not.

Whenever a new build comes in, we always start with smoke testing, because for every new build – there might be some changes which might have broken a major feature ( fixing the bug or adding a new feature could have affected a major portion of the original software).

In smoke testing, we do only positive testing – i.e, we enter only valid data and not invalid data.

Advantages:

1. Test engineer can find blocker and critical defects in the early stage itself.
2. Development team will get sufficient time to fix the defects.
3. Test cycle will not be postponed and hence release will not be delayed.

How to do smoke testing?

Here we should list the feature to be tested as part of smoke testing and the features not to be tested as part of smoke testing.

When we are doing smoke testing, we do only positive testing (only valid data is entered)

Here, we test only basic or critical features

Here, we take basic features and test for important scenarios

How to write smoke testing scenarios?

1.      To check that when user entered test-url welcome page should be displayed
2.      To check that when the user click on sign up link, signup page should be displayed.
3.      To check that when user entered valid data to all the fields in the sign up page and click on submit button, account should be created.
4.      To check that when user entered valid login credentials and click on login button, home page should be displayed.
5.      To verify used can compose and send a mail.
6.      To verify that user can receive the mails
7.      To verify send mails are displayed in sent item.

When we do smoke testing?

1.      As soon as we get new build from development team we do smoke testing.

 (Because for every new build – there might be some changes which might have broken a major feature ( fixing the bug or adding a new feature could have affected a major portion of the original software).)

2.      Whenever the build comes to the customer, before the customer / client does Acceptance Testing, he also do Smoke Testing to verify all the files are received and build is installed properly or not.

3.      Build engineer/Release engineer will do smoke testing to verify whether build is installed properly or not in test server or in production server.

4.      Developer will do smoke testing after WBT and before giving a build to testing team.

Why we do smoke testing?

1.      To check whether software is testable or not

2.      First day itself while doing smoke testing if we find bugs send it to developers so that they will get sufficient time to fix the defect.

3.      To verify whether build is installed properly or not.

4.      Developers are giving build means they would have done some changes, chances are there that changes might affecting old basic or critical features in order  to find that we do smoke testing,

5.      It is like a health check of the product so smoke testing should be done.

6.      It is like a build verification testing, here we check build is broken or not (if the build is having more number of defects then the build is called as broken build.

Important Points to Remember

·         When we are doing smoke testing, we do only positive testing (only valid data is entered)

·         Here, we test only basic or critical features

·         Here, we take basic features and test for important scenarios

·         Before doing through FT/IT/ST we do smoke testing.

·         Before acceptance testing customers will do smoke testing

·         Once after the software is deployed to the production server, before using the software for the business, smoke testing should be done.

Types of Smoke testing:

Smoke testing is classified into two types,

·         Formal Smoke Testing – the development team sends the s/w to the test lead. The test lead then instructs the testing team to do smoke testing and send report after smoke testing. Once, the testing team is done with smoke testing, they send the smoke testing report to the Test lead.

·         Informal Smoke Testing – here, the test lead says the product is ready and to start testing. He does not specify to do smoke testing. But, still the testing team start testing the product by doing smoke testing.

What are the ways to do smoke testing?

There are 2 ways to do smoke testing.

1.      Manual

2.      Automation

Do you write smoke test scenarios?

Yes

Can we automate smoke test scenarios?

Yes

What is the difference between smoke and sanity testing?

As per my knowledge there is no difference between smoke and sanity testing but I have gone through some website and documents were in i got to know there are some difference between smoke and sanity testing.

Smoke Testing	Sanity Testing
It is wide and shallow testing approach	It is a deep and narrow testing approach
Smoke testing is Positive testing.	It is both positive and negative testing.
Here we document scenarios and test case. (Scripted)	Here we don’t document scenarios and test case( unscripted)
We can go for automation	We don’t go for automation
It is done by both developer and tester	It is done by only tester

Build verification testing:

As soon as we get the build, first we verify are there any blocker bugs are there or not is called build verification testing.

Confidence Testing:

While doing smoke testing we get to know there is no blocker bugs in the basic features this is called confidence testing.

Dry Run - A dry run is a testing process where the effects of a  possible failure are intentionally mitigated. For example,  an aerospace company may conduct a "dry run" of a takeoff  using a new aircraft on a runway before the first test  flight.

First day itself if you get to know product is not testable as a test engineer how will you spend your time?

I will spend my time in analyzing and understanding requirement, identifying scenarios and write test cases.