The Testing Wheel: A Framework for Planning Software Tests

Direct answer: Daniel Knott’s Testing Wheel is a framework for discussing a tester’s skills, strengths, and development areas with a team leader. It can help a team surface skill gaps that may affect its testing work, but it is not a test-plan template and does not determine which product features, risks, or quality attributes to test. If you need to select tests based on product quality concerns, a similarly named wheel from Abstracta has a different purpose.

This distinction matters because “planning software tests” can mean planning a person’s development or planning coverage for a product. Knott’s wheel helps with the first. Use a risk-based test plan, requirements, and product-quality goals for the second. Knott describes the wheel as an adaptable conversation aid, not a universal competency standard. Daniel Knott’s Testing Wheel article (PDF); Testμ conference materials.

1. What the Testing Wheel is for

The wheel gives a tester and their leader a shared structure for talking about current capabilities and possible areas to develop. The exercise produces a picture of how each person sees the tester’s skills, followed by a conversation about differences and practical next steps. It is useful when you want to guide coaching, identify potential gaps on a team, or discuss a person’s interests in a structured way.

It does not tell you that a product has adequate test coverage, that a person is objectively competent, or that a team will improve by a particular amount. The source material does not report measured effectiveness or validate the ratings as a universal assessment. Treat the numbers as discussion prompts.

2. The eight categories in Knott’s wheel

Knott’s article names these eight categories. Keep the labels tied to the original framework; teams can explain or adapt them to fit their context.

1. Understand the Project need — Discuss how well the tester understands what the project is trying to achieve and the context in which it operates.
2. Testing Essentials — Discuss foundational testing knowledge and practices relevant to the person’s current work.
3. Test Automation — Discuss the tester’s ability to work with automation as it applies to the team’s testing activities.
4. Get it Done — Discuss how the tester moves testing work forward and completes it in the project context.
5. Listen & Learn — Discuss how the tester takes in information, learns from others, and uses feedback.
6. Testing Team — Discuss how the tester contributes to and works with the testing team.
7. Personal Growth — Discuss the person’s learning and development interests.
8. Agile — Discuss how the tester works within the team’s agile practices and ways of working.

These are broad prompts, not detailed competency definitions. Before rating, agree what each category means for the person’s actual role, project, and opportunities. A skill may not be relevant to every team or role.

3. How to run a Testing Wheel discussion

1. Set the purpose. Explain that the exercise is for coaching and development. It is not an employee performance test or a pass/fail evaluation. Testμ’s conference materials explicitly caution against using the wheel for performance testing.
2. Explain and contextualize the categories. Set aside time to discuss what each category means in the current project. Give concrete examples of work or situations that might fit, without turning the category into a rigid checklist.
3. Choose a rating scale. Knott’s method uses a 0–7 scale. Explain the endpoints consistently—for example, 0 as little current experience or confidence in the project context, and 7 as a strong current capability in that context. The endpoint wording is a facilitation choice; the number itself is not an objective measure.
4. Rate independently. The team member and leader each assess the member’s current skills separately before comparing answers. This makes it easier to see where perspectives differ without one person’s first rating anchoring the other.
5. Put the ratings on one diagram. Plot both sets on the same wheel, using different colors or symbols and a clear legend. Keep the individual ratings visible rather than averaging them into a single score.
6. Discuss the differences. Ask what evidence or experiences informed each view. A mismatch is a prompt to understand expectations, visibility, and examples—not proof that one person is wrong.
7. Agree on a small development step. Choose a useful action such as pairing on a task, shadowing a colleague, taking ownership of a suitable testing activity, or revisiting a skill after relevant work. Record an owner and a follow-up date if that helps the participants.
8. Review when context changes. Repeat the conversation when the person’s responsibilities, project, or learning opportunities change. Do not treat the wheel as a score that must rise on a fixed schedule.

Facilitator checklist: confirm a coaching purpose; explain each category in context; collect independent ratings; compare rather than average; ask for examples; agree one or more development actions; and keep the result private to the people who need it for the conversation.

4. Turn ratings into a useful development plan

A rating is useful only if it leads to a better conversation or a next step. For each category you discuss, capture the two ratings, the examples behind them, and what the person wants to learn or try. Avoid making the wheel a list of deficits: high ratings can reveal strengths the team can share, while low ratings can reflect lack of opportunity rather than lack of ability.

