User Acceptance Testing (UAT) is one of the final phases in the project life cycle and provides end users of the system with the opportunity to test the system prior to its live state. It is the final check that the Business Processes will function in the manner they were intended and built.

You’ll be fully aware that Digital Transformation is at the top of every IT Directors list of things to do. Companies today are facing a couple of big challenges, staying ahead and on top of new technologies and at the same time providing outstanding customer experience. To be clear, Digital Transformation is the process of using new or modified business processes and customer experiences to meet changing business and market requirements by use of new and advanced technology.

In the previous part of this 2-part series, we identified how taking a Lean approach to testing can highlight various wastes that testers face in a project team, and external wastes that end users deal with. This concluding part will identify some solutions that can help with reducing the three types of waste, Muri, Mura and Muda and how continuous improvement can lead on to creating value for the customer.

In the first of this 2-part series, we will look at the various inefficiencies that are faced by testers in a project team, and for the users of the software that we are helping to deliver.

Successful DevOps needs automated processes throughout the software delivery life cycle. It relies on a culture and environment where building, testing and releasing software can happen rapidly, frequently and reliably.

When embarking on a Digital Transformation (DX) project, you would expect a few risk items to be on your radar, but only with actual experience of DX projects does it prepare you for the reality and true extent of the challenges you expect to experience.

The business as usual (BAU) team play a pivotal part of any Digital Transformation (DX) project. Not only do they keep the wheels turning whilst your company embarks on a digital upgrade, but also continue business essential projects whilst DX takes place. The person creating the DX Test Strategy must understand the ongoing goals of the BAU projects and be acutely aware of what is happening and when; this is to ensure and to allow the appropriate approach to be taken to capture changes to core and downstream applications before they are migrated to the new platform. Additionally, detailing the level of risk required to deliver the project to quality, time and cost should also be considered and mitigated.

I love solving problems. In fact, I like to consider myself to be a natural problem solver. It’s just how my brain works; I see an issue and instantly my mind switches into problem solving mode. And in IT, there are always problems to be solved.

So, let’s get this blog post rolling with a nice sterile quote from the internet to outline the what:

I often find many of the high-level risks have repeated themselves on the projects I’ve worked on. However, the risk profile, risk appetite, detail of the risk, how it gets managed, mitigated and controlled varies massively.