پانزده نفر از پانزده نفر جلسه را تمام کردهاند، ۶۴ Journey از ۶۴ Journey «Pass» است و همه فرم Sign-off را امضا کردهاند. آیا UAT موفق بوده و محصول پذیرفته شده است؟ نه لزوماً. ممکن است هر پانزده نفر از یک Role کمریسک باشند، Build میان اجراها عوض شده باشد، Journeyهای برگشتناپذیر اصلاً در Scope نباشند، Facilitator مسیر را گفته باشد یا امضا فقط حضور را تأیید کند.
این راهنما موفقیت تست پذیرش کاربر (UAT) را با تعداد Participant، درصد Pass یا رضایت جلسه تعریف نمیکند. زنجیرهی تصمیم را میسازد: Segment → Participant eligibility → Business Journey → Acceptance Claim → Run/Observation/Evidence → Finding/Exception → Acceptance Recommendation → Authority Decision → Retest/Correction.
پاسخ کوتاه: UAT موفق چه خروجی دارد؟
UAT موفق برای یک Release/Build مشخص نشان میدهد چه کاربران یا نمایندگانی، کدام Journeyهای کسبوکار را، در چه Environment/Data و با کدام Oracle اجرا کردهاند؛ چه چیزی Pass، Fail، Inconclusive یا Not Run شده؛ چه Segment، Risk و Unknownی بیرون مانده؛ چه Exceptionی پذیرفته نشده یا زماندار است؛ و چه Authorityای در چه محدودهای تصمیم گرفته است. نتیجه یک ادعای محدود و قابل اصلاح است، نه تضمین موفقیت بازار.
| سیگنال | آنچه واقعاً میگوید | آنچه ثابت نمیکند |
|---|---|---|
| ۱۵/۱۵ حضور | Completion برنامهریزیشده | نمایندگی Segmentها |
| ۶۴/۶۴ Pass | Verdict ثبتشده برای Attemptها | صحت Oracle یا کفایت Journey |
| ۱۰۰٪ Sign-off | امضا طبق معنای فرم | مجوز Release یا نبود ریسک |
| Zero Finding | Finding ثبتشده صفر | نبود Failure/Unknown/Coverage gap |
| Participant راضی | یک Signal ادراکی | پذیرش همه Roleها یا Outcome بازار |
هدف جستوجو و مرز این راهنما
اگر تعریف UAT، تفاوت آن با System Testing و Sprint Review، نقشها، Entry/Exit، سناریو و قالب عمومی Sign-off را میخواهید، راهنمای پایه تست پذیرش کاربر مالک آن Intent است. این صفحه مسئلهی باریکتر و پیشرفتهتری را حل میکند: چگونه Participant Coverage و Evidence را به یک Acceptance Decision قابل ممیزی وصل کنیم و Sign-off را بیش از ظرفیتش تفسیر نکنیم.
| پرسش | مالک محتوا | خروجی |
|---|---|---|
| UAT چیست و چگونه اجرا میشود؟ | راهنمای پایه UAT | Plan/Scenario/Entry/Exit/Sign-off |
| کاربر واقعاً Workflow را قابل استفاده میداند؟ | Usability Testing | Study finding/measure |
| عملیات آماده پشتیبانی است؟ | Operational Readiness | Runbook/monitoring/recovery evidence |
| Release با ریسک باقیمانده انجام شود؟ | Release Decision | Go/Conditional/No-go record |
| UAT چه ادعایی را با چه نمایندگی پذیرفت؟ | همین مقاله | Acceptance Evidence/Decision record |
تعریف رسمی را دقیق و محدود بخوانید
ISTQB CTFL 4.0.1 Acceptance Testing را متمرکز بر Validation و نشاندادن آمادگی برای Deployment میداند؛ یعنی سیستم نیازهای کسبوکار کاربر را برآورده کند. سند میگوید اجرای آن توسط Intended Userها ایدهآل است و UAT را کنار Operational، Contractual، Regulatory، Alpha و Beta از شکلهای Acceptance Testing میشمارد. این تعریف نه فرم اجباری میدهد و نه میگوید هر UAT مجوز خودکار Go-live است.
UAT با همه Acceptance Testingها یکسان نیست
| نوع | سؤال نمونه | Authority/Evidence محتمل |
|---|---|---|
| User Acceptance | Journey نیاز کسبوکار Intended user را پوشش میدهد؟ | Business acceptance authority |
| Operational Acceptance | Operate/Monitor/Recover ممکن است؟ | Operations/SRE authority |
| Contractual Acceptance | تعهد قراردادی احراز شده؟ | Contract authority |
| Regulatory Acceptance | شرط الزامآور مرتبط احراز شده؟ | Compliance/legal-defined authority |
| Alpha/Beta | در گروه/محیط محدود چه یادگیری حاصل شد؟ | Program-specific decision owner |
یک UAT موفق نمیتواند نبود Operational، Security، Accessibility یا Contractual evidence را پنهان کند. برای سنجش کفایت کلی Release، چارچوب تصمیم انتشار با کیفیت کافی را جدا نگه دارید.
UAT همیشه «آخرین مرحله تست» نیست
در یک جریان ترتیبی ممکن است UAT نزدیک Go-live باشد؛ در Agile/Continuous Delivery میتواند برای Sliceهای ارزش، Prototype، Migration rehearsal یا Release candidate چند بار رخ دهد. پس از UAT نیز ممکن است Retest، Regression، Operational rehearsal، Security verification یا Accessibility review لازم باشد. ترتیب را SDLC، Risk و Decision need تعیین میکند، نه یک جملهی ثابت.
مدل مرکزی: Acceptance Evidence Chain
UATAcceptanceChain {
releaseId, buildId, environmentId, basisVersion,
segmentModelId, participantSetId,
journeyPortfolioId, acceptanceClaimIds[],
runIds[], observationIds[], evidenceManifestId,
findingIds[], exceptionIds[],
recommendationId, decisionId,
limitations[], expiry, correctionId
}
این قرارداد و قراردادهای بعدی الگوی عملیاتی همین راهنما هستند، نه فیلدهای تجویزی ISTQB. ارزش آنها در Traceability است: اگر Build، Basis، Segment، Journey یا Evidence تغییر کرد، میتوان ادعاها و تصمیمهای متاثر را پیدا کرد.
هویتها را پیش از اولین جلسه قفل کنید
Program/Product/Release/UAT Cycle/Charter/Basis/Repository/Commit/Build/Deployment/Environment/Data Profile/Segment Model/Journey Portfolio/Acceptance Policy/Decision Policy/Evidence Manifest و Cutoff زماندار لازماند. «نسخه امروز» یا «محیط UAT» هویت نیست. اگر Hotfix میان دو Run آمده، نتایج دو Build را بیصدا جمع نکنید.
UAT Charter؛ تصمیم مورد انتظار را قبل از اجرا بنویسید
UATCharter {
uatCycleId, purpose, decisionNeed, businessOutcome,
releaseId, basisVersion, inScope[], outOfScope[], notClaimed[],
stakeholderIds[], segmentModelId, journeyPortfolioId,
participantRole, facilitatorRole, testSupportRole,
decisionAuthority, riskAuthority,
entryCriteria[], exitCriteria[], schedule,
changeRule, stopRule, digest
}
«برگزاری UAT» Purpose نیست. بنویسید کدام تصمیم با چه Consequence نیاز به Evidence دارد. notClaimed را صریح کنید: برای مثال Market adoption، کل Product quality، انطباق حقوقی یا آمادگی عملیات با این Cycle اثبات نمیشود.
Acceptance Basis؛ معیار را بعد از دیدن نتیجه عوض نکنید
Business process، Policy، Requirement، Acceptance criteria، Contract rule، Data definition، Workflow map و Decision rule میتوانند Basis باشند. Source/Owner/Version/Effective date/Conflict/Assumption را ثبت کنید. تغییر مشروع است، اما باید Baseline تازه و Change impact داشته باشد؛ حذف Criterion شکستخورده از مخرج، اصلاح نیست.
| Basis item | سؤال کنترل | خطر |
|---|---|---|
| Business rule | نسخه و Owner چیست؟ | قاعده شفاهی |
| Acceptance criterion | Observable و Oracleدار است؟ | «کاربر راضی باشد» |
| Workflow | Role/State/Handoff روشن است؟ | Screen-only scope |
| Data definition | واحد/پول/زمان/Null چیست؟ | Expected مبهم |
| Decision policy | Authority و vocabulary چیست؟ | Sign-off نمایشی |
Segment با Persona یا Job Title یکی نیست
UATSegment {
segmentId, segmentName, jobToBeDone,
businessRole, permissionProfile,
experienceBand, frequencyBand, contextOfUse,
language, locale, timezone,
accessNeeds[], assistiveTechnology[],
connectivityContext, deviceContext, riskExposure,
populationBasis, targetCountRationale,
recruitmentLimitations[], coverageStatus
}
دو نفر با عنوان «کارشناس عملیات» ممکن است Permission، تجربه، Frequency، Context، زبان یا نیاز دسترسی متفاوت داشته باشند. Segment برای پوشش تصمیم ساخته میشود؛ Persona تخیلی بهتنهایی Participant eligibility یا نمایندگی جمعیت را ثابت نمیکند.
Participant مناسب: واقعی، محتمل یا Proxy شفاف
راهنمای رسمی GOV.UK برای جذب مشارکتکننده بر Actual یا likely user، تنوع گروهها، دسترسیپذیری، پرهیز از سوگیری جذب و کمینهسازی داده شخصی تاکید دارد. این منبع درباره User Research است، نه استاندارد UAT؛ اما برای طراحی نمایندگی و محدودیت نمونه مرجع عملی مفیدی است.
در UAT سازمانی، کارمند داخلی میتواند خودِ Intended user باشد. اگر نماینده، Subject-matter expert یا Proxy است، Basis و Limitation را ثبت کنید. گزارهی «داخلی هرگز معتبر نیست» همانقدر نادرست است که «یک مدیر میتواند نماینده همه کاربران باشد».
Participant Contract؛ حضور با نمایندگی برابر نیست
UATParticipant {
participantId, segmentId,
eligibilityEvidence, screeningVersion,
actualOrLikelyUserBasis, conflictDisclosure,
priorExposure, trainingLevel,
accessAccommodation, languageSupport,
consentRef, privacyNoticeRef, dataMinimization,
withdrawalStatus, incentiveClass,
attendanceStatus, replacementRule, pseudonymizedRef
}
Participant ID را Pseudonymous نگه دارید و Attributeهای حساس را فقط طبق Purpose/Policy و با دسترسی محدود ذخیره کنید. Absence، Replacement، Withdrawal، prior product exposure و Training میتواند Interpretation را تغییر دهد؛ حذف بیصدای آنها داده را «تمیز» نمیکند.
تعداد مشارکتکننده عدد جادویی ندارد
هدف Discovery کیفی، Benchmark، اثبات قراردادی یا پوشش Roleهای عملیاتی یکسان نیست. تعداد را از Segment/Risk/Journey/Method/Decision consequence، تنوع، عدمقطعیت و امکان Iteration استدلال کنید. پانزده نفر از یک Segment نمیتوانند فقدان Segment بحرانی را جبران کنند؛ صد نفر نیز Oracle بد را درست نمیکنند.
| پرسش | Evidence لازم | Claim limit |
|---|---|---|
| مسئلهای کشف میشود؟ | نمونه هدفمند و Observation غنی | نه شیوع جمعیتی |
| Journey Role حیاتی پذیرفته است؟ | Eligible role + valid attempts | همان Role/شرایط |
| دو نسخه مقایسه شوند؟ | طرح/نمونه/Measure مناسب | طبق عدمقطعیت طرح |
| تعهد سازمانی احراز شود؟ | Basis/Authority قراردادی | فقط تعهد تعریفشده |
Consent، Privacy و Accessibility بخشی از اعتبار اجرا هستند
Purpose، داده جمعآوریشده، ضبط/مشاهده، استفاده و نگهداری، دسترسی، خروج داوطلبانه و مسیر پرسش را با زبان و قالب قابل فهم Participant روشن کنید. نیازهای Keyboard، Screen reader، بزرگنمایی، مترجم، زمان استراحت، مکان/اتصال و پشتیبانی را پیش از جلسه بپرسید. این متن توصیه حقوقی نیست؛ Policy و Authority سازمان حاکم است.
Journey Portfolio؛ Screen را با Outcome اشتباه نگیرید
BusinessJourney {
journeyId, journeyVersion, segmentIds[],
businessGoal, trigger, preconditions,
startState, endState, steps[], roleHandoffs[],
businessRules[], dataClasses[], dependencies[],
expectedOutcome, unacceptableOutcomes[],
criticality, frequencyBasis, riskIds[],
acceptanceClaimIds[], digest
}
Journey فقط Happy path داخل UI نیست. Handoff، Timeout، Resume، Approval، Export، Notification، Reversal، Retry، Duplicate، Late event و Reconciliation ممکن است بخشی از Outcome باشند. برای ارزیابی عمیق Workflowهای سازمانی، تست کاربردپذیری نرمافزار سازمانی را جدا اجرا کنید.
Acceptance Claim؛ دقیقاً چه چیزی قرار است پذیرفته شود؟
AcceptanceClaim {
claimId, claimText, basisRef,
segmentIds[], journeyId, scope, conditions[],
expectedOutcome, oracleRef,
evidenceRequirement[], threshold, thresholdBasis,
validityWindow, ownerCapability,
limitations[], status, digest
}
«سیستم قابل قبول است» بیش از حد پهن است. Claim سالم میگوید Role تعریفشده روی Build و Environment معین، Journey معین را تحت Conditionهای معین با Outcome و Evidence معین انجام میدهد. Product success، Retention یا رضایت بازار را از یک Cycle داخلی نتیجه نگیرید.
Oracle پذیرش را به لبخند یا نظر لحظهای نسپارید
Participant statement مهم است، اما تنها Oracle نیست. State transition، Business invariant، نتیجه Ledger/Report، Role authorization، Handoff receipt و Outcome observable را کنار آن بگذارید. Expected باید Source و version داشته باشد. برای طراحی Comparator و مرز Expected/Verdict، راهنمای Test Oracle را ببینید.
| Oracle | نمونه | محدودیت |
|---|---|---|
| Business rule | اثر مالی خیالی حداکثر یک بار | نسخه Rule لازم است |
| State | PENDING→RECONCILED | ظاهر UI کافی نیست |
| Document/Report | مجموع/واحد/بازه درست | Source data هم باید معتبر باشد |
| Participant judgment | Outcome برای Role قابل قبول است | Scope و Authority محدود |
| Policy threshold | Unacceptable outcome صفر | Basis و مخرج لازم است |
Environment و Data؛ واقعگرایی چندبعدی است
UAT Environment لازم نیست Production باشد و کپی Production نیز خودکار «واقعی» نیست. نسخه، Configuration، Integration stub، Permission، Feature flag، Locale، Timezone، Device/Network، Data distribution و Volume را نسبت به Claim بسنجید. Fidelity را بعدبهبعد ثبت و Limitation را حمل کنید.
| بعد | پرسش | شاهد |
|---|---|---|
| Build/Config | همان Candidate است؟ | Digest/manifest |
| Identity/Role | Permission واقعینماست؟ | Role matrix |
| Data | Boundary/relationship/state دارد؟ | Data profile |
| Dependency | Stub چه چیزی را شبیه نمیکند؟ | Contract/limitation |
| Locale/Time | fa-IR/RTL/UTC/Asia-Tehran درست است؟ | Environment evidence |
| Access | Participant ابزار لازم دارد؟ | Accommodation record |
Entry Criteria؛ «QA تمام شد» معیار کافی نیست
Charter/Basis/Build/Environment/Data آماده، Participant eligibility و Consent روشن، Journey/Claim/Oracle قابل اجرا، Known issue و Limitation ابلاغ، Evidence capture آزموده، Support و Stop rule حاضر و Change freeze تعریفشده باشند. Entry miss میتواند BLOCK، WAIVE با Authority/expiry یا Reschedule شود؛ نباید ناپدید شود.
Execution Record؛ هر Attempt هویت و محدودیت دارد
UATRun {
runId, participantId, journeyId, claimIds[],
buildId, environmentId, dataProfileId,
startedAt, endedAt, facilitatorId,
assistanceEvents[], deviations[],
attemptStatus, resultVocabulary,
oracleResult, evidenceRefs[], limitations[], digest
}
Attempt را PASS نکنید اگر Build معلوم نیست، Participant اشتباه است، Dependency قطع بوده، Facilitator پاسخ را داده یا Evidence ناقص است. INVALID و INCONCLUSIVE بهاندازه PASS/FAIL واقعیاند؛ حذف آنها Pass rate را زیبا و تصمیم را ضعیف میکند.
Facilitation؛ کمک را ثبت کنید، نه اینکه پنهان کنید
Clarify task wording، توضیح Business rule، Navigation hint، Recovery help و اجرای مستقیم توسط Support اثر یکسان ندارند. Assistance level، زمان، دلیل و اثر بر Verdict را ثبت کنید. Training لازم را از Coaching هنگام Attempt جدا کنید. Participant نباید برای «قبولی پروژه» تحت فشار باشد.
| رخداد | ثبت | اثر محتمل |
|---|---|---|
| توضیح واژه سناریو | Clarification | Limitation/ممکن است Valid بماند |
| گفتن محل دکمه | Navigation hint | Claim استقلال متاثر |
| انجام مرحله توسط Facilitator | Direct intervention | Attempt معمولاً Invalid/Fail برای آن Claim |
| رفع خرابی Environment | Environment intervention | Restart/Separate attempt |
Observation، Feedback، Finding، Defect و Change Request را جدا کنید
UATObservation {
observationId, runId, timestamp,
observedBehavior, participantStatement, interpretation,
evidenceRefs[], assistanceLevel,
affectedClaimIds[], affectedSegmentIds[],
classification, severityProposal, businessImpact,
unknowns[], disposition, ownerCapability, digest
}
Observation میتواند به Defect، Requirement gap، Usability issue، Training/content need، Data/Environment issue، Policy conflict، Change request یا No action with rationale تبدیل شود. گفته Participant واقعیت تجربه اوست، اما Cause یا راهحل قطعی نیست. برای فرایند تصمیم، پروتکل تریاژ باگ را بهکار ببرید.
Evidence Manifest؛ Screenshot بهتنهایی پرونده نیست
Manifest باید Evidence ID/Type/Source/Subject/Run/Claim/Build/Environment/CapturedAt/Producer/Access/Redaction/Retention/Digest و Limitation را نگه دارد. داده شخصی یا کسبوکاری را بینیاز جمع نکنید. Screenshot بدون State، Time، Build و Oracle ممکن است قابل تفسیر نباشد؛ Recording نیز Consent و Access policy میخواهد.
Vocabulary نتیجه را قبل از Run تعریف کنید
| Verdict | معنا | اقدام |
|---|---|---|
| PASS | Claim در Scope و Conditions با Evidence پشتیبانی شد | Carry limitations |
| FAIL | Oracle/Unacceptable outcome نقض شد | Finding/Triage |
| INCONCLUSIVE | Evidence برای Verdict کافی نیست | رفع Gap/تکرار |
| INVALID | Attempt قرارداد اجرا را نقض کرد | اصلاح Setup/تکرار |
| NOT_RUN | Attempt انجام نشد | علت/اثر بر Coverage |
PASS_WITH_ASSISTANCE یا PASS_WITH_LIMITATION را میتوان بهعنوان Extension تعریف کرد، مشروط به semantics نسخهدار. «Completed» Verdict نیست. مخرج را ثابت کنید: Planned، Eligible، Started، Valid، Decided و Retested را یکی نگیرید.
Coverage را چندبعدی گزارش کنید
| Coverage | صورت/مخرج | Blind spot |
|---|---|---|
| Segment | Segments adequately represented / planned | یک نفر نماینده ضعیف |
| Journey | Journeys with valid attempts / scoped | Happy path غالب |
| Claim | Claims with verdict / baselined | Claim پهن یا Oracle ضعیف |
| Risk | Risks with mapped evidence / scoped | شدت بالا بیرون Scope |
| Variant | Boundary/negative/handoff variants / planned | همه Pass اما تکراری |
| Build | Evidence on candidate build / all evidence | نتیجه نسخه قدیم |
Retest و Regression؛ تغییر کوچک Evidence را منقضی میکند؟
Fix، Config، Copy، Permission، Data mapping یا Dependency change میتواند Claimهای دیگری را متاثر کند. Change impact، affected Claim/Journey/Segment، Retest scope، Regression guardrail و Evidence supersession را ثبت کنید. فقط مورد Fail را دوباره زدن ممکن است Handoff یا Variant مجاور را جا بگذارد.
Exception و Residual Risk را زیر Sign-off دفن نکنید
Exception باید Claim/Journey/Segment، Evidence، Rationale، Business impact، Compensating control، Owner، Authority، Expiry، Reopen trigger و Retest plan داشته باشد. Acceptance of a workflow با Acceptance of risk یکی نیست. Participant یا Facilitator لزوماً Risk authority نیست.
Recommendation، Acceptance Decision، Sign-off و Release را جدا کنید
| Artifact/Action | سؤال | Authority |
|---|---|---|
| UAT Result | Evidence چه Verdictهایی ساخت؟ | Evidence/Test owner |
| Recommendation | با این Evidence چه پیشنهاد میشود؟ | Charter-defined recommender |
| Acceptance Decision | کدام Claim در چه Scope پذیرفته است؟ | Business acceptance authority |
| Risk Acceptance | کدام Residual risk پذیرفته میشود؟ | Named risk authority |
| Release Decision | Deploy/Release/Launch شود؟ | Release authority |
| Sign-off | امضا طبق semantics فرم چه چیزی را attest میکند؟ | Defined signatory |
برای بستهی کامل شواهد انتشار، گزارش اختتامیه تست را ببینید. UAT میتواند ورودی آن باشد، اما جای Security، Performance، Operations یا Deployment evidence را نمیگیرد.
Acceptance Result و Decision Record قابلکپی
UATAcceptanceDecision {
recommendationId, cycleId, scope,
basisVersion, releaseId, buildId, environmentId,
segmentCoverage[], journeyCoverage[], claimVerdicts[],
findingSummary[], exceptionRefs[], unknowns[], limitations[],
residualRisk[], recommendation,
decisionAuthority, decision, conditions[],
evidenceManifestId, decidedAt, expiry,
reopenTriggers[], supersedes, digest
}
Vocabulary پیشنهادی: ACCEPT_WITHIN_SCOPE، CONDITIONAL_ACCEPTANCE، DO_NOT_ACCEPT، INCONCLUSIVE و ESCALATE. اینها وضعیت Product یا Release جهانی نیستند. Conditions باید Owner/due/evidence داشته باشند؛ Expiry بدون Reopen نیز فقط یک تاریخ تزئینی است.
Sign-off دقیقاً چه چیزی را امضا میکند؟
فرم میتواند حضور، مشاهدهی Result، تایید صحت Summary، Acceptance محدود Claimها، پذیرش Exception یا Decision انتشار را امضا کند؛ این معناها را یکی نکنید. Signatory role، Authority source، Scope، Build/Basis، Evidence digest، Conditions، Dissent، timestamp و معنا را روی خود Record بیاورید.
| امضا | متن سالم | متن خطرناک |
|---|---|---|
| Acknowledgment | Result نسخه X را دیدم | محصول خوب است |
| Evidence attestation | Summary با Manifest Y سازگار است | هیچ باگی نیست |
| Acceptance | Claimهای A/B در Scope C پذیرفتهاند | همه چیز Accepted |
| Conditional | با شروط/expiry/owner مشخص | بعداً درست میکنیم |
Dissent و Conflict را پاک نکنید
اختلاف Participant، Product، Operations یا Support یک Average ساده نیست. Claim، Evidence، Interpretation، Consequence و Authority را جدا ثبت کنید. تعارض منافع—مثلاً Facilitatorی که هم Delivery target دارد و هم Acceptance authority است—باید Disclosure/Recusal/Escalation داشته باشد. Minority observation ممکن است Risk پراثر را آشکار کند.
Agile و Continuous UAT؛ Evidence کوچک اما نسخهدار
بهجای یک Ceremony سنگین انتهای Release، Claimها را به Journey/Risk Slice تقسیم کنید؛ Business representative میتواند Example review، workflow rehearsal و Candidate acceptance انجام دهد. Automation Preconditions و State checks را آماده میکند، اما تجربه، اختیار و Judgment را تقلید نمیکند. Evidence هر Slice باید Build/Basis و expiry داشته باشد تا جمعشدن آن به معنای جمعکردن نسخههای ناسازگار نباشد.
UAT با Usability Study و Beta چه تفاوتی دارد؟
UAT درباره پذیرش نیاز کسبوکار در Scope تعریفشده است؛ Usability Study میتواند رفتار، موفقیت Task، زمان، خطا، SEQ یا SUS را با طرح پژوهش بررسی کند؛ Beta یادگیری در جمع/محیط محدود و متنوعتری میدهد و معمولاً کنترل کمتر دارد. یک Session ممکن است دادهی چند هدف بسازد، اما Protocol، Sampling، Consent، Measure و Claims را مخلوط نکنید. برای سنجهها به راهنمای معیارهای تست کاربردپذیری مراجعه کنید.
آزمایشگاه فارسی و آفلاین Checkout خیالی
Lab کاملاً ساختگی و بدون شبکه است: Order/PaymentAttempt/PSP Stub/Callback/Ledger/Reconciliation خیالی دارد. Participant شبهنامدارِ Role عملیات باید پس از Timeout نمایشی، وضعیت Fake order را ببیند و دقیقاً یک اثر مصنوعی را Reconcile کند. این مثال هیچ شرکت، کاربر، بانک، PSP، پرداخت یا فرایند واقعی را توصیف نمیکند.
| Journey variant | Acceptance Claim | Unacceptable outcome | Evidence |
|---|---|---|---|
| Timeout پیش از commit خیالی | وضعیت Unknown گمراهکننده نباشد | تکرار کور | State/Observation |
| Timeout پس از commit خیالی | Reconcile اثر موجود را تشخیص دهد | اثر Duplicate | Fake ledger |
| Callback دیررس | Order درست متصل شود | Wrong association | Correlation IDs |
| Callback تکراری | اثر اضافی ساخته نشود | Duplicate effect | Invariant output |
| Handoff Support→Ops | Context قابل بازیابی باشد | Lost context | Receipt/trace |
شناسههای Tenant/Order/Attempt/Event/Ledger/Run/Build/Evidence جدا هستند؛ IRR کاملاً خیالی واحد Canonical و تومان فقط نمایش برچسبخورده است؛ ارقام فارسی/عربی/لاتین، ی/ی و ک/ک، Unicode NFC، RTL/LTR، UTC/Asia-Tehran و جلالی فقط نمایشی آزموده میشوند. هیچ نام، موبایل، ایمیل، IP، Account، PAN، CVV2، OTP، Cookie، Token، Credential، Log یا Screenshot واقعی وجود ندارد.
Fixture: ۱۰۰٪ Sign-off در برابر ۲۲۰ Finding
Fixture مستقل `SYN-UAT-ACCEPTANCE-DECISION-۰۱` با Node.js و بدون Dependency بیرونی اجرا شد. Dashboard نشان داد ۱۵ نفر از ۱۵ نفر حاضر، ۶۴ Journey از ۶۴ Journey Pass و Sign-off برابر ۱۰۰٪ است و `UAT_SIGNOFF_PASS` صادر کرد. ممیزی ۲۳۰قاعدهای همان ورودی را با دقیقاً ۲۲۰ Finding به HOLD برد.
| گروه | قاعده | نمونه |
|---|---|---|
| Identity | 18 | Release/Build/Basis/Environment/Policy |
| Charter | 18 | Decision/Scope/Authority/Stop |
| Segment | 20 | Role/Context/Access/Population/Limit |
| Journey | 20 | Goal/State/Handoff/Rule/Risk |
| Claim | 17 | Basis/Scope/Oracle/Evidence/Validity |
| Participant | 18 | Eligibility/Consent/Exposure/Accommodation |
| Execution | 18 | Attempt/Build/Assistance/Verdict/Evidence |
| Observation | 17 | Behavior/Statement/Interpretation/Disposition |
| Decision | 20 | Coverage/Unknown/Risk/Authority/Expiry |
| Governance | 20 | Policy/Retest/Correction/Access/Metrics |
| Forbidden | 34 | تضمین و یکیگرفتن مفاهیم |
| Relations | 10 | پیوند هویت و vocabulary شرطی |
۲۲۰ Finding برابر ۱۸۶ فیلد غایب و ۳۴ ادعای ممنوع بود؛ ده Relation چون رکوردهای Claim/Run/Decision اصلاً وجود نداشتند، صادقانه فعال نشدند. نسخه اصلاحشده Segment عملیات، Journey `JOURNEY-RECONCILE-SYN-۳۳`، Claim و Oracle، Participant eligibility/Consent، Build/Environment/Data، Assistance، Observation و یک `CONDITIONAL_ACCEPTANCE` منقضیشونده را پیوند داد و `READY_FOR_UAT_ACCEPTANCE_REVIEW` با صفر Finding ساخت؛ نه اثبات حقیقت Evidence، نمایندگی جمعیت، کفایت Threshold، کیفیت محصول، انطباق یا مجوز Release.
Automation و AI در UAT
Automation میتواند Build identity، Data reset، Environment smoke، Journey trace، State invariant، Evidence digest و Coverage diff را کنترل کند. AI میتواند Observationها را برای Human review خوشهبندی، Trace candidate پیشنهاد یا متن Summary را Draft کند؛ نباید Participant statement بسازد، Consent را فرض، Segment را بدون Basis نمایندگی، Finding را خودکار ببندد، Risk بپذیرد یا Sign-off/Release صادر کند. Prompt/Input/Model/Output و Reviewer را ثبت کنید.
معیارهای سالم و Countermetricها
| Metric | کاربرد | Countermetric/محدودیت |
|---|---|---|
| Segment coverage | نمایندگی Scope | Eligibility/Recruitment limitation |
| Valid Journey attempts | Execution واقعی | Assistance/Invalid rate |
| Claim verdict coverage | تصمیمپذیری | Oracle weakness/Unknown |
| Finding-to-claim trace | اثر Finding | Unclassified observations |
| Retest freshness | اعتبار Candidate | Change-trigger misses |
| Exception age | بدهی زماندار | Silent expiry/reopen miss |
| Decision latency | Flow تصمیم | Pressure/weak evidence |
| Correction reach | اصلاح downstream | Access/privacy incident |
۳۴ Anti-pattern در UAT و Sign-off
- UAT موفقیت محصول را تضمین میکند.
- UAT پذیرش بازار را تضمین میکند.
- UAT جلوی شکست Launch را میگیرد.
- Sign-off یعنی محصول بدون Defect است.
- Sign-off همان مجوز Release است.
- همه Pass یعنی Accepted.
- همه امضا کردند یعنی نمونه نماینده است.
- همیشه فقط کاربر واقعی معتبر است.
- کاربر داخلی هرگز معتبر نیست.
- UAT همیشه آخرین تست است.
- UAT فقط قبل Go-live انجام میشود.
- UAT همان Usability Testing است.
- UAT همان Beta Testing است.
- UAT همان Demo مشتری است.
- UAT همان Sprint Review است.
- UAT همان Requirement Review است.
- UAT جای System Testing را میگیرد.
- UAT جای Operational Readiness را میگیرد.
- UAT جای Accessibility Testing را میگیرد.
- UAT جای Security Testing را میگیرد.
- رضایت Participant اثبات Acceptance است.
- Zero Finding اثبات کیفیت است.
- یک فرد نماینده Segment است.
- یک تعداد ثابت برای همه UATها کافی است.
- Participant بیشتر Confidence را تضمین میکند.
- Participant خودکار Decision authority است.
- QA خودکار Acceptance authority است.
- Product Owner همیشه Signatory نهایی است.
- هر Major Finding همیشه Block است.
- هر Minor Finding هرگز Block نیست.
- Production data برای UAT لازم است.
- Production environment برای UAT لازم است.
- AI میتواند Sign-off کند.
- Acceptance یعنی Residual risk صفر است.
چکلیست ۳۲نقطهای UAT Decision Owner
| حوزه | کنترل |
|---|---|
| Identity | Release/Build/Deploy/Environment/Data/Basis/Policy/Cutoff قفل است؟ |
| Charter | Purpose/Decision/Scope/not-claimed/Authorities/Stop روشن است؟ |
| Basis | Source/Owner/Version/Conflict/Change ثبت است؟ |
| Segment | Job/Role/Permission/Experience/Context/Access/Risk/Population دارد؟ |
| Participant | Eligibility/Proxy limit/Exposure/Consent/Privacy/Accommodation ثبت است؟ |
| Journey | Goal/Trigger/State/Handoff/Rule/Dependency/Unacceptable outcome دارد؟ |
| Claim | Basis/Segment/Journey/Scope/Condition/Oracle/Evidence/Validity دارد؟ |
| Execution | Attempt/Build/Time/Assistance/Deviation/Verdict/Evidence متصل است؟ |
| Observation | Behavior/Statement/Interpretation/Unknown جدا هستند؟ |
| Coverage | Segment/Journey/Claim/Risk/Variant/Build با مخرج گزارش شده؟ |
| Finding | Classification/Impact/Disposition/Owner/Retest دارد؟ |
| Exception | Authority/Rationale/Control/Expiry/Reopen دارد؟ |
| Decision | Result/Recommendation/Acceptance/Risk/Release/Sign-off جدا هستند؟ |
| Freshness | Change impact/Validity/Retest/Supersession/Correction تعریف است؟ |
| Governance | Access/Retention/Appeal/AI/Metric/Countermetric روشن است؟ |
Pilot سیروزه برای اصلاح یک UAT موجود
| بازه | کار | خروجی/Guardrail |
|---|---|---|
| روز ۱–۵ | یک Decision و Release انتخاب؛ Charter/Authority | Scope کوچک/not-claimed |
| روز ۶–۱۰ | Segment/Journey/Claim/Oracle | Risk-based coverage |
| روز ۱۱–۱۵ | Recruitment/Consent/Environment/Data dry run | Privacy/accessibility/stop |
| روز ۱۶–۲۰ | Run/Assistance/Observation/Evidence | PASS/FAIL/INC/INVALID/NOT_RUN |
| روز ۲۱–۲۵ | Triage/Retest/Exception/Recommendation | Owner/expiry/reopen |
| روز ۲۶–۳۰ | Decision rehearsal/metrics/correction | Scale/Adapt/Stop |
جمعبندی
UAT را با Ceremony، تعداد شرکتکننده یا صفحه امضا مدیریت نکنید. ابتدا Decision و Authority را روشن کنید؛ Segment و Journey را با Risk بسازید؛ Claim و Oracle را به Basis نسخهدار ببندید؛ Eligibility، Consent، Environment، Assistance و Evidence هر Attempt را حفظ کنید؛ Coverage و Unknown را کنار Verdict بیاورید؛ و Acceptance را از Risk/Release جدا کنید. UAT میتواند یک ادعای کسبوکاری را معتبرتر کند، اما نتیجه خوب یا امضای کامل، آینده محصول را تضمین نمیکند.
سؤالات متداول
آیا ۱۰۰٪ Pass در UAT یعنی محصول پذیرفته شده است؟
فقط اگر مخرج، Segment/Journey/Claim coverage، Oracle، Build، Attempt validity و Authority روشن باشد. حتی آنوقت Acceptance به Scope و Conditions همان Record محدود است؛ Product quality، Residual risk یا Release را خودکار تعیین نمیکند.
چه کسی باید UAT را Sign-off کند؟
نقشی که Charter و Governance برای همان نوع امضا اختیار دادهاند. Participant ممکن است Evidence بدهد، Process owner Claim را بپذیرد، Risk owner Exception را قبول کند و Release authority تصمیم دیگری بگیرد. Product Owner یا QA قانون جهانی نیست.
چند کاربر برای UAT کافی است؟
عدد ثابت وجود ندارد. Decision consequence، Segmentها، Journey/Risk، روش، تنوع، Confidence موردنیاز و Iteration را مبنا قرار دهید. Target count rationale و Recruitment limitation را ثبت کنید و فقدان Segment بحرانی را با تعداد بیشتر در Segment دیگر پنهان نکنید.
آیا کارمند داخلی میتواند Participant معتبر UAT باشد؟
بله، اگر واقعاً Intended user یا نماینده واجدصلاحیت Role سازمانی باشد. Prior exposure، Conflict و Training را ثبت کنید. برای محصول عمومی، Proxy داخلی محدودیت جدی دارد و نباید بیصدا به همه کاربران تعمیم داده شود.
اگر Finding مهمی در UAT پیدا شود چه کنیم؟
Observation را به Claim/Journey/Segment و Evidence وصل، سپس Defect/Requirement/Usability/Data/Environment/Policy یا Change request طبقهبندی کنید. Disposition، Owner، Retest و اثر بر Coverage را ثبت کنید؛ Block یا Exception را Authority و Risk تعیین میکند، نه فقط برچسب شدت.