Discussion signal	Questions to ask	Possible next step
Ratings are close and both are high	How could this strength help the team?	Share an approach, mentor a peer, or use the skill on a suitable task.
Ratings are close and both are low	Is this capability needed in the current role, and has the person had a chance to practice it?	Arrange supported practice or agree it is not a current priority.
Ratings differ substantially	What examples led each person to this view? Are expectations or observations different?	Clarify expectations and gather relevant experience before revisiting.
The person rates an area highly but the leader does not	Has the person’s work in this area been visible to the leader?	Find a suitable way to demonstrate or share the work.
The leader rates an area highly but the person does not	Does the person have confidence, interest, or a different view of what the category means?	Discuss strengths and whether the person wants to develop further.

Keep actions specific and within the team’s control. “Improve automation” is vague; “pair on the next relevant automation task, then discuss what was learned” describes an opportunity without promising an outcome. Revisit the discussion after the person has had a chance to act.

5. Adapt the wheel to your team

Knott says the number of categories and their contents can change to suit a company, team, or project. Adaptation is useful when it makes the discussion more relevant, but label changes clearly so participants know what they are rating.

• Keep the original eight categories if you want to follow Knott’s published version.
• Change the explanation or examples first; broad labels often fit different roles once grounded in local work.
• Add, remove, or rename categories only when the current set does not serve the conversation.
• Avoid adding categories that measure personal worth or turn the exercise into a disguised performance score.
• Document the scale endpoints and category definitions so repeated discussions are understandable.
• Do not compare people by adding ratings or ranking their wheel shapes. The exercise is meant to guide an individual conversation.

6. The Testing Wheel is not a product test plan

If your real question is “What should we test in this application?”, use a product-oriented planning process. Start from the system’s intended use, important risks, and quality goals; identify relevant behaviors and conditions; choose test approaches; and define evidence that would support a release decision. The Testing Wheel can surface team skills relevant to that work, but it does not supply the product risks or coverage model.

There is a second framework with a similar name. Abstracta’s Software Testing Wheel connects software quality factors and attributes with associated test types. Its focus is product quality and how to think about testing those concerns. Knott’s wheel focuses on tester skills and development. Neither wheel is a ranking of quality; choose based on the question you need to answer.

Framework	Main purpose	Organizing dimensions	Useful output
Daniel Knott’s Testing Wheel	Tester development and coaching	Eight areas of testing, teamwork, and personal growth	A paired discussion about perceived strengths and possible growth areas
Abstracta’s Software Testing Wheel	Relate product quality concerns to testing approaches	Quality factors, attributes, and associated tests	A view of quality concerns and testing approaches to consider

7. Capture a web page while documenting the discussion

If your team records the agreed wheel or a development resource as a web page, a screenshot can preserve how that page appeared at a particular point in the discussion. A screenshot is a record of a rendered page, not a substitute for the two underlying ratings, their context, or the conversation. For sensitive coaching records, follow your organization’s access and retention practices before saving or sharing captures.

For a local browser-based capture, install Playwright and its Chromium browser:

npm install playwright
npx playwright install chromium

Save this as capture.mjs and run node capture.mjs https://example.com. It takes a full-page PNG after the page load event, waits briefly for rendering, and reports navigation failures.

import { chromium } from 'playwright';

const target = process.argv[2];
if (!target) {
  console.error('Usage: node capture.mjs https://example.com');
  process.exit(2);
}

let parsed;
try {
  parsed = new URL(target);
  if (!['http:', 'https:'].includes(parsed.protocol)) throw new Error('Use http or https');
} catch (error) {
  console.error(`Invalid URL: ${error.message}`);
  process.exit(2);
}

const browser = await chromium.launch({ headless: true });
try {
  const page = await browser.newPage({ viewport: { width: 1440, height: 1000 }, deviceScaleFactor: 1 });
  page.setDefaultNavigationTimeout(45000);
  const response = await page.goto(parsed.href, { waitUntil: 'load' });
  if (!response) throw new Error('Navigation returned no main-document response');
  if (!response.ok()) console.error(`Main document returned HTTP ${response.status()}`);
  await page.waitForTimeout(500);
  await page.screenshot({ path: 'page.png', fullPage: true });
  console.log(`Saved page.png (HTTP ${response.status()})`);
} catch (error) {
  console.error(`Capture failed: ${error.message}`);
  process.exitCode = 1;
} finally {
  await browser.close();
}

Replace the example URL with a page you are authorized to access. For pages where the relevant content appears after client-side rendering, wait for a stable selector with page.waitForSelector('main') or wait for a specific application state rather than increasing a fixed delay indefinitely. To capture just one element, locate it and use locator.screenshot({ path: 'element.png' }). To save a PDF, use Chromium’s page.pdf({ path: 'page.pdf', format: 'A4' }) on a page designed for print output.

8. Or skip the browser setup

One GET request can return a screenshot through ScreenshotNeo, a website screenshot API and MCP server from Yorker Media. See the ScreenshotNeo API documentation for request options and response behavior.

