One of the main principles of testing is that it is always necessary to know the state of the system being explored. If a bug is caught, but the tester is unaware of what causes the system to crash, in this case, he will have difficulties in reproducing this failure. The need to put the system in a known state before running tests on it means that each test case should bring hardware and software into a known state. This does not mean that the tester must de-energize the system, restart it and run the program from the very beginning – as with any other test situations, everything has its limits.
In order to prevent the system under test from moving to states that cannot be played back, there are a number of practical measures. One of them is to implement the power cycle of the system prior to starting testing – this, apparently, should be done at the beginning of each working day. Another measure involves systematic update of databases and deletion of test directories. If test automation is used, it is possible to clean databases and data catalogs frequently and at that not spend much time on this procedures. It may be that the system being tested makes changes to the embedded software. If this is the case, the firmware will need to be rebooted either before running logically related tests, or at the beginning of each working day, which will ensure testing of an undistorted version of the firmware. Ideally, automated tools are used to save the current state of the system under test in a special storage area, to register various kinds of deviations and to move the system to the desired state. Web testing service helps to understand the cause of improper behavior that your web app is showing. Web applications are checked for defects before the code goes live.
There are two approaches to initializing the test. One of them involves the use of a special setup program that moves the system to a known state before testing starts, and uses standard cleaning programs that “cancels” the changes made during the test. Another approach entails only set up procedure without cleaning the data. If the corresponding installation operation is performed before each test is run, it does not matter what happens at the end of the test – anyway prior to the next test run, known conditions will be restored, and the efforts spent on cleaning operation may turn out to be useless. Without doubt, there can be problems in situations where a new test is added, not designed for installation, and the tests performed earlier brought the system into an unintended state.
Comments are closed.
