How to test software for business
“They taught the bad, now we teach the good”
First, do not be lazy, dear leaders. If the program is designed for you, if it only makes your life easier, brings money to your companies, take the time and energy for self-testing. Of course, this does not mean that everything will have to be done independently, but it is you who assess the program according to the degree of effectiveness. Please remember this thesis, we will come back to it.
What makes sense to delegate to IT staff? Three things.
First, it must complete the installation of test software on employees' computers and on the server. If you don’t want to conduct testing on a “combat” infrastructure, you can pre-create a test (although for the sake of fairness, I note that it is better to test business applications in a working environment: they almost never can “break” the system, which means there is no need to create a special “ sandbox ”, and only your work systems will be able to provide actual, not invented data for further analysis).
')
Secondly, IT staff should train you and other users (not IT specialists) involved in testing, working with the program.
Thirdly, the IT department provides technical support (possibly by redirecting requests to the support service of the software manufacturer).
And it's all! The remaining actions, including debriefing, are performed only by business employees. And not just any, but precisely those who should be interested in implementing this program, those whose life will be better after the introduction, financial performance is higher, and work is more productive. If you make a mistake, load a business user with a testing program that he does not need, then be sure that he will give a negative feedback on the best program.
And finally, on the debriefing. Gather everyone who participated in the testing, listen to everyone, but try to turn the conversation over to the discussion of the program’s functionality. Does she generate reports? Discuss whether it generates them well, what is missing, whether it is in the programs of competitors, if they are also tested. And if the implementation of the report generation program has already been taken, harshly stop feedback from places like “lived without reports and live on”, “yes, I’ll generate these reports for you,” especially if they come from the IT department.
If IT professionals have their concerns about technical issues, then they can and should express them. The program is too heavy for your local network, you need to buy a new server and so on. Listen, write down and be sure to direct the developers of the program. Let them comment on all objections. The truth, as always, is somewhere in the middle. The manufacturer wants to sell the program, your IT professionals do not want to take on the extra trouble.
But then you make the decision. Look at the rate of payback, the intangible effect, the criticality for your business - and reach for the wallet. Or do not stretch. But you decide. And only you.
First, do not be lazy, dear leaders. If the program is designed for you, if it only makes your life easier, brings money to your companies, take the time and energy for self-testing. Of course, this does not mean that everything will have to be done independently, but it is you who assess the program according to the degree of effectiveness. Please remember this thesis, we will come back to it.
What makes sense to delegate to IT staff? Three things.
First, it must complete the installation of test software on employees' computers and on the server. If you don’t want to conduct testing on a “combat” infrastructure, you can pre-create a test (although for the sake of fairness, I note that it is better to test business applications in a working environment: they almost never can “break” the system, which means there is no need to create a special “ sandbox ”, and only your work systems will be able to provide actual, not invented data for further analysis).
')
Secondly, IT staff should train you and other users (not IT specialists) involved in testing, working with the program.
Thirdly, the IT department provides technical support (possibly by redirecting requests to the support service of the software manufacturer).
And it's all! The remaining actions, including debriefing, are performed only by business employees. And not just any, but precisely those who should be interested in implementing this program, those whose life will be better after the introduction, financial performance is higher, and work is more productive. If you make a mistake, load a business user with a testing program that he does not need, then be sure that he will give a negative feedback on the best program.
And finally, on the debriefing. Gather everyone who participated in the testing, listen to everyone, but try to turn the conversation over to the discussion of the program’s functionality. Does she generate reports? Discuss whether it generates them well, what is missing, whether it is in the programs of competitors, if they are also tested. And if the implementation of the report generation program has already been taken, harshly stop feedback from places like “lived without reports and live on”, “yes, I’ll generate these reports for you,” especially if they come from the IT department.
If IT professionals have their concerns about technical issues, then they can and should express them. The program is too heavy for your local network, you need to buy a new server and so on. Listen, write down and be sure to direct the developers of the program. Let them comment on all objections. The truth, as always, is somewhere in the middle. The manufacturer wants to sell the program, your IT professionals do not want to take on the extra trouble.
But then you make the decision. Look at the rate of payback, the intangible effect, the criticality for your business - and reach for the wallet. Or do not stretch. But you decide. And only you.
Source: https://habr.com/ru/post/213333/
All Articles