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?

  • I actually asked a question -very- similar to this the other day. Does this answer your question: sqa.stackexchange.com/q/15737/65
    – corsiKa
    Dec 9 '15 at 16:28
  • kind of relevant, and obviously we can take one use case/script as input to other (if require), but my question is about "smoke testing(it is not a formal testing)" , can we take it as pre-condition and as assumptions, and you also know pre-condition and assumptions are two different things
    – jklm
    Dec 9 '15 at 16:40
  • Your smoke test isn't formalized? I'd fix that!
    – corsiKa
    Dec 9 '15 at 16:46
  • smoke testing is done before starting a formal testing to check all the interfaces etc are working right so QA team do not need to check these little initial things
    – jklm
    Dec 9 '15 at 16:48
  • So how would you handle the scenario where one person has X Y and Z when they do a smoke test and you do X Y and W in your smoke test? How can you assume (in this simple scenario) that Z or W ever got tested? That's why I say it should be formalized.
    – corsiKa
    Dec 9 '15 at 16:51

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.

  • you want to say that it is good practice to take them as a pre-condition but not as an assumption ? please correct me if I am wrong
    – jklm
    Dec 9 '15 at 16:51
  • I do not understand the difference between a pre-condition and an assumption. It is generally a bad idea for a test to depend on the side-effects of another test.
    – user246
    Dec 9 '15 at 17:20

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.