Quality assurance has become the most common afterthought in our industry. Websites need to be built quickly and efficiently, which doesn’t leave much time for tedious tasks like testing. Convincing your managers, or possibly even convincing yourself to commit to quality assurance, can be tough. You’re confident in your team’s ability to write quality code, why would you need to invest so much time in testing it out afterwards? It looks great in staging so it should look great in production, right?
The reality is that every website, no matter how “lean,” is essentially a mess of independent technologies stitched together with good intentions. In theory, these technologies are more than capable of intermingling. In reality, there are far too many points of failure for any one developer to predict. This is where a well-established QA process comes in. You must catch mistakes and failures before your users do, especially when it comes to first impressions.
To illustrate this, I want to share a pretty damning story about the first time I demoed bastions with a potential customer.
A valuable mistake
Bastions started out as a testing tool specifically for lead generation forms on websites (contact forms, sales forms, etc.). It still services this niche in the form of its integrations and job templates, but I ended up pivoting to provide more general testing early on. My prospect, a B2B web development agency, was very interested in bastions’ core service at the time so they scheduled a demo.
I got through the presentation deck, started showing them bastions’ key features, and created a new test to demonstrate its ease of use. Everything was going smoothly, until I decided to show them a new feature that I had pushed to production the previous day. After having bragged about this new ‘run on-demand’ feature, I attempted to run the new job I had created for them. The page loaded, the timer began, and there it went.
And it went.
And it went.
Something was clearly wrong, and I was embarrassed. I tried to run the job again, assuming it was a one-off error that wouldn’t happen twice, but I was blocked by my own safeguard put in place to limit running on-demand jobs to one. This meant that the feature did not work on the front-end nor the back-end. It was official: the feature was broken, and I looked silly.
This prospect ended up passing on bastions, and I don’t really blame them. I was pitching them a QA product that had obviously not done enough QA on itself. I was embarrassed, I wanted a do-over.
Unfortunately, there are no do-overs when it comes to first impressions. No matter what I came back with, this person would always associate my product with error and laziness. I had failed their expectations and, more importantly, I had failed the product.
QA is your duty, not your burden
We should be associating a sense of responsibility with our projects. Whether it’s for work, or a labor of love, it is our duty to ensure that the project is in a presentable state. If you’ve taken a project all the way from inception to launch, you should perform the due diligence customers expect.
Reid Hoffman, founder of LinkedIn, once said,
“If you are not embarrassed by the first version of your product, you’ve launched too late.”
This is a very sound piece of advice. However, I don’t believe that Mr. Hoffman is handing out a “free pass” to launch your product without establishing a proper QA process. Believe me, even with a QA process, there will be plenty of things about your product to be embarrassed by at first. Do yourself a favor and make sure those embarrassing moments aren’t due to your basic features failing.
Establish a QA process, whether that be automated or manual, and stick to it. Don’t ignore your responsibility to test, it will come back to haunt you.