Testing for Web Development

On Thursday 14th March I did not manage to complete my next day in the #100DaysofCode challenge, as it was a classroom day for my Apprenticeship programme. We talked about how to test a website – an important part of the website design process.

So what is testing? Testing is investigation, exploration, mitigation, valuable, and potentially infinite. It requires good communication with the rest of the project team – developers, product owners, stakeholders, users, managers and the testers themselves (this is usually a specific team).

It is important that some testing is done throughout product development, rather than only finding out about a potentially system-breaking bug at the very end.

Here are my notes and things I learned from the training session, as well as some examples from my own experience.

Creating a Testing Plan

Creating a testing plan as part of your project plan is an important part of the project – it gives clarity on the scope of the project and gives confidence in the final finished product. Testing is potentially infinite and never truly ‘finished’ – so as part of the testing plan, developers have to prioritise what to test and be able to justify those decisions.

Tools to use: Asana/Trello (or similar) to keep track of bugs and ongoing issues, with the ability to assign tasks to members of a team with set due dates, progress, and the ability to add screenshots or additional info where needed; Chrome Developer Tools or Google Lighthouse; Awesome Screenshot or Loom; BrowserStack (browser cross-test functionality)

When creating a testing plan, consider your audience Рwhat are the most popular devices your audience uses? (Use Google Analytics to decide.) What connection speed do they have? Obviously testing will be limited by the resources, the project timeline and the budget, so the testing plan does need to be prioritised by business needs, such as the income and traffic value of certain devices:

  1. Fully supported browser or device
    All content is readable, all functionality must work, deviation from the approved graphic design must be minimal
  2. Partially supported browser or device
    All content is readable, navigation must work, business logins must work
  3. Not supported

Types of testing:

  • Functional testing
  • Usability testing
  • Interface testing
  • Compatibility testing
  • Performance testing
  • Security testing
  • Accessibility testing

We talked about each of these in detail and how we might be able to do these.

Usability Testing

This can be done at each stage, and includes remote and local tests such as card sorts, questionnaires, and analysing the user journey on an existing website. It also doesn’t need to be tested by hundreds of people.

Possible tools: Loom (browser recorded), InVision (to create design mock ups)

While assisting the agency with Happy’s new website, we conducted tests with delegates on training courses, showing them a mock up of the website on InVision. They were asked to complete a task (book a beginner Excel course) on the mock up, and the screen was recorded while they did it. When they had finished, they were then asked if they had any difficulties when using the site or if there was anything that they found confusing. These results were then analysed and used to improve the initial designs.

Interface Testing

This is to make sure that the web server and the application server work correctly. Are error messages displaying correctly? Are interruptions by the server or users handled well?

Compatibility Testing

This is to ensure that your website is compatible with common devices – for example, check that JavaScript, AJAX, Web Sockets, browser notifications and authentication requests are all working as designed on different browsers, operating systems and devices.

For Happy’s new website technical specification, I analysed the current website’s Google Analytics between 1st April 2017 and 31st March 2018. During this period, 49% of users were using Chrome, 21% used Safari and 15% used Internet Explorer or Edge. Of this 15%, 94% had IE11, 2% had IE9 and 2% had IE10.¬† Because of this, the original website brief specified that the new website would have to be compatible with users of Chrome, Firefox, Internet Explorer and Edge (IE9, IE10, IE11 and Edge). Some of the IE9 and IE10 users were clients in the public sector, who are restricted on what software they can use, so this made sense from a business perspective.

By the time the website build was underway in January 2019, these stats had changed – between 1st March 2018 and 15th March 2019, 96% of users were using IE11, 1.67% use IE9, 0.9% use IE8, 0.3% use IE7 and 0.3% use IE10. Just one booking from came from a user on IE9 and three from IE10 users. Because things have obviously changed in the last year, we decided to change the technical requirements of the new website to only support IE11.

Performance Testing

How does the website fair under pressure? This includes load testing (how the site performs under usual conditions when multiple users access it simultaneously) and stress testing (how much traffic it takes to break a website – e.g. if a site suddenly goes viral).

The accepted page speed is 85/100.

Possible tools: Google Lighthouse (gives page speeds and insights)

Security Testing

This is testing for a bug in a website that allows someone to access the system to steal data or manipulate the site in a way that is not intended. We had a workshop in November that talked about security testing in more detail and gave us the opportunity to test and play about with a website in a testing environment, to see if we could manipulate it – and thus know what to look for in our own websites.

Things to test include whether secure pages can be accessed without authorisation, that open sessions are closed after ongoing user activity, verify the website’s SSL certificate, and make sure that restricted files cannot be downloaded without authorisation.

Accessibility Testing

I have covered a lot about this recently – from my recent Treehouse studies and from the workshop we had with Andrew Macpherson.

Things to test include checking the site against the Web Content Accessibility Guidelines (WCAG) to A or AA standards. Even if a review has been done by an external team, fixing the issues and then testing them also counts.

Tools: How to Meet WCAG 2 (Quick Reference Guide); W3C Web Accessibility Initiative (WAI)

Further resources (all open in a new tab)

If you have any other useful links or tools I should know about, please leave them in the comments below!

Leave a Reply

Your email address will not be published. Required fields are marked *