In-House QA Team vs Outsourced QA

Recommendation: do not sign the proposal as written. Keep the testing of the product in-house and strengthen that team; cover the peak with staff augmentation, two testers working inside the Scrum teams from 3 Jan to 25 Feb 2027 after onboarding from 20 Dec 2026; and buy the load test of the month-end payroll run and the security assessment as two fixed-scope outsourced engagements before go-live. Provider X may quote for these parts on the corrected terms below. The decision is made per need, not once for the whole company, and it combines several degrees of independence of testing, which CTFL v4.0 says is usually best for most projects.

Decision checklist. (1) Horizon and pattern: the product is the whole business with a three-year roadmap, and testing is continuous, every sprint and a monthly release, with one peak in January and February 2027: in-house for the base, outside help for the peak. (2) Skills: functional testing of payroll rules and regression are needed every week; load testing and security assessment about once a year: from outside. (3) Data and approval: the test environments hold synthetic data, so a third party can work without personal data and the approval takes about 6 weeks; with personal data it takes about 12 (step 3). (4) Test assets: the most important one, the payroll regression checklist, is a spreadsheet on one tester’s laptop, so today the company does not really hold it; every asset, including the provider’s, must live in the company’s tracker and repository. (5) Measurement: nothing is measured today; choose outcome metrics (below). (6) The end: augmentation ends on 25 Feb 2027 and the specialist engagements at go-live, each with a handover to Huda and Omar during the work, not after it. (7) The in-house alternative: hiring takes about 3 months, so a tester approved today would start around 5 Jan 2027, after the peak has begun, with no product knowledge, and would remain a fixed cost after it; load-test and security specialists on staff would be paid all year for about one use each, plus the tooling a provider brings. So questions 1, 2 and 7 point to in-house for the continuous work and to outside help for the peak and the specialist work; question 3 allows outside help only with synthetic data; questions 4 to 6 are conditions that apply whichever model is chosen.

Model per part. Continuous work: in-house. The product is the core business for years, testing is continuous so the fixed cost is used, payroll is a complex domain whose rules change, and that knowledge is worth owning. Outsourcing all of it (P1) would put control of priorities into the contract and the product knowledge with the provider, and would bring the drawbacks of independent testers that CTFL v4.0 lists, such as isolation from the developers and developers feeling less responsible for quality. The peak: staff augmentation. Two people for eight weeks is the case the guide names as fastest to start; the testers work inside the Scrum teams under the product owner’s priorities, so control and most of the knowledge stay with the company; the cost is a day rate for ten weeks, and no one is idle after go-live. Specialist work: outsourced as two fixed-scope engagements with a written scope, deliverables and dates, and for the security assessment a written authorisation of what may be tested. Load testing and security assessment are specialist and occasional skills, a provider brings the people and the tooling and spreads their cost across clients, and testers from outside the organisation give very high independence, which suits a second opinion before a critical release. A hybrid (build-operate-transfer) is not needed: the company already has a QA function and knows its domain.

Dates. Access is needed by 20 Dec 2026. Without personal data (6 weeks), the approval must start by 8 Nov 2026. With personal data (12 weeks), it would have had to start by 27 Sep 2026, which has already passed. So clause P4 is not only a data-protection problem: accepting it would make the peak impossible to staff in time. Synthetic test data is both the safer route and the only one that fits the dates. Start the 6-week approval this month, together with the approvals for the two specialist engagements.

Clauses. P1, scope of all testing with 30 days’ notice for changes: control of priorities and the product knowledge move to the provider, and a 30-day notice cannot follow two-week sprints. Ask for: scope limited to the named engagements with their dates; during augmentation, the product owner sets priorities every sprint. P2, 1,500 test cases a month and a report of executions, hours and defects logged: activity metrics reward volume; the count can be met with easy tests, and counting defects logged rewards duplicates and splitting one defect into several. Ask for: review on outcomes (below) and, for the specialist engagements, on accepted deliverables. P3, assets in the provider’s tool with an export on request: the testware lives with the provider, and an export at the end comes too late and in an unknown format. Ask for: all test cases, scripts, data generators and reports created in the company’s tracker and repository from day one, and accessible on the day the engagement ends.

P4, a monthly copy of production data: the national IDs, salaries and IBANs of the customers’ employees would reach a third party’s systems, the provider would become a processor under the PDPL, and the 12-week approval misses the dates. Ask for: no production data leaves the company; test data is synthetic and generated in the company’s test environments, and it can still be realistic, with generated payroll records that cover the edge cases the team needs. P5, one shared admin account: actions cannot be traced to a person, one person’s access cannot be revoked alone, and admin rights exceed what testing needs. Ask for: one named account per person with the least rights needed, logged, and revoked on that person’s last day. P6, one week of knowledge transfer at the end: too late to transfer anything. Ask for: transfer scheduled across the engagement, with pairing and shadowing with Huda and Omar, documentation reviews every sprint, and a walkthrough of the load-test scripts and the security findings before the specialists leave. Missing from the proposal: deliverables, service levels such as the time from a defect report to a reproducible ticket, the metrics that will be reviewed and by whom, the security terms that third-party access requires, an end date tied to the work, and the handover obligations.

The in-house risk is already visible: Huda is a single point of failure, and the payroll regression checklist is an asset the company does not hold. Contain it before the peak: move the roughly 400 checks into the company’s tracker as test cases, have Omar review them with Huda, and run the next regression from the tracker with the two of them pairing. The augmented testers then learn from the tracker, not from one person’s memory. A manual regression that takes 4 working days every month is also worth reviewing later: the guide’s other in-house risk is stagnation.

Metrics for the whole arrangement, whoever employs the testers: defect escape rate per release (defects found in production versus before release), requirement coverage (release 5.0 acceptance criteria with a passing test), regression suite duration and stability, and the time from a defect report to a reproducible ticket. You prepare them; the product owner and the CTO review them at every release, and they inform the go-live decision for 5.0. For the specialist engagements, the measure is the accepted deliverable: a load-test report against targets agreed with the product owner beforehand, with the scripts in the company’s repository, and a security report with each finding’s severity and evidence, followed by confirmation testing of the fixes before go-live.

If your answer differs, check it against the containment measures the guide applies to every model: test assets in systems the company owns; a contract that states scope, deliverables, service levels, metrics and handover; synthetic test data with access that is scoped, logged and revoked on exit; and knowledge transfer across the engagement, not in the last week. Other choices can be defended with a recorded reason, for example a small managed service for the regression of the existing web portal during the peak, with a fixed scope and the assets in the company’s tracker, or a third permanent tester if the roadmap shows the base load growing, although that hire would not arrive in time for the peak. A choice that leaves personal data with a third party, the assets in the provider’s tool, or the contract measured on test-case counts does not meet the guide’s measures.