Frequently, when we talk about testing, we are talking about tests done by a dedicated testing team. More recently, development have also had to think about developer testing.
There are many different types of testing: development testing and automated testing such as unit testing, integration testing and regression testing; as well as manual testing performed by dedicated QA staff. One important type of testing that is frequently overlooked is business process testing, such as UAT.
What is UAT?
When you make a change in your ERP system, whether they are testing SAP ERP or Oracle EBS, you want to make sure it does what it is supposed to do.
Testing is important to ensure that innovation can occur. The era of infrequent releases for the waterfall age is over and we are living in the agile age. The digital transformation is here. Our development tests have adopted but shouldn’t our business tests follow through as well?
User Acceptance Testing, or UAT, refers to testing a software product by the end-user to determine whether it meets the technical and business requirements, and whether it can be accepted or rejected.
In simple terms: UAT verifies that the process does what the user expects it to do. In major business projects, failures in UAT can have dramatic impacts on the quality of the project, not to mention introduce serious risks in production.
User testing issue with UAT
However, one of the critical problems with UAT is clear in the name – user testing. Until recently, even software developers refused to test – resorting testing to “professional testers.” But technical code testing is not the same.
Most testers weren’t trained to do UAT. Mainstream testing literature doesn’t talk about UAT – since the focus is on the business not the technical.
Traditional testing may know about technical tests, but programmers and developers don’t have the business expertise that IT and key users have. Developers or analysts aren’t business users. Nor are they mind readers. Detailed functional specifications documents don’t replace testing by business users. Business users still need to make sure that their needs are met.
However, business users have other things to do besides test. They already have full-time jobs. Typically, UAT is not part of their job description and so they may resent needing to test. Isn’t this someone else’s job? What happens if they break something? Will they be blamed? There’s professional risk as well.
Traditionally, UAT has been cumbersome. Users frequently “opt out” due to lack of time. Of course, this hurts them later when critical functionality doesn’t work as expected.
It’s been especially challenging among complex ERP systems.
Any solutions?
However, there is a way out of the UAT mess. Modern tools, such as Panaya, brings your UAT to the next level. By working in the cloud, cumbersome Excel reports are eliminated. Managers stop wasting time compiling cumbersome reports and test handoffs are much easier.
Business users can conduct the UAT and their tests can be recorded in reusable test libraries. This gives the technical development team the information on how business users utilize the systems and provides them with real-life data. They can then turn these real-life test recordings into accurate test scripts and improve their system and conduct further tests based on real-world usage. This way business users can devote their time to driving business innovation while the technical team can ensure that their SAP ERP and Oracle EBS systems work and keep from becoming a bottleneck. This cooperation and breaking down of silos is core to increasing quality in today’s era of digital transformation.
