Before actually starting testing we do smoke testing and after that we start the actual testing. Can we take the results of the smoke testing session as pre-condition and assumption while writing test cases?
If yes/no then why?
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.Sign up to join this community
The question asks whether other test cases can cite smoke testing as a dependency. The answer depends on the purpose of the dependency.
If the purpose is to narrow down what your test cases need to cover, that's fine.
If the purpose is to exploit a side-effect of the smoke test, e.g. to take advantage of configuring the software in a certain way, or creating specific kind of data, you need to be careful. Generally, it is a bad idea to make assumptions about the order in which test cases are executed, because the order can change. Your example is mitigated by the fact that the tests you depend on are smoke tests, which by definition run before anything else. Still, a better practice would be to divide the smoke test into two parts: a setup process for the side-effects that your other other tests depend on, and one for the actual smoke-tests. That way, if you ever want to run your other tests without first running the smoke tests, you will know how to do it.
I don't think that in an official master test plan a smoke test can be accepted as pre-condition for starting with formal test plans, or at least it would be difficult for me to justify a not formalized condition as trigger for a testing session. Everything changes if your smoke test is composed by a predefined sequence of steps but, in that case, you are not performing a real smoke test.
Smoke tests are really useful when you need to quickly reject a build and you do not want to invest your budget testing poor quality versions of a software.