How we practice corridor testing
Developers want to make clear and convenient software products.
But for us, both the console and hotkeys are quite understandable and user-friendly interface:
If you can write a plugin to the program, then it is convenient and extensible. If you can change in the config the background color of the message box is flexible. A normal user from such flexibility is neither warm nor cold, he has to solve his tasks, and not write plugins.
Previously, we tested the user interface during trial operation (this is when a new version is installed in our company). This method has some flaws:
We decided to combat these shortcomings with the help of corridor testing. Here we want to share our experience.
Prepare scenarios that are close to real. It is important to prepare scenarios with real data: contracts and acts with real names, and not a “test document”, real users and the organizational structure in the system. If you just give a poke system, this effect will not.
Adapt scripts during testing. If the first two users have problems, change the script. You can directly in the process to come up with new situations of interaction with the system.
')
Test on different users. For us, the most interesting users who gave the most useful feedback were newbies or not at all familiar with the system. They have not yet fixed their eyes and do not have harmful habits from working with previous versions. From oldies, especially developers, basically comments are received on the fact that their favorite hot key does not work, but such users cannot be ignored either.
Exclude bureaucracy from the process. Almost any company is ready to allocate 15–20 minutes; no harsh coordination with managers and people’s choices are needed; it’s enough to write on the communicator and agree on the time. Almost everyone responds without problems; I did not respond alone - there is always someone to call instead of a deviation.
Limit the number of experimental. 8–10 people with different levels of training and functional responsibilities are enough to find the main problems. According to the results of one of the corridor tests, the number of detected bugs and the number of new bugs for each user were calculated. It can be seen that recent users no longer say almost anything new:
Get the natural environment. Keyboard, monitor, system, languages ​​and other environments should be standard and familiar, so as not to interfere with and not distract people.
Test on beta. To test on a crude product - normally. Not scary if a couple of bugs come out. We do the corridor testing at the end of the sprint. Here, almost everything works and there is time to quickly fix or analyze something and plan for correction in the next sprint.
You can create scripts before development, they will be useful in design and planning (to understand what needs to be done), during development for testing and testing, and in demo.
Write down everything. Fix not only the problems, but also that with which there were no problems. This is necessary in order not to spoil what works well now.
But for us, both the console and hotkeys are quite understandable and user-friendly interface:
If you can write a plugin to the program, then it is convenient and extensible. If you can change in the config the background color of the message box is flexible. A normal user from such flexibility is neither warm nor cold, he has to solve his tasks, and not write plugins.
Previously, we tested the user interface during trial operation (this is when a new version is installed in our company). This method has some flaws:
- Users have no time to make comments to the product. Especially if it concerns the usability of the program, and not the functionality.
- It is not clear how intuitive the interface is. You can, of course, conduct surveys, but they are usually uninformative.
- Comments come too late. The developer has less time to fix them.
We decided to combat these shortcomings with the help of corridor testing. Here we want to share our experience.
Our recommendations for CT
Prepare scenarios that are close to real. It is important to prepare scenarios with real data: contracts and acts with real names, and not a “test document”, real users and the organizational structure in the system. If you just give a poke system, this effect will not.
Adapt scripts during testing. If the first two users have problems, change the script. You can directly in the process to come up with new situations of interaction with the system.
')
Test on different users. For us, the most interesting users who gave the most useful feedback were newbies or not at all familiar with the system. They have not yet fixed their eyes and do not have harmful habits from working with previous versions. From oldies, especially developers, basically comments are received on the fact that their favorite hot key does not work, but such users cannot be ignored either.
Exclude bureaucracy from the process. Almost any company is ready to allocate 15–20 minutes; no harsh coordination with managers and people’s choices are needed; it’s enough to write on the communicator and agree on the time. Almost everyone responds without problems; I did not respond alone - there is always someone to call instead of a deviation.
Limit the number of experimental. 8–10 people with different levels of training and functional responsibilities are enough to find the main problems. According to the results of one of the corridor tests, the number of detected bugs and the number of new bugs for each user were calculated. It can be seen that recent users no longer say almost anything new:
Get the natural environment. Keyboard, monitor, system, languages ​​and other environments should be standard and familiar, so as not to interfere with and not distract people.
Test on beta. To test on a crude product - normally. Not scary if a couple of bugs come out. We do the corridor testing at the end of the sprint. Here, almost everything works and there is time to quickly fix or analyze something and plan for correction in the next sprint.
You can create scripts before development, they will be useful in design and planning (to understand what needs to be done), during development for testing and testing, and in demo.
Write down everything. Fix not only the problems, but also that with which there were no problems. This is necessary in order not to spoil what works well now.
Source: https://habr.com/ru/post/238653/
All Articles