وقتی تستر میگوید «این تغییر هنوز قابل ارزیابی نیست» و توسعهدهنده پاسخ میدهد «روی سیستم من درست است»، مسئله لزوماً کمبود احترام یا ابزار نیست. ممکن است هیچکس نداند درخواست از چه مسیری وارد میشود، «دریافت شد» چه معنایی دارد، چه شواهدی برای تحویل لازم است، چه کسی دربارهٔ فوریت تصمیم میگیرد و اختلاف چه زمانی باید Escalate شود. همکاری تستر و توسعهدهنده با شعار «کیفیت مسئولیت همه است» عملیاتی نمیشود؛ به یک Team Working Agreement نسخهدار و قابل بازبینی نیاز دارد.
این راهنما قرارداد شیوهٔ کار مشترک بین نقشهای تست و توسعه را میسازد: Scope، واژگان الزام، کلاس درخواست، Channel، Source of Truth، زمان تأیید و پاسخ، Handoff دوطرفه، حالتهای کار، اختیار تصمیم، Escalation، Exception، Measure و Correction. اگر مسئلهٔ شما طراحی یک درخواست همکاری منفرد، Pair Testing یا Joint Evidence است، راهنمای Collaboration Interface تستر و توسعهدهنده مالک دقیقتری است؛ این مقاله دربارهٔ «سیستم کار تیم» است، نه یک تعامل منفرد.
پاسخ کوتاه: توافق کاری تستر و توسعهدهنده چیست؟
توافق کاری تستر و توسعهدهنده یک سند کوتاه اما اجرایی است که اعضای تیم با مشارکت هم تعیین میکنند: برای انواع مختلف کار چگونه درخواست بدهند، کجا پاسخ دهند، چه چیزی Handoff را آماده میکند، چه کسی چه تصمیمی دارد، در Block یا اختلاف چه مسیری طی شود و خود توافق چگونه با شواهد بازنگری شود. «اجرایی» یعنی هر بند Actor، Trigger، Behavior، Artifact و در صورت لزوم زمان یا مسیر استثنا دارد؛ جملهٔ «همیشه خوب ارتباط برقرار میکنیم» توافق قابل ممیزی نیست.
- یک مشکل واقعی و دامنهٔ محدود را انتخاب کنید.
- درخواستها، کانالها، حالتها و Handoffهای موجود را مشاهده کنید.
- بندهای MUST/SHOULD/MAY را با مسئول و Exception بنویسید.
- زمان پاسخ را بر اساس کلاس کار تعریف کنید، نه عدد جهانی.
- اختیار، Escalation، Appeal و Correction را روشن کنید.
- نسخه را در یک Pilot اجرا و با داده و تجربه بازبینی کنید.
مرز مالکیت: Working Agreement با Interface و Conflict Resolution یکی نیست
| موضوع | واحد طراحی | خروجی اصلی | مالک محتوایی |
|---|---|---|---|
| Team Working Agreement | شیوهٔ کار پایدار یک تیم | قواعد نسخهدار Channel، SLO، Handoff، Authority و Review | همین مقاله |
| Collaboration Interface | یک نیاز همکاری | Request، Mode، Joint Evidence، Follow-up و Closure | مقالهٔ ۱۸۶۱ |
| Bug Report | یک مشاهدهٔ نقص | Reproduction Contract و Evidence Packet | گزارش باگ قابل بازتولید |
| Defect Triage | یک تصمیم دربارهٔ Finding | Disposition، Severity، Priority و Decision Record | پروتکل تریاژ باگ |
| Conflict Resolution | تعارض مشخص | مسیر حل، Repair یا Appeal | راهنمای مستقل حل تعارض |
توافق تیم میتواند بگوید Bug Report از چه Route و با چه Ack عبور کند؛ اما قالب بازتولید را دوباره تعریف نمیکند. میتواند بگوید Disposition در تریاژ ثبت شود؛ اما Severity و Priority را یکی نمیگیرد. میتواند Escalation پیشگیرانه داشته باشد؛ اما جای فرآیند رسیدگی به تعارض یا رفتار آسیبزا را نمیگیرد.
منابع اصلی چه میگویند و چه چیزی را تضمین نمیکنند؟
Working Agreements Play اتلسین توافق کاری را هنجارهای مشترک برای کار، ارتباط و همکاری میداند و بر Channel، Meeting، Escalation و بهبود مستمر تأکید میکند. این یک Play سازمانی مفید است، نه استاندارد الزامآور برای تیم ایرانی و نه تضمین عملکرد. اعداد زمان اجرای Workshop یا دورهٔ بازبینی آن نسخهٔ عمومی برای همهٔ تیمها نیستند.
Scrum Guide 2020 تیم Scrum را Cross-functional و Self-managing توصیف میکند، کل Scrum Team را در برابر Increment ارزشمند و مفید پاسخگو میداند و Developers را در قبال ایجاد کیفیت با Definition of Done پاسخگو میشمارد. از این متن نمیتوان نقش ثابت «QA همهچیز را تست میکند و Developer فقط Fix میکند»، SLA پیام، ابزار یا جلسهٔ اختصاصی استخراج کرد.
برای نوشتن شدت الزام، این مقاله از منطق BCP ۱۴ و RFC ۸۱۷۴ الهام میگیرد: MUST، SHOULD و MAY فقط وقتی معنای هنجاری دارند که تعریف و با شکل متمایز نوشته شوند. این اقتباس زبانی، توافق تیم را به RFC یا استاندارد IETF تبدیل نمیکند. همچنین راهنمای ارتباط Async گیتلب بر Context، Documentation و انتخاب متوازن Async/Sync تأکید دارد؛ تجربهٔ یک شرکت Remote قانون عمومی برای هر سازمان نیست.
قرارداد مرکزی: Tester–Developer Working Agreement
agreement_id: TDA-CHECKOUT-01
version: 1.0.0
status: PILOT
supersedes: null
effective_from: 2026-08-17
review_at: 2026-09-16
team/product/goal: TEAM-CHECKOUT / SYN-CHECKOUT / GOAL-17
scope: [feature handoff, finding response, verification request]
out_of_scope: [HR case, security incident, production incident]
problem_signals: [ambiguous handoff, unacknowledged block, duplicate chat]
co_authors: [test capability, development capability, product interface]
approver/change_owner: TEAM-DECIDER / DELIVERY-ENABLEMENT
normative_terms: {MUST: required, SHOULD: default-with-recorded-exception, MAY: optional}
request_classes: [NORMAL, BLOCKED, URGENT]
source_of_truth: WORK-ITEM
ack_slo/response_slo: per_class
handoffs: [QA_TO_DEV, DEV_TO_QA]
states: [DRAFT, READY, ACKNOWLEDGED, IN_PROGRESS, BLOCKED, DECIDED, VERIFIED, CLOSED]
decision_rights/escalation/appeal: versioned references
exception/expiry: required
measures/countermetrics: versioned set
people_scoring: false
correction/retirement/audit_log: required
not_claimed: [team health, product quality, release safety, causality]
این قالب یک Skeleton است. مقدارهای نمونه مصنوعیاند و نباید بدون مشاهدهٔ Flow واقعی کپی شوند. توافقی که فقط فیلد دارد هنوز اثربخش نیست؛ هر بند باید برای اعضا قابل فهم، در ابزار روزمره قابل اجرا و در Review قابل رد یا اصلاح باشد.
هویت، نسخه و وضعیت را قفل کنید
عنوان «توافق تیم QA» هویت کافی نیست. `agreement_id` پایدار، Version، Status، تاریخ اثر، نسخهٔ قبلی و Review date را ثبت کنید. وضعیت میتواند DRAFT، PILOT، ACTIVE، SUSPENDED یا RETIRED باشد. «آخرین صفحهٔ ویکی» بدون تاریخچه اجازه میدهد یک بند بعد از رخداد بیصدا تغییر کند و کسی نداند در زمان تصمیم کدام نسخه معتبر بوده است.
Goal و Scope را پیش از رفتارها مشخص کنید
Goal باید یک مسئلهٔ همکاری قابل مشاهده را هدف بگیرد؛ برای مثال «کاهش رفتوبرگشت مبهم در تحویل Build به ارزیابی»، نه «ایجاد بهترین تیم». Scope بگوید کدام Product، Team، Workflow و Class را پوشش میدهد. Out-of-scope مسیرهای حساس مثل Incident، گزارش آسیبپذیری، پروندهٔ منابع انسانی یا تصمیم انتشار را جدا میکند. یک قرارداد واحد نباید بدون Authority همهٔ این مسیرها را ببلعد.
Problem Signal را به برچسب افراد تبدیل نکنید
بهجای «Developerها همکاری نمیکنند» یا «QA کند است»، Signal قابل بررسی ثبت کنید: ۱۲ Work Item در ماه گذشته بدون Build identity تحویل شده؛ چهار Block بیش از یک روز کاری Ack نشده؛ سه تصمیم فقط در پیام خصوصی مانده است. Observation را از Interpretation و Cause جدا کنید. تا پیش از بررسی، این شواهد علت یا تقصیر فردی را اثبات نمیکند.
توافق را مشترک بنویسید، اما Veto مبهم نسازید
افرادی که تحت تأثیر بندها هستند باید بتوانند مسئله، محدودیت و استثنا را مطرح کنند. مشارکت مشترک به معنی اجماع ابدی یا اختیار برابر در هر تصمیم نیست. Facilitator بحث را نگه میدارد، Co-authorها بند را میسازند، Approver دامنهٔ اختیار خود را اعمال میکند و Change owner تاریخچه را حفظ میکند. مخالفت ثبتشده و Appeal سالمتر از توافق ظاهری است.
MUST، SHOULD و MAY را عملیاتی تعریف کنید
| واژه | معنای محلی پیشنهادی | نمونه |
|---|---|---|
| MUST | برای اعتبار Flow لازم است؛ نقض باید Block یا Exception ثبتشده بسازد | Build ID در DEV_TO_QA MUST ثبت شود |
| SHOULD | پیشفرض است؛ انحراف دلیل و پیامد دارد | بحث پیچیده SHOULD پس از دو رفتوبرگشت به Mode مناسب منتقل شود |
| MAY | گزینه است و نبود آن Failure نیست | برای توضیح Timeline MAY ویدئوی پاکسازیشده افزود |
«سریع»، «در اسرع وقت»، «کامل»، «لازم» و «همیشه» بدون Definition قابل آزمون نیستند. هر MUST باید Owner، Trigger و Exception path داشته باشد؛ در غیر این صورت بیشتر شبیه تهدید مبهم است تا قرارداد کار.
کلاس درخواست را از Urgency جدا کنید
Request class ماهیت تقاضا را نشان میدهد: Clarification، Feature Handoff، Finding Investigation، Verification، Pairing یا Decision. Urgency دربارهٔ زمان و پیامد تأخیر است. هر سؤال QA «فوری» نیست و هر Incident هم Request عادی نیست. Class، Trigger، Minimum packet، Route، Ack، Response owner و Exit را در یک Registry نسخهدار تعریف کنید.
| Class مصنوعی | Trigger | Minimum packet | Route | Exit |
|---|---|---|---|---|
| NORMAL | ابهام بدون توقف Flow | Context، Question، Work ID | Work item | Answer ثبتشده |
| BLOCKED | کار قابل ادامه نیست | Impact، attempted path، needed decision | Work item + team signal | Unblocked یا Escalated |
| URGENT | شرط از پیش تعریفشدهٔ حساس | Impact، time، evidence locator، incident route | مسیر مصوب Urgent | Owner Ack و انتقال به پروتکل مربوط |
Request Template باید نیاز را قابل اقدام کند
request_id: COLLAB-REQ-104 class: BLOCKED work_item: SYN-WORK-81 requester/needed_capability: TEST-CAP / API-IMPLEMENTATION-CAP context: callback duplicate in synthetic environment question_or_action: identify whether idempotency key is consumed before commit evidence_locators: [RUN-SYN-44, TRACE-SANITIZED-8] impact_if_delayed: verification cannot start needed_by: 2026-08-18T09:00:00Z source_of_truth: SYN-WORK-81 sensitive_data: none ack_state: PENDING
این Request جای Bug Report یا تصمیم Triage را نمیگیرد. عبارت «یه نگاه بنداز» Context، سؤال و Exit ندارد؛ Attachment بدون Locator و Redaction هم Evidence امن نیست. برای طراحی عمیق Request و Joint Evidence به مقالهٔ ۱۸۶۱ رجوع کنید.
Channel Map؛ هر ابزار یک Purpose دارد
Channel را با Purpose، Audience، Record type، Retention، Searchability و Fallback تعیین کنید. Work item میتواند Source of Truth باشد، Chat فقط Signal، تماس Sync برای Investigation پیچیده و سند تصمیم برای Closure. نام ابزار مهمتر از Contract نیست؛ Jira، GitLab، Azure DevOps، پیامرسان داخلی یا راهکار دیگر فقط وقتی مفید است که مسیر و مرجع معتبر روشن باشد.
| Channel | Purpose | نباید تنها محل چه چیزی باشد؟ | Fallback |
|---|---|---|---|
| Work item | Context، State، Evidence locator و تصمیم | Secret یا Artifact بدون کنترل دسترسی | سامانهٔ ثانویهٔ ثبتشده |
| Team chat | Signal و هماهنگی کوتاه | تصمیم نهایی یا تغییر Scope | اعلان جایگزین |
| Sync session | کاهش رفتوبرگشت پیچیده | تنها سابقهٔ تصمیم | خلاصهٔ Async |
| Runbook | قاعدهٔ پایدار و Route | وضعیت لحظهای Work | نسخهٔ Exportشده |
Source of Truth را از Notification جدا کنید
پیام «در Slack گفتم» ممکن است Notification باشد، نه Record معتبر. برای هر نوع داده بگویید Authority کجاست: وضعیت Work، Build، Finding، Decision، Exception و Correction. Link باید به نسخه یا ID پایدار برسد. اگر ابزار اصلی از دسترس خارج شد، Fallback و Reconciliation بعد از بازگشت را از قبل تعیین کنید.
Acknowledgement با پاسخ و پذیرش فرق دارد
Ack فقط میتواند بگوید گیرنده درخواست را دیده، Class را فهمیده و Owner یا زمان بررسی را ثبت کرده است. Ack به معنی موافقت با Claim، پذیرش Defect، تعهد به Fix یا پایان Investigation نیست. Vocabulary نمونه: RECEIVED، NEEDS_CONTEXT، OWNED، ROUTED و DECLINED_WITH_REASON. ایموجی مبهم نباید بهطور خودکار Ack معتبر شمرده شود مگر تیم معنای آن را صریح تعریف کرده باشد.
SLO پاسخ را از دادهٔ محلی بسازید
«همه پیامها در ۱۵ دقیقه» هم تمرکز را میشکند و هم معمولاً قابل نگهداری نیست. Ack SLO، First-response SLO، Decision SLO و Resolution expectation را جدا کنید. ساعت کاری، تعطیلی، ظرفیت On-call، Class و Cost of delay در محاسبه دخیلاند. از Baseline واقعی شروع کنید، یک هدف آزمایشی بگذارید و Miss را برای یادگیری بررسی کنید؛ SLO همکاری SLA حقوقی یا تضمین Fix نیست.
Urgent باید شرط و Route محدود داشته باشد
اگر هر موضوع Urgent شود، Signal از بین میرود. Triggerهای مصنوعی میتوانند «Incident فعال با اثر تعریفشده» یا «Deadline تصمیم مصوب با Cost روشن» باشند. Requester، evidence minimum، فرد یا نقش مجاز برای تغییر Priority، Channel و Downgrade rule را ثبت کنید. Urgency نباید راهی برای دورزدن Queue یا اعمال قدرت سازمانی باشد.
Focus time و Collaboration window را صریح کنید
همکاری سالم به معنای دسترسپذیری لحظهای نیست. ساعتهای تمرکز، بازهٔ همپوشانی، زمانهای مناسب Pairing و رفتار خارج از ساعت کاری را مشخص کنید. اختلاف Time zone، تعطیلات ایران، مرخصی و محدودیت اینترنت ممکن است ظرفیت پاسخ را تغییر دهد. این دادهها برای طراحی Flow هستند، نه نظارت بر حضور فرد.
Delegation باید Capability و Continuity داشته باشد
ارجاع کور «بده به QA» یا «بفرست برای Backend» مالکیت را پنهان میکند. Delegation record باید نیاز Capability، Delegate، Scope اختیار، Context، Artifact، موعد، Acceptance و مسیر بازگشت را داشته باشد. Delegator تا پذیرش روشن نباید خودکار از مسئولیت Continuity خارج شود. غیبت یک فرد نباید کل Flow را متوقف کند؛ Backup مبتنی بر نقش و دسترسی لازم تعریف کنید.
Handoff توسعه به تست یک بستهٔ آماده است
`DEV_TO_QA` بسته به زمینه میتواند Work ID، Scope تغییر، Commit/Build، محیط، Feature flag، Migration، Test data، known limits، مشاهدههای Developer، Rollback locator و Basis/acceptance reference داشته باشد. «کد تمام شد» Ready for Test نیست. Minimum packet را Risk-based تنظیم کنید؛ فهرست سنگین ثابت برای تغییر کوچک هم اتلاف میسازد.
handoff_id: DEV-QA-208 work/build/commit: SYN-WORK-81 / BUILD-SYN-22 / COMMIT-SYN-A7 change_scope: callback idempotency path environment/data: ENV-SYN-3 / DATASET-SYN-9 basis: AC-SYN-v4 flags/migrations: FLAG-IDEM-2 / none known_limits: delayed callback beyond synthetic window not covered developer_observations: UNIT-RUN-19 requested_evaluation: duplicate and reordered callback ready_state: READY_FOR_TEST_REVIEW
Handoff تست به توسعه فقط «Failed» نیست
`QA_TO_DEV` باید Question یا Finding identity، Subject/Build، Oracle basis، Attempt، Observation، Evidence locator، uncertainty و درخواست بعدی را برگرداند. PASS/FAIL بدون Scope و هویت Build قابل استفاده نیست. گزارش عمیق نقص را به Reproduction Contract بسپارید و در توافق فقط شرط Route و Ack را نگه دارید.
State Vocabulary جلوی برداشتهای متناقض را میگیرد
READY، ACKNOWLEDGED، IN_PROGRESS، BLOCKED، DECIDED، FIXED، VERIFIED و CLOSED یک چیز نیستند. برای هر State، Entry criteria، Owner، allowed transitions، timestamp و Exit تعریف کنید. «Done» در برد توسعه ممکن است با «Verified» در Evidence Flow فرق داشته باشد؛ این تفاوت باید آشکار باشد، نه منبع نزاع پنهان.
| State | معنا | چه چیزی را ثابت نمیکند؟ |
|---|---|---|
| READY | Minimum handoff packet حاضر است | درستی Feature |
| ACKNOWLEDGED | گیرنده Request و Route را فهمیده | پذیرش Claim |
| FIXED | تغییر ادعایی با هویت مشخص ساخته شده | رفع مشاهده در محیط هدف |
| VERIFIED | Verification تعریفشده نتیجه ثبت کرده | نبود همهٔ Defectها |
| CLOSED | Exit قراردادی کامل شده | کیفیت یا ایمنی Release |
Pairing را Triggerمحور کنید
Pairing روزانه برای همه قانون عمومی نیست. Trigger میتواند ابهام Oracle، Reproduction پرهزینه، Debug چندلایه یا طراحی سناریوی پرریسک باشد. Session باید Goal، Roles، Timebox محلی، Artifact و Exit داشته باشد. Pairing نباید به Micro-management، کنترل صفحهٔ همکار یا حذف زمان تمرکز تبدیل شود.
Async پیشفرض مطلق و Sync راهحل جادویی نیست
Async برای Traceability، Time zone و تمرکز مفید است؛ اما Context ناقص میتواند رفتوبرگشت را زیاد کند. Sync برای Debug پویا یا ساخت فهم مشترک مفید است؛ اما اگر خروجی ثبت نشود حافظهٔ شفاهی میسازد. Mode را با Complexity، Urgency، Sensitivity، Need for shared observation و Cost of delay انتخاب و نتیجهٔ Sync را به Source of Truth برگردانید.
Meeting Contract؛ جلسه باید Exit داشته باشد
تعداد جلسه معیار همکاری نیست. هر جلسهٔ لازم باید Purpose، Input readiness، Participants based on capability، Facilitator، Decision authority، Timebox، Record owner و Exit داشته باشد. جلسهای که صرفاً وضعیتهای قابل خواندن را بازگو میکند Candidate حذف یا Async شدن است. برای Daily Scrum، راهنمای نقش تستر در Daily Scrum و Evidence Flow مرز رویداد Scrum را توضیح میدهد.
Evidence Rule را با حریم و کفایت همراه کنید
«اسکرینشات بفرست» قانون Evidence نیست. Artifact باید به Subject، Build، Attempt و Time متصل باشد؛ Provenance، Access، Redaction، Retention و Freshness داشته باشد. Screenshot میتواند Observation را نشان دهد اما State پنهان، Cause یا Expected result را لزوماً ثابت نمیکند. Secret، Token، دادهٔ مشتری یا لاگ خام را برای سرعت در کانال عمومی کپی نکنید.
Decision Rights؛ مسئولیت مشترک را بیصاحب نکنید
کیفیت مشارکت همگانی میخواهد، اما هر Risk، Finding، Priority، Fix scope، Exception و Release decision صاحب اختیار مشخص میخواهد. نقشها را بر اساس Capability و Mandate تعریف کنید، نه کلیشهٔ عنوان شغلی. راهنمای رهبری QA و مالکیت همگانی کیفیت تفکیک Accountability و Decision right را عمیقتر پوشش میدهد.
| Decision | Input contributors | Decider نمونه | Record |
|---|---|---|---|
| آمادگی Handoff | سازنده و Reviewer | Owner تغییر | Handoff record |
| اعتبار Observation | تست و توسعه | صاحب پروتکل Evidence | Finding record |
| Priority | محصول، تست، توسعه و عملیات | Authority مصوب | Triage decision |
| پذیرش Risk | صاحبان Evidence و Impact | Risk acceptance authority | Exception/decision record |
Escalation مسیر شکست نیست
Escalation یعنی رساندن مسئله به سطح اختیار یا ظرفیت مناسب، نه تنبیه. Trigger، Route، Minimum packet، Ack، Temporary owner و Closure را تعیین کنید. نمونه Trigger: SLO رد شده و Flow Block است؛ دو Source authority متناقضاند؛ Risk از Mandate تیم فراتر است. «CC کردن مدیر» بدون درخواست تصمیم و Evidence، مسیر Escalation نیست.
escalation_id: ESC-SYN-12 trigger: BLOCKED_SLO_BREACH work/request: SYN-WORK-81 / COLLAB-REQ-104 decision_needed: select temporary verification environment options: [ENV-SYN-4, defer verification] impact/unknowns: one-day delay / data parity unknown decider: DELIVERY-AUTHORITY needed_by: 2026-08-18T10:00:00Z temporary_owner: FLOW-COORDINATOR decision_record: pending
Appeal و Recusal را پیش از نیاز تعریف کنید
اگر فردی معتقد است Evidence نادیده گرفته، اختیار فراتر رفته یا Conflict of interest وجود دارد، مسیر Appeal باید امن و محدود باشد. Appeal باید موضوع، Decision ID، دلیل، Evidence و مرجع مستقل را ثبت کند. Recusal در تعارض منافع نشانهٔ ضعف نیست. این مسیر جای گزارش آزار، تبعیض یا تخلف سازمانی را نمیگیرد؛ آن موارد کانال حمایتی مستقل میخواهند.
Blocked Rule؛ سکوت را وضعیت عادی نکنید
BLOCKED باید Reason code، Since time، blocked work، needed capability، temporary mitigation، Owner و next review داشته باشد. Age را با تقویم کاری درست محاسبه کنید. Block count بهتنهایی Performance افراد نیست؛ افزایش آن ممکن است ناشی از آشکارشدن بهتر مشکلها باشد. تصمیم دربارهٔ Swarm، Replan یا Escalation باید Contextual باشد.
Remote، Time zone و تعطیلی را در Contract بیاورید
توافق باید Canonical time، Time zone نمایش، روز کاری، تعطیلی، Handoff بین شیفتها و رفتار خارج از Overlap را بگوید. برای تیم ایران ممکن است UTC برای Event و `Asia/Tehran` برای نمایش مناسب باشد؛ این انتخاب بسته به سامانه است. تاریخ جلالی اگر استفاده میشود Presentation باشد و Instant اصلی را جایگزین نکند. زمان پاسخ نباید ساعات مرخصی را تخلف نشان دهد.
زبان، دسترسپذیری و Unicode بخشی از همکاریاند
اگر تیم فارسی و انگلیسی را مخلوط میکند، شناسهها و واژههای قراردادی را ثابت نگه دارید و خلاصهٔ تصمیم را به زبان قابل فهم مخاطب بنویسید. ی/ی، ک/ک، نیمفاصله، ارقام فارسی/عربی/لاتین و متن RTL/LTR میتوانند Search یا Copy را مختل کنند؛ ID لاتین پایدار کنار Label فارسی کمک میکند. Alt text، Transcript، Contrast و مشارکت Async را برای افراد با نیازهای متفاوت فراموش نکنید.
ابزار از توافق مهمتر نیست
خرید Jira، TestRail، Slack یا هر ابزار دیگر مشکل مالکیت و معنا را خودکار حل نمیکند. پیش از Automation، State، Field authority، Requiredness، Permission، Integration، Failure mode و Export را تعریف کنید. Bot ممکن است Reminder بدهد یا Packet ناقص را Flag کند؛ نباید از یک Emoji پذیرش Risk یا از سکوت رضایت بسازد.
امنیت، حریم و Retention را طراحی کنید
اصل کمینهسازی را اعمال کنید: فقط دادهٔ لازم، دسترسی حداقلی، Redaction قابل بازبینی و Retention متناسب. Evidence حساس Route جدا میخواهد. پیام خصوصی ممکن است حریم بیشتری بدهد اما Source of Truth تیم نیست؛ خلاصهٔ غیرحساس را ثبت کنید. این مقاله توصیهٔ حقوقی یا امنیتی نیست و Policy سازمان و Review متخصص مربوط را جایگزین نمیکند.
AI میتواند Draft بدهد، نه توافق یا Evidence بسازد
مدل زبانی میتواند بندهای تکراری را خلاصه، تعارض واژگان را Candidate یا صورتجلسه را Draft کند. ورودی ممکن است حساس باشد؛ Hallucination، حذف مخالفت، سوگیری زبان و نسبتدادن نادرست تصمیم خطرند. انسان مجاز باید Source را بررسی و نسخه را Approve کند. «AI گفت همه موافقاند» Agreement receipt نیست و متن تولیدشده Evidence رویداد واقعی نیست.
Onboarding؛ توافق باید قابل کشف و تمرین باشد
عضو تازه، Contractor یا همکار تیم مجاور باید بداند قرارداد کجاست، چه دامنهای دارد و چگونه Exception میگیرد. یک سناریوی تمرینی کوچک برای Request، Handoff و Escalation اجرا کنید. Quiz اجباری یا امضای صوری فهم را ثابت نمیکند؛ مشاهدهٔ اجرای درست در Sandbox و امکان پرسش شواهد بهتری برای آمادگیاند.
Exception راه سالمِ انحراف از قاعده است
قاعدهای که هیچ استثنایی ندارد احتمالاً در بحران دور زده میشود؛ قاعدهای که هر استثنا را میپذیرد بیمعناست. Exception record باید Rule، Context، Reason، Risk، Compensating control، Approver، Scope، Expiry و Review داشته باشد. پایان زمان باید Revert، Renew یا Amend بسازد؛ Exception منقضیشده نباید بیصدا تبدیل به روش دائمی شود.
exception_id: EX-SYN-7 agreement/rule: TDA-CHECKOUT-01@1.0.0 / DEV_TO_QA-MIGRATION-REF context: synthetic hotfix with no schema migration reason: field is not applicable to this change risk: handoff ambiguity if scope statement is wrong compensating_control: reviewer confirms change scope approver: CHANGE-AUTHORITY expires_at: 2026-08-20T12:00:00Z review_outcome: pending
Correction؛ توافق و رکورد گذشته را بیصدا ویرایش نکنید
اگر State، Decision یا بند اشتباه بوده، Correction با `correction_id`، affected records، old/new value، reason، evidence، author، time و notification بسازید. نسخهٔ قبلی باید قابل ردیابی بماند. اصلاح قرارداد آینده با اصلاح تصمیم گذشته فرق دارد؛ ممکن است هر دو لازم باشند. Silent edit اعتماد و قابلیت Audit را ضعیف میکند.
Measure همکاری را از رتبهبندی افراد جدا کنید
هدف Measure پاسخ به سؤال دربارهٔ Fitness توافق است، نه امتیازدهی تستر و Developer. نمونهها: درصد Handoff آماده در اولین بررسی همراه با نرخ Reopen؛ Ack SLO همراه با Focus interruption؛ Block age همراه با Severity mix؛ Decision traceability همراه با Record burden؛ Exception expiry compliance همراه با bypassهای پنهان. هر Metric به Population، Denominator، Window، Source، Owner و Countermetric نیاز دارد.
| Measure | سؤال محدود | Countermetric | نباید برای چه کاری استفاده شود؟ |
|---|---|---|---|
| First-review ready rate | Packetهای تعریفشده چند بار Minimum را داشتند؟ | زمان و بار تهیه Packet | قضاوت مهارت فرد |
| Ack SLO attainment | Classها در Window قرارداد Ack شدند؟ | Interruptions و meaningless ACK | اثبات همکاری سالم |
| Decision traceability | تصمیمها Record قابل پیگیری دارند؟ | زمان ثبت و کیفیت نمونهای Record | اثبات درستی تصمیم |
| Exception aging | استثناها قبل از Expiry بازبینی شدند؟ | استثناهای ثبتنشدهٔ کشفشده | مقایسهٔ تیمها |
راهنمای فرهنگ کیفیت و مشوق ضدبازی توضیح میدهد چرا سنجه و پادسنجه باید کنار هم باشند. در این قرارداد `people_scoring=false` است؛ دادهٔ همکاری برای Coaching سیستم و اصلاح Flow استفاده میشود، نه Ranking افراد.
Review با رأی رضایت پایان نمییابد
در Review، Evidence کمّی، نمونهٔ Work، تجربهٔ اعضا، Missها، Exceptionها و گروههای کمشنیدهشده را کنار هم ببینید. سه خروجی کافیاند: KEEP، AMEND یا RETIRE، همراه Owner و زمان اثر. Survey رضایت میتواند Signal باشد ولی Nonresponse، ترس از اظهار نظر و تغییر ترکیب تیم محدودیت ایجاد میکند. نبود شکایت اثبات سلامت نیست.
چه زمانی توافق را بازبینی کنیم؟
Cadence ثابت جهانی وجود ندارد. Triggerهای مفید شامل پایان Pilot، تغییر Team یا Product، Reorganization، تغییر ابزار یا Time zone، تکرار SLO miss، Incident، افزایش Exception و بندی است که دیگر قابل رعایت نیست. تاریخ Calendar فقط Backstop است. توافق فعال باید Change proposal و تاریخچهٔ رأی/تصمیم داشته باشد.
آزمایش تکرارپذیر: آیا پنج شعار و چهار جلسه یعنی همکاری سالم؟
Fixture مصنوعی `SYN-TESTER-DEVELOPER-WORKING-AGREEMENT-۰۱` پنج عبارت «احترام، همکاری، پاسخ سریع، QA تست میکند، Developer اصلاح میکند»، چهار جلسهٔ هفتگی و وجود پاسخ Chat را دارد. Gate سطحی فقط همین نشانههای فعالیت را میبیند و `COLLABORATION_HEALTHY` میدهد. ممیز مستقل وجود فیلدهای Contract را بررسی میکند؛ محتوا، حقیقت یا اثر آنها را تأیید نمیکند.
{
"fixture": "SYN-TESTER-DEVELOPER-WORKING-AGREEMENT-01",
"superficialGate": "COLLABORATION_HEALTHY",
"initialAudit": "HOLD",
"initialFindingCount": 63,
"independentRule64PeopleScoringDisabled": true,
"correctedAudit": "READY_FOR_WORKING_AGREEMENT_REVIEW",
"correctedFindingCount": 0,
"proves": "structural completeness only"
}
ردپای اصلاح خود آزمایش
اجرای اول بهجای عدد مورد انتظار ۶۳، فقط ۶۲ Finding واقعی ساخت و Validator عمداً `TEST_DESIGN_ERROR` داد. شمارنده به ۶۲ تغییر داده نشد؛ فهرست طراحی بازبینی و کنترل substantive جاافتادهٔ `delegationRule` اضافه شد. اجرای دوم ۶۳ Finding واقعی داد. این Correction مهم است: عدد مورد انتظار نباید بر خروجی واقعی غلبه کند.
۶۳ Finding اولیه در چه گروههایی بودند؟
| گروه | کنترلهای غایب |
|---|---|
| هویت و چرخه | Agreement ID، Version، Status، Supersedes، Effective from، Review at |
| زمینه | Team، Product، Goal، Scope، Out of scope، Problem signals |
| حاکمیت | Co-authors، Approver، Change owner |
| زبان و Intake | MUST، SHOULD، MAY، Request classes، Request template |
| ارتباط | Channel map، Source of truth، Ack meaning، Ack SLO، Response SLO، Urgency، Priority authority |
| ظرفیت | Focus hours، Overlap window، Delegation |
| Flow | QA→Dev، Dev→QA، State vocabulary، Owner per state، Pairing، Sync، Meeting exit، Evidence |
| تصمیم و Block | Decision rights، Escalation، Appeal، Blocked rule |
| شمول و ایمنی | Time zone، Leave، Accessibility، Language، Security، Retention، Tool fallback، AI limit |
| چرخهٔ تغییر | Onboarding، Exception، Expiry، Measures، Countermetrics، Baseline، Review evidence، Change، Correction، Retirement |
| حفاظها | Owner، Audit log، Not claimed |
Rule شصتوچهارم مستقل بررسی کرد که `people_scoring=false` است و PASS شد؛ بنابراین در ۶۳ Finding شمرده نشد. پس از پرکردن همهٔ کنترلها، نتیجه `READY_FOR_WORKING_AGREEMENT_REVIEW` با صفر Finding ساختاری بود—نه اثبات رضایت اعضا، کیفیت محصول، صحت Evidence، کفایت SLO، بهبود Flow، نبود تعارض یا آمادگی انتشار.
آزمایشگاه فارسی و آفلاین
آزمایشگاه Checkout کاملاً خیالی و بدون شبکه است: `Order`، `PaymentAttempt`، PSP Stub، Callback، Ledger، Reconciliation و Notification مصنوعی. سناریوها Timeout پیش و پس از Commit خیالی، Callback تکراری/دیر/جابجا، Build اشتباه، Handoff ناقص، Ack مبهم، غیبت Owner و Expiry استثنا را Seed میکنند. شناسهها پایدار و Timestamp اصلی UTC است؛ نمایش `Asia/Tehran` و تاریخ جلالی فقط View هستند.
مبلغها IRR کاملاً خیالیاند و نمایش تومان فقط با Label صریح انجام میشود. ارقام فارسی/عربی/لاتین، ی/ی، ک/ک، نیمفاصله و RTL/LTR برای آزمون Search و Copy حاضرند. هیچ شبکه، Production، شرکت، تیم، کاربر، سفارش، پرداخت، PSP، بانک، پول واقعی، نام، موبایل، ایمیل، IP، حساب، PAN، CVV2، OTP، Cookie، Token، Credential، Log یا Screenshot واقعی وجود ندارد. آزمایشگاه ادعای مالی، بانکی، حقوقی، امنیتی، حریم خصوصی یا منابع انسانی ندارد.
سناریوی نمونه: تحویل Callback تکراری
- Developer بستهٔ `DEV-QA-۲۰۸` را با Build، Commit، Basis و Known limit ثبت میکند.
- Tester ظرف Window کلاس، Ack از نوع OWNED میدهد؛ این Ack پذیرش سلامت Feature نیست.
- Run مصنوعی Callback تکراری Observation تازه میسازد و `QA_TO_DEV` با Attempt و Evidence locator ثبت میشود.
- Developer Cause را حدس نمیزند؛ Request بررسی محل مصرف Idempotency key را میپذیرد.
- اختلاف دربارهٔ Priority به پروتکل Triage میرود، نه Chat خصوصی.
- Fix ادعایی Build تازه میسازد؛ Verification روی همان Subject و Oracle نتیجه را ثبت میکند.
- اگر رکورد قبلی اشتباه بود، Correction به تصمیمها و Viewهای متاثر وصل میشود.
۲۸ ضدالگوی همکاری تستر و توسعهدهنده
- کیفیت مسئول همه است، پس Owner لازم نیست.
- QA همهچیز را تست میکند و Developer فقط Fix میکند.
- هر پیام باید فوری پاسخ داده شود.
- هر موضوعی که مدیر فرستاد Urgent است.
- ایموجی بدون تعریف یعنی پذیرش.
- Chat تنها Source of Truth است.
- تصمیم Sync ثبت نمیشود.
- Meeting count معیار همکاری است.
- Pairing دائمی برای همه اجباری است.
- Async همیشه بهتر است.
- Sync همیشه سوءتفاهم را حذف میکند.
- Handoff یعنی «کد تمام شد».
- Failed بدون Build و Oracle کافی است.
- Fixed و Verified یکیاند.
- Closed یعنی محصول باکیفیت است.
- Severity را Developer و Priority را QA بهتنهایی تعیین میکند.
- Escalation یعنی شکایت از فرد.
- CC مدیر جای Decision request است.
- Delegation فوراً مسئولیت را حذف میکند.
- سکوت یعنی موافقت.
- نبود شکایت یعنی امنیت روانی.
- همهٔ Exceptionها شفاهیاند.
- توافق و رکورد گذشته بیردپا ویرایش میشود.
- Response time ابزار رتبهبندی افراد است.
- تعداد باگ سهم شخص از کیفیت را نشان میدهد.
- خرید ابزار مشکل همکاری را حل میکند.
- AI میتواند توافق یا Evidence واقعی بسازد.
- یک Template برای همهٔ تیمها و همیشه معتبر است.
چکلیست ۲۴نقطهای ممیزی توافق
- ID، Version، Status و تاریخ اثر مشخص است.
- Goal از Outcome مبهم جداست.
- Scope و Out-of-scope روشناند.
- Problem signal به فرد برچسب نمیزند.
- Co-author، Approver و Change owner معلوماند.
- MUST/SHOULD/MAY تعریف محلی دارند.
- Classهای Request و Minimum packet نسخهدارند.
- Channel map و Source of Truth جدا شدهاند.
- Ack با Acceptance اشتباه نمیشود.
- SLOها Window و تقویم کاری دارند.
- Urgency و Priority authority روشناند.
- Focus، Overlap، Leave و Backup پوشش داده شدهاند.
- Delegation پذیرش و Continuity دارد.
- Handoff دوطرفه و Risk-based است.
- Stateها Entry/Exit/Owner دارند.
- Pair/Sync/Meeting Trigger و Exit دارند.
- Evidence امن، قابل ردیابی و محدود است.
- Decision rights با مسئولیت مشترک جایگزین نشدهاند.
- Escalation، Appeal، Recusal و Block روشناند.
- زبان، Unicode و Accessibility دیده شدهاند.
- Tool fallback و AI limit تعریف شدهاند.
- Exception، Expiry و Correction بیردپا نیستند.
- Measure همراه Countermetric و `people_scoring=false` است.
- Review، Change، Retirement و Not-claimed ثبت شدهاند.
Pilot سیروزهٔ توافق کاری
| بازه | کار | خروجی | Gate |
|---|---|---|---|
| روز ۱ تا ۵ | مشاهدهٔ Flow، مصاحبه و نمونهبرداری Work | Problem signals، Baseline و Scope | مسئله و Authority معتبرند |
| روز ۶ تا ۱۰ | همنویسی قرارداد و Scenario walkthrough | Draft v0.۱، Channel/State/Handoff maps | بندها قابل اجرا و Exceptionپذیرند |
| روز ۱۱ تا ۲۰ | اجرای محدود روی یک Flow | Request/Handoff/Decision/Exception records | آسیب یا بار نامتناسب ایجاد نشده |
| روز ۲۱ تا ۲۷ | Sampling و گفتوگوی Review | Measure، Countermetric و تجربهٔ اعضا | Evidence برای Keep/Amend/Stop کافی است |
| روز ۲۸ تا ۳۰ | تصمیم و Correction | ACTIVE، AMENDED یا RETIRED + audit log | Owner و Review بعدی مشخص است |
عدد ۳۰ یک چارچوب آموزشی است، نه مدت استاندارد. تیم کوچک با Flow پرتکرار شاید زودتر Evidence بسازد؛ تیم کمتکرار یا حساس به Window بلندتر نیاز دارد. Pilot نباید بهانهای برای دورزدن Policy امنیتی، حقوق کار یا Incident response باشد.
ارتباط توافق با Feedback و فرهنگ کیفیت
Working Agreement Route و رفتار پایه را میسازد؛ برای تبدیل بازخورد به Claim، حق پاسخ و اقدام، از راهنمای بازخورد در تیم QA استفاده کنید. برای طراحی Message، Audience، Interpretation check و Decision receipt، مقالهٔ ارتباط در تست نرمافزار مرجع تخصصی است. اتصال این قراردادها مفید است، اما ادغام همه در یک فرم عظیم اصطکاک تازه میسازد.
چه چیزی را نباید از این توافق نتیجه گرفت؟
کاملبودن ساختار یا رعایت SLO ثابت نمیکند اعضا اعتماد دارند، Evidence درست است، تمام Riskها پوشش یافتهاند، Product باکیفیت است یا Release امن است. Association میان اجرای توافق و کاهش Cycle time علت را ثابت نمیکند. این قرارداد Performance framework، قرارداد استخدام، Definition of Done، Test Strategy، Incident protocol یا Release authority نیست؛ اتصال آنها باید صریح و محدود باشد.
جمعبندی: همکاری را به سیستم کار قابل اصلاح تبدیل کنید
همکاری تستر و توسعهدهنده از نیت خوب شروع میشود، اما با Contract زنده دوام میآورد. توافق مؤثر میگوید چه کسی، در چه Trigger، با چه Packet، از کدام Route، در چه Window و با چه Exit عمل میکند؛ سپس Exception، Evidence، Measure و Correction خود را هم میپذیرد. نسخهٔ کوچک و قابل اجرا بسازید، روی Flow واقعی Pilot کنید، اثر و هزینه را کنار هم ببینید و بندی را که کار نمیکند بدون پاککردن تاریخچه اصلاح یا بازنشسته کنید.
سؤالات متداول درباره همکاری تستر و توسعهدهنده
آیا Team Working Agreement همان Definition of Done است؟
خیر. Definition of Done توصیف رسمی حالت Increment هنگام رسیدن به معیارهای کیفیت است؛ Working Agreement شیوهٔ کار، ارتباط، Handoff و تصمیم تیم را مشخص میکند. ممکن است قرارداد به DoD نسخهدار Link دهد، اما نباید آن را بیاجازه بازتعریف کند.
زمان پاسخ مناسب بین تستر و توسعهدهنده چقدر است؟
عدد جهانی وجود ندارد. Class درخواست، Cost of delay، ساعت کاری، Time zone، ظرفیت و Incident route را ببینید؛ Ack، پاسخ اولیه، تصمیم و Resolution را جدا کنید. با Baseline محلی یک SLO آزمایشی بسازید و آن را همراه Countermetric وقفه و Ackهای بیمعنا بازبینی کنید.
آیا بهتر است همهٔ ارتباطها Async باشد؟
خیر. Async برای ردیابی و تمرکز مناسب است؛ Sync میتواند Investigation پیچیده را کوتاه کند. Trigger انتخاب Mode را تعریف کنید و نتیجهٔ Sync را به Source of Truth بازگردانید. هیچکدام بدون Context و Exit همکاری سالم را تضمین نمیکنند.
وقتی تستر و توسعهدهنده درباره یک باگ اختلاف دارند چه کنیم؟
Observation، Oracle، Build و Attempt را جدا و Evidence مشترک بسازید؛ سپس Finding را از مسیر Disposition و Authority مصوب عبور دهید. Ack را پذیرش باگ ندانید. اگر تعارض Evidence حل نشد، Escalation یا Appeal ثبتشده بهکار ببرید؛ بحث شخصیتی و شمارش رأی جای بررسی فنی نیست.
چگونه بفهمیم توافق کاری مؤثر است؟
Question محدود تعریف کنید، Baseline بگیرید و Measure را با Countermetric، نمونهٔ Work و تجربهٔ اعضا بررسی کنید. Handoff آماده، Traceability تصمیم یا Block age فقط Signal هستند. Review باید بتواند KEEP، AMEND یا RETIRE بدهد و صریحاً از رتبهبندی افراد، ادعای علت و تضمین کیفیت محصول پرهیز کند.
