I think that each of us has come across this advice in our lives. This trivial operation can often solve the current problem, but from the point of view of software testing, we should resort to it only in extreme cases. What should the tester do before pressing the reset button? That's what we're going to talk about now.
In the picture above, we can see that the user does not have the option to go back to the login form in case of an unsuccessful login attempt. This leaves the user with no choice but to "restart" back to the home screen.
The opposite extreme would be to redirect the user to the home screen directly, without providing any feedback. It is essential that users are aware of any errors that occur. Ideally, users should be able to resolve the situation themselves.
Restarting can help us return the system or application to its default state. However, applications can often "remember" the state before a reboot, so it is important to prevent these situations.
Create a diagram of your application and "tick" your way through each node as you test. Especially for exploratory tests, I recommend writing down all the steps you perform. For randomly discovered bugs, this can greatly assist you in identifying the causes, and you can also pass the steps to the developers to reproduce, saving time during debugging.
Similarly, you can prepare different paths and thus actually "generate" unique test scenarios. Keep in mind that such a schema needs to be kept up-to-date - for example, you can add an update of the schema to the DoD or as one of the test scenario points.
Unresolved errors or exceptions can also cause the application to get "stuck". However, even in this case the user should be informed about the error and have the opportunity to resolve the situation. An error does not mean that the application should stop responding to user input or stop working altogether.
After all, testing is interested in the quality of the software as a whole, and user friendliness or usability is also an important part.
If the environment in which the current application is running runs out of system resources, there is not much you can do to intervene. That's why performance (stress) tests are important to expose application or system weaknesses before deploying to a "live" production environment.
System integration testing, on the other hand, will help us to detect weaknesses in the interaction of individual components, modules, or third-party services, for example. By removing a component, we can simulate the failure or unavailability of that component.
Restarting may result in the loss of important data. Some data may be stored in the operating memory, or files may be lost if they are currently locked by a process.
Therefore, before restarting, collect as much (useful) information as possible, such as logs or the configuration of the application and the environment it is running on.
It is also important to be able to describe the steps that led to the error. Writing down all the steps we perform, or perhaps recording the screen, can help us do this.
Thank you! You have successfully subscribed to the newsletter.
