Quality and Test Plan

Phase: Planning | Audience: Internal | Project: WEB-2026-01 Corporate Website Development

Understand it first

In simple words: The Quality and Test Plan defines what 'good quality' means for this website, how it will be tested, how serious each defect is and when testing can start and finish.

Think of it like: Before a restaurant opens, the owner decides the standards (food hot within 15 minutes, clean tables), tastes every dish, and does not open until serious problems are fixed.

When is it created?	Planning (12 Oct 2026)
Who prepares it?	QA Tester
Who approves or uses it?	Project Manager
What happens next?	Test cases are written and run; the client does UAT

How it connects to other documents

Targets come from the RFP's non-functional requirements (speed, browsers, accessibility).
Leads to the UAT Test Cases and UAT Sign-off.
Exit criteria are checked in the Go-Live Checklist.

The sample document

Below is the actual document for project WEB-2026-01. Read the purpose first, then go through each numbered section.

Issued by: [Your Company] Technologies Pvt. Ltd.

Purpose: Quality targets for the website, the testing approach, defect rules and the criteria for moving between stages.

Item	Detail
Document no.	WEB-2026-01/QTP
Version	1.0
Date	12 Oct 2026
Owner	QA Tester
Audience	Internal
Phase	Planning
Status	Approved

1. Quality targets

Area	Target	How measured
Performance	Load under 3 s on 4G; mobile PageSpeed score 80 or more	Google PageSpeed Insights
Responsiveness	Correct layout at 360, 768, 1280 and 1920 px	Browser tools and real devices
Browsers	Latest two versions of Chrome, Safari, Edge, Firefox	Manual testing
Accessibility	WCAG 2.1 AA contrast, alt text, keyboard navigation	Contrast checker, keyboard test
Forms	Email reaches sales inbox within 1 minute	Test submissions
SEO	Unique title and description on every page; sitemap submitted	SEO plugin report
Defects at launch	Zero critical or high defects open	Jira defect board

2. Test types

Test	What	Who	When
Design review	Designs against requirements	PM, client	Week 3–4
Unit and developer testing	Each template and component	Developers	Weeks 5–8
System testing	All pages and functions	QA	Weeks 8–9
Cross-browser and device	Layouts and behaviour	QA	Week 8
Performance and accessibility	Speed and WCAG checks	QA	Week 9
User acceptance testing	Business scenarios	Client	1–4 Dec

3. Defect severity

Severity	Definition	Example	Fix time
Critical	Site or key function unusable	Contact form does not send	Same day
High	Major function wrong, no workaround	Menu broken on mobile	1 working day
Medium	Function works with a workaround	Gallery filter slow	3 working days
Low	Cosmetic	Spacing off by a few pixels	Before go-live if time allows

4. Entry and exit criteria

Stage	Entry	Exit
System testing	All pages on staging; content uploaded	All test cases run; no critical defects
UAT	System testing exit met; UAT script shared	All UAT cases passed; client sign-off
Go-live	UAT signed; go-live checklist ready	Smoke test passed on production

WEB-2026-01/QTP · v1.0 · Internal. Bracketed items such as [Client Name] are placeholders.

Key takeaways

Quality targets must be measurable (under 3 seconds, PageSpeed 80+).
Define defect severity before testing starts.
Entry and exit criteria stop half-ready work moving forward.

Common mistakes to avoid

Testing only on one browser or device.
Arguing about severity during UAT because it was never defined.
Launching with high-severity defects open.

Next lesson: 22. Procurement Plan