I have gone through many blogs and articles to find the difference between Sanity and Smoke testing.

Here is the difference:

1. Smoke Testing is a wide approach of testing and covers all major functionalities (areas) of a application where as Sanity Testing is a narrow approach and covers a few areas.

2. Smoke Testing is scripted means testers usually write test cases for Smoke testing so that he should not miss any functionalities where as Sanity Testing does not need any test cases as it is done for a specific area or functionality

So, as per my view both Smoke and Sanity Testing are more or less focus on whether the application is ready to test rigorously however the scope of Smoke Testing is all major functionalities whereas in Sanity testing its some functionalities.

Nice to see a good responses in this forum,

here is a small clarification on “product pass/failure”
As per the client this terms are very much important.
but as per the tester/developer every project is a challenge, and learning skill set for growth.
Its said like Team …which is responsible.

Regards,
Ravi

Currently i am working in 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 , ill be more grateful, or else show me the right place in Hyderabad

Thanks & regards
T.Chaitanya
t.chaitu@yahoo.com

I have absorbed in many projects….one person work in same project for long time..he might end up with careless of doing the work since he believe he konws everythnig and he get bored of thinging and doing the same core functionalities and flow of work so his thinking process skill will not be improved.

2) tester will get detailed knowledge , not even the person who collected the requirement nor the customer has a detailed knowledge of the product or domain
Pradeep, I am surprised how are you holding your position in the organization with such thought process !! Attitude matters the most..esp for the testers. Question is NOT about understanding ins and outs of the product being developed… BUT about understanding 100% of WHATEVER requirement is available at ANY point in Time of product development. Haven’t you faced the req change during the development and both, developer and tester, adapting to the new requirement for the product development and testing ?

3) Quick bugs:
Anyone can find a bug – as no product is 100% correct. Does it mean the person qualifies as tester? depends – I have seen such defect also from a well seasoned tester – “if u click X button 100 times and then click on Y button 150 times, the application crashes”. The real question to be asked is what is the value addition for the customer/end user by fixing those QUICK defects. you will get the answer yourself.

4) Flight training for car driver:
Pradeep, you have been too harsh on Vijay. Even the car driver would have learned the driving by training from some one for a day/an hour or some quanta of time. Obviously, training is the starting point..after that one has to practice. I remember my company purchased chip design tools worth lacs and then sent the entire team (13 ppl) for 7 days training but there were not a single project to practice or utilize our training..result – the tools are in dumpyard..and so do that skillset of people.

5) Tester getting biased
its again mindset. The more the tester is exposed to product domain, better (s)he would be able to write test cases to catch CORE or high severity defects than the UI or cosmetic defects. If the tester doesn’t know about the product than it’s energy will be wasted (to a good extent) on finding defects that are irrelevant or invalid.

6) Why should companies encourage you to do extra activities?
to better their products and to avoid rework expenses. If you can show improvement in the quality, company would pay and encourage u to do so.
When companies want to make money..then why would you WORK for FREE on a WEEKEND for your COMPANY without ANY ENCOURAGEMENT?

7) Out of box thinking
My stand on this is to not to force the tester to follow a template (other than reporting)..let them be creative to find high severity and valuable defects at the earliest.

General comment:
I always see this -A wall between the testers and developers; almost no or very little information flow across this wall. This should be avoided. no one is biased if they are honest to themselves and their responsibilities.

Lakshim,
I really liked the diff between Verification and Validation -south Indian way ( I like Dosa / idlies).
just reiterating – Verification is against the requirements while validation is against the product in customer scenario.

A great forum..keep me posted.
- Mukesh Soni

Nice Example for Verification and Validation process.