RFP generator for software testing services

Request for proposal: software testing services for [Buyer]

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

1. Background

[Buyer] is inviting proposals for software testing services. Product: [describe the product, its users and how it is sold].

Technology: [languages, frameworks, hosting, CI system].

Current state of testing: [who tests today, what is automated, how often you release, known problems].

2. Scope

The service covers the following surfaces:

• [list the surfaces in scope]

Goals: [what must be true after six and twelve months].

Compliance context: [regulations and supplier expectations that apply].

Engagement model: Open: vendors propose a model. Vendors may propose an alternative model in addition, priced separately.

3. Deliverables

• A test strategy for the product covering scope, risks, approach, environments, entry and exit criteria, following the content described in ISO/IEC/IEEE 29119-3.
• Test plans and test cases maintained in our tools.
• Automated tests, where in scope, committed to our repository and running in our pipeline from the first week.
• A weekly status report stating what was tested, what was not, open risks and a release recommendation.
• A completion report at each release and at the end of the engagement.
• Documentation sufficient for our team or a successor to continue the work without the vendor.

1 / 3

4. Evaluation criteria and weights

Proposals will be scored against these criteria. Weights are shown so you can focus your response. Price is evaluated as total cost over 12 and 24 months, including onboarding and exit.

A proposal that does not name the delivery team, or that requires test code to remain in the vendor's systems, will score zero on the related criteria.

5. Required responses

Answer each question in the response template in Appendix A. Answer with specifics: names, documents, examples. Attach evidence where asked.

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.
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?
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?
4. Please share an anonymised test strategy or test plan you have written for another client. What sections does it contain?
5. How do you decide what to test first and what not to test? Walk us through how you would assess risk on our product.
6. What are your entry and exit criteria for a test cycle, and who has the authority to say a release is not ready?
7. Where will the test automation code live? Will it be in a repository that we own and control from the first commit?
8. 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?
9. Which automation framework would you use for our product, and why that one? What would make you choose differently?
10. Which tools will you use for test management, defect tracking and reporting, and will they be our accounts or yours?
11. Are any of the tools you propose licensed by you and charged to us, directly or inside your rate? What happens to those licences if we part ways?
12. Can all test cases, results and defect history be exported in an open format such as CSV, JSON or plain text at any time, not only at exit?
13. Can you share your most recent SOC 2 Type II report under NDA, and tell us its audit period, the Trust Services Criteria in scope, and which offices and systems it covers?
14. What does your ISO/IEC 27001 certificate cover: which legal entity, which sites and which services? Which certification body issued it, which accreditation body accredits that body, and when does it expire?
15. Where will our test data, test results, screenshots and logs be stored, in which countries, and on whose systems? Who on your side can reach them?
16. Can you show us a real, anonymised weekly status report from a current engagement, with nothing added for the sales process?
17. How exactly do you define and count your defect metrics, such as severity, priority, defect leakage, reopen rate and fix verification time? Where are those definitions written down?
18. Which measurable outcomes would you agree to be held to, how are they measured, and what happens when one is missed?
19. Is your price based on time and materials, fixed price or outcomes, and exactly which activities are inside the price and which are billed separately?
20. If we pay for time, how are hours recorded, approved and evidenced on invoices, and can we see timesheets by person and activity?
21. Can you lock your rates for the initial term, and what is the mechanism and cap for any increase after that?
22. What exactly will you hand over when the contract ends: test cases, automation code, test data, environments configuration, defect history, documentation and credentials?
23. Will you agree a written exit plan within the first months of the contract, keep it updated, and test it?
24. How long a knowledge transfer period will you support at exit, what does it include, and how is it priced?

6. Timeline

7. Submission format

• Appendix A completed in the order given, one answer per question.
• CVs of every proposed team member, with the allocation of each person.
• A sample test strategy and a sample status report from a comparable engagement, anonymised.
• Commercial response: rates by role, what is included and excluded, onboarding and exit costs, rate review terms.
• Security evidence: certificates with scope, or a current SOC 2 Type II report under NDA.
• Three references from comparable engagements, at least one of them a former client.
• Budget: [state a budget band, or say that total cost will be compared].

8. Contract terms vendors must accept or mark up

State for each term whether you accept it, or propose alternative wording.

• Ownership of test code and test assets
• Repository and tool accounts held by the buyer
• Knowledge transfer on exit
• Exit plan and exit assistance period
• Staff replacement terms
• Key personnel
• Service levels with measurable targets
• Service credits and remedies
• Data processing agreement
• Subprocessor approval and data location
• No production data without written approval
• Security obligations and incident notification
• Audit and information rights
• Restriction on subcontracting
• Confidentiality
• Rate lock and price review
• Change control
• Termination for convenience and for cause
• Acceptance of deliverables
• Limitation of liability with carve-outs
• Insurance

2 / 3

Appendix A: response template

3 / 3