Over the last few months, we’ve talked a lot about the transformation we are starting to see in the IT industry including, but not limited to: the surge of digitization, drive towards total experience, data-driven imperative and, certainly, the ever-growing tech talent deficit.

My most recent blog on the tech talent deficit can be found by clicking here.

The trends are not going to stop, so the question becomes: what can we as tech leaders do right now to better prepare our teams and larger organization for the wave of transformation that’s coming?

Today, I want to dive into three things that Quality Engineering leaders (in particular) can start doing today to meet the challenges that are coming within the next decade.

Elevate the Product Owner

One of the most important things that has come out of Agile development is the ability to engage more directly with the business and translate more directly the business needs into features for use by end users. This greatly improves the end user experience.

To support this charter, it’s critical to have a strong Product Owner role. This should be somebody from the business who has direct communication with the end users and the people using the product. The Product Owner needs to be empowered to make decisions about development and should be directly involved throughout the design and development and release of any product or features. For this reason, we are also big advocates of the idea of Behavior-Driven Development (BDD). The advantage of BDD is that it enables business users to write user stories in plain English, which becomes easily translatable into features that developers can develop and testers can test to prove that the feature is “done”.

Rethink UAT

When we think about the end user experience, it’s also time to rethink the user acceptance test (UAT) paradigm. Historically, UAT has been a milestone event that occurs very late in the development and release process; this really limits its ability to have much impact on the quality of the release as it goes out the door.

It’s time to start re-defining UAT as a continuous opportunity to engage with true end users throughout, as opposed to its being a “once-and-done” event at the end of development and testing. Also, historically QE leaders have not gone consistently to the actual end-user community – that is, the people who currently use the product in their daily work, and who will be enacting the functionality you develop in actual workflows when new features are released.

It is a best practice for QE leaders to solicit that community to contribute a limited number of end users who will be engaged efficiently throughout the development process. If we re-imagine the UAT process, we can instead engage the end users on a frequent and timely basis, ensuring that they are reading user stories and looking at story boards, prototypes, user interfaces, and workflows to ensure the product is going to meet the business needs that they are facing day-to-day. When done this way, the traditional UAT event now becomes a confirmation event rather than a discovery.

Continuous Integration and Continuous Release

Finally, QE leaders need to start looking at test frameworks to make sure they are ready to meet the challenges of continuous integration and continuous release and dynamic or cloud provisioning. Most companies made a significant investment in test automation some years ago, which means these investments support an QE older paradigm. In many cases, these tests — although they might be effective at verifying functionality or ensuring that features have not regressed — may not be the most efficient in terms of being able to support the newer QE 3.0 paradigm.

Related Reading: Are You Ready for QE 3.0?

It’s time to go back and re-examine this investment and ensure that tests are written modularly, that you are testing at the optimum level (e.g., the user interface or API level), and that the data setup is not intensely manual and involving a lot of build processes that make it hard to do through dynamic provisioning.

It’s also important to make sure that the tests are designed to support reliable unattended execution in addition to being modular and correctly targeted. This ensures that the test frameworks can become enablers of a faster build process, as opposed to an additional potential stumbling block that you have to overcome to really get to that nirvana state of continuous integration.

What about you? As a QE leader, what do you believe are the top things we need to focus on as we prepare our teams for what comes next? I’d love to hear your thoughts. You can reach out to me directly by clicking here.