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 ♦Commented Dec 9, 2015 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– jklmCommented Dec 9, 2015 at 16:40
-
Your smoke test isn't formalized? I'd fix that!– corsiKa ♦Commented Dec 9, 2015 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– jklmCommented Dec 9, 2015 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 ♦Commented Dec 9, 2015 at 16:51
|
Show 1 more comment
2 Answers
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– jklmCommented Dec 9, 2015 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.– user246Commented Dec 9, 2015 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.
