I want to apply smoke testing and sanity testing to running testing projects. So any one can help me by proper plan using which I can apply real smoke and sanity testing professionally as QA.
Smoke testing is less about QA than about saving time. The term comes from the electronics business: you plug your new device into a power outlet and watch whether it starts to smoke. If it does, there is no point in testing any further.
The analogy for software could be as simple as checking whether the program crashes as soon as you start it. More typically, a software smoke test involves trying out some essential functions that need to work before you any other testing is possible.
Smoke testing is most valuable when you have a large team consuming a build and a history of poor-quality builds. You don't want a large team trying out a new build if the software is fundamentally broken. If the team is small, or if builds tend to not have serious regressions in fundamental features, smoke-testing may be a waste of time.
Have said all that, if you need a smoke test, you must already know what kinds of fundamental features need to work, and so it's just a matter of deciding how to test those features. A smoke test could be as simple as a set of written instructions, or an automated test suite, or both.