How to test business software correctly
“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 to do independent testing. Of course, this does not mean that you have to do everything yourself, but you are the one who evaluates the program by 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, he must install the test software on employee computers and on the server. If you don’t want to conduct testing on a “combat” infrastructure, you can first create a test one (although in fairness I’ll note that business applications are best tested in a working environment: they can almost never “break” the system, which means there is no need to create a special “ sandbox ”, and only your working systems will be able to provide actual, not invented data for further analysis).
Secondly, the 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 (perhaps by redirecting requests to the support service of the manufacturer of software products).
And it's all! Other actions, including debriefing, are carried out only by business employees. Moreover, not everyone, namely those who should be interested in implementing this program, those whose life will be better after implementation, financial performance is higher, and work is more productive. If you make a mistake, load the business user with testing a program that he does not need, then be sure - he will give a negative review for the best program.
And finally, on the debriefing.Gather everyone who participated in the test, listen to everyone, but try to transfer the conversation to the discussion of the program’s functionality. Does she generate reports? Discuss whether it generates them well, what is missing, is it in the programs of competitors, if they were also tested. And if the implementation of the report generation program has already been adopted, firmly suppress feedback from places like “lived without reports and will continue to live”, “yes I’ll generate these reports for you with my own hands”, especially if they come from the IT department.
If the IT department specialists have their own 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 send to the developers of the program. Let them comment on all the objections. The truth, as always, is somewhere in between. The manufacturer wants to sell the program, your IT specialists do not want to take on unnecessary trouble.
But then you make the decision. Look at the payback speed, the intangible effect, the criticality for your business - and reach for the wallet. Or don't reach out. But you decide. And only to 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 to do independent testing. Of course, this does not mean that you have to do everything yourself, but you are the one who evaluates the program by 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, he must install the test software on employee computers and on the server. If you don’t want to conduct testing on a “combat” infrastructure, you can first create a test one (although in fairness I’ll note that business applications are best tested in a working environment: they can almost never “break” the system, which means there is no need to create a special “ sandbox ”, and only your working systems will be able to provide actual, not invented data for further analysis).
Secondly, the 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 (perhaps by redirecting requests to the support service of the manufacturer of software products).
And it's all! Other actions, including debriefing, are carried out only by business employees. Moreover, not everyone, namely those who should be interested in implementing this program, those whose life will be better after implementation, financial performance is higher, and work is more productive. If you make a mistake, load the business user with testing a program that he does not need, then be sure - he will give a negative review for the best program.
And finally, on the debriefing.Gather everyone who participated in the test, listen to everyone, but try to transfer the conversation to the discussion of the program’s functionality. Does she generate reports? Discuss whether it generates them well, what is missing, is it in the programs of competitors, if they were also tested. And if the implementation of the report generation program has already been adopted, firmly suppress feedback from places like “lived without reports and will continue to live”, “yes I’ll generate these reports for you with my own hands”, especially if they come from the IT department.
If the IT department specialists have their own 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 send to the developers of the program. Let them comment on all the objections. The truth, as always, is somewhere in between. The manufacturer wants to sell the program, your IT specialists do not want to take on unnecessary trouble.
But then you make the decision. Look at the payback speed, the intangible effect, the criticality for your business - and reach for the wallet. Or don't reach out. But you decide. And only to you.