QA & Review

This SOP covers how work is tested, reviewed, and approved before it goes live. It is part of the Inkblot SOP Library — a reference set of SOPs that are activated selectively as needed.

Overview

Quality assurance at Inkblot is a multi-layered process. Every piece of work goes through self-review, peer review, and client review before it is approved for deployment. The goal is to catch issues early, ensure design fidelity, and deliver work that meets both our standards and the client’s expectations.

Steps

1. Self-Review

Before requesting any external review, the developer should:

• Test locally — Verify the feature works as expected across different screen sizes (mobile, tablet, desktop)
• Cross-browser check — Test in Chrome, Firefox, and Safari at minimum
• Design comparison — Compare the implementation against the Figma designs, checking spacing, typography, colours, and responsive behaviour
• Content check — Ensure all content is correct, no placeholder text remains, and CMS-driven content renders properly from Sanity
• Performance — Check for obvious performance issues (large images, unnecessary re-renders, slow page loads)
• Accessibility — Verify basic accessibility: keyboard navigation, alt text on images, proper heading hierarchy, sufficient colour contrast
• Console check — Ensure no errors or warnings in the browser console

2. Code Review

• The developer opens a pull request on GitHub (see Development Workflow SOP)
• Jonathan de Kock (Web Dev Lead) reviews the code for:
  • Code quality and adherence to Inkblot coding standards
  • Component architecture and reusability
  • Performance implications
  • Security considerations
  • Sanity schema correctness (if applicable)
• Reviewer leaves comments on the PR; developer addresses feedback and pushes updates
• PR is approved once all concerns are resolved

3. QA Testing

• Use the Vercel preview deployment generated for each pull request to test in a production-like environment
• Test all user flows and interactions end-to-end
• Test on real devices where possible (not just browser resizing)
• Verify CMS content editing works correctly in Sanity Studio
• Check forms, links, navigation, and any interactive elements
• Log any issues found as comments on the PR or as sub-tasks in ClickUp

4. Client Review

• Once internal QA passes, share the Vercel preview link with the client
• Provide a brief summary of what to review and any known limitations
• Give the client a clear timeframe for providing feedback
• Log client feedback in ClickUp and triage into actionable tasks
• Address feedback, then re-share for a second review if changes are significant

5. Sign-Off

• The client confirms approval (via email or ClickUp comment)
• The project lead (Adriana) confirms all feedback has been addressed
• The PR is approved and ready to merge
• The project status in ClickUp moves to the next stage (typically toward deployment)

Bug Reporting

When bugs are found during QA:

• Where to log: As comments on the relevant PR for code-level issues, or as ClickUp tasks for broader issues
• What to include: Description of the bug, steps to reproduce, expected behaviour, actual behaviour, screenshots or screen recordings, browser/device information
• Priority levels:
  • Critical — Blocks launch or causes data loss; fix immediately
  • High — Major functionality broken; fix before launch
  • Medium — Noticeable issue but workaround exists; fix in current sprint
  • Low — Minor cosmetic or edge case; can be addressed post-launch

Owner

Jonathan de Kock (Web Dev Lead) owns the technical QA and code review process. Adriana van Rooyen (Project & Operations Manager) coordinates client review cycles and sign-off.