Vendor questionnaire

81 questions by theme, each with why it matters and what strong and weak answers sound like.

What this does

The question bank holds 81 questions in 8 themes: team and staffing, process, automation and code ownership, tooling, security and data, reporting, commercials and exit. Each question is written to make a vendor show how it actually works, not how it describes itself.

Choose your situation and themes, add your details, and export either the vendor version with answer spaces or the buyer's guide with the rationale and answer markers. The CSV works as a form: vendors fill the answer column, your evaluators fill the score column.

See a sample output

QA vendor questionnaire: buyer's guide

ChooseQAVendor framework v1.0. Situation: Automation build-out. 27 questions. Nothing you enter in the toolkit is sent anywhere.

Issued by Example Product Ltd. Please answer every question in writing by Friday of week 3. Answer with specifics: names, documents, numbers and examples. Where you cannot answer, say so; a blank or generic answer scores zero.

Team and staffing

Who actually does the work, how senior they are, and what happens when people leave.

1. Who, by name and role, will work on our account in the first three months? Please share their CVs and confirm these are the people who will start, not examples.

Why it matters: The people named in a proposal are often not the people who arrive. Asking for named CVs up front lets you hold the vendor to the team you evaluated.

Strong answer: Named individuals with CVs, their current allocation, a start date for each, and a willingness to list them as key personnel in the contract.

Weak answer: "Sample profiles", "a team like this", or "we will assign the right people once the contract is signed".

2. Who is the single accountable lead on your side, how much of their time is allocated to us, and what decisions can they make without escalating?

Why it matters: A lead spread across many accounts cannot make timely decisions. Knowing their allocation and authority tells you how fast problems get resolved.

Strong answer: A named lead with a stated percentage of time on your account, a list of decisions they own, and the escalation route for the rest.

Weak answer: "Your account manager will coordinate everything" with no allocation or decision rights stated.

3. How will your testers work inside our team day to day: which of our meetings do they attend, whose backlog do they work from, and who on our side assigns their work?

Why it matters: Testing works well when testers sit in the delivery team rather than receive builds over a wall. The answer shows whether the vendor expects to be embedded or separate.

Strong answer: A concrete working model: which ceremonies they join, the shared tools and backlog they use, and a named buyer contact who prioritises their work.

Weak answer: "We adapt to any process" with no description of how, or a model where testing happens only at the end of each release.

7 more pages in the download.

Build your questionnaire

Keeps the questions that apply to your situation. Choose no specific situation to include all.

Themes to include

Appears in the introduction the vendor reads.

For example a date, or 'with the proposal'.

The vendor version has answer spaces. The buyer's guide adds why each question matters and what strong and weak answers sound like: keep it for your evaluators.

81 questions selected.

QA vendor questionnaire

ChooseQAVendor framework v1.0. Situation: General. 81 questions. Nothing you enter in the toolkit is sent anywhere.

Issued by [Buyer]. Please answer every question in writing. Answer with specifics: names, documents, numbers and examples. Where you cannot answer, say so; a blank or generic answer scores zero.

Team and staffing

Who actually does the work, how senior they are, and what happens when people leave.

1. Who, by name and role, will work on our account in the first three months? Please share their CVs and confirm these are the people who will start, not examples.

Answer:

Evidence attached (document name or link):

2. What is the seniority mix of the proposed team, and how many years of testing experience does each person have on products like ours?

Answer:

Evidence attached (document name or link):

3. If a named team member leaves or is moved to another client, how much notice do you give us, who approves the replacement, and how is knowledge handed over?

Answer:

Evidence attached (document name or link):

4. What proportion of the proposed team are your own employees, and will any work be done by contractors or subcontractors? If so, which roles and where are they based?

Answer:

Evidence attached (document name or link):

5. Which testing qualifications do the proposed testers hold, and how can we verify them?

Answer:

Evidence attached (document name or link):

6. Who is the single accountable lead on your side, how much of their time is allocated to us, and what decisions can they make without escalating?

Answer:

Evidence attached (document name or link):

7. How will your testers work inside our team day to day: which of our meetings do they attend, whose backlog do they work from, and who on our side assigns their work?

Answer:

Evidence attached (document name or link):

8. How many working hours overlap between your team and ours, and who is available during our core hours when a release is blocked?

