Pre-launch testing and Healthcare.gov
Est. Reading Time: 2 minutes
I ran into this article today “Contractors describe scant pre-launch testing of U.S. healthcare site” and, politics aside, I can’t help but feel for the contractors involved. In my 20+ year IT career, I’ve run into multiple projects where the timeline and budget get squeezed beyond recognition and the pre-launch testing phase becomes the final casualty. Add to that a last minute scope change requiring “turning off anonymous browsing and requiring online visitors to create accounts before researching health plan information and determining their eligibility for federal subsidies to help pay premiums” (no small feat, I’m sure!) and I can see why the launch of Healthcare.gov has been fraught with such controversy.
It turns out that I feel so strongly about this topic that I even wrote a blog about pre-launch testing a few of years ago. Though web technology has advanced since then (particularly in the mobile space), the basics are still true. I think the key to preserving the integrity of the testing phase is to fully define the testing requirements before development even begins. For example:
- A carefully defined and approved requirements document that can be used as the “punch list” for testing the site’s functionality during the testing phase is critical. If scope changes are made during the development, the requirements document (and applicable testing plans) should be revised and approved accordingly.
- If the site is responsive, what devices will it be tested upon? There are a number of emulators and online tools that simplify this work, but it is important to define in advance. I was pleased to see that Healthcare.gov is responsive, but it doesn’t function particularly well on my Android device.
- What browsers (and versions of those browsers) will the site support? If a browser is not supported (curse you IE6 and 7!!!), what will the visitor experience using those older browsers? Perhaps a gentle message encouraging them to upgrade for optimal performance?
- When is the list of post-testing change requests due from the testers and is there enough time built into the schedule to resolve these issues before launch?
- Plan to use an approved testing checklist – don’t just hunt and peck around the site. Make sure you have a defined set of repeatable tasks that are performed in each browser and on each device.
Please share your experience and recommendations with pre-launch testing in the comments!