TestDel delivered a high number of portals QA projects in 2019. We just called a meeting of all of our QA Managers for the determination of lessons learned after managing so many test plans for the new and existing clients. Here’s a summary of what we perceived from the teams. We highly recommend checking this lesson learned to benefit your next website quality assurance.
Examine carefully into Requirements – Every Time!
Describing requirements upfront has been a key principle of TestDel software testing since we began, It’s identical for website testing. “Just test it” just doesn’t fit out very well.
Intensely understanding the client’s needs about their website indicate us to design the accurate test plan – how much work do we focus on functional testing versus feature-based testing for pattern. Or, if the site has been restructured, should we consider regression testing?
In 2019 we were recapped, time after time, how essential it is to know the customer’s target audience well. If we recognise who will be using the website we can build our strategy for appropriate test coverage. Understanding the devices, browsers, IOS used by most of the website visitors is mandatory, but so is location and regime characteristics. After checking customer audience we like to know how much technical they are, which countries do they reside in? Knowing the age and gender of the users is also valuable to us when designing a successful test strategy.
There’s a pound and pennies foundation for designing the test coverage to match the user profile. It occasionally makes economic sense to invest resources testing on a device used by 1% of your website’s visitors. There are numerous devices, operating systems, and browser versions to test them all, Therefore we connect with the client upfront to outline the scope of the test coverage.
Set the appropriate severity and priority of defects
Not all defects are measured equally intolerable by the customer. We have learned over the years, and it was covered in 2019 as well, to help the customer describe for us what type of defects are the most significant to them and to their users. We raise two simple queries about defects raised by the client:
- What type of defects are you okay consuming in your website?
- What type of defects are you not willing to have in your website?
For instance, a button that doesn’t resize properly but is still understandable might be adequate to some customer as long as the button functions properly. For other customers, the same button must resize and function because it is used for a critical process. Our verification uncovers both defects, but, we will report them differently. In the former case, the resizing defect will be classified as Low Priority. In the latter example, the defect will receive a High Priority status.
Because writing test plans for UI testing is very labour-intensive, we adopt using checklists. Test plans, scenarios, and test cases are always written for features, function and regression testing.
Testing artefacts services for You
Have a website testing project coming up? We welcome the opportunity to talk to you about it. Send us a query so we can be in touch with you to provide a free quote.