cURL:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://screenshotneo.com/blog/ -o shot.webp

Python:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://screenshotneo.com/blog/"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

Node.js (Node 18 or newer, which includes fetch):

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://screenshotneo.com/blog/' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status} ${await res.text()}`);
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer())));

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before capture; bot checks, blank pages, and failed loads are never billed; an MCP server provides screenshot tools for AI agents; and 1,000 screenshots a month are free with no card, with paid plans starting at $5 for 3,000. Other listed plans are Growth at $15 for 15,000, Pro at $39 for 60,000, Scale at $99 for 250,000, and Business at $249 for 1,000,000; yearly billing gives two months free. Every feature is available on every plan. Responses include page-verdict and billing headers, and options include full-page capture, element selection, device presets, PDF output, waits, custom headers and cookies, caching, and async jobs. Review the docs before relying on a particular option or using captures in a workflow.

Sign up for 1,000 free screenshots a month, with no card required.

9. Reliability, performance, and cost considerations

For the coaching exercise

Reliability comes from consistent facilitation, not precision in the drawing. Use the same category definitions and scale during a given conversation, let participants rate independently, and preserve the difference between ratings. The wheel has no validated scoring model in the cited source material, so avoid calculating averages, targets, or team rankings from it.

For browser screenshots

Rendering time depends on the target page, browser startup, network conditions, and how much content must load. Full-page images can consume more time and memory than viewport captures. Prefer a meaningful readiness condition over a large arbitrary delay. Pages with animations, rotating content, ads, personalized content, or lazy-loaded media may vary between captures; control those conditions when repeatability matters. A failed page load should be treated as a capture failure, not as evidence that the page is blank or correct.

With a local browser, you pay in compute and maintenance: browser dependencies, runtime, and capture workers. With a hosted screenshot API, account for the plan limits and the options you use. ScreenshotNeo says cache hits and unsuccessful/unclean outcomes such as bot checks, blank pages, timeouts, and failed loads cost nothing; inspect its X-Page-Verdict and X-Billed response headers when tracking usage. Cache behavior can make repeated captures faster, but use a suitable TTL when you need a fresh view.

10. Troubleshooting

Symptom	Likely cause	Fix
Participants give very different interpretations of a category	Labels are broad and were not mapped to current work.	Pause ratings, agree examples and scope, then rate independently.
The wheel feels like an appraisal	Ratings are being used as targets, rankings, or evidence of employee performance.	Restate the coaching purpose, remove scoring pressure, and do not use the diagram as a performance score.
A low rating is treated as a confirmed skill gap	The person may not have had an opportunity to practice, or the rating may reflect confidence rather than observed work.	Ask for examples and context; agree on a suitable opportunity before drawing a conclusion.
Playwright reports that Chromium is missing	The browser binary was not installed in the environment.	Run npx playwright install chromium in the same project environment.
The screenshot is blank or incomplete	The page may require client-side rendering, a selector may be wrong, or navigation may not have reached the relevant state.	Check the URL and response, wait for a relevant selector or app state, and inspect console/network errors.
Navigation times out	The site may be slow, waiting on long-running requests, or unreachable from the capture environment.	Check reachability and the timeout; use an appropriate readiness event or selector rather than waiting for every network request to stop.
Only part of a long page appears	Content may load lazily as the page scrolls, or the page may change during capture.	Scroll through the page to trigger lazy content, wait for it to settle, or capture the relevant sections separately.
ScreenshotNeo rejects the request or returns an error	The API key, URL encoding, account access, or request parameters may be invalid.	Check the key, ensure the URL is encoded, inspect the HTTP response and documentation, and confirm the requested option is supported.
A capture is not billed or is not an image	The response may indicate a cache hit or an unclean/failed page verdict.	Read the response headers, including X-Page-Verdict and X-Billed, and handle the returned outcome explicitly.

11. Frequently asked questions

Is the Testing Wheel a standard assessment?

No. Knott presents an adaptable set of categories for discussion. The cited sources do not establish it as a validated or universal competency standard.

Should every tester aim for a 7 in every category?

No. The relevant skills depend on the person’s role, project, interests, and available opportunities. A higher number is not a universal goal.

Can a manager complete the wheel on a team member’s behalf?

The method is more useful as a comparison of independent perspectives. Have the team member and leader assess separately, then discuss the differences together.

Can this wheel tell us whether our product is adequately tested?

No. It is about tester skills and development. For product quality concerns and test types, see Abstracta’s separate Software Testing Wheel; for actual coverage decisions, plan from product risks and requirements.

Does the screenshot preserve the wheel’s ratings or discussion?

Only if those details are visible on the captured page. A screenshot records rendered pixels; keep the underlying development notes and discussion context in the appropriate record.