Answer:

Evidence attached (document name or link):

9. How quickly can you add or reduce testers, what notice do you need in each direction, and does the rate change when the team size changes?

Answer:

Evidence attached (document name or link):

10. Can we interview the proposed testers before we sign, and can we run a short paid pilot with the same people?

Answer:

Evidence attached (document name or link):

Process and methodology

How the vendor decides what to test, documents it and fits into your delivery cycle.

11. Please share an anonymised test strategy or test plan you have written for another client. What sections does it contain?

Answer:

Evidence attached (document name or link):

12. How do you decide what to test first and what not to test? Walk us through how you would assess risk on our product.

Answer:

Evidence attached (document name or link):

13. What are your entry and exit criteria for a test cycle, and who has the authority to say a release is not ready?

Answer:

Evidence attached (document name or link):

14. What does a defect report from your team contain, and can you show us a few real, anonymised examples?

Answer:

Evidence attached (document name or link):

15. How do you fit testing into an agile, iterative delivery cycle? At what point in a sprint or release does your team start testing a change?

Answer:

Evidence attached (document name or link):

16. How do you plan and record exploratory testing so that we can see what was covered and what was found?

Answer:

Evidence attached (document name or link):

17. How do you cover non-functional quality such as performance, accessibility and security? Which of these do you do yourselves, and which would you leave to us or a specialist?

Answer:

Evidence attached (document name or link):

18. How do you get and manage test data? Will your team ever need access to production data, and if so, how is it masked or protected?

Answer:

Evidence attached (document name or link):

19. What test environments do you need from us, and how do you make sure results in those environments reflect how the product behaves in production?

Answer:

Evidence attached (document name or link):

20. In your first 30 days on our account, what will you produce and how will we know onboarding has worked?

Answer:

Evidence attached (document name or link):

Automation and code ownership

Who owns the test code, which framework it uses, and whether you can maintain it without the vendor.

21. Where will the test automation code live? Will it be in a repository that we own and control from the first commit?

Answer:

Evidence attached (document name or link):

22. Who owns the intellectual property in the test code, test cases, data and documentation you produce for us, and does any of it depend on your own libraries or accelerators?

Answer:

Evidence attached (document name or link):

23. Which automation framework would you use for our product, and why that one? What would make you choose differently?

Answer:

Evidence attached (document name or link):

24. How do you define, detect and deal with flaky tests? What do you do with a test that passes and fails on the same code?

Answer:

Evidence attached (document name or link):

25. How will the automated tests run in our CI pipeline, and how long should a full run take before it slows our developers down?

Answer:

Evidence attached (document name or link):

26. How do you keep test code maintainable? Do you have coding standards, code review and a way of structuring tests that our developers could follow?

Answer:

Evidence attached (document name or link):

27. How do you decide which tests to automate and which to keep manual, and how will you report automation coverage to us?

Answer:

Evidence attached (document name or link):

28. If we ended the contract tomorrow, could our own engineers run, read and extend the test suite without you? What documentation would they have?

Answer:

Evidence attached (document name or link):

29. What access will your engineers need to our code, pipelines and cloud accounts, and how will that access be granted, reviewed and removed?

Answer:

Evidence attached (document name or link):

30. If you are taking over automation from a previous supplier or our own team, how will you assess the existing suite before deciding to keep, fix or rewrite it?

Answer:

Evidence attached (document name or link):

5 more pages in the download.

Download your document:

Everything on this page runs in your browser. Nothing you type is sent to us or to anyone else, and nothing is stored after you close the tab.

Framework v1.0 · released 2026-09-24 · changelog

Questions buyers ask

How many questions should we send?
Send the questions that change your decision. For a first shortlist, filter by your situation and keep the themes you will actually score. A long questionnaire with generic answers tells you less than a short one answered with specifics.
Should the vendor see the strong and weak answers?
No. Send the vendor version. Keep the buyer's guide for your evaluators so they score answers against the same markers.
How do we score the answers?
Score each answer 0 to 5 in the CSV, or carry the results into the scorecard under the matching criterion. A missing or generic answer scores zero.
Where do the questions come from?
Each question in the framework cites a public standard, regulator or government guidance. The sources are listed on the methodology page.