User Acceptance Testing (UAT) with Release Ephemeral Environments

Product Managers, Designers, QA teams, and product stakeholders are always last in line...

Are you a Product Manager or Designer that would love to get a sneak peak at new features being built? Have you ever had to perform User Acceptance Testing (UAT) without a trusted environment? Have you ever wanted a demo environment, but find it too cumbersome and expensive for your DevOps to spin up for you? Does your QA team struggle with having enough environments they trust for feature testing? With Release’s Ephemeral Environments, it’s possible to view a developer’s changes at any time or any place. You don’t need to worry about having the proper environment variables in place or running any code locally.

If you have the ability to ideate quicker using environments, then you can refine your product with features that are truly worthwhile to users.

Environments are a critical resource needed by Product Managers, Designers, QA teams and product stakeholders, but they are difficult and expensive for DevOps teams to create and maintain. It’s hard enough to create environments for the core development team, let alone environments for these auxiliary support roles for their needs. Usually this means these roles have to do without, which results in slower than ideal product velocity and less than ideal product solutions.

Teams typically measure throughput velocity by measuring the number of features released over time. This standard metric is worthwhile in knowing how fast things are pushed out the door, but there is still a challenge in knowing if those changes are relevant and important to the customer. Yes, you may be pushingout features, but are they features your customers want? If you have the ability to ideate quicker with stakeholders vieiwng and giving feedback in the development process then you can refine your product faster with features that are truly worthwhile to users.

Current Product Management Software Tools for sharing features are less than ideal...

Sharing in-progress feature development is vital to ensuring features are developed correctly and meet customer needs. So how do companies usually solve sharing work-in-progress changes? Here are some of the current solutions and pitfalls to solve sharing development in progress:

• Sitting over your developer's shoulder (during covid quarantine this is likely a zoom). The downside is that you only get a ‘show n tell’ without the ability to fully experience the app.
  
• Use ngrok or another tunneling technology to portal into another local machine. This approach lacks prod-like data that won’t persist, performance is limited to the local dev laptop, and the portal closes after a short time.
• Send static screenshots back-n-forth offers no dynamic interactivity.
• The most common solution is shared staging environments, but this single shared resource creates a bottleneck across the organization and you have to wait for access. Data can be changed out from under you making testing/previewing difficult too.

Release Ephemeral Environments solve a major pain point for collaborative User Acceptance Testing (UAT)

The main premise behind Release is to enable teams to move faster by previewing each other’s work in rapid fashion automatically with every PR or at the click of a button. This opens up a new door for support-related roles to view work-in-progress through environment that may have been inaccessible before. Product Managers, UI/UX Designers, Quality Assurance (QA), Sales & Marketing teams, and Senior Management can now open up an environment and see new product changes while they are being developed. There are many use-cases ranging from: sales demos, stakeholder feedback meetings, previewing features, major product version launches, bug fixes, test databases, and user research focus groups.

Release Ephemeral Environments offer an accessible avenue for collaboration between developers and the various support roles that are all working toward a unified product vision. This allows for all team members to be involved as early as possible in the development process which increases velocity and quality, while removing costly rework. It can be counterproductive for people to work in silos, then find out later on during a team meeting that a new feature is off the mark. When development work is shared easily and often, it fosters a higher quality, faster product iteration which yields a competitive edge, delights your customer base, and boosts team morale.

How do you share Release Ephemeral Environments with product development stakeholders?

When a developer makes a feature branch in their source control system, Release automatically creates an ephemeral environment that anybody can preview with a simple URL to the environment. This makes UAT incredibly simple.

Different methods for sharing Release Environments:
Copy/paste the URL and send via message or email

Slack integration posts your PR environments into a channel for easy sharing

Log in to Release, find the Environment, then click the link

Log in to GitHub or BitBucket, find a Pull Request and click the Environment link

Enter a URL variable in Release which enables Public environment-sharing

Conclusion

Release Ephemeral Environments give your ENTIRE team a competitive edge when developing new product features and performing UAT. Support team members that are engaged in non-coding work can now participate early and often in the development cycle. DevOps teams can spend less time managing environmnents and spend more time working on vital needs of the business. The end result is faster development with products that truly meet customers needs.

You might also like: