پرسش درست این نیست که «تیم QA داخلی بهتر است یا برونسپاری؟»؛ پرسش درست این است که کدام قابلیت، با چه پیامدی، تحت چه اختیاری و با چه مسیر خروجی باید از کجا تأمین شود. ممکن است طراحی Oracle و پذیرش ریسک داخل سازمان بماند، تست نفوذ به متخصص مستقل سپرده شود، ظرفیت Regression موقت خریداری شود و نگهداری Automation میان دو طرف تقسیم شود. واگذاری فعالیت، پاسخگویی سازمان در برابر محصول، داده و کاربر را واگذار نمیکند.
این راهنما یک QA Sourcing & Control Model میسازد: Outcome و Capability slice را تعریف میکند؛ مدلهای In-house، Staff augmentation، Managed capacity، Managed service، Specialist assessment و Hybrid را مقایسه میکند؛ Retained capability، مسئولیت و اختیار را نگه میدارد؛ Due diligence، امنیت، قرارداد، Evidence، TCO، انتقال دانش، Continuity و Exit را به هم متصل میکند. هدف انتخاب تبلیغاتی Vendor یا تضمین کیفیت نیست؛ هدف تصمیمی محدود، قابلآزمون و قابلبازگشت است.
پاسخ کوتاه: تیم داخلی یا برونسپاری QA؟
هیچکدام ذاتاً ارزانتر، امنتر، سریعتر، بیطرفتر یا باکیفیتتر نیست. تیم داخلی میتواند دانش نزدیک و دسترسی سریع داشته باشد، اما کمبود ظرفیت، سوگیری، Bus factor یا هزینهٔ ثابت هم داشته باشد. تأمینکننده میتواند تخصص یا ظرفیت فراهم کند، اما Ramp-up، هماهنگی، دسترسی، نرخ تغییر نیرو، زنجیرهٔ پیمانکار فرعی، وابستگی و Exit هزینه دارند. تصمیم باید بهازای یک Capability slice و دورهٔ زمانی مشخص گرفته شود، نه برای کل مفهوم «کیفیت».
| ادعای رایج | چرا کافی نیست؟ | شاهد لازم |
|---|---|---|
| داخلی کنترل بیشتری میدهد | کنترل از Decision rights، دسترسی و Governance میآید | RACI/authority، SLA و Evidence flow |
| برونسپاری ارزانتر است | قیمت قرارداد TCO نیست | Transition، coordination، rework، tool، security و exit cost |
| Vendor متخصص است | رزومهٔ شرکت مهارت افراد تحویلی نیست | Work sample، named role، evidence و substitution rule |
| طرف بیرونی بیطرف است | قرارداد، KPI و وابستگی مالی سوگیری میسازند | independence need، conflict disclosure و escalation |
| مدل Hybrid بهترین است | مرز مبهم دو صف و هیچ مالک میسازد | Capability map، interface، retained owner و exit |
مرز این مقاله با مدل عملیاتی و رهبری QA
راهنمای مدل عملیاتی QA ساختار Centralized، Embedded، Federated و Enabling را درون یک سیستم محصول طراحی میکند. راهنمای رهبری تیم QA به ظرفیت، رشد، بازخورد و سلامت تیم میپردازد. این مقاله مالک مرز تأمین است: کدام Work package/Capability داخل میماند یا بیرون میرود، چه Interface و Controlهایی لازم است و چگونه بدون قفلشدن یا از دستدادن پاسخگویی وارد/خارج میشویم.
واحد تصمیم را از «تیم» به Capability Slice تغییر دهید
خرید «سه تستر» Demand مبهمی است. واحد بهتر، برش قابلتحویل از Capability است: مثلاً «طراحی و اجرای ارزیابی دسترسپذیری نسخهٔ وب R12 در برابر دامنهٔ مشخص WCAG، با Evidence و retest» یا «افزایش ظرفیت اجرای Regression تعریفشده برای سه Release». هر Slice باید Outcome، Non-outcome، ورودی، خروجی، Skill، اختیار، وابستگی و Exit داشته باشد.
QASourcingRequest RequestID / sponsor / decision owner / facts-as-of Product/service/build/release/risk identities Problem and measurable outcome hypothesis Capability slice / work package / volume range In-scope / out-of-scope / explicit non-outcomes Required skills, independence and evidence Data/system/access classification Interfaces, dependencies and retained owners Start/ramp/steady-state/exit horizon Constraints: budget range, timezone, language, Iran access Options considered / unknowns / review date
«بهبود کیفیت»، «پوشش کامل» یا «تضمین بدون باگ» Outcome قابلخرید نیست. مثال قابلسنجشتر: کاهش زمان انتظار برای ارزیابی Buildهای Tier-۱ از Baseline تعریفشده، با سقف False result و بدون افزایش رخداد دسترسی غیرمجاز. حتی این هدف هم علتومعلول قطعی را ثابت نمیکند؛ تغییرات محصول و Release باید ثبت شوند.
Context Pack؛ قبل از Make/Buy چه چیزهایی باید معلوم باشد؟
- Product/Service، کاربران و پیامد خرابی؛
- معماری، Release cadence، محیطها و Third partyها؛
- Test basis، Oracleها، داده و Evidence موجود؛
- تقاضای پایه، Peak، نوسان و deadline؛
- Capabilityهای موجود، شکاف، Bus factor و زمان یادگیری؛
- دادهٔ شخصی/حساس، Secret، Source code و Production access؛
- الزام استقلال، ممیزی، قرارداد مشتری یا مجوز حرفهای؛
- زبان، منطقهٔ زمانی، فارسی/RTL و ارتباط با ذینفعان؛
- بودجه، Currency، شیوهٔ پرداخت و تغییر قیمت؛
- محدودیت دسترسی ابزار/ابر/Device farm از ایران؛
- افق زمانی، reversibility و هزینهٔ شکست/خروج؛
- تصمیمها و فعالیتهایی که سازمان نمیخواهد یا نمیتواند واگذار کند.
Unknown را با «Vendor بعداً حل میکند» نبندید. اگر Test basis، محیط یا داده آماده نیست، تأمینکننده نیز صف ابهام را به صف قراردادی تبدیل میکند. نخست Readiness را بسنجید و هزینهٔ کشف را صریح قیمتگذاری کنید.
طیف مدلهای تأمین QA
| مدل | چه چیزی خریداری میشود؟ | کنترل روزانه | ریسک غالب | کاربرد محتمل |
|---|---|---|---|---|
| In-house | استخدام و Capability بلندمدت | سازمان | هزینه ثابت/Bus factor/ظرفیت | دانش مستمر و کار هستهای |
| Staff augmentation | زمان فرد/نقش | سازمان | ابهام employment/IP/جایگزینی | شکاف ظرفیت با مدیریت داخلی |
| Managed capacity | ظرفیت تیم با backlog مشترک | مشترک | Throughput بهجای Outcome | تقاضای متغیر و work packageهای روشن |
| Managed service | Service level و خروجی | تأمینکننده با Governance | black box/KPI gaming/lock-in | خدمت پایدار و interface قابلتعریف |
| Specialist assessment | ارزیابی محدود و گزارش | تأمینکننده در scope | snapshot/claim overreach | امنیت، دسترسپذیری، Performance تخصصی |
| Independent assurance | چالش یا ارزیابی مستقل | مرز استقلال | فاصله از context/conflict | ریسک بالا یا الزام مشخص |
| Hybrid/multisource | چند Slice از چند منبع | retained integrator | شکاف interface/blame | Capabilityهای ناهمگون با مالک روشن |
Hybrid «بهترین دو دنیا» نیست؛ فقط معماری تأمین پیچیدهتری است. اگر Integrator، مرز تحویل، منبع حقیقت و اختیار رفع تعارض معلوم نباشد، دو طرف میتوانند هر Failure را به Interface نسبت دهند.
چه چیزهایی باید Retained Capability بمانند؟
Retained به معنای انجام همهٔ کارها داخل نیست؛ یعنی سازمان توان تعریف، نظارت، تصمیم و خروج را از دست ندهد. دامنه برحسب قانون/قرارداد و Context فرق دارد، اما معمولاً این قابلیتها باید یک مالک داخلی پاسخگو داشته باشند:
- هدف محصول، Risk appetite و اولویتهای کسبوکار؛
- Support policy و تعریف پیامد قابلقبول؛
- مالکیت داده، طبقهبندی و تأیید دسترسی؛
- پذیرش Residual risk و Release authority؛
- تعریف Oracleهای حساس و منبع Test basis؛
- Vendor governance، تضاد منافع و escalation؛
- صحتسنجی Evidence و challenge مستقل؛
- معماری Integration، Secret و محیط؛
- Business continuity و incident coordination؛
- مالکیت Artifact، مخزن و اسناد؛
- Knowledge map، backup و succession؛
- Exit decision، انتقال و archive/deletion verification.
راهنمای مالکیت همگانی بدون ابهام تفکیک Contribution، Accountability و Decision rights را کامل میکند. عبارت «Vendor مسئول کیفیت است» اگر اختیار محصول، بودجه، Release و ریسک را ندارد، هم ناعادلانه است و هم غیرعملی.
مسئولیت، پاسخگویی و اختیار را در یک جدول نریزید
| موضوع | Responsible | Accountable | Decision authority | Evidence |
|---|---|---|---|---|
| تعریف Test basis | Product/engineering/QA contribution | مالک requirement | مالک دامنه | نسخه و approval |
| اجرای Work package | تیم نامگذاریشده | service owner | در محدودهٔ روش | attempt/result/artifact |
| دسترسی حساس | platform/security operation | data/system owner | access approver | ticket/log/expiry |
| پذیرش Risk | Evidence contributors | risk owner | صاحب اختیار سازمان | decision record |
| Release | چند Contributor | release owner | طبق operating model | bounded release evidence |
| Exit | دو طرف | contract/service owner | sponsor/procurement | handover/deletion/acceptance |
برای هر نقش، انتظار را از Title جدا کنید. راهنمای Role & Capability Charter مهندس QA کمک میکند Requirement را به Task، Work product، Evidence، سطح استقلال و Support تبدیل کنید؛ «Senior QA» یا «Automation expert» معیار پذیرش نیست.
Make/Buy/Partner را بهازای هر Slice امتیازدهی کنید
| عامل | به نفع Retain | به نفع External | سؤال ضدسوگیری |
|---|---|---|---|
| دانش ضمنی | تغییر مداوم/پیامد بالا | قابلکدگذاری و محدود | چه چیزی مستندشدنی نیست و چرا؟ |
| تقاضا | پایدار و بلندمدت | کوتاه/Peak/متغیر | آیا مشکل واقعاً ظرفیت است یا صف ابهام؟ |
| تخصص | هستهٔ مزیت و تکرارشونده | نادر و دورهای | چگونه competence فرد تحویلی سنجیده میشود؟ |
| استقلال | استقلال ساختاری داخلی ممکن | ارزیابی بیرونی لازم | Externality واقعاً independence میآورد؟ |
| داده/دسترسی | تفکیک دشوار و بسیار حساس | محیط synthetic/segmentable | کمینهٔ داده و privilege چیست؟ |
| سرعت | تیم آماده و context حاضر | ظرفیت qualified آماده | Ramp-up و approval در lead time آمده؟ |
| بازگشتپذیری | خروج بیرونی پرهزینه | Artifact/skill قابلانتقال | در روز اول Exit چگونه انجام میشود؟ |
وزنها، امتیازها و Threshold را پیش از دیدن پیشنهاد Vendor تعریف کنید. عدد Score تصمیم را خودکار نمیکند؛ اختلاف ارزیاب، Evidence ضعیف و Hard gate باید جدا دیده شوند.
Hard Gate؛ چه چیزی امتیازپذیر نیست؟
- عدم امکان اجرای شرط ضروری داده، حریم خصوصی یا امنیت؛
- ابهام در هویت شرکت، محل ارائه یا زنجیرهٔ پیمانکار فرعی؛
- نپذیرفتن حق Audit/Evidence لازم در دامنهٔ توافقشده؛
- نداشتن مسیر revoke دسترسی و مدیریت incident؛
- مالکیت مبهم Source، Test artifact، داده یا مشتقات؛
- عدم امکان Export قابلاستفاده و Exit assistance؛
- تعارض منافع افشانشده یا حلنشده؛
- وابستگی به ابزار/ابر/پرداختی که دسترسی ایران آن تأیید نشده؛
- ادعای تضمین بدون Defect، کیفیت یا Compliance بدون Scope؛
- Substitution افراد کلیدی بدون اطلاع و qualification؛
- استفاده از دادهٔ واقعی بدون Basis، minimization و approval؛
- نبود Business continuity متناسب با پیامد توقف.
Due Diligence تأمینکننده؛ گواهی پایان بررسی نیست
NIST در SP 800-161 Rev. 1 Update 1 ریسک زنجیرهٔ تأمین را به چرخهٔ شناسایی، ارزیابی، پاسخ و پایش پیوند میدهد؛ این سند چکلیست اختصاصی خرید خدمات QA یا گواهی Vendor نیست. راهنمای تازهٔ NIST SP 1326 نیز Due diligence را پژوهش اطلاعات مرتبط برای تصمیم آگاهانه دربارهٔ Supplier میداند و مؤلفههایی مانند provenance، resilience، practices پایه و supply-chain tiers را برجسته میکند. کاربرد این منابع باید متناسب با Risk و حقوق/قرارداد محلی باشد.
SupplierDueDiligenceRecord Legal identity / ownership / operating locations Service locations / remote-work model / subcontractor tiers Financial and continuity evidence + facts-as-of Named delivery leadership and key-role substitution rule Secure development/operation practices relevant to scope Incident/vulnerability history disclosure process Data flow, storage, backup, deletion and subprocessors Access administration, logging and offboarding Tool/cloud/device-farm dependencies and regions Insurance/certification/attestation: scope + issuer + expiry References: comparable scope, independently contacted Conflicts, litigation/claims as legally appropriate Finding / evidence / confidence / owner / review / expiry
وبسایت زیبا، لوگوی مشتری، NDA، مدرک فردی یا گواهی سازمانی بهتنهایی نشان نمیدهد چه کسی روی Scope شما کار میکند و چه Evidence تحویل میدهد. Certification scope، محل، تاریخ و استثنا را بخوانید؛ Reference را با اجازه مستقل تماس بگیرید؛ و ادعاهای مهم را در Pilot قابلآزمون کنید.
امنیت، حریم خصوصی و زنجیرهٔ پیمانکار
«داخلی» مساوی امن و «بیرونی» مساوی ناامن نیست؛ Risk از Data flow، privilege، endpoint، identity، logging، subcontractor و پاسخ Incident میآید. CISA در Secure by Demand Guide توصیه میکند انتظار امنیت پیش، حین و پس از خرید در پرسشها و قرارداد وارد شود. این راهنما دربارهٔ خرید نرمافزار است، نه قرارداد خدمات QA؛ از آن برای منطق demand و evidence استفاده کنید، نه انطباق خودکار. فایل رسمی در مرورگر و نتیجهٔ جستوجوی منبع قابلبررسی بود، اما endpoint هنگام کنترل مستقیم فرمانخطی پاسخ ۴۰۳ ضدبات داد؛ این وضعیت را خرابی محتوا یا تأیید کنترلهای یک Supplier تفسیر نکنید.
| Control plane | کنترل حداقلی | Evidence نمونه | Failure/Exit |
|---|---|---|---|
| Identity | named identity، MFA، joiner/mover/leaver | approval و access review | revoke فوری |
| Privilege | least privilege، time-bound، JIT در صورت امکان | role/policy/session log | break-glass audit |
| Environment | تفکیک synthetic/staging/production | network/path diagram | isolate/disable |
| Data | minimize، synthesize، redact، retain/delete | dataset manifest | deletion proof |
| Endpoint | managed device، patch، encryption، screen/download policy | bounded posture evidence | remote revoke |
| Secrets | broker/vault، no shared secret، rotation | issuance/usage log | rotate on exit |
| Subcontractor | prior disclosure/flow-down/approval | tier and location register | replacement/termination |
| Incident | severity/contact/clock/evidence/preservation | tabletop and report | containment/notification |
NDA فقط تعهد قراردادی است؛ Data minimization، access control، monitoring، incident process یا حذف داده را اجرا نمیکند. از دادهٔ Production برای «واقعیتر شدن تست» استفاده نکنید مگر ضرورت، مبنا، حداقلسازی، مجوز و کنترل آن صریح باشد.
درخواست پیشنهاد را از Solution-free Problem شروع کنید
RFP که از ابتدا تعداد نفر، ابزار یا روش را قفل میکند ممکن است مسئله را پنهان کند. ابتدا Problem، Outcome، constraints، interfaces، data class، evidence و decision cadence را بدهید؛ سپس از هر گزینه بخواهید Assumption، dependency، exclusion، staffing، ramp، risk و exit خود را روشن کند.
- سناریوی تقاضای پایه، کمینه، بیشینه و شوک؛
- Artifactهای ورودی و Definition of Ready؛
- Work productها و Acceptance method؛
- result vocabulary و Evidence manifest؛
- پرسشهای qualification یکسان برای همه؛
- قالب قیمت قابلمقایسه و assumptionهای volume؛
- نام افراد کلیدی و درصد تخصیص؛
- Subcontractor، ابزار، region و licence؛
- Security/privacy questionnaire متناسب؛
- Pilot/work sample با دادهٔ synthetic؛
- Transition-in، steady state، transition-out؛
- حق پرسش، clarification log و نسخهٔ پاسخ.
Qualification با Work Sample، نه Demo نمایشی
Pilot باید نمونهٔ کوچک اما نماینده از کار واقعی باشد و برای گزینههای رقیب Contract یکسان داشته باشد. Demo از پیش تمرینشده یا bug hunt بدون Oracle بیشتر توان ارائه را میسنجد تا قابلیت تحویل. داده و سیستم Pilot باید synthetic/isolated باشد و کار بیجبران یا استخراج ارزش واقعی از Candidate نباشد.
QualificationExperiment ExperimentID / capability / question / decision Versioned fictional work sample and hidden holdout Inputs, constraints, allowed questions and tools Expected work products, not one secret answer Scorers blinded where practical; conflict declared Criteria: reasoning, risk, oracle, evidence, communication, reproducibility, privacy, repair, handover and cost Critical faults / minimum gates / weighted scores Multiple trials or reviewers / disagreement handling Candidate feedback / data deletion / compensation rule Result / confidence / unknowns / not-generalizable claims
فقط تعداد defect یا سرعت را امتیاز ندهید؛ Candidate میتواند با گزارش noise برنده شود. False finding، شدت اشتباه، سؤال درست، Evidence قابلبازتولید، رعایت محدوده، اصلاح پس از feedback و کیفیت handover را هم بسنجید.
قرارداد باید Operating Model را قابلاجرا کند
Sourcing Playbook دولت بریتانیا بر ارزیابی Delivery model، Should-cost، Pilot، KPI، تخصیص Risk، رابطهٔ قراردادی، پایش مالی و Resolution planning تأکید میکند. این سیاست برای بخش عمومی بریتانیاست و نسخهٔ آمادهٔ حقوقی برای شرکت ایرانی نیست؛ ارزش آن در یادآوری چرخهٔ کامل و طراحی رفتار قرارداد است. متن نهایی باید توسط متخصص حقوقی/مالی ذیصلاح در حوزههای مرتبط بررسی شود.
- Service description، Scope، volume band و change control؛
- Named deliverable، Definition of Ready/Done و acceptance/rejection؛
- RACI، authority، retained roles و escalation؛
- Staffing/skills/location/substitution/key-person controls؛
- Onboarding، ramp، shadow، service commencement؛
- Tool/IP/source/data ownership و licence portability؛
- Security/privacy/subprocessor/audit/incident/deletion clauses؛
- SLA/SLO/KPI، measurement source، exclusion و dispute؛
- Pricing unit، index/currency/tax assumptions و invoice evidence؛
- Liability/indemnity/insurance متناسب و حقوقی؛
- Business continuity، disaster/supplier-failure resolution؛
- Termination for cause/convenience و cure period؛
- Exit assistance، knowledge transfer، export و credential revoke؛
- Record retention، correction، confidentiality survival؛
- Governing law/dispute terms فقط با مشاورهٔ حقوقی مناسب.
Service Catalogue و Work Order را از Master Contract جدا کنید
Master terms نباید برای هر Release بازنویسی شود و Work order هم نباید امنیت/مالکیت را دور بزند. سه لایه مفید است: قواعد رابطه در Master، تعریف هر Service در Catalogue و Scope/Build/volume/date دقیق در Work order. اولویت اسناد و Change authority را روشن کنید.
QAServiceEntry ServiceID / version / owner Purpose / eligible work / exclusions Input readiness and queue policy Activities / methods / tools / locations Deliverables and evidence schema Volume unit and capacity band Service levels + measurement source Data/access/security profile Dependencies and customer obligations Price unit and assumptions Escalation / continuity / exit artifact Review / expiry / superseded-by
تعریف Done بر پایهٔ Evidence، نه ساعت یا تعداد Test Case
Time sheet میتواند ورودی پرداخت باشد، اما نشان نمیدهد سؤال تست پاسخ گرفته است. Acceptance باید Work product و Evidence را بسنجد: Scope/Build/environment/data، روش، Attemptها، result vocabulary، یافته و duplicate، limitation/unknown، raw artifact، owner و correction. راهنمای ارائهٔ نتایج تست زنجیرهٔ Evidence تا تصمیم را تکمیل میکند.
ServiceEvidenceManifest WorkOrder / deliverable / question / risk IDs Artifact/build/commit/config/environment Test basis and oracle source/version Data/profile/tool/runner/operator/attempt/time PASS | FAIL | ERROR | SKIPPED | INCONCLUSIVE Finding IDs / duplicates / false-result corrections Raw artifact digest / location / redaction / retention Coverage denominator/exclusion/freshness Limitations / unknowns / claim / claim limit Producer review / customer acceptance or dispute
KPIهایی که رفتار بد نمیخرند
| نیاز تصمیم | Measure محتمل | Countermeasure | بازی محتمل |
|---|---|---|---|
| پاسخگویی | زمان تا acknowledge/usable evidence | کیفیت/False result | پاسخ سریع و بیمحتوا |
| قابلیت پیشبینی | distribution زمان برحسب work class | blocked/exclusion | انتخاب کار آسان |
| کیفیت یافته | valid/reproducible severity-weighted finding | missed/duplicate/noise | تورم severity |
| Evidence | manifest completeness/freshness | capture cost/privacy | مدرک زیاد و بیربط |
| انتقال دانش | artifact usable/replay by receiver | handover effort | تعداد جلسه/صفحه |
| Outcome فرضی | baseline-to-window change | product/change confounders | انتساب همهٔ بهبودها |
Bug count، pass rate، Test case count، Automation percentage، utilization و hours billed نباید بهتنهایی KPI کیفیت یا پاداش فردی باشند. راهنمای سنجش اثربخشی QA Claim، denominator، countermetric و Attribution limit را برای این قراردادها فراهم میکند.
مدل قیمت؛ Incentive باید با Outcome قابلکنترل همراستا باشد
| مدل | مزیت | ریسک | کنترل |
|---|---|---|---|
| Time & materials | انعطاف در ابهام | پرداخت زمان بدون outcome | capacity cap، backlog/evidence review |
| Fixed price | بودجهٔ Slice روشن | change dispute/کاهش عمق | assumption و change mechanism |
| Per test/bug | واحد ساده | تورم حجم/noise | اغلب اجتناب؛ acceptance سخت |
| Capacity subscription | دسترسی پایدار | utilization gaming | service outcome و flex bands |
| Outcome-based | همراستایی ظاهری | Attribution/unsafe shortcuts | فقط outcome قابلکنترل + guardrail |
| Hybrid | تقسیم base/variable | پیچیدگی و dispute | formula، source و worked examples |
هیچ پرداختی نباید Vendor را به پنهانکردن defect، ردکردن Work دشوار، افزایش Bug count یا سبزکردن Retry تشویق کند. Payment formula را با دادهٔ ساختگی اجرا و edge caseهای volume صفر، Peak، reject، rework و termination را پیش از امضا حل کنید.
TCO؛ قیمت روزانه فقط یک ردیف است
TCO_horizon = sourcing + legal + diligence + pilot + transition_in + onboarding + knowledge_capture + service_price + tools + devices + environments + data + internal_governance + coordination + queue + rework + false_results + incidents + downtime + currency/payment/indexation risk + transition_out + replacement + archive/deletion - avoidable_internal_cost (bounded, evidenced)
حقوق داخلی نیز TCO کامل نیست: جذب، onboarding، مدیریت، تجهیزات، ظرفیت بلااستفاده، training و attrition را دارد. برای مقایسه، Horizon، volume، نرخ، Currency، inflation/indexation، احتمال سناریو و Range را یکسان کنید. «صرفهجویی ۴۰ درصدی» بدون Baseline و فرضها تبلیغ است.
مدل هزینهٔ سهسناریویی
| سناریو | Demand | رخداد | محاسبهٔ لازم |
|---|---|---|---|
| Low | کمتر از پیشبینی | ظرفیت بلااستفاده | minimum commitment و redeploy |
| Expected | Base + نوسان معمول | عملیات عادی | fully loaded steady-state TCO |
| Stress | Peak یا incident | اضافهظرفیت/شبکاری/دسترسی | surge price، lead time و safety |
| Exit | کاهش به صفر/تعویض | handover و overlap | dual running، export، revoke و revalidation |
انتقال دانش؛ جلسه و Wiki کافی نیست
Knowledge باید به قابلیت قابلاجرا تبدیل شود. Runbook بدون replay، ویدئو بدون index، یا Test case بدون Oracle انتقال نیست. راهنمای مستندات تست زنده برای هر Artifact owner، source، freshness، drift signal، review و supersession میسازد.
| دانش | Artifact | آزمون دریافتکننده |
|---|---|---|
| Product/risk | map + decision history | توضیح و challenge یک سناریوی تازه |
| Environment/data | provision/run/reset runbook | ساخت مستقل محیط synthetic |
| Automation | repo/CI/dependency/triage | تغییر، اجرا و رفع یک failure |
| Manual/exploratory | charter/oracle/evidence examples | اجرای blind sample |
| Service operation | queue/SLA/escalation/contact | tabletop incident |
| Commercial/security | asset/access/licence/register | revoke/export/deletion drill |
Knowledge transfer دوطرفه است: سازمان باید Context قابلاستفاده بدهد و Vendor باید یافته، روش، Artifact و تصمیم را بازگرداند. ساعت آموزش KPI نیست؛ Receiver باید کار منتخب را بدون کمک انجام دهد و اختلاف ثبت شود.
Transition-in؛ Big Bang نکنید
- Discovery محدود با Unknown و access plan؛
- Baseline روی Work package شناختهشده؛
- Shadow: مشاهده و بازپخش Evidence؛
- Reverse shadow: Supplier اجرا، Retained owner بازبینی؛
- Pilot با volume محدود و Hard gate؛
- Ramp مرحلهای با entry/exit criterion؛
- Steady state پس از acceptance عملیاتی؛
- اولین Correction و Exit drill پیش از وابستگی کامل.
شروع Service وقتی است که نقش، Environment، داده، Tool، queue، escalation و Evidence کار میکنند؛ نه روز امضای قرارداد یا ورود نخستین نفر. کاهش موقت Throughput در Ramp باید در Forecast باشد.
ارتباط، منطقهٔ زمانی و زبان را به Interface تبدیل کنید
SourcingInterface InterfaceID / purpose / parties / owner Input + readiness + system of record Question channel / response class / service expectation Overlap hours / timezone / holiday calendar Language / terminology / translation ownership Handoff / acknowledgement / rejection reason Decision authority / dissent / escalation ladder Sensitive channel restrictions Async fallback / outage fallback Minutes / action / evidence / correction
مشکل «فرهنگی» را به کلیشهٔ ملی تبدیل نکنید. رفتار قابلمشاهده را ثبت کنید: تأخیر در acknowledgement، واژگان مبهم، escalation دورزدهشده یا feedback بیپاسخ. Remote یا co-location هیچکدام همکاری مؤثر را تضمین نمیکند.
استقلال؛ بیرونیبودن کافی نیست
Independence چند بعد دارد: جدایی از Author، خط گزارش، بودجه، پذیرش Deliverable و منافع تجاری. Vendor که برای تمدید قرارداد به KPI «همهچیز سبز» وابسته است ممکن است مستقل نباشد؛ تیم داخلی با مسیر escalation محافظتشده ممکن است challenge مؤثرتری بدهد. سطح استقلال را از پیامد و الزام تعیین کنید و هزینهٔ context loss/latency را بپذیرید.
- Conflict of interest و کار برای رقیب/تأمینکنندهٔ مرتبط؛
- جدایی فروش از امتیازدهی فنی؛
- حق ثبت Dissent و ارسال به Risk owner؛
- عدم تنبیه بابت finding معتبر یا INCONCLUSIVE؛
- بازبین مستقل برای ادعای پرپیامد؛
- عدم خودتأییدی Deliverable و invoice؛
- rotation بدون نابودی context؛
- محرمانگی و least disclosure در عین challenge.
ایران: دسترسی، پول، زبان و Continuity را پیش از قرارداد بیازمایید
این بخش مشاورهٔ حقوقی، مالیاتی، تحریمی یا ارزی نیست. باید با متخصصان ذیصلاح و ارائهدهندگان واقعی بررسی شود. از نظر عملی، Vendor یا تیم ایرانی ممکن است با عدم دسترسی به SaaS، Device farm، Region ابری، پرداخت بینالمللی، شمارهٔ تلفن/OTP، Store account یا Licence روبهرو شود. وعدهٔ «VPN حل میکند» برنامهٔ Continuity نیست.
- هر Tool/Region/Account با Build آزمایشی و مسیر واقعی دسترسی شود؛
- شرایط استفاده و مجازبودن مسیر دسترسی بررسی شود؛
- Fallback داخلی یا Export استاندارد و زمان سوییچ تعریف شود؛
- Currency، نرخ تبدیل، زمان تسویه و هزینهٔ انتقال شفاف باشد؛
- تعطیلات، timezone و overlap در Capacity plan بیاید؛
- فارسی/RTL و اصطلاحات Domain در qualification سنجیده شود؛
- داده و Artifact در Region نامعلوم رها نشود؛
- قطع Vendor/ابر/پرداخت/اینترنت Tabletop شود؛
- قانون حاکم، مالیات، مالکیت فکری و انتقال داده با مشاور بررسی شود؛
- مسیر جایگزین نباید امنیت یا قرارداد را دور بزند.
Business Continuity و شکست تأمینکننده
| رویداد | سیگنال | Containment | Recovery/Exit evidence |
|---|---|---|---|
| خروج افراد کلیدی | notice/coverage gap | backup + access freeze | qualification/reverse shadow |
| اختلال Tool/Region | failed access/queue | fallback lane | export/replay result |
| نقض امنیتی | alert/disclosure | revoke/isolate/preserve | incident record/correction |
| افت مالی Vendor | due-diligence trigger | resolution plan | asset/people/replacement map |
| اختلاف قراردادی | dispute aging | continue critical safe service | escalation/termination path |
| قطع کامل | service unavailable | retained minimum capability | RTO/RPO-like recovery evidence |
Continuity plan که فقط فایل دارد کافی نیست. دستکم access revoke، repository/export restore، critical-work reassignment و contact escalation را با دادهٔ ساختگی تمرین کنید. «تأمینکننده معتبر است» جای Resolution plan را نمیگیرد.
Exit از روز اول طراحی میشود
QAExitPlan Exit triggers: expiry / convenience / cause / risk / access Decision owner and notice/cure timeline Service minimum during transition Asset register: repo, tests, data, evidence, licences, devices Export format / schema / digest / completeness check Knowledge receiver / shadow / replay / acceptance Open work/findings/risks/decisions and final snapshot Accounts/secrets/tokens/devices revoke and rotate Data return/deletion + backup/subprocessor coverage IP/licence/continued-use confirmation Replacement/insource overlap and cost ceiling Final invoice/dispute/retention/confidentiality Post-exit validation / correction / lessons
Exit test را پیش از Scale انجام دهید: یک Artifact، تاریخچه، Evidence و Runbook را Export کنید؛ Receiver آن را در محیط پاک اجرا کند؛ دسترسی آزمایشی را revoke و Secret را rotate کنید. اگر خروج کوچک ممکن نیست، Lock-in پیش از قرارداد آشکار شده است.
Governance cadence؛ جلسهٔ وضعیت کافی نیست
| Cadence | تصمیم | ورودی | خروجی |
|---|---|---|---|
| روزانه/عملیاتی | queue/blocker/handoff | work system | owner/ETA/escalation |
| هفتگی Service | capacity/evidence/SLA | denominator-backed measures | action/correction |
| ماهانه Risk | access/data/supplier/continuity | risk/access/incident registers | treatment/review |
| فصلی Capability | retain/buy/learn/rebalance | skill/knowledge/TCO/outcome | portfolio decision |
| پیش از Renewal | extend/change/compete/exit | full evidence + alternatives | authorized sourcing decision |
جلسه نباید جای System of record را بگیرد. Decision، Dissent، owner، due date، Evidence، scope و supersession را ثبت کنید. Vendor manager بدون فهم عملی Service نمیتواند فقط از Dashboard قرارداد را اداره کند.
آزمایش مستقل: پنج شعار در برابر ۵۵۴ کنترل
برای اینکه راهنما به جدول مزایا/معایب محدود نماند، یک Validator قطعی و بدون وابستگی روی Node.js ۲۴.۱۸.۰ اجرا شد. Fixture کاملاً ساختگی SYN-QA-SOURCING-CONTROL-01 فقط پنج شعار داشت: داخلی کنترل میدهد، برونسپاری ارزان است، Vendor متخصص است، Hybrid بهترین است و NDA امنیت میآورد. بررسی سطحی همان پنج Token را یافت و خروجی نادرست زیر را ساخت:
HYBRID_QA_LOW_COST_HIGH_QUALITY_SECURE_READY
ممیزی مستقل دقیقاً ۵۵۴ کنترل یکتای group-qualified را در ۲۹ گروه identity، outcome، context، capability، criticality، model، retained، responsibility، authority، demand، supplier، diligence، security، data، access، qualification، pilot، contract، service، evidence، metric، cost، knowledge، transition، continuity، exit، governance، correction و limits مطالبه کرد. Fixture شعاری هیچکدام را نداشت:
HOLD-554 NO_REAL_TARGET_PASS
قانون مستقل دوم تأیید کرد هیچ Organization، Worker، Supplier، Contract، System، Payment یا Outcome واقعی در Fixture نیست. پس از درج همهٔ کنترلهای ساختگی با کلید یکتا و assertion تعداد/uniqueness، نتیجهٔ ساختاری اصلاح شد:
READY_FOR_QA_SOURCING_CONTROL_REVIEW-0
این خروجی فقط کاملبودن ساختار Fixture را نشان میدهد؛ نه صلاحیت یا سلامت Vendor/Worker، صحت Evidence، امنیت/حریم خصوصی، انطباق حقوقی، کفایت قرارداد، قیمت/صرفهجویی، کیفیت محصول، رضایت کاربر، موفقیت رابطه یا آمادگی امضا/Release.
آزمایشگاه آفلاین فارسی؛ سه پیشنهاد ساختگی برای Checkout
آزمایشگاه هیچ شبکه، شرکت، فرد، قرارداد، بانک، PSP، پرداخت یا پول واقعی ندارد. محصول فرضی Checkout فقط Stubهای Order، PaymentAttempt، Callback، Ledger و Reconciliation دارد. سه گزینهٔ کاملاً ساختگی مقایسه میشوند: Retained team، Managed capacity «سپهر» و Specialist «پرتو». نامها Benchmark بازار نیستند.
SYN-QA-SOURCING-LAB-01 Demand: 4 fictional releases + one surge Data: synthetic only; no PAN/CVV2/OTP/name/mobile/email/IP Money: fictional IRR canonical; labelled display-only toman Locale: fa-IR/RTL; Persian/Arabic/Latin digits; ی/ي; ک/ك; ZWNJ Time: UTC event; Asia/Tehran view; Jalali presentation-only Faults: timeout-before/after-fake-commit; duplicate/late/reordered Access: local isolated repo/CI/stubs; expiring fictional identities No network/Production/real org/worker/vendor/contract/payment/outcome
ارزیابی naive فقط نرخ روزانه و تعداد رزومه را میسنجد و گزینهٔ ظاهراً ارزان را برنده میکند. ارزیابی Contract، competence را با Work sample، False finding، Evidence replay، privacy behavior، ramp time، coordination، TCO سهسناریویی، knowledge receipt و Exit drill میسنجد. نتیجهٔ آزمایش باید بتواند HOLD، PILOT، LIMITED-SLICE یا REJECT بدهد؛ «Vendor برتر» خروجی مجاز نیست.
نمونهٔ Scorecard بدون ساختن حقیقت از عدد
| بعد | وزن ساختگی | Hard gate؟ | Evidence |
|---|---|---|---|
| Capability/Work sample | ۲۰ | بله برای critical skill | artifact + blinded review |
| Security/data/access | ۲۰ | بله | flow/control/drill |
| Operating interface | ۱۰ | خیر | handoff simulation |
| Evidence/repair | ۱۵ | بله | manifest/replay/correction |
| Continuity/exit | ۱۵ | بله | export/revoke/receiver test |
| TCO range | ۱۵ | خیر | same-horizon model |
| Commercial fit | ۵ | خیر | terms/assumptions |
وزنها نمونهاند و نباید کپی شوند. هر Score باید Evidence، confidence و comment داشته باشد؛ Hard gate را میانگین نگیرید؛ اختلاف ارزیاب را حل یا حفظ کنید؛ و Sensitivity analysis نشان دهد تغییر وزنها تصمیم را چقدر عوض میکند.
Correction؛ وقتی فرض تأمین غلط از آب درآمد
SourcingCorrection Original request/score/decision/contract evidence New fact or incident + source + time Affected capability/service/data/access/deliverables Prior claim now invalid or narrowed Containment and stakeholder notification Re-score / re-scope / retrain / replace / exit option Owner / authority / due / verification Superseded records retained; no silent rewrite
تعویض افراد، خرید شرکت Vendor، تغییر Subprocessor، افت دسترسی ایران، Incident، افزایش نرخ یا drift کیفیت میتواند تصمیم قدیمی را منقضی کند. قرارداد و Scorecard باید trigger بازبینی داشته باشند؛ Renewal خودکار بهعلت «هزینهٔ جابهجایی» یک تصمیم بدون بازآزمایی است.
ضدالگوهای تیم داخلی و برونسپاری QA
- واگذاری کل «کیفیت» بهجای Capability slice؛
- مقایسهٔ حقوق داخلی با نرخ Vendor؛
- داخلی مساوی امن و بیرونی مساوی پرریسک؛
- Vendor بیرونی ذاتاً بیطرف و تازهنگر است؛
- مدل Hybrid بدون Integrator و Interface؛
- خرید headcount بدون Outcome/Work product؛
- رزومهٔ فروش بهجای افراد تحویلی و Work sample؛
- گواهی یا NDA بهعنوان کنترل اجرایی؛
- اعتماد به Reference معرفیشده بدون Scope؛
- استفاده از دادهٔ Production برای Pilot؛
- Pilot رایگان با کار واقعی و استثمار Candidate؛
- Bug/Test/hour count بهعنوان KPI کیفیت؛
- پرداخت per-bug یا per-test بدون کنترل gaming؛
- Fixed price روی Scope ناشناخته؛
- Outcome pricing برای چیزی خارج از کنترل Vendor؛
- QA Vendor بهعنوان Release/risk owner پیشفرض؛
- دسترسی مشترک، دائمی یا بدون owner؛
- Subcontractor نامرئی و location نامعلوم؛
- Tool/Cloud وابسته بدون تست دسترسی ایران؛
- انتقال دانش با تعداد جلسه یا صفحه؛
- Big-bang transition و حذف زودهنگام تیم قبلی؛
- Runbook بدون replay توسط Receiver؛
- مالکیت مبهم Automation و Artifact؛
- Exit در پایان قرارداد طراحی میشود؛
- تمدید بهعلت Lock-in بدون گزینهسنجی؛
- ویرایش خاموش Score، KPI یا گزارش قدیمی؛
- تعمیم Pilot کوچک به کیفیت/امنیت کل Service؛
- تضمین کیفیت، صرفهجویی یا سرعت بدون Baseline.
چکلیست مالک QA Sourcing
- Request، Sponsor، Decision owner و Facts-as-of مشخصاند؟
- Capability slice بهجای «تیم/کیفیت» تعریف شده؟
- Outcome hypothesis و Non-outcome قابلسنجشاند؟
- Product/Build/Risk/volume/horizon هویت دارند؟
- In/out، dependency و Unknown ثبت شدهاند؟
- Retained capability و حداقل ظرفیت داخلی معلوم است؟
- RACI از Decision authority و risk acceptance جداست؟
- همهٔ مدلهای معقول Make/Buy/Partner دیده شدهاند؟
- Hard gate پیش از امتیازدهی تعیین شده؟
- وزن و rubric پیش از پیشنهاد Vendor منجمد شده؟
- هویت، location و subcontractor tiers معلوماند؟
- افراد کلیدی، تخصیص و substitution rule روشن است؟
- Due diligence Evidence/date/scope/expiry دارد؟
- Data flow و کمینهٔ داده ترسیم شده؟
- Access named/time-bound/logged/revocable است؟
- Incident/backup/deletion/continuity قابلآزموناند؟
- Work sample نماینده، synthetic و اخلاقی است؟
- False finding، repair و handover سنجیده میشوند؟
- Contract با Operating model همراستاست؟
- Service/Work order/Master و اولویت اسناد روشناند؟
- Definition of Ready/Done و Evidence schema وجود دارد؟
- KPI denominator، source، countermetric و gaming review دارد؟
- Pricing formula با edge case اجرا شده؟
- TCO افق/Range/Transition/Exit یکسان دارد؟
- Knowledge با receiver replay پذیرفته میشود؟
- Ramp stage و stop/rollback gate دارد؟
- زبان/timezone/holiday/handoff به Interface تبدیل شده؟
- استقلال و conflict بهجای externality سنجیده شده؟
- دسترسی/پرداخت/Tool/Region ایران واقعاً آزموده شده؟
- Exit export/revoke/delete/transition تمرین شده؟
- Renewal trigger و Correction بدون silent edit وجود دارد؟
- مشاوران حقوقی/امنیتی/مالی لازم در تصمیم حضور دارند؟
Pilot سیروزهٔ بدون Vendor واقعی
| بازه | کار | خروجی | Stop condition |
|---|---|---|---|
| روز ۱ تا ۵ | Context/Capability/Retained map | Sourcing Request v0 | Outcome یا owner نامعلوم |
| روز ۶ تا ۱۰ | Options/Hard gates/TCO schema | Decision rubric | یک گزینه از پیش برنده است |
| روز ۱۱ تا ۱۵ | Data/access/security/continuity | control and due-diligence pack | Production data لازم پنداشته شود |
| روز ۱۶ تا ۲۰ | Synthetic qualification experiment | scored artifacts + disagreement | free real work یا secret answer |
| روز ۲۱ تا ۲۵ | service/evidence/KPI/pricing simulation | draft catalogue/work order | gaming یا claim بیحد |
| روز ۲۶ تا ۳۰ | transition/receiver/exit/correction drill | decision options + unknowns | export/revoke/replay ناموفق |
این Pilot فقط Design و Process را با Fixture میآزماید. پیش از خرید واقعی، هویت، توان مالی، صلاحیت، داده، قرارداد، مالیات، امنیت، دسترسی و حقوق باید با Evidence واقعی و متخصصان ذیصلاح بررسی شود.
جمعبندی؛ Capability را تأمین کنید، پاسخگویی را نه
انتخاب تیم QA داخلی یا برونسپاری مسابقهٔ مزایا و معایب نیست. مدل حرفهای از Context و Outcome شروع میکند، کار را به Capability slice قابلتحویل میشکند، Retained capability و Decision rights را نگه میدارد، گزینهها را با Work sample و Due diligence میآزماید و امنیت، Evidence، قیمت، TCO، دانش، Continuity و Exit را پیش از Scale طراحی میکند.
زنجیرهٔ نهایی این است: Context → Capability → Sourcing option → Retained control → Supplier evidence → Pilot → Contract/Service → Evidence/KPI/TCO → Knowledge/Continuity → Exit/Correction. برونسپاری میتواند یک ابزار تأمین ارزشمند باشد؛ اما نه کیفیت را تضمین میکند، نه مسئولیت سازمان را منتقل، و نه یکبار برای همیشه تصمیم گرفته میشود.
سوالات متداول
چه زمانی برونسپاری تست نرمافزار منطقی است؟
وقتی Capability slice محدود و قابلتحویل است، تخصص یا ظرفیت درون سازمان بهموقع ساخته نمیشود، داده و دسترسی قابلکنترلاند، Qualification واقعی انجام شده، TCO و Exit قابلقبولاند و Retained owner باقی میماند. کوتاهمدت یا بودجهٔ کم بهتنهایی دلیل کافی نیست.
آیا برونسپاری QA همیشه ارزانتر از تیم داخلی است؟
خیر. نرخ Vendor را باید با هزینهٔ کامل داخلی در افق و Demand یکسان مقایسه کرد و sourcing، Pilot، Ramp، هماهنگی، ابزار، داده، Rework، incident، Currency و Exit را افزود. نتیجه ممکن است برای یک Slice ارزانتر و برای Slice دیگر گرانتر باشد.
چگونه امنیت اطلاعات را هنگام برونسپاری QA حفظ کنیم؟
با حذف نیاز به دادهٔ واقعی در حد ممکن، طبقهبندی و Data-flow، محیط تفکیکشده، identity نامگذاریشده، least privilege زماندار، endpoint/secret control، logging، subcontractor transparency، incident drill، retention/deletion و revoke/rotate در Exit. NDA لازم ممکن است باشد، اما این کنترلها را اجرا نمیکند.
در مدل Hybrid چه چیزی باید داخل سازمان بماند؟
یک پاسخ جهانی نیست؛ حداقل توان تعریف Outcome/Risk، مالکیت داده و دسترسی، Oracle/Test basis حساس، بررسی Evidence، Vendor governance، پذیرش Residual risk، Release authority، Continuity و Exit نباید گم شود. فعالیت میتواند بیرونی باشد، اما accountable owner و decision right باید صریح بماند.
مهمترین معیار انتخاب شرکت برونسپاری تست چیست؟
یک معیار واحد وجود ندارد. ابتدا Hard gateهای امنیت، داده، مالکیت، دسترسی، Continuity و Exit؛ سپس Work sample افراد تحویلی، کیفیت Evidence/repair/handover، Operating fit و TCO همافق را بسنجید. امتیاز بالا نباید شکست Hard gate یا Unknown پرپیامد را پنهان کند.
