Continental Test Lab: August 2014
Continental Test Lab: August 2014
August 2014
1Smoke Testing
2Regression Testing
The results of this testing is used to decide if a build is stable enough to proceed with further
testing.
The term ‘smoke testing’, it is said, came to software testing from a similar type of hardware
testing, in which the device passed the test if it did not catch fire (or smoked) the first time it
was turned on.
The result of this test is used to decide whether to proceed with further testing.
If it fails, halt further tests and ask for a new build with the required fixes.
If an application is badly broken, detailed testing might be a waste of time and effort.
As and when an application becomes mature, with addition of more functionalities etc, the
smoke test needs to be made more expansive.
Sometimes, it takes just one incorrect character in the code to render an entire application
useless.
It provides some level of confidence that changes to the software have not adversely
affected major areas (the areas covered by smoke testing, of course)
NOTE
Do not consider smoke testing to be a substitute of functional/regression testing.
1Smoke Testing
2Regression Testing
The likelihood of any code change impacting functionalities that are not directly associated
with the code is always there and it is essential that regression testing is conducted to make
sure that fixing one thing has not broken another thing.
During regression testing, new test cases are not created but previously created test cases
are re-executed.
In an ideal case, a full regression test is desirable but oftentimes there are time/resource
constraints.
In such cases, it is essential to do an impact analysis of the changes to identify areas of the
software that have the highest probability of being affected by the change and that have the
highest impact to users in case of malfunction and focus testing around those areas.
Due to the scale and importance of regression testing, more and more companies and
projects are adopting regression test automation tools.
a. It’s often extremely difficult for a programmer to know how a change in one part of
the software will echo in other parts of the software.
AND what’s even worse:
b. Programmers sometimes change the software without even trying to figure out
if their changes might break something.
On the other hand, testers usually know (or can make an educated guess) which features
will be directly affected by a change.
The 1st group must contain test suites that check legacy (i.e., existing) features that are
directly affected by a change in software.
The 2nd group must contain test suites that check legacy features that may somehow
depend on the changed features
3rd group. As a rule, the majority of test suites don’t fall into the 1st and 2nd groups. But
that majority surely needs to be tested too, because, as we know, a change in one part of
the software can often break other seemingly unrelated part(s) of the software. It’s usually
out of question to execute ALL of those test suites during Regression Testing for a single
release, so what we can do is to set up a plan to execute all the test suites within a defined
period of time – e.g., 6 months.
How To Resolve The Contradiction Between Our Limited Resources And The Ever
Growing Number Of Test Suites?
The prioritization of test suites and test cases is the cheapest and, in many cases, most
effective solution to resolve the issue of contradiction.
If you use test suite/case priorities as the criteria for test suite/case selection for Regression
Testing, you should keep those priorities up-to-date.
The test suite/case priority must be changed, for example, when a tested feature loses its
importance or, on the contrary, becomes more important.
For point b – Some test cases can be simplified because new helper tools are written.
To hire new testers or to outsource testing is the most linear way to resolve the
contradiction.
There is no universal advice here; it all depends on the company and its type of business.