5. Standard Tools & Providing UAT Feedback
Testing is the final safeguard before launch. This guide outlines the environments we use, the tools required, and how to manage feedback effectively to protect your budget and timeline.
Environment Strategy
HubSpot has specific limitations regarding data and configuration replication compared to traditional software development. As automated options for moving configurations between environments are limited, we adapt our approach based on the project type to minimise risk.
While planning your organisational testing and UAT, you should be considering what type of data and testing is required. If real data and end to end testing is required, you may need to test in Production.
If testing in production, you will need to consider how you ringfence real data and production processes and contacts, and clear any test data from the system once testing is complete.
Brand New Portals
For a completely new build, we typically develop directly in the Production environment. This reduces the risk associated with manually replicating complex configurations from a Sandbox. Once the build is approved, we copy the state to a Sandbox during the cutover process to create a safe testing space for future updates.
Existing Portals
When enhancing a live portal, we work in a Sandbox environment first to ensure daily operations are not disrupted. Once tested and approved, these changes are part automatically through replication tools and manually replicated in Production.
To limit costs for manual replication, we try to limit the configuration of lower risk items such as reporting to production only.
Avidly APAC also uses specialised partner tools to support more advanced environment replications. It should be noted that these tools are not available to direct customers or supported by all partners.
Standard Tools
HubSpot
This is the core platform we are onboarding or enhancing. Depending on the strategy above, your testing will take place here, either in the live instance or a designated sandbox.
Workstreams Portal
Our proprietary project management platform acts as the central hub for the project. You will use this to raise new feedback items, monitor existing feedback items, provide additional feedback and close resolved and verified feedback items.
Marker.io
For web-based builds, we install this widget on the test app or site. It allows testers to annotate feedback, and automatically record technical data (browser, OS, screen size, previous steps, underlying browser errors) without leaving the page.
Sentry
Sentry is an error monitoring platform that helps us track and fix bugs in real-time, even those that don't cause an immediate, visible crash.
We integrate Sentry into your build during our internal testing phase and keep it active through UAT and the 30-day warranty period.
This allows us to:
- Catch Silent Errors: Identify and resolve errors that might not be visible to the end-user but affect performance, data integrity, or future stability.
- Proactive Quality Assurance: Improve the overall quality of the build by being proactive in identifying and fixing otherwise silent errors.
- Faster Troubleshooting: When strange or intermittent issues occur, Sentry provides detailed stack traces, context, and user environment data, drastically speeding up the diagnosis and resolution process.
Ongoing Monitoring
If you would like to continue leveraging Sentry's proactive error monitoring beyond the warranty period, you can opt into our ongoing maintenance service. Through this service, we proactively run corrective and preventative maintenance across your site, using Sentry data to identify and address emerging issues before they impact your users, ultimately improving and hardening your site over time.
Test Scripts and Instructions
It is recommended that you provide your internal test team with clear test scripts to streamline and ensure you get the desired outcomes from the testing process.
These should outline specific user journeys to ensure testing remains focused on the agreed scope and functional requirements.
Managing Feedback & Scope
The Gatekeeper
To maximise the value of your budget, the development team should be focused on resolving confirmed issues.
An internal review of feedback ensures that agency resources are directed towards fixing valid defects, rather than time being lost on triaging duplicates or non-issues.
Staying in Scope
Testing naturally generates new ideas. To protect the project timeline, it is important to distinguish between defects and requests that sit outside the original requirements.
By logging new features for a future phase, we ensure the team remains fully focused on delivering the agreed scope for launch.
Raising Actionable Issues
Clear feedback allows us to reproduce and fix issues quickly. Vague reports lead to wasted time and delays.
- Location: Specify the exact page or CRM record (not required where logging from Marker.io widget).
- Steps: Detail the steps taken to trigger the issue (not required where logging from Marker.io widget).
- Actual vs. Result: Contrast what happened against what you expected.
- Examples: Attach screenshots or videos using the tools provided (not required where logging from Marker.io widget).
For a comprehensive guide on structuring your reports, please refer to our Raising good feedback article.
Working with your Avidly APAC PM
Please confirm which team member will act as your internal triage gatekeeper so we can arrange their access to the Workstreams Portal and provide them with guides and information to support their testing and UAT process.