The Website QA Lessons We Learned in 2018

In This Post

• Dig Deep to Define Requirements
• Prioritize Customer-Found Defects
• Download: Website Testing Checklist
• QA Common Sense

My company was awarded a record number of website QA projects in 2018. I recently called a meeting of all of our QA Managers for the purpose of sharing what we had learned after conducting so many test plans for the new and existing clients. Here’s a recap of what I heard from the team. Use this information to help guide your next website QA project.

Dig Deeper into Website QA Requirements – Every Time!

Defining requirements upfront has been a key tenet of TESTCo’s software testing since we started in 2002 It’s no different for website testing. “Just test it” just doesn’t turn out very well.

Deeply understanding the client’s needs about their website leads us to design the right test plan – how much effort do we place on functional testing versus feature-based testing for example. Or, if the site has been updated, should we consider regression testing?

In 2018 we were reminded, time after time, how important it is to know the client’s target audience well. If we know who will be using the website we can design the correct test coverage. Knowing the devices and browsers used by most of the website visitors is mandatory, but so is demographic and lifestyle characteristics. Of the client’s audience we like to know how techie they are, what countries do they reside in? Knowing age and gender of the users is also useful to us when designing an effective test strategy.

There’s a dollar and cents rationale for designing the test coverage to match the user profile. It seldom makes economic sense to invest resources testing on a device used by, say, 1% of your website’s visitors. There are too many devices, operating systems, and browser versions to test them all. Therefore we communicate with the client to define upfront the scope of the test coverage.

Set the Website QA Bar for Customer-Found Defects

Not all defects are considered equally unacceptable by the client. We have learned over the years, and it was reinforced in 2018, to help the client define for us what type of defects are the most important to them and to their users. We ask two simple questions about Customer Found Defects (CFP):

• “What type of defects are you okay having in your website?”
• “What type of defects are you not willing to have in your website?”

For example, a button that doesn’t resize correctly but is still readable might be acceptable to some clients as long as the button functions properly. For other clients, the button must resize and function. Our testing finds both defects, but, we will report them differently. In the former case the resizing defect will be classified as Low Priority. In the later example, the defect will receive a High Priority status.

Because writing test plans for UI testing is very time-intensive, we prefer to use checklists. Test plans are always written for features, function and regression testing.

A Website Testing Checklist for You

Website QA Common Sense?

At the end of my meeting with the QA Managers, I said something along these line, “Guys, this is good stuff, but it’s just plain common sense. Software Testing 101. Why are you telling me that identifying requirements is the biggest lesson of 2018?”

Here’s what they told me. “Jeff, it’s because our clients’ internal QA teams don’t do it well and neither do the other website QA companies they’ve tried. The testing starts to go off the rails immediately because the goals and requirements aren’t clearly set first.”

Enough said. Have a website testing project coming up? I’d welcome the opportunity to talk to you about it. Just request a call back by using for blue and green button on this page.