وقتی تیم میگوید «۷۵٪ تستها تمام شده و وضعیت سبز است»، گیرنده معمولاً یک سؤال مهمتر دارد: دقیقاً کدام کار، روی کدام Build، با چه شاهدی، تا چه زمانِ برشی و با چه مانعی؟ اگر پاسخ در خود پیام نباشد، درصد نه پیشرفت را اثبات میکند و نه مبنای امنی برای تصمیم است. اطلاعرسانی پیشرفت تست باید یک بستهٔ نسخهدار، قابلپیگیری و قابلاقدام باشد؛ نه انبوهی از شمارندهها و نه خوشبینی شفاهی.
این راهنما مالک «پروتکل بهروزرسانی زندهٔ پیشرفت و موانع تست» است: از تعریف جمعیت و وضعیت تا Facts-as-of، Evidence، انحراف، Forecast، بستهٔ مانع، درخواست تصمیم، تأیید دریافت و تصحیح. هدف آن گزارشسازی زیبا نیست؛ هدف این است که یک مخاطب مجاز بتواند بدون حدس بفهمد چه چیزی معلوم است، چه چیزی هنوز معلوم نیست و چه اقدام یا تصمیمی تا چه موعدی لازم است.
پاسخ کوتاه: یک Update قابلاقدام چه دارد؟
- هویت: شناسه Update، موضوع، دامنه، برنامه/موج، Build، محیط، مالک و نسخه؛
- زمان: زمان برش واقعیتها، زمان انتشار، Freshness SLA و منطقهٔ زمانی؛
- Claim پیشرفت: جمعیت واجد شرایط، حالتها، صورت و مخرج، Evidence Profile و Unknownها؛
- Delta: تفاوت واقعیت با Baseline/Plan و تغییرات دامنه یا ریسک؛
- Blocker Packet: مشاهده، کار مسدود، وابستگی، اثر، مالک پاسخ، موعد بررسی، Escalation و گزینهٔ جایگزین؛
- Forecast: بازه، فرضها، وابستگیها و منطق Confidence؛
- Action: سؤال تصمیم، گزینهها، مرجع تصمیم، Deadline و کانال ثبت؛
- Closure: دریافت/پذیرش، Update بعدی، پیوند شواهد و سازوکار Correction.
یک پیام خوب میتواند کوتاه باشد، اما نباید مبهم باشد. جزئیات حجیم در Registry و Evidence Store میماند و پیام با شناسههای پایدار به آنها اشاره میکند.
مرز مالکیت: این مقاله چه چیزی نیست؟
| Artifact | پرسش اصلی | مرز با این مقاله |
|---|---|---|
| Test Plan | چه چیزی، چرا و چگونه برنامهریزی شده است؟ | Baseline را میدهد؛ Update واقعیت و Delta را نسبت به آن گزارش میکند. |
| Test Status Report | تصویر مدیریتی وضعیت و ریسک چیست؟ | میتواند چند Update را Roll-up و برای تصمیم ارائه کند؛ پروتکل اتمی پیام اینجاست. |
| Test Summary | در زمان برش پایان/Closure چه انجام شد؟ | Snapshot منجمد است؛ Update زنده و قابلتصحیح است. |
| Defect Report | رفتار نامطلوب محصول چیست و چگونه بازتولید میشود؟ | Blocker ممکن است Defect باشد، اما هر Defect مانع نیست و هر مانع Defect نیست. |
| Decision Record | چه مرجعی با چه دلایلی چه تصمیمی گرفت؟ | Update درخواست و شواهد را حمل میکند؛ خودش تصمیم یا Risk Acceptance نیست. |
| Dashboard | یک View از دادهها چیست؟ | Dashboard منبع حقیقت یا اثبات خودکار Freshness نیست. |
برای معماری کامل گزارش وضعیت به راهنمای گزارش تست و تصمیم انتشار، برای Baseline به برنامه تست زنده و برای Snapshot نهایی به گزارش خلاصه تست مراجعه کنید.
واژهنامهٔ عملیاتی پیش از ارسال اولین پیام
| واژه | تعریف قراردادی | اشتباه رایج |
|---|---|---|
| Fact | رکورد قابل ارجاع از منبع و زمان مشخص | برداشت شخصی بدون Source |
| Claim | گزارهای که از Factها با Rule اعلامشده ساخته شده | رنگ یا درصد بدون مخرج |
| Progress | تغییر قابلسنجش نسبت به Baseline و Goal نامدار | Activity یا مشغولبودن |
| Blocker | شرطی که کار/شاهد نامدار را متوقف یا ناممکن کرده | هر ناراحتی یا هر Bug |
| Impediment | مانع پیشرفت تیم در واژگان Context قراردادی | نقش یا فرایند واحد در همهٔ روشها |
| Risk | عدمقطعیتی با اثر احتمالی | واقعهٔ رخداده |
| Issue | مسئلهٔ رخداده که نیازمند رسیدگی است | علت اثباتشده |
| Forecast | برآورد شرطی آینده با بازه و فرض | وعدهٔ قطعی |
| Unknown | دانستهٔ ناقص و اثر آن بر Claim | صفر، Fail یا حذف |
چرا پیامهای معمولی تصمیم را خراب میکنند؟
- «۴۰ تست اجرا شد» نمیگوید جمعیت چیست، تکرارها حذف شدهاند یا نه و کدام ریسکها لمس شدهاند.
- «Environment مشکل دارد» Subject، زمان، مشاهده، وابستگی و اثر را پنهان میکند.
- «تا فردا تمام میشود» فرض رفع مانع، ظرفیت و بازهٔ خطا را حذف میکند.
- «QA قرمز اعلام کرد» مشاهده را با ارزیابی، توصیه، Risk Acceptance و Release Decision یکی میکند.
- Dashboard زندهای که Snapshot/Refresh time ندارد، میتواند یک View کهنه با ظاهر تازه باشد.
- پیام فوری بدون Record ممکن است اقدام بسازد اما بعداً منشأ تصمیم و تصحیح قابلبازیابی نباشد.
مدل جریان: Fact تا اقدام و یادگیری
Source snapshot -> normalized Fact -> bounded Progress / Blocker / Forecast Claim -> audience-specific View -> acknowledgement -> decision or action record -> next observation -> correction / closure / learning
این زنجیره عمداً دوطرفه است. گیرنده فقط مصرفکننده نیست: ممکن است معنای Claim را سؤال کند، اقدام را بپذیرد، فرض را رد کند یا دادهٔ تازهای برگرداند. یک Update بدون Acknowledgement و Next Check، اعلان است نه حلقهٔ کنترل.
قرارداد هویت Update
UpdateContract {
update_id, revision, supersedes_update_id,
purpose, audience, requested_decision,
subject_id, plan_baseline_id, wave_or_run_id,
build_id, environment_id, data_snapshot_id,
facts_as_of, emitted_at, timezone,
source_snapshot_ids[], owner, reviewers[],
freshness_sla, next_update_at, correction_policy
}
عنوانهایی مثل «گزارش امروز» شناسه نیستند. Update باید حتی پس از تغییر نام Sprint، جابهجایی کارت یا کپی پیام در کانال دیگر، قابل تشخیص بماند. Build ID هم باید به Artifact واقعی اشاره کند؛ نام مبهم «آخرین نسخه» در زمان بازخوانی معنای ثابتی ندارد.
Facts-as-of با Emitted-at یکی نیست
| زمان | معنا | کنترل |
|---|---|---|
| Observed at | واقعه یا مشاهده چه زمانی رخ داد؟ | Clock/Timezone منبع |
| Ingested at | سامانه چه زمانی داده را دریافت کرد؟ | Lag و Duplicate |
| Facts as of | آخرین نقطهای که مجموعهٔ Factها تا آن کامل فرض شده | Watermark قراردادی |
| Computed at | Claim چه زمانی محاسبه شد؟ | Rule/Code/Query version |
| Emitted at | پیام چه زمانی منتشر شد؟ | Delivery log |
| Acknowledged at | گیرندهٔ مسئول چه زمانی دریافت را ثبت کرد؟ | Receipt |
| Next check | بازبینی بعدی چه زمانی است؟ | Scheduler/Escalation |
ممکن است پیام ساعت ۱۴ منتشر شود اما دادهها تا ساعت ۱۰ کامل باشند. نوشتن فقط «بهروز» این چهار ساعت تأخیر را پنهان میکند. برای قواعد جامع تازگی و Drift، مستندات تست زنده و Freshness Contract را ببینید.
Progress Claim را پیش از درصد تعریف کنید
ProgressClaim {
claim_id, goal_id, eligible_population_snapshot,
unit_of_count, state_vocabulary_version,
numerator_rule, denominator_rule,
evidence_profile, build_id, cutoff,
result, unknown_count, exclusions[], limitations[]
}
«درصد اجرا» میتواند درصد Test Case، Risk item، Requirement، Configuration cell، Session، Pipeline یا Evidence obligation باشد. اینها قابلجایگزینی نیستند. اگر واحد شمارش و Snapshot جمعیت تغییر کند، Trend باید Break marker داشته باشد؛ چسباندن دو سری ناسازگار، پیشرفت مصنوعی میسازد.
مخرج و جمعیت: منشأ بیشتر سبزهای کاذب
| سؤال | نمونهٔ پاسخ قابل ممیزی | پاسخ ناکافی |
|---|---|---|
| جمعیت چیست؟ | Registry C1..C86 در Snapshot REG-۱۷ | همهٔ تستها |
| چه چیزی واجد شرایط است؟ | Scope=IN و Build-compatible در Cutoff | موارد فعال |
| چه چیزی حذف شده؟ | ۱۲ مورد OUT با Exception ID | موارد غیرضروری |
| تکرار چگونه حذف شده؟ | Unique by subject_id + build_id | از Dashboard |
| مخرج ثابت است؟ | Baseline ۸۶؛ Delta +۴ جدا نمایش داده میشود | تقریباً |
| Unknown چه میشود؟ | ۷ مورد جدا؛ نه Pass و نه صفر | فعلاً حساب نشده |
واژگان حالت را نسخهدار کنید
| State | معنای نمونه | Evidence لازم |
|---|---|---|
| NOT_STARTED | کار واجد شرایط است اما Attempt ندارد | Registry membership |
| IN_PROGRESS | Attempt معتبر آغاز شده ولی Outcome نهایی ندارد | Attempt ID و Actor/time |
| PASS | Oracle اعلامشده برای Build/Environment برآورده شده | Result + Evidence Profile |
| FAIL | Oracle اعلامشده برآورده نشده | Observed/Expected/Evidence |
| BLOCKED | Attempt یا Evidence obligation به مانع نامدار متوقف است | Blocker ID |
| INCONCLUSIVE | شاهد برای نتیجهٔ معتبر کافی نیست | Reason/Unknown |
| NOT_APPLICABLE | طبق Rule و Authority خارج است | Disposition ID |
| STALE | نتیجه دیگر Freshness/Build contract را برآورده نمیکند | Invalidation reason |
Blocked را Pass یا Fail نکنید؛ این وضعیت دربارهٔ امکان تولید شاهد معتبر است، نه رفتار محصول. همچنین «Done» باید یک Projection روشن از Stateها باشد، نه واژهای که هر تیم متفاوت تفسیر میکند.
Evidence-backed progress چیست؟
| سطح ادعا | حداقل پیوند | آنچه اثبات نمیکند |
|---|---|---|
| Activity started | Work/Attempt ID | پیشرفت به سمت Goal |
| Executed | Attempt + Build + Environment | نتیجهٔ معتبر |
| Outcome recorded | Result + Oracle version | کفایت پوشش |
| Evidence accepted | Evidence Profile + Reviewer/Rule | کیفیت کل محصول |
| Obligation complete | Subject + accepted Evidence + Freshness | Release readiness |
شمارش ردیفهای Done در ابزار، اگر Evidence به Build دیگری تعلق داشته باشد یا Result منقضی شده باشد، پیشرفت قابل اتکا نمیسازد. مدیریت Attempt و Outcome در راهنمای چرخه اجرای تست با جزئیات آمده است.
Build، Environment و Data را در Claim قفل کنید
EvidenceRef {
evidence_id, subject_id, attempt_id,
build_digest, environment_snapshot,
data_snapshot, oracle_version,
observed_at, artifact_uri, integrity_hash,
retention_class, access_class
}
اگر هدف B17 است، موفقیت B16 فقط وقتی قابل استفاده است که یک Compatibility/Reuse rule از پیش پذیرفتهشده وجود داشته باشد. «هیچ کدی در آن بخش عوض نشده» باید به Change-impact evidence ارجاع دهد؛ یک فرض شفاهی نیست.
پیشرفت را با ریسک و تعهد شواهد بخوانید
دو موج هر دو ممکن است ۶۰٪ Done باشند، اما در یکی شواهد ریسکهای بحرانی کامل و در دیگری فقط مسیرهای کماثر اجرا شدهاند. کنار شمارندهٔ Activity، وضعیت Evidence obligationهای ریسک، Gapهای ممنوع، Unknown و سن شواهد را نشان دهید. عدد وزندار نیز حقیقت مطلق نیست: وزن، مدل و Authority آن باید نسخهدار و Countermetric داشته باشد. برای روش تحلیل ریسک، راهنمای تست مبتنی بر ریسک مرجع خوشه است.
| View | Claim مجاز | Countermetric |
|---|---|---|
| Activity | Attemptهای یکتا/جمعیت | Re-run و Duplicate rate |
| Outcome | Stateها با Unknown | Stale/foreign-build |
| Risk evidence | تعهدهای پذیرفتهشده بر حسب Risk tier | Gap بحرانی و Inconclusive |
| Flow | Age/WIP/Throughput در Window | Scope churn و blocked time |
| Forecast | بازهٔ شرطی | Calibration و فرضهای شکسته |
Delta نسبت به Plan، نه فقط وضعیت اکنون
DeltaRecord {
baseline_id, fact_snapshot_id,
dimension: scope | schedule | risk | evidence | capacity | environment,
expected, actual, variance,
observed_cause_or_hypothesis,
impact, response, owner, review_at
}
Status میگوید اکنون کجاییم؛ Delta میگوید نسبت به چه چیزی تغییر کردهایم. افزایش مخرج پس از ورود چهار Coverage item باید جدا نمایش داده شود، وگرنه تیم با همان مقدار کار ظاهراً عقب میرود. Control Loop بین Strategy، Plan و Summary در راهنمای سهسندی تست توضیح داده شده است.
Forecast وعده نیست؛ گزارهای شرطی است
Forecast {
target_id, as_of,
earliest, most_likely_optional, latest,
unit_and_method, comparable_history_window,
assumptions[], dependencies[],
confidence_level, confidence_rationale,
invalidation_triggers[], owner, refresh_at
}
اگر دادهٔ کافی برای بازه ندارید، آن را صریحاً Unknown اعلام کنید. «جمعه تمام میشود» را به «در صورت رفع DEP-۷ تا چهارشنبه ۱۱:۰۰ و بدون Scope delta، بازهٔ فعلی پنجشنبه تا شنبه با Confidence پایین است» تبدیل کنید. Confidence بالا بدون سابقهٔ مشابه یا با وابستگی حلنشده، فقط برچسب است.
Forecast را چگونه کالیبره کنیم؟
| کنترل | پرسش | نشانهٔ هشدار |
|---|---|---|
| Backtest | چه درصدی از Outcomeها داخل بازه افتاد؟ | همیشه خوشبینانه |
| Interval width | آیا بازه با عدمقطعیت وسیعتر میشود؟ | همیشه یک روز |
| Assumption hit rate | فرضها چند بار برقرار ماندند؟ | فرضهای بدون Owner |
| Churn | Scope و اولویت چهقدر عوض شد؟ | Trend بدون Break |
| Dependency delay | زمان انتظار خارجی چقدر بود؟ | حذف blocked time |
| Correction speed | پس از شکستن فرض، Forecast چهقدر سریع اصلاح شد؟ | حفظ تاریخ قبلی برای ظاهر خوب |
Blocker، Defect، Risk و Dependency را جدا کنید
| نوع | مثال | رکورد مالک | رابطه با Blocker |
|---|---|---|---|
| Defect | دوبار ثبتشدن Callback | Defect record | فقط اگر Attempt/شاهدی را واقعاً متوقف کند |
| Risk | احتمال ناسازگاری Retry | Risk register | ممکن است هنوز رخ نداده باشد |
| Issue | Stub از ساعت ۱۰ پاسخ نمیدهد | Issue/incident record | میتواند علت یا نشانهٔ مانع باشد |
| Dependency | دریافت Seed dataset از Data owner | Dependency record | تا نقض شرط، الزاماً مانع نیست |
| Blocker | C6 بدون Dataset معتبر قابل اجرا نیست | Blocker packet | پیوند بین شرط و کار متوقفشده |
| Decision gap | Authority برای پذیرش Scope delta معلوم نیست | Decision request | ممکن است کنترل را متوقف کند |
جزئیات چرخهٔ نقص، Severity/Priority و Triage در راهنمای مدیریت نقص نرمافزار آمده است. در این مقاله Defect فقط یک Reference احتمالی در Blocker Packet است.
قرارداد کامل Blocker Packet
BlockerPacket {
blocker_id, status, detected_at, facts_as_of,
blocked_subject_ids[], blocked_evidence_profiles[],
observation, source_and_evidence,
confirmed_cause_optional, hypotheses[],
dependency_id, dependency_condition,
impact_claim, impact_evidence, unknowns[],
response_owner, decision_authority,
actions[], workaround_options[], tradeoffs[],
next_check_at, escalation_trigger,
closure_condition, closed_at, correction_refs[]
}
«مسئول مانع» میتواند مبهم باشد. بهتر است Response owner، Dependency owner، Decision authority و Test work owner جدا باشند. تیم تست مالک آشکارسازی و پیگیری شاهد است؛ الزاماً اختیار تعمیر Environment، تغییر Scope یا پذیرش ریسک را ندارد.
مشاهده، فرضیه و علت را با هم قاطی نکنید
| سطح | نمونهٔ دقیق | لحن نامعتبر |
|---|---|---|
| Observation | در Attempt A17، ۵ درخواست Stub در ۳۰ ثانیه Timeout شد | Backend خراب است |
| Correlation | Timeout با افزایش latency در Snapshot M7 همزمان بود | Monitoring ثابت کرد |
| Hypothesis | محدودیت Connection pool محتمل است؛ هنوز آزموده نشده | علت قطعاً Pool است |
| Confirmed cause | Config diff C9 و آزمایش بازتولید کنترلشده علت را پشتیبانی کرد | توسعهدهنده اشتباه کرد |
| Impact | Evidence Profile EP-REC برای C6 قابل تولید نیست | کل انتشار دو روز عقب افتاد |
اثر مانع را بدون اغراق بیان کنید
- اثر مستقیم: کدام Work/Evidence/Environment و از چه زمانی متوقف است؟
- اثر دامنهای: کدام Risk/Objective بهدلیل نبود شاهد Unknown میماند؟
- اثر زمانی: زمان انتظار ثبتشده و بازهٔ Forecast چگونه عوض شده؟
- اثر تصمیمی: کدام سؤال با دادهٔ فعلی پاسخپذیر نیست؟
- اثر احتمالی: سناریوی شرطی با فرض، نه واقعیت قطعی.
مانع یک تست بحرانی میتواند مهم باشد، اما از آن بهتنهایی «دو روز تأخیر انتشار» نتیجه نگیرید؛ مگر اینکه مسیر وابستگی، Capacity، گزینههای جایگزین و مرجع زمانبندی آن Claim را پشتیبانی کند.
Owner، Deadline و Next Check سه چیز متفاوتاند
| فیلد | پرسش | نمونه |
|---|---|---|
| Action owner | چه کسی اقدام نامدار را انجام میدهد؟ | role:environment-owner |
| Decision authority | چه کسی گزینه را تصویب/رد میکند؟ | role:test-plan-owner |
| Due at | اقدام/تصمیم تا چه زمان لازم است؟ | 2026-04-15T11:15:00Z |
| Next check | اگر هنوز بسته نشد، چه زمان دوباره مشاهده میکنیم؟ | 2026-04-15T11:00:00Z |
| Escalation trigger | چه شرطی مسیر بعدی را فعال میکند؟ | عدم پاسخ تا Due at |
| Update owner | چه کسی Claim را تازه/تصحیح میکند؟ | role:test-observer |
Escalation تنبیه نیست؛ مسیر قراردادی تصمیم است
if blocker.age > SLA and action.not_acknowledged:
notify(escalation_role)
include(blocker_id, prior_receipts, impact_delta, options)
if forecast.invalidation_trigger == true:
supersede(update_id)
emit(corrected_forecast)
if sensitive_data_detected == true:
stop_broadcast()
restrict_access()
open(sanitization_record)
Escalation باید از قبل Threshold، گیرنده، حداقل اطلاعات و مسیر برگشت داشته باشد. CC کردن مدیران بدون Deadline و گزینه، فقط نویز و فشار میسازد. نقشها و حق تصمیم باید بر اساس قابلیت و Context تعیین شوند؛ راهنمای رهبری تضمین کیفیت و مالکیت همگانی این مرز را باز میکند.
درخواست تصمیم را از گزارش جدا و پیونددار کنید
DecisionRequest {
request_id, related_update_id, question,
options[], option_tradeoffs[],
evidence_refs[], unknowns[],
recommendation_optional, recommender,
authority, due_at,
default_if_no_response,
decision_record_uri
}
گفتن «لطفاً راهنمایی کنید» کار بعدی را تعریف نمیکند. سؤال باید پاسخپذیر باشد: «آیا C6 تا رفع DEP-۷ از Wave جاری خارج شود؟ گزینه A: حفظ Scope و جابهجایی Forecast؛ گزینه B: خروج موقت با Exception E4؛ تصمیمگیر: Plan owner؛ موعد: ۱۱:۱۵.» توصیهٔ تست میتواند ورودی باشد، اما امضای تصمیم نیست.
Acknowledgement با Agreement فرق دارد
| Receipt state | معنا | گام بعد |
|---|---|---|
| DELIVERED | کانال تحویل فنی را ثبت کرده | هنوز انسان ندیده است |
| ACKNOWLEDGED | گیرندهٔ مسئول دریافت و فهم موضوع را ثبت کرده | اقدام/سؤال ممکن است باز باشد |
| ACCEPTED_ACTION | مالک اقدام و موعد را پذیرفته | پیگیری تا Closure |
| CHALLENGED | Claim یا اثر نیازمند اصلاح/شاهد بیشتر است | Issue یا Correction |
| DECIDED | Authority تصمیم را ثبت کرده | Plan/Scope/Record را همگام کنید |
| CLOSED | شرط Closure با شاهد برآورده شده | Retrospective در صورت نیاز |
Cadence را از Urgency جدا کنید
| نوع ارتباط | Trigger | Cadence نمونه | نباید منتظر چه بماند؟ |
|---|---|---|---|
| Dashboard refresh | رسیدن Snapshot معتبر | خودکار/ساعتی | تصمیم فوری |
| Team sync | بازبینی Flow و برنامهٔ نزدیک | روزانه/Context-based | مانع بحرانی |
| Status roll-up | Cutoff مدیریتی | هفتگی یا Milestone | Incident یا Expired gate |
| Blocker alert | شرط Severity/Impact | Event-driven | جلسهٔ بعدی |
| Forecast correction | شکستن فرض یا تغییر Scope | Event-driven | گزارش دورهای |
| Closure update | برآوردهشدن Closure condition | Event-driven | یادآوری دستی |
در Scrum رسمی، Daily Scrum برای بازرسی پیشرفت به سمت Sprint Goal و تطبیق Sprint Backlog است؛ ساختار ثابت یا نمودار burn-down اجباری نیست. همچنین نسبتدادن خودکار همهٔ موانع تست به Scrum Master یا تبدیل Daily Scrum به Status meeting مدیریتی، از راهنمای رسمی نتیجه نمیشود. منبع: Scrum Guide 2020.
کانال را بر اساس کار انتخاب کنید
| کانال | کار مناسب | کنترل لازم |
|---|---|---|
| Test management / issue tracker | Record و Workflow اصلی | ID، history، access، retention |
| Chat | Alert و هماهنگی سریع | پیوند canonical، thread، عدم افشای راز |
| توزیع رسمی/برونتیمی | Recipient control، version، correction | |
| Dashboard | کاوش View و Trend | cutoff، source، filter، drill-down |
| Meeting | رفع ابهام و تصمیم پیچیده | pre-read و Decision record |
| Pager/incident channel | اثر عملیاتی فوری طبق Policy | on-call، severity، security |
Chat نباید تنها حافظهٔ مانع باشد. پیام کوتاه شامل شناسه و Action است؛ Record اصلی شامل تاریخچه، شواهد و Closure. عکس Dashboard نیز اگر Query/Filter/Cutoff نداشته باشد، Snapshot قابل بازتولید نیست.
یک حقیقت، چند View برای مخاطبان مختلف
| مخاطب | نیاز غالب | View مناسب | جزئیات پرخطر |
|---|---|---|---|
| تیم اجرا | کار بعدی، Attempt، dependency | فهرست عملیاتی | Token/PII در Log |
| Plan owner | Delta، ظرفیت، Scope، Forecast | Control view | عدد بدون uncertainty |
| Risk owner | Evidence gap و گزینه | Risk-evidence view | آمار فنی بدون اثر |
| Release authority | Claimهای محدود، Unknown و Decision request | Decision packet | تعبیر QA بهجای Authority |
| مدیر اجرایی | اثر، روند، تصمیم باز | Summary roll-up | Vanity metric |
| Auditor/Reviewer | Lineage و Correction history | Evidence/manifest view | پیوند منقضی یا دسترسی بیشازحد |
Tailoring یعنی Projection از یک Fact/Claim registry، نه بازنویسی حقیقت برای خوشایند هر مخاطب. عدد، Build و زمان برش در همهٔ Viewها باید سازگار بماند؛ توضیح و سطح جزئیات میتواند فرق کند.
چراغ راهنمایی را Claim کنید، تزئین نکنید
ColorPolicy v3 GREEN = all named green predicates true AND no forbidden unknown AMBER = at least one amber predicate; impact bounded; action active RED = at least one red predicate or expired decision/blocker threshold UNKNOWN = evidence/freshness insufficient to evaluate predicates
رنگ باید Rule، Owner و Effective version داشته باشد و کنار متن/آیکون قابل فهم نمایش داده شود. میانگینگیری «دو سبز + یک قرمز = زرد» میتواند یک Gap ممنوع را پنهان کند. UNKNOWN را به سبز یا زرد تبدیل نکنید و رنگ را تنها حامل معنا نسازید.
Dashboard خوب پرسشپذیر است
- عنوان Claim و Decision context را دارد، نه فقط نام نمودار؛
- Build، Environment، Population snapshot، Cutoff و Refresh time قابل مشاهده است؛
- Unknown، Inconclusive، Blocked، Stale و Excluded را حذف نمیکند؛
- Drill-down از عدد به Subject و Evidence مجاز ممکن است؛
- Filter فعال و Scope change ثبت میشود؛
- رنگ با متن و Pattern همراه است و در حالت تکرنگ معنا میماند؛
- Export دارای manifest است و اسکرینشات را منبع حقیقت نمیداند.
Unknown و عدمقطعیت را طراحی کنید
| Unknown | اثر بر Claim | اقدام |
|---|---|---|
| Population incomplete | درصد نهایی قابل محاسبه نیست | Registry owner + موعد Snapshot |
| Foreign-build evidence | قابل تعمیم به Build هدف نیست | Reuse rule یا rerun |
| Cause unknown | راهحل هنوز فرضیهای است | Diagnostic action |
| Impact unknown | Forecast باید بازتر/معلق شود | Impact investigation |
| Authority unknown | درخواست تصمیم بیمقصد است | Governance lookup |
| Freshness unknown | Claim ممکن است کهنه باشد | Source health check |
شفافیت به معنی قطعیت نمایشی نیست. پیام حرفهای Unknown را نام میبرد، اثرش را محدود میکند و مسئول کاهش آن را مشخص میسازد.
Correction و Supersession بخشی از صداقتاند
CorrectionRecord {
correction_id, prior_update_id,
discovered_at, corrected_fields[],
reason, impact_on_prior_claims,
corrected_update_id,
recipients_re_notified[],
downstream_records_reconciled[]
}
پیام اشتباه را بیصدا Edit نکنید. Revision جدید باید Update قبلی را Supersede کند، تغییر و اثرش را بگوید و به همان گیرندگان برسد. اگر تصمیمی بر Claim قبلی تکیه کرده، Decision record نیز نیازمند بازبینی است. Audit trail برای سرزنش نیست؛ برای بازیابی معنای تصمیم است.
قالب یکصفحهای Update روزانه/رویدادمحور
شناسه/نسخه: UPD-B17-042 / r3 (جایگزین r2) هدف/مخاطب: کنترل Wave W4 / Plan owner و Risk owner موضوع: Checkout-Recovery | Build: B17 | Env: LAB-2 Facts-as-of: ۱۴۰۵/۰۱/۲۶، ۱۳:۴۵ Asia/Tehran منابع: REG-17, RUN-SNAP-28, BLK-SNAP-9 پیشرفت: - جمعیت واجد شرایط: ۶ Subject یکتا - Evidence-backed complete: ۲ (۳۳٫۳٪) - In progress: ۳ | Blocked: ۱ | Unknown: ۰ - Delta: C6 از ۱۰:۳۰ به علت DEP-ENV-7 مسدود مانع BL-1: - مشاهده: Stub در Attempt A17 طی ۵ درخواست Timeout داد - اثر: EP-REC برای C6 تولید نمیشود؛ اثر Release هنوز Unknown - مالک اقدام: role:environment-owner | Next check: ۱۴:۳۰ - Workaround: Dataset replay آفلاین؛ Trade-off: parity شبکه سنجیده نمیشود Forecast: پنجشنبه تا شنبه؛ Confidence پایین فرض: DEP-ENV-7 تا ۱۴:۳۰ رفع شود؛ در غیر این صورت Forecast باطل است درخواست تصمیم: خروج موقت C6 از Wave؟ Plan owner تا ۱۴:۴۵ Update بعدی: ۱۵:۰۰ یا با تغییر وضعیت BL-1
قالب پیام کوتاه بدون از دستدادن معنا
[ACTION REQUIRED][UPD-B17-042 r3] Facts-as-of 13:45 +03:30 | B17 | W4 ۲/۶ تعهد شواهد کامل؛ C6 از 10:30 با BL-1 مسدود. اثر مستقیم: EP-REC تولید نمیشود؛ اثر Release هنوز Unknown. مالک اقدام: Env owner، بررسی 14:30. تصمیم: خروج موقت C6 از W4؟ Plan owner تا 14:45. Forecast شرطی: پنجشنبه–شنبه، Confidence پایین. رکورد/شواهد: [canonical link] | Update بعدی 15:00.
پیام کوتاه باید به Record اصلی پیوند دهد. اگر کانال اجازهٔ Link امن نمیدهد، شناسهٔ قابل جستوجو بگذارید و از کپی Log، دادهٔ شخصی یا Credential خودداری کنید.
قالب مستقل Blocker برای Triage سریع
| فیلد | مقدار نمونه |
|---|---|
| Blocker ID / status | BL-1 / OPEN |
| Blocked subject | C6 / EP-REC / Build B17 |
| Observation | ۵ Timeout در Attempt A17؛ Evidence EV-TIMEOUT-۷ |
| Cause | Unknown؛ H1: Connection pool |
| Dependency | DEP-ENV-7: Stub accepts callback within 2s |
| Impact | Evidence gap برای R-REC؛ Release impact Unknown |
| Owner / authority | Env owner / Plan owner |
| Action / due | Config diff review / 14:20 |
| Next check | 14:30 Asia/Tehran |
| Workaround | Offline replay؛ parity شبکه خارج از شاهد |
| Escalation | اگر تا ۱۴:۴۵ ACK نشد |
| Closure | ۳ Attempt موفق + accepted EP-REC روی B17 |
آزمایش تکرارپذیر: چرا ۷۵٪ سبز معتبر نبود؟
برای آزمودن مکانیک پروتکل، Fixture کاملاً ساختگی SYN-PROGRESS-BLOCKER-UPDATE-01 ساخته شد. Registry مستقل فقط C1 تا C6 را دارد و Build هدف B17 است. Draft هشت ردیف نشان میدهد که شش ردیف Done هستند؛ کنترل سطحی چون ۶ از ۸ برابر ۷۵٪ است، رنگ GREEN و PASS میدهد.
داده و قواعد Fixture ساختگی
| مؤلفه | مقدار اعلامشده |
|---|---|
| Registry | C1..C6؛ شش Subject یکتا |
| Build هدف | B17 |
| Freshness max | ۲ ساعت |
| Draft rows | ۸ ردیف؛ شامل C2 تکراری و C99 ناشناخته |
| Draft Done | ۶ ردیف؛ C3 روی B16 و C4 بدون Evidence |
| Blocker | BL-۱ بدون Dependency/Owner/Evidence و Next check منقضی |
| Forecast | یک تاریخ، Confidence بالا، بدون بازه/فرض/منطق |
| Decision request | بدون Authority و Due |
Rule ممیزی Done را فقط وقتی میشمارد که Subject در Registry باشد، Build دقیقاً B17 باشد و Evidence ID داشته باشد. این Rule کفایت طراحی تست یا درستی Evidence را نمیسنجد؛ فقط اتصال ساختاری Claim به Registry/Build/Evidence را بررسی میکند.
خروجی واقعی اجرای Fixture
fixture: SYN-PROGRESS-BLOCKER-UPDATE-01 superficial: PASS | percent=75 | color=GREEN auditedDraft: HOLD | evidenceBackedDone=2 findings (15): 1 stale-facts-as-of 2 duplicate-subject:C2 3 foreign-build:C3:B16->B17 4 missing-evidence:C4 5 unknown-subject:C99 6 claim-done-mismatch:6->2 7 blocker-missing-dependency:BL-1 8 blocker-missing-owner:BL-1 9 blocker-next-check-expired:BL-1 10 blocker-impact-unsupported:BL-1 11 forecast-missing-range 12 forecast-missing-assumptions 13 forecast-confidence-unexplained 14 decision-request-missing-authority 15 decision-request-missing-due corrected: READY_FOR_UPDATE_REVIEW evidenceBackedDone=2 | findings=0
تفسیر درست آزمایش و محدودیتهای آن
نسخهٔ اصلاحی جمعیت را ۶، Done شواهدمحور را ۲، In progress را ۳ و Blocked را ۱ اعلام کرد؛ Facts-as-of تازه شد، مانع Owner/Dependency/Next check/Impact evidence گرفت، Forecast به بازهٔ شرطی با Confidence پایین تبدیل شد و درخواست تصمیم Authority/Due گرفت. نتیجه فقط READY_FOR_UPDATE_REVIEW است، نه PASS محصول و نه مجوز انتشار.
- همهٔ شناسهها، زمانها، ردیفها، قواعد، رنگ و درصدها عمداً ساختگیاند.
- نمونه هیچ ابزار، تیم، محصول، Release، بازار یا سازمان واقعی را Benchmark نمیکند.
- Evidence ID بهتنهایی اصالت/کفایت Evidence را اثبات نمیکند.
- Fixture پوشش، طراحی تست، کیفیت محصول، درستی Forecast، علت مانع یا Risk acceptance را نمیسنجد.
- از این خروجی نباید Threshold جهانی، الگوریتم Release یا ادعای انطباق استخراج کرد.
سناریوی ایرانی کاملاً ساختگی: Checkout و PSP جعلی
فرض کنید یک آزمایشگاه آفلاین برای Checkout فروشگاه خیالی داریم. اجزا عبارتاند از Order، PaymentAttempt، Stub کاملاً جعلی PSP، Callback، Ledger آزمایشی، Reconciliation و Notification fake. هدف Wave B17 تولید Evidence برای Retry، Timeout-before-commit، Timeout-after-fake-commit، Callback تکراری، ترتیب معکوس و تطبیق Ledger است. هیچ اتصال بانکی، PSP واقعی، کاربر یا پول واقعی وجود ندارد.
| ریسک ساختگی | تعهد شاهد | وضعیت Update | محدودیت |
|---|---|---|---|
| R1: ثبت دوبارهٔ اثر پس از Retry | C1/C2 + EP-IDEMP | Done روی B17 | فقط Stub آفلاین |
| R2: از دسترفتن Callback دیررس | C3 + EP-LATE | In progress | Clock مصنوعی |
| R3: Timeout after fake commit | C4/C5 + EP-REC | In progress | بدون شبکهٔ واقعی |
| R4: مغایرت Ledger | C6 + EP-RECON | Blocked by DEP-ENV-7 | Dataset seed نرسیده |
هویت، پول و زمان در سناریوی فارسی
- Tenant، Order، Attempt، Callback event، Ledger entry، Reconciliation run، Build و Evidence شناسههای جدا دارند.
- مقدار canonical فقط IRR ساختگی است؛ نمایش تومان صریحاً برچسب و Rule تبدیل دارد.
- اعداد فارسی «۱۲۳»، عربی «۱۲۳» و لاتین «۱۲۳» فقط ورودیهای Unicode آزمایشگاهیاند و نرمالسازیشان ثبت میشود.
- Instantها ISO ۸۶۰۱/UTC ذخیره، Asia/Tehran بهعنوان View و تاریخ جلالی فقط Presentation است.
- نام، موبایل، ایمیل، IP، حساب، کارت، PAN، CVV2، OTP، Cookie، Token، Secret، Screenshot و Log واقعی ممنوعاند.
این سناریو هیچ توصیهٔ بانکی، مالی، حقوقی، مالیاتی، امنیتی، حریم خصوصی یا تحریمی دربارهٔ ایران نیست. ارقام، شناسهها و نام نقشها صرفاً Fixture آموزشیاند.
Update نمونه برای همان آزمایشگاه
UPD-LAB-B17-07 / r1 | Facts-as-of 13:45 Asia/Tehran موضوع: Evidence obligations C1..C6 | Build B17 | LAB-OFFLINE-2 کامل شواهدمحور: ۲/۶؛ درحالاجرا: ۳؛ مسدود: ۱ BL-RECON-1: مشاهده: Seed snapshot مورد انتظار در manifest LAB-DATA-4 موجود نیست. اثر مستقیم: C6/EP-RECON قابل اجرا نیست. اثر Release: خارج از دامنهٔ این آزمایشگاه و Unknown. مالک اقدام: role:synthetic-data-owner؛ موعد بررسی 14:30. گزینه: Seed حداقلی تولیدشده؛ Trade-off: نمایندگی Production اثبات نمیشود. Forecast: 16 تا 18 آوریل، مشروط به رفع DEP-DATA-4 تا 14:30. Confidence: پایین؛ سابقهٔ مشابه کافی نیست. درخواست تصمیم: پذیرش Seed حداقلی برای همین Lab؟ Lab plan owner تا 14:45.
امنیت، حریم خصوصی و حداقلسازی داده
| ریسک ارتباطی | کنترل | جایگزین امن |
|---|---|---|
| Token در Log | Redaction پیش از ingestion | Evidence ID محدود |
| PII در Screenshot | Data classification و review | Fixture مصنوعی |
| Link عمومی | Access control و expiry | Repository داخلی |
| Forward ایمیل | Recipient minimization | Role-based distribution |
| Prompt کردن دادهٔ حساس | AI usage policy و DLP | Schema/نمونهٔ synthetic |
| Retention نامحدود | Class و deletion schedule | Manifest بدون payload |
| افشای آسیبپذیری | Need-to-know workflow | Sanitized impact claim |
شفافیت با پخش عمومی همهٔ جزئیات یکی نیست. گیرنده باید برای تصمیم لازم، کمترین دادهٔ کافی را ببیند؛ Evidence حساس در مخزن کنترلشده میماند و پیام فقط Reference مجاز ارائه میکند.
اتوماسیون: چه چیزی را ماشین بسازد؟
- استخراج Snapshotهای immutable از Registry، Run و Blocker store؛
- Deduplication با کلید قراردادی و آشکارسازی foreign-build/stale evidence؛
- محاسبهٔ Claim از Rule نسخهدار و انتشار numerator/denominator؛
- Freshness، schema، referential integrity و balanced totals check؛
- تولید Viewهای مخاطب از یک Claim registry؛
- هشدار بر اساس Trigger و suppression/dedup window؛
- ثبت Delivery، Acknowledgement، Supersession و Correction؛
- آزمون synthetic مسیر اعلان، بدون Ping کردن افراد واقعی.
ماشین نباید از روی شمارندهها علت مانع، اثر تجاری، Risk acceptance یا Release decision را اختراع کند. اگر Source ناقص است، Pipeline باید UNKNOWN/HOLD بدهد، نه آخرین مقدار را با برچسب «زنده» تکرار کند.
قرارداد Pipeline گزارش خودکار
extract(source_snapshots) -> validate(schema, identities, timestamps) -> normalize(states, timezones, build_ids) -> deduplicate(subject_id, build_id, attempt_semantics) -> compute(claim_rule_version) -> attach(lineage, unknowns, limitations) -> review_if(high_impact_or_low_confidence) -> publish(audience_view) -> record(delivery, acknowledgement) -> monitor(correction_and_escalation_triggers)
هر مرحله باید Failure mode داشته باشد. اگر State ناشناخته است، نگاشت پیشفرض به Fail/Pass نکنید. اگر Timezone قابل解析 نیست، ترتیب را حدس نزنید. اگر دریافت پیام شکست خورد، Delivery را Acknowledged ثبت نکنید.
هوش مصنوعی در خلاصهسازی Update
| کار | استفادهٔ محدود | Gate انسانی |
|---|---|---|
| تلخیص | کاهش متن از Claimهای موجود | بررسی عدد/هویت/زمان |
| طبقهبندی | پیشنهاد نوع مانع | تأیید Context owner |
| Draft مخاطب | بازنویسی لحن بدون تغییر Fact | Diff معنایی |
| تشخیص تناقض | پرچمگذاری Build/Owner/date | Rule قطعی برای Gate |
| Forecast narrative | شرح مدل محاسبهشده | عدم ساخت عدد/فرض |
| Recommendation | فهرست گزینه از دادهٔ مجاز | Authority و provenance |
Prompt، مدل، نسخه، ورودی، خروجی و ویرایش انسانی را برای کاربردهای پراثر ثبت کنید. متن روان مدل جای Evidence را نمیگیرد. دادهٔ حساس را بدون مجوز وارد سرویس بیرونی نکنید و Hallucination را با «بازخوانی انسانی» صرف مهارشده فرض نکنید؛ Ruleهای هویت و جمع باید مستقل اجرا شوند.
نقشها و حق تصمیم
| قابلیت/نقش | مسئولیت نمونه | حق خودکار ندارد |
|---|---|---|
| Test observer | ثبت Fact و Evidence gap | اعلام علت بدون بررسی |
| Update owner | ساخت Claim، انتشار و Correction | تغییر Baseline پنهانی |
| Work owner | اجرای اقدام تست | پذیرش ریسک کسبوکار |
| Dependency owner | پاسخ به شرط خارجی | تغییر Scope تست |
| Plan owner | کنترل Baseline و Deviation | Release مگر با اختیار صریح |
| Risk owner | تفسیر اثر و Treatment | تغییر Fact |
| Release authority | تصمیم انتشار طبق Governance | بازنویسی Outcome تست |
| Security/privacy owner | طبقهبندی و مسیر افشا | کفایت تست عملکردی |
ISTQB CTAL-TM v3.۰ پایش و کنترل را فعالیتهای مداوم میداند و بر ارتباط وضعیت Work productها و منابع با Plan و هدفهای راهبردی و قابلفهمبودن برای ذینفعان تأکید میکند. این منبع آموزشی، ساختار سازمانی یا Authority جهانی تجویز نمیکند. منبع: ISTQB CTAL-TM v3.0 Syllabus.
متریکهای سلامت ارتباط و Countermetricها
| Metric | تعریف | Countermetric |
|---|---|---|
| Time-to-notify | از detect تا انتشار معتبر | false/duplicate alerts |
| Time-to-ack | از انتشار تا ACK نقش مسئول | ACK بدون action |
| Blocker age | زمان در OPEN با window روشن | reopen rate |
| Action closure | اقدامهای بسته/موعددار | closure بدون evidence |
| Claim correction rate | Updateهای تصحیحشده/کل | under-reporting |
| Freshness compliance | Claimهای داخل SLA | source outage |
| Forecast calibration | Outcome داخل بازه/Forecastها | interval width |
| Decision latency | از request تا decision | quality of decision input |
| Evidence-link validity | Refهای قابل بازیابی/کل | access overexposure |
| Unknown aging | سن Unknownهای اثرگذار | premature forced classification |
کاهش Correction rate لزوماً خوب نیست؛ ممکن است افراد خطا را گزارش نکنند. کاهش Time-to-notify نیز اگر Duplicate alert و افشای داده بالا رود، بهبود خالص نیست. هر Metric باید Owner، Window، Population، Target و بازیپذیری شناختهشده داشته باشد.
ضدالگوهایی که باید متوقف شوند
- درصد بدون Population snapshot و واحد شمارش؛
- سبزکردن Unknown یا Inconclusive؛
- جمعزدن Re-run و Duplicate بهعنوان پیشرفت؛
- استفاده از Evidence متعلق به Build دیگر بدون Reuse rule؛
- گفتن «Environment خراب است» بدون Observation و blocked subject؛
- یکیدانستن Defect با Blocker؛
- اعلام علت از روی همزمانی؛
- Deadline بدون Owner یا Owner بدون Authority؛
- Forecast نقطهای بدون فرض و Invalidation trigger؛
- Confidence رنگی بدون منطق؛
- ارسال مانع بحرانی در گزارش هفتگی بعدی؛
- تبدیل Daily Scrum به گزارش به مدیر؛
- الزام نمودار burn-down به نام Scrum؛
- کپی Screenshot حساس در Chat؛
- ویرایش بیصدای پیام اشتباه؛
- ACK فرضی چون پیام Delivered شده؛
- Dashboard بدون Cutoff و Source health؛
- Roll-up میانگین درصدهای ناهممخرج؛
- نسبتدادن Release decision به QA صرفاً چون گزارش را نوشته؛
- خلاصهٔ AI بدون تطبیق عدد و Lineage؛
- گزارش Activity به جای Outcome/Evidence؛
- Escalation بهعنوان سرزنش؛
- اعلام اثر زمانی قطعی از یک مانع بدون Dependency path؛
- بستن Blocker با کامنت، بدون Closure evidence.
Pilot سیروزه برای استقرار کمریسک
| بازه | کار | خروجی |
|---|---|---|
| روز ۱–۵ | انتخاب یک Wave، مخاطب و سه تصمیم پرتکرار؛ نمونهبرداری پیامهای قبلی | Problem baseline و واژهنامه |
| روز ۶–۱۰ | تعریف Identity/Facts-as-of/State/Population/Evidence rules | Update contract v0.1 |
| روز ۱۱–۱۵ | ساخت Blocker/Decision/Correction templates و دادهٔ synthetic | Fixture و acceptance checks |
| روز ۱۶–۲۰ | اجرای Shadow؛ مقایسه با روش موجود بدون حذف آن | Gap log و false-alert rate |
| روز ۲۱–۲۵ | تمرین stale source، broken link، no-ACK و correction | Recovery evidence |
| روز ۲۶–۲۸ | بازبینی دسترسپذیری، حریم خصوصی و نقشها | Approved distribution map |
| روز ۲۹–۳۰ | تصمیم Pilot با Countermetric و rollback | Adopt/Adapt/Stop record |
Pilot را با یک تیم و یک تصمیم واقعی اما کمخطر شروع کنید. هدف «خودکارسازی کامل» نیست؛ هدف کاهش زمان رسیدن از Fact معتبر به Action روشن، بدون افزایش سبز کاذب یا افشای داده است.
چکلیست قبل از ارسال Update
- Purpose، مخاطب و سؤال تصمیم مشخص است.
- Update ID، Revision و Supersedes ثبت شده است.
- Subject، Plan baseline، Wave/Run، Build و Environment دقیقاند.
- Facts-as-of، Emitted-at، Timezone و Freshness SLA معلوماند.
- Source snapshotها قابل بازیابیاند.
- Population، واحد، numerator، denominator و exclusions تعریف شدهاند.
- Duplicate، Re-run و foreign-build کنترل شدهاند.
- Unknown/Inconclusive/Blocked/Stale جدا نمایش داده میشوند.
- هر Done ادعایی Evidence Profile لازم را دارد.
- Delta نسبت به Baseline ثبت شده است.
- رنگ Rule نسخهدار و متن جایگزین دارد.
- Forecast بازه، فرض، dependency، Confidence rationale و trigger دارد.
- Blocker، blocked subject و Observation روشن دارد.
- Cause اثباتنشده بهعنوان Hypothesis نوشته شده است.
- Impact مستقیم از اثر احتمالی جداست.
- Action owner با Decision authority یکی فرض نشده است.
- Due، Next check، Escalation و Closure condition موجودند.
- درخواست تصمیم سؤال، گزینه، Trade-off و deadline دارد.
- کانال با حساسیت و فوریت متناسب است.
- Record canonical و Link مجاز وجود دارد.
- پیام دادهٔ شخصی/Token/Secret ندارد.
- Acknowledgement و Correction path تعریف شده است.
- Update بعدی یا Event trigger معلوم است.
- متریکها Countermetric دارند.
- متن ادعای Quality/Release/Compliance فراتر از شواهد نمیسازد.
مسیر مطالعهٔ مرتبط بدون همپوشانی
- گزارش تست، Status و تصمیم انتشار: Roll-up مدیریتی و بستهٔ تصمیم؛
- برنامه تست زنده: Baseline، Scope، Risk و Gate؛
- گزارش خلاصه تست: Snapshot پایان و Closure؛
- Control Loop سهسندی: Interface بین Strategy، Plan و Summary؛
- مستندات تست زنده: Freshness و Drift؛
- چرخه اجرای تست: Run، Attempt، Outcome و Closure؛
- مدیریت نقص: Defect record، Triage و SLA؛
- رهبری تضمین کیفیت: مالکیت مشترک و حق تصمیم.
سؤالات متداول درباره گزارش پیشرفت و موانع تست
۱. گزارش پیشرفت تست هر چند وقت یکبار ارسال شود؟
تناوب ثابت جهانی وجود ندارد. Status دورهای را بر اساس سرعت تغییر و نیاز تصمیم تنظیم کنید، اما مانع اثرگذار، شکستن فرض Forecast، منقضیشدن Gate و Correction نباید منتظر جلسه یا گزارش بعدی بماند. در قرارداد، Cadence عادی و Triggerهای رویدادمحور را جدا بنویسید.
۲. بهترین درصد برای نشاندادن پیشرفت تست چیست؟
درصد واحدی بهترین نیست. ابتدا Goal، Population snapshot، واحد شمارش، State، Evidence Profile، Build و Cutoff را تعیین کنید. معمولاً شمارندهٔ Activity باید کنار Evidence obligationهای ریسک، Unknown، Stale و Scope delta دیده شود. درصد بدون این قرارداد میتواند دقیق اما بیمعنا باشد.
۳. فرق Blocked test با Defect چیست؟
Defect ادعایی دربارهٔ رفتار نامطلوب محصول است؛ Blocked میگوید Attempt یا تعهد شاهد بهعلت شرط نامدار قابل تکمیل نیست. یک Defect فقط وقتی Blocker است که واقعاً کار مشخصی را متوقف کند. محیط، داده، دسترسی، ابهام یا Decision gap نیز میتوانند Blocker باشند بیآنکه Defect محصول باشند.
۴. آیا QA باید وضعیت سبز یا قرمز و تصمیم انتشار را اعلام کند؟
QA یا Test role میتواند Fact، Claim محدود، Evidence gap، ارزیابی و توصیه را ارائه کند. Rule رنگ و مرجع ارزیابی باید قراردادی باشد. پذیرش ریسک و Release decision متعلق به Authority تعریفشده در Governance است؛ مگر آنکه همان شخص صریحاً آن اختیار را نیز داشته باشد. نویسندهٔ گزارش خودبهخود تصمیمگیر نیست.
۵. آیا Dashboard یا خلاصهٔ هوش مصنوعی جای Update انسانی را میگیرد؟
Dashboard برای View و AI برای Draft/تلخیص مفید است، اما هیچکدام بهتنهایی معنای Population، اثر مانع، Authority، Unknown یا Trade-off را تضمین نمیکنند. Claimهای هویتی و عددی باید با Ruleهای مستقل اعتبارسنجی شوند و موارد پراثر بازبینی انسانی، Lineage، Acknowledgement و Correction path داشته باشند.
جمعبندی: از «اطلاع دادن» تا حلقهٔ کنترل قابلاعتماد
اطلاعرسانی مؤثر تست با لحن مثبت یا نمودار رنگی شروع نمیشود؛ با قرارداد معنا شروع میشود. هویت و زمان برش را قفل کنید، پیشرفت را به جمعیت و Evidence متصل کنید، Delta و Unknown را پنهان نکنید، مانع را به Observation/اثر/مالک/موعد/گزینه تبدیل کنید و Forecast را شرطی نگه دارید. سپس مطمئن شوید گیرندهٔ مسئول پیام را دریافت کرده، اقدام یا تصمیم ثبت شده و هر خطا قابلتصحیح است. اینگونه Update از یک اعلان تشریفاتی به حلقهای برای کنترل آگاهانه تبدیل میشود—بدون آنکه خودش کیفیت محصول، پذیرش ریسک یا مجوز انتشار را جعل کند.
