Appearance
C4 · Testing & Evaluation
Spec reference: Learning Aim C - Develop a Website to Meet Client Requirements Key idea: A website must be systematically tested and evaluated against the original client brief.
Why testing matters
Testing ensures your website:
- Works correctly across different browsers and devices
- Meets the client's requirements from the brief
- Has no broken links, missing images or layout errors
- Is accessible to all users
- Loads at an acceptable speed
In your assignment, you must provide evidence of testing - not just say "I tested it".
Types of testing
Functional testing
Checks that all features work correctly:
| What to test | How to test | Pass/Fail |
|---|---|---|
| All navigation links go to the correct page | Click every link | |
| Contact form validates correctly | Submit with empty fields / invalid email | |
| Contact form accepts valid data | Submit with correct data | |
| Images load on all pages | View each page | |
| No 404 errors | Click every link and image | |
| JavaScript features work | Use each interactive element |
Browser compatibility testing
Test in at least three browsers:
| Browser | Tested | Issues found |
|---|---|---|
| Chrome | ||
| Firefox | ||
| Safari / Edge | ||
| Mobile Chrome | ||
| Mobile Safari |
Responsive testing
Check the layout works on different screen sizes:
| Screen size | Tested | Issues |
|---|---|---|
| Mobile (375px) | ||
| Tablet (768px) | ||
| Desktop (1200px) | ||
| Large desktop (1440px) |
Use Chrome DevTools (F12 → Toggle Device Toolbar) to simulate different screen sizes.
Accessibility testing
- Run Google Lighthouse (F12 → Lighthouse → Accessibility)
- Check all images have alt text
- Test keyboard navigation (Tab key to move through elements)
- Check colour contrast with WebAIM Contrast Checker
- Test with browser zoom at 200% - does layout still work?
Performance testing
Run Google Lighthouse (F12 → Lighthouse → Performance):
- Aim for 90+ on all categories
- Note and explain any areas scoring below 90
Test table example
A test table documents your testing systematically:
| Test # | What was tested | Expected result | Actual result | Pass/Fail | Evidence |
|---|---|---|---|---|---|
| 1 | Click "Products" in navigation | Opens products.html | Opened products.html | ✅ Pass | Screenshot |
| 2 | Submit contact form with no name | Error message displayed | "Please enter your name" shown | ✅ Pass | Screenshot |
| 3 | Submit contact form with valid data | Success message shown | Success message shown | ✅ Pass | Screenshot |
| 4 | View site on mobile (375px) | Single column layout | Layout displayed correctly | ✅ Pass | Screenshot |
| 5 | View site in Firefox | Same appearance as Chrome | Slight margin difference | ⚠️ Issue | Screenshot |
Evidence
Take screenshots at each stage and reference them in your test table. Markers need to see that you actually tested - not just that you wrote a table.
Fixing issues found in testing
When testing reveals a problem:
- Describe the issue clearly - "The navigation menu overflows off screen on mobile (375px width)"
- Identify the cause - "The nav links don't wrap because of
white-space: nowrap" - Describe the fix - "Added a media query to hide desktop nav and show hamburger menu below 768px"
- Retest - confirm the fix works
- Document - add the fix and retest result to your test table
Evaluation
An evaluation is a written reflection on your finished website. It must:
- Measure against the brief - does it meet every requirement?
- Identify strengths - what works well and why?
- Identify weaknesses - what could be improved?
- Justify design decisions - why did you choose those colours/fonts/layout?
- Suggest improvements - what would you do differently or add next?
Evaluation against the brief - Sweet Delights example
| Client requirement | Met? | Evidence |
|---|---|---|
| Homepage with image banner | ✅ Yes | Hero section with full-width banner image |
| Product gallery (4+ categories) | ✅ Yes | Breads, Cakes, Cookies, Seasonal pages |
| Blog section | ✅ Yes | blog.html with 3 sample posts |
| Review section | ✅ Yes | Testimonials section on homepage |
| Contact form with map | ✅ Yes | contact.html with form and embedded Google Map |
| Warm brown/cream/pink colour scheme | ✅ Yes | Matches brand guidelines from brief |
| Handwritten heading font | ✅ Yes | Pacifico font from Google Fonts |
Writing a strong evaluation
Weak: "I think the website looks good and meets the requirements."
Strong: "The colour scheme successfully reflects Sweet Delights' brand identity - the warm brown (#6B3F2A) used for headings and navigation directly matches the brief's requirement for 'warm browns'. The pastel pink (#F4A7B9) accent colour is applied consistently to all call-to-action buttons, meeting the consistency design principle. However, the loading time on the Products page scores 78/100 on Lighthouse due to uncompressed JPEG images. In a future iteration I would convert these to WebP format to improve performance."
W3C Validation
Validate all HTML and CSS files:
- Go to validator.w3.org
- Paste your HTML or upload your file
- Fix any errors shown
- Include a screenshot of the "No errors" result as evidence
Summary
| Term | Meaning |
|---|---|
| Functional testing | Testing that all features work as expected |
| Browser compatibility | Testing that the site works correctly in multiple browsers |
| Responsive testing | Testing that the layout adapts correctly to different screen sizes |
| Test table | A structured record of what was tested, expected/actual results, and pass/fail |
| Evaluation | A written reflection measuring the finished site against the original brief |
| Lighthouse | Google tool (F12) that audits performance, accessibility, best practices and SEO |
Test Yourself
Question 1 of 5
What is the purpose of a test table in website development?