در برنامهٔ فصلی تیم نوشتهاند: «اعتماد به کیفیت Checkout را افزایش میدهیم.» پایین همان جمله دو عدد دیده میشود: رضایت ۴٫۵ از ۵ و کاهش ۲۰درصدی تیکت. هر دو سبز شدهاند، اما معلوم نیست اعتماد برای کدام کاربر، در کدام موقعیت، نسبت به چه چیزی و با چه شواهدی تعریف شده است. آیا کسی که پیام «پرداخت ناموفق» را فهمیده اما هنوز پولش برنگشته، تجربهٔ قابلاعتمادی داشته است؟ عدد سبز بهتنهایی پاسخ نمیدهد.
هدف کیفی در QA یک شعار غیرعددی، «حس خوب» یا KPI مبهم نیست. توصیف نسخهداری از وضعیت مطلوب یک Quality Attribute برای Actor، Object، Context و Horizon مشخص است که Question، Observable، Rubric، Evidence plan، Success/Stop criteria، Guardrail، Owner، Review و Correction دارد. برای پیگیری آن معمولاً به ترکیب شواهد کیفی و کمی نیاز دارید؛ نه تبدیل اجباری هر معنا به یک درصد.
خلاصهٔ اجرایی: از آرمان تا ادعای محدود
- واژهٔ کیفیت را به Construct، Actor، Object، Context و مرزهای روشن تبدیل کنید.
- وضعیت فعلی، وضعیت مطلوب، Horizon و تصمیمی را که Evidence پشتیبانی میکند جدا بنویسید.
- با Goal→Question→Evidence از جمعکردن Metricهای آماده جلوگیری کنید.
- Observable و Rubric لنگردار بسازید؛ تفسیر را پیش از دیدن نتیجه ثبت کنید.
- Evidence کمی، کیفی، رفتاری و عملیاتی را با Sample و Slice معتبر ترکیب کنید.
- شواهد مخالف، Unknown، Harm و Guardrail را حفظ کنید؛ میانگین را جای تجربهٔ همه ننشانید.
- در Review فقط یکی از Continue، Adapt، Stop، Achieved-with-scope یا Inconclusive را با دامنهٔ محدود انتخاب کنید.
Intent و کلیدواژههای این راهنما
| جزء | انتخاب |
|---|---|
| Intent اصلی | اطلاعاتی و اجرایی؛ طراحی، پیگیری و بازبینی هدف کیفیت در تیم محصول/QA |
| کلمهٔ کلیدی اصلی | هدف کیفی در QA |
| کلیدواژههای فرعی | اهداف کیفیت نرمافزار، Quality Goal، هدف تضمین کیفیت، سنجش هدف کیفی، Rubric، Qualitative Evidence |
| لانگتیل | چگونه هدف کیفی را اندازهگیری کنیم، نمونه هدف کیفی برای تیم تست، تفاوت هدف کیفی و KPI، پیگیری اهداف کیفیت نرمافزار، قالب Quality Goal Contract |
| پاسخ کوتاه | هدف را عملیاتی کنید، نه اینکه صرفاً آن را عددی کنید. |
هدف کیفی دقیقاً چیست؟
در این مقاله، Quality Goal یعنی یک وضعیت مطلوب دربارهٔ کیفیت محصول، خدمت یا سیستم کار؛ مانند «کاربر بتواند وضعیت پرداخت ناموفق را بدون حدسزدن بفهمد» یا «شواهد Release برای تصمیمگیرنده قابلردیابی باشد». واژههایی مثل قابلفهم، قابلاعتماد، بازیابیپذیر یا منصفانه Construct هستند: مفاهیمی که باید تعریف، مشاهده و با Evidence ارزیابی شوند.
«کیفی» در فارسی دو کاربرد دارد: گاهی «مربوط به کیفیت» و گاهی «غیرعددی/Qualitative». این دو را یکی نگیرید. هدف مربوط به کیفیت میتواند Evidence عددی داشته باشد؛ دادهٔ کیفی نیز میتواند با Coding یا Rubric دستهبندی شود. نوع هدف، نوع داده و مقیاس Measure سه انتخاب مستقلاند.
هدف کیفی با آرزو فرق دارد
«تجربه را عالی کنیم»، «فرهنگ کیفیت بسازیم» و «اعتماد را بالا ببریم» جهت میدهند، اما هنوز قابل Review نیستند. آرمان میتواند الهامبخش باشد؛ Quality Goal باید امکان مشاهدهٔ اختلاف، ثبت Unknown، تصمیم و بازنگری را ایجاد کند. افزودن یک تاریخ یا درصد به جملهٔ مبهم، ابهام Construct را درمان نمیکند.
شش مرز که نباید مخلوط شوند
| مفهوم | پرسش | نمونه |
|---|---|---|
| Vision | جهت بلندمدت چیست؟ | Checkout قابلاعتماد برای همه |
| Quality Goal | چه وضعیت مطلوبی، برای چه کسی و کجا؟ | کاربر وضعیت PaymentAttempt را درست بفهمد |
| Strategy | با چه رویکردی شاید به هدف برسیم؟ | بازطراحی پیام و Timeline |
| Activity/Output | چه کاری/چیزی تحویل میدهیم؟ | پنج مصاحبه یا یک کامپوننت جدید |
| Evidence/Measure | چه چیزی دربارهٔ پیشرفت میآموزیم؟ | Observation، Rubric و نرخ تماس پشتیبانی |
| Decision | با Evidence چه تغییری میدهیم؟ | Adapt پیام، Stop طرح یا محدودسازی Rollout |
Quality Goal با KPI یکی نیست
هدف میگوید چه وضعیت مطلوبی مهم است؛ KPI یک Measure منتخب برای تصمیم و Action مشخص است. یک هدف میتواند چند Question و چند Evidence داشته باشد و بعضی Evidenceها اصلاً KPI نباشند. برای طراحی Registry، Target، Threshold، Guardrail و چرخهٔ KPI به راهنمای KPI تضمین کیفیت بروید؛ این مقاله مالک تعریف و اثبات محدود خود هدف است.
Quality Goal با OKR و SMART یکی نیست
SMART یک یادآور برای Specific/Measurable/Achievable/Relevant/Time-bound است، نه روش اعتبارسنجی Construct یا کفایت Evidence. OKR نیز میتواند Objective توصیفی و Key Result عددی داشته باشد، اما نامگذاری KR ثابت نمیکند عدد، نمایندهٔ معتبر Outcome است. این قالبها در صورت سازگاری سازمانی مفیدند؛ Goal Contract زیر جای آنها را نمیگیرد و آنها نیز جای Evidence Protocol را نمیگیرند.
منابع و مرز استفاده از آنها
- پارادایم دانشگاهی Goal–Question–Metric از Basili و همکاران، اندازهگیری را از Goal و Question مشتق میکند؛ اینجا آن را برای طراحی پرسش بهکار میبریم، نه بهعنوان گواه ISO یا نسخهٔ آماده برای هر تیم.
- پژوهش DORA دربارهٔ انتخاب Measurement Framework متناسب با اهداف سازمانی بر Goal-first بودن و تناسب چارچوب با نیاز تأکید دارد؛ Metricهای DORA را هدف جهانی QA فرض نمیکنیم.
- راهنمای رسمی GOV.UK برای تحلیل پژوهش کاربر Observation، Finding و Action را جدا میکند؛ آن را الگوی Audit trail میگیریم، نه استاندارد اجباری تحقیق در ایران.
- سند عمومی اصول مدیریت کیفیت ISO Context، ذینفع، Process، Improvement و تصمیم مبتنی بر Evidence را توضیح میدهد؛ این مقاله ادعای انطباق یا بازتولید متن ISO ۹۰۰۱ ندارد.
زنجیرهٔ اصلی: Purpose تا Review
Purpose → Quality Construct → Actor/Object/Context → Current State → Desired State/Horizon → Questions → Observable/Rubric → Evidence Plan/Sample/Slices → Collection → Observation → Finding → Claim + Uncertainty → Decision/Action → Review → Adapt/Stop/Achieved-with-scope/Correction
گام اول: Purpose و Decision را قبل از Measure بنویسید
هدف بدون Purpose به فهرست فضیلتها تبدیل میشود. روشن کنید چرا اکنون این هدف مهم است و چه تصمیمی در چه موعدی به Evidence آن نیاز دارد. «بهبود اعتماد» برای یک Roadmap، یک Release محدود، اصلاح Recovery یا ارزیابی یک سیاست پشتیبانی، معنای یکسانی ندارد.
Purpose: کدام مسئله/ریسک/نیاز ذینفع؟ Decision: چه انتخابی، توسط کدام Authority، در چه موعدی؟ Use: Evidence برای Learn، Prioritize، Adapt، Gate یا Retire؟ Not deciding: چه تصمیمهایی خارج از این Review هستند؟
گام دوم: Construct را تعریف کنید
Construct همان مفهومی است که میخواهید دربارهاش ادعا کنید: «وضوح»، «اعتماد»، «همکاری» یا «قابلیت بازیابی». تعریف فرهنگ لغت کافی نیست. تعریف عملیاتی باید بگوید Construct در این محصول چگونه ظاهر میشود، چه چیزی نمونهٔ آن نیست و با کدام مفهوم نزدیک اشتباه نمیشود.
Construct: clarity_of_payment_state در این Context یعنی: Actor بتواند State، اقدام بعدی و زمان/مرجع پیگیری را بدون حدس یا اطلاعات متناقض توضیح دهد. نیست: زیبایی صفحه، سرعت پاسخ، رضایت کلی یا موفقشدن پرداخت. مفهوم نزدیک: trust؛ در این Review فقط Clarity بررسی میشود.
گام سوم: Actor، Object و Context را ببندید
کیفیت همیشه برای کسی و در شرایطی معنا دارد. «قابلفهم» برای کاربر فارسیزبان کمتجربه روی موبایل و شبکهٔ ناپایدار با همان ویژگی برای اپراتور پشتیبانی یکسان نیست. Population و Exclusion را ثبت کنید تا چند جلسهٔ راحت به کل کاربران تعمیم داده نشود.
| فیلد | پرسش مرزی |
|---|---|
| Actor/Stakeholder | چه کسی کیفیت را تجربه یا بر اساس آن تصمیم میگیرد؟ |
| Object | Journey، Capability، Artifact، Process یا تعامل دقیق کدام است؟ |
| Context | State، Channel، Device، Locale، Role و محدودیت چیست؟ |
| Population | ادعا دربارهٔ چه Universeای است؟ |
| Exclusion | چه گروه/Stateای سنجیده نشده و چرا؟ |
| Horizon | تا چه زمان و تحت چه نسخهای معتبر است؟ |
گام چهارم: وضعیت فعلی و مطلوب را جدا کنید
Baseline یک عدد قدیمیِ در دسترس نیست؛ Snapshot شواهد دربارهٔ Current State با همان Construct، Population، روش و Context است. Desired State نیز صرفاً «بهتر» نیست. تفاوت Current/Desired باید با Observable و Rubric قابل بحث باشد، حتی اگر فعلاً Baseline ندارید. نبود Baseline را `UNKNOWN` ثبت کنید، نه صفر.
قالب Quality Goal Contract
goal_id / revision / supersedes / status / as_of purpose_ref / decision_ref / authority / due construct / definition / non_examples / adjacent_constructs actor / object / context / population / exclusions current_state_ref / desired_state / horizon questions / observables / rubric_ref evidence_plan_ref / sample_plan / slices / counterevidence success_criteria / stop_criteria / guardrails / unknown_policy strategy_ref / action_owner / goal_owner / evidence_steward review_cadence / invalidation_triggers / expiry not_claimed / privacy_access / correction_policy
Goal را از Strategy جدا کنید
«با افزودن Timeline اعتماد را زیاد میکنیم» هدف و راهحل را زود به هم میچسباند. هدف: کاربر State و اقدام بعدی را بفهمد. Strategy candidate: Timeline. Hypothesis: Timeline در Context خاص Observableهای وضوح را بهتر میکند بدون افزایش زمان یا افشای اطلاعات. اگر Strategy شکست خورد، Goal ممکن است همچنان معتبر بماند.
Outcome، رفتار و Output را تفکیک کنید
برگزاری Workshop، افزودن تست و نوشتن راهنما Output هستند. پرسیدن سؤال روشنکننده یا ثبت ریسک Behavior است. تصمیم بهتر یا کاهش سردرگمی Outcome است. Output میتواند Evidence اجرای Strategy باشد، اما تحقق Outcome را ثابت نمیکند. تعداد جلسه، تعداد تستکیس یا تعداد کامنت را جای هدف کیفی ننشانید.
Goal→Question→Evidence بهجای Metric-first
منطق GQM کمک میکند اول بپرسیم برای داوری هدف چه باید بدانیم، سپس Evidence مناسب را انتخاب کنیم. اگر از Data موجود شروع کنید، Goal به چیزی تقلیل مییابد که ابزار راحت میشمارد. هر Question میتواند به چند Evidence و هر Evidence به یک دامنهٔ Claim محدود متصل شود.
| Question | Evidence محتمل | مرز |
|---|---|---|
| Actor State را چگونه توضیح میدهد؟ | Task observation + پاسخ آزاد | فهم در سناریوی نمونه، نه اعتماد کلی |
| کجا حدس یا توقف میکند؟ | Observation با Event marker | رفتار مشاهدهشده، نه انگیزهٔ قطعی |
| آیا پیام با Ledger سازگار است؟ | Oracle فنی مستقل | درستی State، نه فهم کاربر |
| چه گروهی آسیب بیشتری میبیند؟ | Sliceهای ازپیشتعریفشده | Sample محدود، نه Population کامل |
| چه پیامد ناخواستهای رخ میدهد؟ | Guardrail و Counterevidence | عدم مشاهده، اثبات عدم وجود نیست |
Observable چیست؟
Observable آن چیزی است که واقعاً میبینید، میشنوید یا از سیستم میخوانید؛ نه تفسیر شما. «کاربر گفت نمیدانم پول کجاست» Observation است. «کاربر اعتماد ندارد» Finding/Interpretation است. «طراحی بد است» Judgment است. این جداسازی Audit trail را حفظ میکند.
Rubric لنگردار بسازید
Rubric کیفیت را جادویی و عینی نمیکند؛ تفسیر را صریح و قابلبررسی میکند. هر Level باید Anchor رفتاری/شواهدی داشته باشد، `UNKNOWN` و `NOT_APPLICABLE` را جدا کند و پیش از مشاهدهٔ نتیجه نسخهگذاری شود. جمعزدن Levelهای ترتیبی به یک میانگین ممکن است معنای کاذب بسازد.
| Level | Anchor ساختگی برای وضوح State |
|---|---|
| 0 — Contradictory | State یا اقدام بعدی را خلاف Oracle توضیح میدهد |
| 1 — Guessing | State را حدس میزند یا برای ادامه کمک ضروری میخواهد |
| 2 — Partial | State را میگوید اما اقدام/زمان/مرجع را ناقص میداند |
| 3 — Clear-in-scope | State، اقدام و مرجع را در سناریوی مقید درست توضیح میدهد |
| U — Unknown | Evidence کافی/قابلاستفاده نیست |
| NA | Observable طبق Contract برای این State کاربرد ندارد |
Rubric باید Calibration داشته باشد
دو Reviewer باید چند Evidence مشترک را مستقل کدگذاری، اختلاف را بررسی و Anchorها را اصلاح کنند. Agreement بالا حقیقت Construct را ثابت نمیکند؛ فقط سازگاری Coding در Sample را نشان میدهد. اختلاف را با اجماع بیردپا پاک نکنید: کد اولیه، دلیل تغییر و نسخهٔ Rubric را نگه دارید.
Evidence کیفی را به نقلقول تزئینی تقلیل ندهید
یک Quote جذاب ممکن است مسئله را روشن کند، اما فراوانی یا شیوع آن را ثابت نمیکند. Research question، Recruitment/Sample، Context، Consent، روش یادداشت/ضبط، Observation ID، Coding و تحلیل موارد مخالف باید ثبت شوند. راهنمای تست تجربه کاربری از Observation تا Product Decision مرزهای عمیقتر پژوهش UX را پوشش میدهد.
Evidence کمی را Proxy حقیقت ننامید
رضایت، تعداد تیکت، نرخ تکمیل یا زمان انجام ممکن است Signal بدهند، اما Constructهای مجاور، Self-selection، تغییر Mix کاربران، کانالهای بسته یا تغییر Taxonomy بر آنها اثر میگذارد. برای Definition/Population/Window و Data lineage از قرارداد متریکهای تست نرمافزار استفاده کنید؛ Measure را اثبات علت یا معنای کامل Goal ندانید.
Triangulation یعنی پرسش مشترک، نه انباشت داده
سه Dataset نامرتبط، Triangulation نیست. شواهد باید به Question مشترک از زاویههای متفاوت پاسخ دهند: Observation نشان دهد Actor چه کرد، پاسخ آزاد بگوید چگونه فهمید، Event/Support data نشان دهد الگو در Window چه تغییری دارد و Oracle فنی State واقعی را تثبیت کند. همگرایی Confidence را بالا میبرد؛ واگرایی خودش Finding است.
وقتی شواهد با هم تعارض دارند
- تعارض را Average نکنید؛ Evidence source، Population و Time را مقایسه کنید.
- بررسی کنید Construct یا Question یکسان بوده است یا نه.
- Data quality، Recruitment، Survivorship و instrumentation change را ممیزی کنید.
- Sliceهای پنهانشده در Aggregate را باز کنید.
- نتیجه را `INCONCLUSIVE` نگه دارید و Follow-up Evidence تعریف کنید.
Sample و Slice بخشی از ادعا هستند
پنج مشارکتکنندهٔ راحت یا یک تیم داوطلب، کل Population نیستند. Sampling را بر اساس هدف Evidence طراحی کنید: Purposeful برای تنوع تجربه، Risk-based برای Stateهای حساس، Stratified برای Sliceهای ازپیشتعریفشده و Random در جایی که استنباط کمی لازم و ممکن است. Size را از یک «عدد جادویی» نگیرید؛ محدودیت و Saturation/precision plan را صریح کنید.
sample_id / population_ref / method / recruitment_channel inclusion / exclusion / target_slices / achieved_slices unit / planned_size / achieved_size / nonresponse context / period / stop_rule / limitations / privacy_ref
Baseline کیفی چگونه ثبت میشود؟
Baseline میتواند ترکیبی باشد: Distribution سطحهای Rubric، Observationهای دارای ID، Themeهای نسخهداری، Quoteهای کمینهشده و Measureهای پشتیبان. Baseline باید با Method/Population/Context یکسان یا دارای Bridge قابلمقایسه باشد. «قبلاً شکایت زیاد بود» Baseline نیست.
Desired State و Success Criteria
Success Criteria میتواند Predicate چندجزئی باشد: برای Sample و Sliceهای مشخص، شواهد سطح ۰ وجود نداشته باشد، بیشتر Evidenceهای قابلاستفاده Anchor سطح ۳ را داشته باشند، Oracle mismatch صفر باشد، Guardrailها بدتر نشوند و شواهد مخالف بدون Disposition باقی نماند. این Predicate Benchmark صنعت نیست و باید با هزینهٔ خطا و تصمیم همان تیم توجیه شود.
Threshold، Target و Rubric را قاطی نکنید
Rubric قاعدهٔ طبقهبندی Evidence است. Target وضعیت مطلوب برنامهریزیشده است. Threshold مرز Action/Gate است. Baseline وضعیت مشاهدهشده است. اگر یک عدد هر چهار نقش را بازی کند، نتیجه قابل ممیزی نیست. حدود آماری و Signal/Noise نیز مسئلهٔ جداگانهای است که در تحلیل روند معیارهای تست تشریح شده است.
Guardrail و Harm را قبل از اقدام ثبت کنید
بهینهکردن یک Construct میتواند کیفیت دیگری را خراب کند. پیام دقیقتر شاید طولانیتر، اضطرابآورتر یا برای Screen reader نامفهوم شود. کاهش تیکت شاید از سختترشدن دسترسی به پشتیبانی بیاید. Accessibility، Privacy، Latency، Error recovery، Exclusion و بار شناختی Guardrailهای محتملاند؛ انتخابشان وابسته به Context است.
شواهد مخالف را عمداً جستوجو کنید
Evidence plan فقط دنبال تأیید نیست. Negative case، State ناموفق، Slice کمنماینده، عبارت خلاف Theme و شرایطی را که Goal در آن صدق نمیکند جستوجو کنید. ثبت `counterevidence_search` و `disconfirming_result` مانع تبدیل Review به مراسم تأیید میشود.
هدف پیشرو و پسرو نیست؛ Indicator میتواند باشد
گاهی Strategy behavior زودتر دیده میشود و Outcome دیرتر؛ اما این رابطه باید فرضیه و اعتبارسنجی داشته باشد. عبارت «مشارکت بیشتر باعث فرهنگ بهتر میشود» رابطهٔ علّی اثباتشده نیست. برای Promotion و Validation از راهنمای شاخص پیشرو و پسرو در QA استفاده کنید.
Goal برای امتیازدهی افراد نیست
کیفیت محصول و همکاری نتیجهٔ سیستم، Context، اختیار، Dependency و تصمیمهای چندنقشی است. استفاده از تعداد Finding، Rubric، رضایت یا Cycle time برای رتبهبندی فردی، Evidence را آلوده و رفتار نمایشی میسازد. Contract باید `people_scoring=false`، unit of analysis و منع استفادهٔ ثانویهٔ تنبیهی داشته باشد. برای سیستم رهبری، از راهنمای رهبری تیم QA کمک بگیرید.
Evidence کیفی، دادهٔ شخصی و دسترسی
مصاحبه، صدا، ویدئو، Quote و Observation میتوانند هویت، سلامت، شغل یا رفتار حساس را افشا کنند. Purpose limitation، Consent، Minimization، Pseudonymization، access-by-role، Retention/Deletion و ممنوعیت انتشار Quote قابلشناسایی را پیش از جمعآوری تعیین کنید. «داخلی بودن» مجوز استفادهٔ نامحدود نیست.
Observation، Finding، Claim و Action را جدا نگه دارید
OBS-SYN-07: Actor پس از پیام timeout گفت «پس پول کم نشده». ORACLE-SYN-07: fake ledger یک debit-pending ساختگی نشان میدهد. FINDING-SYN-03: پیام، pending state را برای این Actor/Scenario منتقل نکرد. CLAIM-SYN-v1: در Sample/Context مقید، Evidence وضوح کافی نیست. ACTION-SYN-04: Message/Timeline candidate را Adapt و دوباره بررسی کن. NOT CLAIMED: شیوع در کل کاربران، اعتماد کلی، Cause یا اثر مالی.
Evidence Pack قابل ممیزی
- Goal Contract و Revision دقیق؛
- Question/Evidence map و روش انتخابشده؛
- Sample/Recruitment/Slice و Exclusion؛
- Instrument، Discussion guide یا Task/Scenario نسخهدار؛
- Consent/Privacy/Retention reference؛
- Raw Evidence امن با شناسه و Provenance؛
- Rubric/Codebook و Calibration log؛
- Observation، Coding، Finding و Counterevidence؛
- Measure Contract و Data quality برای Evidence کمی؛
- Claim، Limitations، Unknown و Decision record؛
- Correction/Supersession و Follow-up.
Review Cadence را از Horizon و Decision بگیرید
نسخهٔ قبلی مقاله Weekly/Monthly/Quarterly را یک نسخهٔ عمومی میدانست. Cadence باید از سرعت تغییر Construct/Context، هزینهٔ Evidence، زمان اثر Strategy و موعد Decision بیاید. Event-driven triggerهایی مثل تغییر Journey، Population، Instrument، Rubric، Policy یا Data source ممکن است مهمتر از تقویم باشند.
وضعیتهای چرخهٔ Quality Goal
DRAFT → REVIEWED → SHADOW → ACTIVE ACTIVE → CONTINUE | ADAPT | ACHIEVED_IN_SCOPE | INCONCLUSIVE ACTIVE/SHADOW → STOPPED | RETIRED هر وضعیت → SUPERSEDED یا CORRECTED با حفظ تاریخچه
Achieved باید دامنه و تاریخ انقضا داشته باشد
`ACHIEVED_IN_SCOPE` یعنی Predicate ازپیشتعریفشده برای Population/Sample، Context، Version و Window مشخص با Evidence موجود برقرار بوده است. این برچسب تضمین کیفیت آینده، همهٔ کاربران، علت Strategy یا نبود Harm نیست. Expiry و Revalidation trigger تعیین کنید.
Stop شکست نیست
ممکن است Goal نامرتبط، Construct غیرقابلاستفاده، هزینهٔ Evidence نامتناسب یا Harm بیشتر از Benefit باشد. Stop یا Redefine کردن هدف، اگر با دلیل ثبت شود، یادگیری است. ادامهدادن صرفاً چون فصل آغاز شده یا Dashboard ساخته شده، Sunk-cost behavior است.
تغییر Goal نیاز به Revision دارد
تغییر Construct، Population، Context، Rubric، Success predicate یا Horizon، Revision جدید میخواهد. اگر مقایسهٔ قبل/بعد لازم است، Bridge study یا Dual coding تعریف کنید. تاریخچه را برای زیباترکردن روند بازنویسی نکنید.
Correction بدون پاککردن تصمیم گذشته
correction_id / discovered_at / owner affected_goal_revision / evidence_ids / claims / decisions issue: bad coding | wrong population | stale source | privacy breach | other impact / corrected_result / supersedes notification / remediation / revalidation / closure
نقشها و Authority
| نقش | مسئولیت | نباید خودکار فرض شود |
|---|---|---|
| Goal Owner | Purpose، Context، Review و Follow-up | Release Authority |
| Construct/Rubric Steward | تعریف، Anchor، Calibration و Revision | مالک حقیقت محصول |
| Evidence Steward | روش، Provenance، کیفیت و دسترسی | تصمیمگیر نهایی |
| Research/Data roles | جمعآوری و تحلیل متناسب با تخصص | تأیید Strategy |
| Decision Authority | انتخاب Continue/Adapt/Stop و پذیرش Unknown | تغییر خاموش Evidence |
| Privacy/Security | کنترل داده و Risk | داوری تجربه بهتنهایی |
از Goal Review تا Improvement Experiment
Goal Review میگوید Evidence فعلی دربارهٔ Desired State چه میگوید. اگر میخواهید اثر Strategy را بسنجید، یک Experiment جدا با Hypothesis، Assignment/Comparison، Guardrail و Decision طراحی کنید. راهنمای Sprint Retrospective از Action Item تا Experiment مرز این کار را پوشش میدهد.
Goal Review اثربخشی QA را ثابت نمیکند
بهبود یک Outcome پس از فعالیت QA ممکن است با تغییر محصول، Mix کاربر، فصل، پشتیبانی یا عامل دیگری همراه باشد. برای Theory، Attribution و Contribution از ارزیابی اثربخشی QA استفاده کنید. هدف محققشده را به عملکرد فرد یا تیم نسبت ندهید مگر طرح ارزیابی متناسب داشته باشید.
آزمایش اجرایی: شعار + دو Proxy
Fixture زیر کاملاً ساختگی و آفلاین است. Checker سطحی وجود یک Statement و دو Proxy را میبیند و `GOAL_ACHIEVED` اعلام میکند. ممیزی Contract دقیقاً ۵۹ Rule دارد؛ ۵۸ جزء اصلی غایباند و Rule آخر People scoring را منع میکند. چون مقدار آن false است، نسخهٔ خام دقیقاً ۵۸ Finding میگیرد. تعداد Ruleها Benchmark یا سطح بلوغ نیست.
const draft = {
statement: "اعتماد به کیفیت Checkout را افزایش میدهیم",
proxy_kpis: ["رضایت 4.5/5", "تیکت -20%"],
declared_status: "GOAL_ACHIEVED",
people_scoring: false
};
const present = (v) =>
v !== undefined && v !== null &&
!(typeof v === "string" && v.trim() === "") &&
!(Array.isArray(v) && v.length === 0);
const rules = [
["QG-01 goal_id", x => present(x.goal_id)],
["QG-02 revision", x => present(x.revision)],
["QG-03 supersedes", x => present(x.supersedes)],
["QG-04 as_of", x => present(x.as_of)],
["QG-05 purpose_ref", x => present(x.purpose_ref)],
["QG-06 decision_ref", x => present(x.decision_ref)],
["QG-07 decision_authority", x => present(x.decision_authority)],
["QG-08 decision_due", x => present(x.decision_due)],
["QG-09 construct", x => present(x.construct)],
["QG-10 construct_definition", x => present(x.construct_definition)],
["QG-11 non_examples", x => present(x.non_examples)],
["QG-12 adjacent_constructs", x => present(x.adjacent_constructs)],
["QG-13 actor", x => present(x.actor)],
["QG-14 object", x => present(x.object)],
["QG-15 context", x => present(x.context)],
["QG-16 population", x => present(x.population)],
["QG-17 exclusions", x => present(x.exclusions)],
["QG-18 current_state_ref", x => present(x.current_state_ref)],
["QG-19 desired_state", x => present(x.desired_state)],
["QG-20 horizon", x => present(x.horizon)],
["QG-21 questions", x => present(x.questions)],
["QG-22 observables", x => present(x.observables)],
["QG-23 rubric_ref", x => present(x.rubric_ref)],
["QG-24 rubric_anchors", x => present(x.rubric_anchors)],
["QG-25 rubric_unknown", x => present(x.rubric_unknown)],
["QG-26 calibration", x => present(x.calibration)],
["QG-27 evidence_plan_ref", x => present(x.evidence_plan_ref)],
["QG-28 evidence_types", x => present(x.evidence_types)],
["QG-29 sample_plan", x => present(x.sample_plan)],
["QG-30 slices", x => present(x.slices)],
["QG-31 provenance", x => present(x.provenance)],
["QG-32 data_quality", x => present(x.data_quality)],
["QG-33 observation_finding_split", x => x.observation_finding_split === true],
["QG-34 counterevidence", x => present(x.counterevidence)],
["QG-35 contradiction_policy", x => present(x.contradiction_policy)],
["QG-36 triangulation", x => present(x.triangulation)],
["QG-37 baseline_ref", x => present(x.baseline_ref)],
["QG-38 success_criteria", x => present(x.success_criteria)],
["QG-39 stop_criteria", x => present(x.stop_criteria)],
["QG-40 guardrails", x => present(x.guardrails)],
["QG-41 unknown_policy", x => present(x.unknown_policy)],
["QG-42 strategy_ref", x => present(x.strategy_ref)],
["QG-43 hypothesis_ref", x => present(x.hypothesis_ref)],
["QG-44 not_claimed", x => present(x.not_claimed)],
["QG-45 goal_owner", x => present(x.goal_owner)],
["QG-46 rubric_steward", x => present(x.rubric_steward)],
["QG-47 evidence_steward", x => present(x.evidence_steward)],
["QG-48 action_owner", x => present(x.action_owner)],
["QG-49 privacy_access", x => present(x.privacy_access)],
["QG-50 retention", x => present(x.retention)],
["QG-51 review_cadence", x => present(x.review_cadence)],
["QG-52 invalidation_triggers", x => present(x.invalidation_triggers)],
["QG-53 status_model", x => present(x.status_model)],
["QG-54 expiry", x => present(x.expiry)],
["QG-55 change_policy", x => present(x.change_policy)],
["QG-56 correction_policy", x => present(x.correction_policy)],
["QG-57 evidence_pack", x => present(x.evidence_pack)],
["QG-58 review_outputs", x => present(x.review_outputs)],
["QG-59 people_scoring_prohibited", x => x.people_scoring !== true]
];
const findings = (x) => rules.filter(([, ok]) => !ok(x)).map(([id]) => id);
console.log("SUPERFICIAL", draft.proxy_kpis.length, draft.declared_status);
console.log("CONTRACT", findings(draft).length ? "HOLD" : "READY", findings(draft).length);
const corrected = {
goal_id: "SYN-QG-042", revision: "v1", supersedes: "none:first-revision",
as_of: "2026-08-13T09:00:00Z", purpose_ref: "PURPOSE-SYN-042",
decision_ref: "DEC-SYN-042", decision_authority: "ROLE-PRODUCT-DECISION",
decision_due: "2026-09-15T09:00:00Z", construct: "payment_state_clarity",
construct_definition: "actor explains state, next action and reference without contradiction",
non_examples: ["visual appeal", "payment success", "general satisfaction"],
adjacent_constructs: ["trust", "usability", "accuracy"], actor: "SYN-ACTOR-SEGMENT-A",
object: "fake checkout failure-state journey", context: "fa-IR mobile; synthetic timeout states",
population: "fictional segment in bounded lab", exclusions: ["real users", "production", "other journeys"],
current_state_ref: "BASE-SYN-QG-042-v1", desired_state: "rubric predicate SYN-SUCCESS-v1",
horizon: "bounded 30-day shadow", questions: ["state understood?", "next action understood?", "harm?"],
observables: ["actor explanation", "help request", "oracle match"], rubric_ref: "RUBRIC-SYN-042-v1",
rubric_anchors: ["0 contradiction", "1 guessing", "2 partial", "3 clear-in-scope"],
rubric_unknown: "U and NA remain distinct", calibration: "dual-code seed pack; preserve disagreement",
evidence_plan_ref: "EPLAN-SYN-042-v1", evidence_types: ["task observation", "open response", "fake event"],
sample_plan: "purposeful fictional sample with explicit limits", slices: ["timeout-before", "timeout-after"],
provenance: "immutable synthetic evidence IDs", data_quality: "completeness/freshness/oracle checks",
observation_finding_split: true, counterevidence: "search negative cases and contradictory explanations",
contradiction_policy: "retain conflict; investigate source/context; allow inconclusive",
triangulation: "same questions across observation, response and oracle", baseline_ref: "BASE-SYN-QG-042-v1",
success_criteria: "versioned multi-part predicate by slice", stop_criteria: "harm or unusable construct",
guardrails: ["accessibility", "privacy", "task time"], unknown_policy: "unknown cannot pass or become green",
strategy_ref: "STRAT-SYN-MESSAGE-v1", hypothesis_ref: "HYP-SYN-MESSAGE-v1",
not_claimed: ["population prevalence", "causality", "trust", "production quality", "financial impact"],
goal_owner: "ROLE-GOAL-OWNER", rubric_steward: "ROLE-RUBRIC-STEWARD",
evidence_steward: "ROLE-EVIDENCE-STEWARD", action_owner: "ROLE-ACTION-OWNER",
privacy_access: "synthetic only; least privilege; no identity", retention: "delete synthetic pack after expiry",
review_cadence: "event-driven plus end-of-shadow", invalidation_triggers: ["context", "rubric", "sample", "source"],
status_model: ["DRAFT", "SHADOW", "ACTIVE", "ADAPT", "ACHIEVED_IN_SCOPE", "INCONCLUSIVE", "STOPPED"],
expiry: "2026-10-01T09:00:00Z", change_policy: "new revision plus bridge when comparable",
correction_policy: "supersede; notify affected claims/decisions; no silent edit",
evidence_pack: "contract+sample+rubric+raw IDs+coding+findings+claim+decision",
review_outputs: ["CONTINUE", "ADAPT", "STOP", "ACHIEVED_IN_SCOPE", "INCONCLUSIVE"],
people_scoring: false
};
const correctedFindings = findings(corrected);
console.log("CORRECTED", correctedFindings.length ? "HOLD" : "READY_FOR_QUALITY_GOAL_REVIEW", correctedFindings.length);خروجی مستقل Fixture و مرز تفسیر
SUPERFICIAL 2 GOAL_ACHIEVED CONTRACT HOLD 58 CORRECTED READY_FOR_QUALITY_GOAL_REVIEW 0
نسخهٔ خام فقط Statement و دو Proxy دارد؛ Rule منع People scoring تنها Rule پاسشده است. نسخهٔ اصلاحشده صفر Finding ساختاری دارد، اما صدق Evidence، اعتبار Construct/Rubric، کفایت Sample، تحقق Desired State، نبود Harm، اثر Strategy، کیفیت محصول یا درستی Decision را ثابت نمیکند. خروجی عمداً Review است، نه Achieved/Approved.
آزمایشگاه آفلاین فارسی: وضوح وضعیت پرداخت
برای تمرین، یک Checkout کاملاً ساختگی و قطع از شبکه بسازید: fake Order، PaymentAttempt، PSP Stub، Callback، Ledger، Reconciliation و Notification. Stateها شامل timeout پیش/پس از fake commit، retry، duplicate، late و reordered event باشند. Oracle مستقل Fake Ledger است؛ موفقشدن UI یا پاسخ Stub بهتنهایی حقیقت نیست.
| Contract | مقدار ساختگی | Evidence |
|---|---|---|
| Construct | وضوح State پرداخت، نه اعتماد کلی | Rubric 0–3/U/NA |
| Actor/Context | Segment خیالی، fa-IR، Mobile، timeout | Sample manifest |
| Observable | توضیح State/اقدام/مرجع بدون تناقض | Observation ID + پاسخ آزاد |
| Technical truth | State در fake Ledger | Oracle snapshot |
| Guardrail | دسترسپذیری، Privacy، زمان Task | Evidence مستقل |
| Decision | Continue/Adapt/Stop/Inconclusive | Decision record محدود |
مرزهای ایمنی آزمایشگاه ایران
Tenant/Order/Attempt/Event/Ledger/Run/Build/Sample/Evidence/Goal/Decision شناسههای ساختگی و جدا دارند. مبلغ فقط IRR خیالی و نمایش تومان با برچسب «نمایشی» است؛ هیچ نرخ بازار یا توصیهٔ مالی وجود ندارد. ارقام فارسی/عربی/لاتین، ی/ی، ک/ک، ZWNJ، RTL/Bidi، UTC instant، نمایش Asia/Tehran و تاریخ جلالی صرفاً نمایشی آزموده میشوند.
آزمایش هیچ اتصال شبکه، Production، سازمان/کاربر/سفارش/پرداخت/PSP/بانک واقعی، پول واقعی، PII، نام، موبایل، ایمیل، IP، حساب، PAN، CVV2، OTP، Cookie، Token، Credential، Log یا Screenshot واقعی ندارد و توصیهٔ بانکی، مالی، حقوقی، مالیاتی، امنیتی یا حریم خصوصی نیست.
Pilot سیروزهٔ Evidence Protocol
- روز ۱ تا ۵: Purpose/Decision/Construct/Context و Baseline Unknownها را ثبت کنید.
- روز ۶ تا ۱۰: Question map، Observable، Rubric و Counterevidence plan بسازید.
- روز ۱۱ تا ۱۵: Seed evidence را دوکدگذاری و Anchor/Privacy/Sample را اصلاح کنید.
- روز ۱۶ تا ۲۳: Evidence را در Shadow جمع کنید؛ هیچ Reward یا Gate خودکار نسازید.
- روز ۲۴ تا ۲۷: Observation→Finding→Claim را با اختلافها و Unknownها تحلیل کنید.
- روز ۲۸ تا ۳۰: Review محدود انجام دهید و Continue/Adapt/Stop/Inconclusive را ثبت کنید.
ضدالگوهای تعیین و پیگیری اهداف کیفی
- افزودن درصد به واژهٔ تعریفنشده؛
- یکیدانستن Quality Goal با دادهٔ Qualitative؛
- شروع از KPIهای موجود بهجای سؤال؛
- تبدیل Strategy یا Output به Goal؛
- استفاده از رضایت کلی برای Construct خاص؛
- استفاده از یک Quote بهعنوان شیوع؛
- استفاده از میانگین برای پنهانکردن Slice آسیبدیده؛
- Rubric بدون Anchor، U و NA؛
- تغییر Rubric پس از دیدن نتیجه؛
- حل اختلاف Reviewer با حذف تاریخچه؛
- Sample راحت و ادعای کل Population؛
- تعریف Baseline صفر هنگام نبود داده؛
- Triangulation با Datasetهای نامرتبط؛
- میانگینگرفتن از Evidence متعارض؛
- نبود Counterevidence و Stop criterion؛
- کاهش تیکت بدون بررسی سختترشدن Support؛
- Cadence ثابت هفتگی/فصلی برای هر Goal؛
- اعلام Achieved بدون Scope/Expiry؛
- نسبتدادن Outcome به QA بدون طرح Contribution؛
- امتیازدهی افراد و استفادهٔ تنبیهی از Evidence؛
- نگهداری نامحدود صدا/ویدئو/Quote؛
- ویرایش خاموش Goal، Evidence یا Decision گذشته.
چکلیست Owner پیش از شروع Tracking
- Purpose و Decision/Authority/موعد روشن است؟
- Construct تعریف و Non-example دارد؟
- Actor/Object/Context/Population/Exclusion بسته شدهاند؟
- Current و Desired State و Horizon جدا هستند؟
- Goal از Strategy/Activity/Output مستقل است؟
- Questionها پیش از Measure نوشته شدهاند؟
- Observable از Finding و Claim جداست؟
- Rubric Anchor/U/NA/Revision و Calibration دارد؟
- Evidence کیفی و کمی به یک Question وصلاند؟
- Sample/Slice/Nonresponse/Limitations ثبت شدهاند؟
- Baseline با روش قابلمقایسه وجود دارد یا Unknown است؟
- Success/Stop/Guardrail/Counterevidence از پیش ثبت شدهاند؟
- تعارض Evidence میتواند Inconclusive بماند؟
- Data quality/Provenance/Privacy/Access/Retention مشخص است؟
- Goal/Rubric/Evidence/Action Owner و Authority جدا هستند؟
- `people_scoring=false` و استفادهٔ ثانویه محدود است؟
- Review cadence و Invalidation trigger متناسباند؟
- Achieved دامنه، Version، Window و Expiry دارد؟
- Change/Bridge/Correction/Supersession تعریف شدهاند؟
- Not claimed صریح است و هیچ تضمین یا Cause بیمدرکی نداریم؟
پرسشهای متداول درباره هدف کیفی در QA
تفاوت هدف کیفی و هدف کمی چیست؟
این دو همیشه متضاد نیستند. هدف کیفیت یک وضعیت مطلوب دربارهٔ Construct مشخص است و میتواند Evidence توصیفی و عددی داشته باشد. «کمی» بودن Measure، اعتبار هدف یا نمایندگی Construct را خودکار ثابت نمیکند؛ «کیفی» بودن داده نیز به معنای غیرقابلبررسی بودن نیست.
چگونه یک هدف کیفی را اندازهگیری کنیم؟
ابتدا Construct، Actor/Object/Context و تصمیم را تعریف کنید؛ سپس Question، Observable، Rubric و Evidence plan بسازید. Observation، پاسخ آزاد، Oracle فنی و Measureهای پشتیبان را با Sample/Slice مشخص ترکیب و Claim را به همان Scope محدود کنید. هدف را فقط به یک Proxy عددی تبدیل نکنید.
آیا SMART برای اهداف کیفی کافی است؟
خیر. SMART میتواند ابهام زمان، ارتباط یا قابلیت پیگیری را یادآوری کند، اما Construct validity، Sampling، Rubric، Data quality، Counterevidence، Privacy یا ادعای محدود را طراحی نمیکند. آن را در صورت نیاز کنار Evidence Protocol استفاده کنید.
آیا میتوان رضایت یا تعداد تیکت را KPI هدف کیفیت دانست؟
فقط با قرارداد مشخص و پس از بررسی نمایندگی آنها برای Question هدف. رضایت کلی ممکن است Constructهای زیادی را مخلوط کند و کاهش تیکت میتواند از دشوارشدن تماس باشد. Population، Window، Data quality، Guardrail و شواهد مکمل لازماند؛ Proxy را خود هدف یا Cause ننامید.
هر چند وقت یکبار هدف کیفی را بازبینی کنیم؟
تناوب جهانی هفتگی، ماهانه یا فصلی وجود ندارد. Cadence را از Horizon هدف، سرعت اثر Strategy، هزینهٔ Evidence، سرعت تغییر Context و موعد Decision بگیرید. تغییر Construct، Journey، Population، Rubric یا Data source باید Review رویدادمحور ایجاد کند.
جمعبندی: معنا را حفظ کنید و ادعا را محدود نگه دارید
هدف کیفی نه جملهای زیباست و نه عددی که به آن چسباندهایم. آن را به Construct، Actor/Object/Context، Current/Desired State، Question، Observable، Rubric، Evidence، Sample/Slice، Guardrail و Review متصل کنید. Observation را از Finding و Claim، Goal را از Strategy و Evidence را از Decision جدا نگه دارید.
کیفیت را به یک Proxy تقلیل ندهید و از معنا هم بهدلیل دشواری سنجش فرار نکنید. Evidence متعارض میتواند Inconclusive بماند؛ Stop یک خروجی معتبر است؛ Achieved فقط در Scope و تا Expiry معنا دارد. یک Quality Goal بالغ، وعدهٔ موفقیت پایدار نمیدهد—قراردادی میسازد که تیم بتواند با شواهد محدود، اختلافها و Unknownهای آشکار، تصمیمی قابلاصلاح بگیرد.
