As discussed in the first part of this series, there are 9 things that project manager should not do in order to make UAT successful. And the previous article has introduced and discussed the former 4 of them.
This article will discuss the rest 5 of them.
Keywords: project management, project, UAT, user acceptance test, software development
5. Grab whoever is available
Junior project managers may say, "UAT is just a test, and it is just a very simple task. If the key team member is not available for the UAT, then just let somebody else who’s available do the tests. Perfect!"
Well, actually not everyone can do the UAT tests. The main reason is that UAT is to validate the product from the user’s perspective. And for this reason, the ones who perform the UAT acceptance tests should be proficient in business needs. The perfect person for performing the UAT tests should be representative users of this product. Therefore, you can not simply grab someone who’s available to perform UAT tests. If you happen to grab someone who’s not very familiar with the user’s business requirements for this product, then the UAT would be very possible to fail.
6. Skim the surface!
Junior project managers may say, "UAT tests are very simple. Just let the users click some of the “buttons” and use the software a little bit. There is no need to test every user case since all the technical tests have been passed before the UAT. There should be no problem. In other word, UAT tests are just for skimming the surface of the product."
Well, the biggest issue with “just skimming the surface” is that the technical tests before UAT and the acceptance tests in UAT have different focus points. The technical tests before UAT mostly focus on verifying the product’s function, performance, and reliability. Hence the technical testers just have to make sure all these results are aligned with the technical requirements of the product. But the technical eligibility could not represent the user’s satisfaction with the product. In other words, the final purpose of UAT tests is not just from a technical perspective. Therefore, both the acceptance personnel and development team should accept and take UAT seriously.
7. Lack of effective communication
Junior project managers may say, "If there was some issue being discovered in UAT tests, just post it by an instant messaging tool such as WhatsApp. All stakeholders can see the information in the group chat, how convenient is that! Perfect!"
Well, we all know that instant messaging tools are mostly used for what we called Push Communication, which means the stakeholders could not receive the information in real-time and can not read your emotional expression when you’re typing the message, neither can you read the emotional expression of the message receivers. Therefore, if conditions allow, it would be best if the UAT acceptance personnel and the development team can be in the same office or meeting room for discussing the issues. Face-to-face communication is very high efficient and the issues discovered by UAT tests can be resolved quickly. If we use the non-face-to-face communication like email or instant messaging tools, then the communication efficiency would below. As a result, the problems which should have been solved in very little time maybe need half a day or even longer to be solved. This would furthermore lower the efficiency of UAT tests.
The issues and problems discovered in the UAT tests are suggested to be documented in a certain defect tracking tool for unified tracking management. For example, JIRA is one of the good defect tracking and management tool.
8. Fail to identify all key stakeholders
Key stakeholders for UAT mainly mean the user or acceptance personnel for accepting the final product.
In this case, the junior project manager may say, "Why should we identify stakeholders? Just invite whoever submitted all those requirements to come to the UAT tests as acceptance personnel. And that would be enough! Why bother anyone else?"
Well, sometimes UAT acceptance tests are not just about the acceptance of business requirements and functions, it may involve acceptance of something else. For example, UAT tests could involve acceptance of financial aspects of the project if there had been changes of financial accounting in the process of the project. In this case, the key stakeholders for UAT could include the financial staff. An essential reason for including financial acceptance in UAT tests is to avoid any financial accounting problems or outstanding obligations caused by the problem data after the product was running online. Therefore, before UAT tests, all key stakeholders should be identified and included in the UAT, in order to avoid an incomplete UAT acceptance. Only if all perspectives for the product being running online normally are accepted, then the UAT acceptance can be considered as successful.
9. No review or summary after UAT
Junior project managers may say, "If UAT acceptance turns out to be successful, and no problem or defect is found during UAT tests, there would be no need for review or summary after the UAT. On the other hand, if the result of UAT turns out to be very bad, then having a review or summary meeting after UAT would force us to recall all those bad memories and reveal those scars again, and what good would that be?"
Well, there is an old Chinese saying – “Learning without thought is labor lost, and thought without learning is dangerous” – it basically means that if you do not learn from the failure or mistakes, then there would be no improvement for you in the future. Review and summary are to learn from the bad things in the process of UAT, and would significantly help you avoid all those bad things for future projects. We could think of the UAT tests as “Check” as in the “PDCA” cycle, and the review and summary would be the “Action” of the same cycle.
In summary, as the second part of the series, this article introduces and discusses the rest 5 things which project manager should avoid in order to make UAT acceptance tests successful. Hope this series would be helpful for those software development project managers.