همکاری تستر و توسعهدهنده با زیادشدن پیام، جلسه یا Pair session اثبات نمیشود. ممکن است تیم در یک روز دهها پیام ردوبدل کند، چند باگ را ببندد و همچنان روی Build اشتباه بحث کند، سؤال مبهم بپرسد، Evidence را بدون محدودیت تفسیر کند یا تصمیمی بگیرد که اختیارش را ندارد. Collaboration وقتی قابل اتکاتر میشود که Context، درخواست، پاسخ، Artifact، Observation، Decision و Follow-up به هم متصل باشند.
این راهنما یک Developer–Tester Collaboration Interface میسازد. هدف آن حذف گفتوگو یا رسمیکردن همهچیز نیست؛ کمینهکردن گمشدن Context در نقاطی است که دو یا چند قابلیت باید با هم مسئلهای را روشن کنند. Pair Testing، Review، BDD، TDD، Three Amigos، CI و گفتوگوی Async گزینهاند، نه نسخهٔ جهانی و نه تضمین کیفیت، سرعت یا کاهش هزینه.
مسیر کوتاه همکاری در هشت گام
| گام | پرسش | خروجی |
|---|---|---|
| Context | Goal/Basis/Build/Risk جاری چیست؟ | Baseline |
| Request | چه کمک یا تصمیمی لازم است؟ | Collaboration Request |
| Acknowledge | درخواست قابلفهم و قابلپاسخ است؟ | Status/Owner/Due |
| Mode | Async، Review، Pair یا Workshop؟ | Mode rationale |
| Work | با چه نقش/زمان/Artifact؟ | Session contract |
| Evidence | چه مشاهده شد و چه Unknown ماند؟ | Joint Evidence |
| Decision | چه کسی چه تصمیمی میگیرد؟ | Decision/Action |
| Closure | چگونه Verify و Correct میشود؟ | Follow-up/Correction |
همکاری خوب چیست و چه چیزی نیست؟
| همکاری قابلبررسی | نشانهٔ ناکافی |
|---|---|
| سؤال و Context مشترک | تعداد پیام |
| Artifact و Evidence قابلردیابی | تعداد جلسه |
| نقش و اختیار روشن | عنوان شغلی |
| Observation جدا از تفسیر | توافق سریع |
| Follow-up و Verification | Closed ticket |
| حق مخالفت و Correction | نبود تعارض آشکار |
| انتخاب Mode متناسب | Pairing دائمی |
برای مهارتهای گفتوگو، شنیدن و نوشتن پیام، راهنمای ارتباط بین تستر و توسعهدهنده را ببینید. این مقاله مالک Communication عمومی نیست؛ Interface عملی برای انجام کار مشترک و نگهداری Evidence را تعریف میکند.
منابع چه میگویند و چه چیزی را تضمین نمیکنند؟
اصول پشت Agile Manifesto بر همکاری روزانهٔ افراد کسبوکار و توسعهدهندگان، گفتوگو، ریتم پایدار، توجه به تعالی فنی و بازاندیشی منظم تأکید میکند. این اصول نقش Tester، Three Amigos، Jira، Pair Testing یا تقسیم تستها را تجویز نمیکنند و مدرک موفقیت یک تیم خاص نیستند.
Scrum Guide 2020 یک Scrum Team بدون زیرتیم یا سلسلهمراتب و با سه accountability یعنی Product Owner، Scrum Master و Developers تعریف میکند. Tester عنوان رسمی Scrum نیست؛ متخصص تستی که Increment میسازد در معنای Scrum جزو Developers است. Guide تقسیم Unit test برای Developer و E2E برای QA، جلسهٔ Three Amigos یا QA approval gate تعریف نمیکند.
ISTQB CTFL 4.0.1 Whole-team approach را همکاری اعضای دارای دانش و مهارت لازم برای کیفیت میداند و همزمان میگوید سطحی از استقلال تست میتواند برای یافتن برخی Failureها مؤثر باشد. پس «همه با هم» نباید به حذف perspective مستقل یا حلشدن accountabilityها در شعار تبدیل شود.
مالکیت این مقاله: Collaboration Interface Contract
Goal / Test Basis / Repository / Commit / Build / Risk / DoD -> Collaboration Request -> Acknowledgement / Negotiated Response -> Mode Selection + Rationale -> Session Roles / Consent / Timebox / Access -> Joint Artifact + Evidence + Unknown -> Authorized Decision / Action -> Follow-up / Verification -> Closure / Correction / Learning
Interface یک Ticket factory یا قرارداد حقوقی نیست. Record کوچکی است که هنگام عبور سؤال از مرز قابلیتها از تحریف Subject و Authority جلوگیری میکند. برای سؤال ساده ممکن است یک Comment کوتاه کافی باشد؛ برای Risk مبهم، Incident یا اختلاف Evidence، Contract کاملتر لازم است.
Baseline را پیش از همکاری قفل کنید
| هویت | نمونهٔ ساختگی | اگر نباشد |
|---|---|---|
| Initiative/Product Goal | INIT-18/PG-10 | حل مسئلهٔ اشتباه |
| Sprint Goal | SG-18 | اولویت محلی نامرتبط |
| Test Basis | BASIS-v5 | Oracle منسوخ |
| Repository/Commit | checkout-api/C18 | Code متفاوت |
| Build | BUILD-R18 | `latest` مبهم |
| Risk Registry | RISK-v6 | Risk ناشناخته |
| Definition of Done | DOD-v5 | Closure متفاوت |
| Facts cutoff | ISO instant | Evidence دیررس |
collaborationBaseline: initiative: INIT-18 productGoal: PG-10 sprintGoal: SG-18 testBasis: BASIS-v5 repository: checkout-api commit: C18 build: BUILD-R18 riskRegistry: RISK-v6 definitionOfDone: DOD-v5 factsCutoff: 2026-08-13T04:00:00Z
از «یه نگاه بنداز» به Collaboration Request برسید
| درخواست مبهم | درخواست محدود |
|---|---|
| یه نگاه بنداز | Contract و component evidence برای AUTHZ-۸ اختلاف دارند؛ Source و دو Run پیوست است، تا پیش از Merge نظر لازم است. |
| این باگ را درست کن | در BUILD-R18 Observation بازتولید شده؛ علت معلوم نیست؛ Investigation owner و response time میخواهیم. |
| این Story قابل تست است؟ | برای Rule بازپرداخت، Oracle و state transition مشخص نیست؛ خروجی مورد انتظار Example decision است. |
| همهٔ تستها را بزن | تغییر C18 به authorization path خورده؛ R2 و mandatory checks را انتخاب و skipped scope را ثبت کنید. |
| تأیید QA بده | Risk owner برای تصمیم نیازمند Evidence درباره R1/R2 و Unknownهای باقیمانده است. |
قالب Collaboration Request
collaborationRequest: id: RQ-18 baselineRef: COLLAB-BASE-v1 riskRef: RISK-v6#R2 sourceRef: BASIS-v5#AUTHZ-8 subject: BUILD-R18 / commit C18 observation: contract PASS; component negative case FAIL question: which evidence is invalid or incomplete? requestedCapability: testing + implementation + product context expectedOutput: joint evidence record channel/access: restricted collaboration registry responseDue: 2026-08-13T08:00:00Z requester: capability/requester-18 status: ACKNOWLEDGED
درخواست باید Subject، Source، Observation، سؤال، قابلیت موردنیاز، خروجی و موعد داشته باشد. «Developer» یا «QA» بهتنهایی Recipient دقیقی نیست؛ ممکن است پاسخ نزد فردی با Context محصول، پایگاه داده، امنیت یا Test modeling باشد.
Acknowledgement با Acceptance تفاوت دارد
| Status | معنا | کار بعدی |
|---|---|---|
| RECEIVED | رسیده، هنوز بررسی نشده | زمان پاسخ |
| NEEDS_CONTEXT | Source/Subject/Question ناکافی | درخواست تکمیل |
| ACKNOWLEDGED | فهم مشترک اولیه | Mode/Owner/Due |
| SCHEDULED | کار مشترک زمانبندی شده | Session contract |
| REDIRECTED | قابلیت دیگری لازم است | Owner تازه با trace |
| DECLINED | خارج Scope/ناامن/بیمجوز | Reason/alternative/escalation |
| CLOSED | خروجی و Follow-up ثبت شده | Correction امکانپذیر |
Seen، emoji یا حضور در جلسه Acceptance نیست. پاسخ میتواند موعد را مذاکره کند، Context بخواهد یا مسیر امنتری پیشنهاد دهد. Silence نیز consent یا agreement محسوب نمیشود.
Mode را از روی مسئله انتخاب کنید
| Mode | مناسب برای | هزینه/محدودیت | خروجی |
|---|---|---|---|
| Async question | سؤال محدود و Source قابلخواندن | رفتوبرگشت/تأخیر | پاسخ نسخهدار |
| Artifact review | Code/Test/Contract/Model آماده | Context پنهان | Finding/Disposition |
| Pair testing | Exploration یا diagnosis مشترک | تمرکز و انرژی دو نفر | Charter/Evidence |
| Pair programming | تغییر Code و یادگیری مشترک | برای همه/همیشه مناسب نیست | Code/Test/decision |
| Example workshop | Rule/Example/Unknown | نیاز به perspective مرتبط | Basis decision |
| Triage | Findingهای متعدد/متعارض | نباید دادگاه مقصر باشد | Classification/Owner |
| Independent check | Bias/authority/high-risk | Feedback دیرتر | Counter-evidence |
Mode را با ابهام، شدت Risk، توزیع Context، نیاز به همزمانی، هزینهٔ interruption، محدودیت دسترسی و زمان تصمیم انتخاب کنید. جلسه پاسخ پیشفرض نیست. Async pre-read و independent attempt پیش از Pair میتواند anchoring را کمتر کند؛ Pair نیز در اختلاف فوری Evidence ممکن است ارزشمند باشد.
Pair Testing یک Session طراحیشده است
- Charter و Subject را پیش از شروع بنویسید.
- رضایت، زمان، وقفه و حق توقف را روشن کنید.
- Driver/Navigator یا Tester/Observer را موقت و قابلچرخش نگه دارید.
- Observation، idea، question و action را با label جدا ثبت کنید.
- Fix فوری را بدون Build/Commit/Verification گم نکنید.
- در پایان Output، Unknown و Follow-up بسازید.
مقالهٔ On Pair Programming یک تجربهٔ مفصل درباره Driver/Navigator، تعویض نقش، سبکهای Pairing، خستگی و تناسبنداشتن Pairing برای بعضی کارها ارائه میکند. این منبع استاندارد یا تضمین بهرهوری نیست؛ راهنمای تجربی است و باید با Context و رضایت تیم Adapt شود.
Pairing نباید Micro-management شود
| خطر | Signal | Control |
|---|---|---|
| Keyboard monopoly | یک نفر همیشه اجرا میکند | role rotation/choice |
| Command mode | دستور گامبهگام | question/space/stop |
| Authority pressure | مخالفت ثبت نمیشود | independent note/appeal |
| Exhaustion | تمرکز و کیفیت افت میکند | timebox/break/async |
| Surveillance | Session برای ارزیابی فرد | purpose/data boundary |
| Instant-fix loss | تغییر بدون trace | commit/build/verification |
Three Amigos سه عنوان شغلی ثابت نیست
Business، Development و Testing سه perspective مفیدند، نه الزام حضور دقیق Product Owner، Developer و Tester در هر Story. برای یک تغییر مالی شاید Domain/Accounting، برای دسترسی Security/Privacy و برای عملیات SRE لازم باشد. سؤال مهم این است: چه perspectiveای برای Rule/Risk غایب است؟
| Perspective | سؤال نمونه | خروجی |
|---|---|---|
| Value/Domain | Rule و استثنا چیست؟ | Example/Decision |
| Implementation | State/Dependency/Constraint چیست؟ | Technical option |
| Testing | Oracle/Boundary/Unknown چیست؟ | Quality question |
| Security/Privacy | Asset/abuse/data access چیست؟ | Control obligation |
| Operations | Detect/rollback/recover چگونه؟ | Runtime obligation |
| Accessibility/User | چه Contextی غایب است؟ | Representative check |
BDD و Gherkin فقط وقتی زبان مشترکاند که معنا مشترک باشد
Given/When/Then میتواند Example را خوانا کند، اما Syntax یکسان، فهم یا توافق را تضمین نمیکند. Source، Rule، Example boundary، Oracle، Unknown و Decision باید معلوم باشند. سناریو ممکن است مستند، مثال، Specification یا Automated check باشد؛ این چهار ادعا را یکی نکنید. آموزش کامل در نوشتن سناریو Gherkin در BDD آمده است.
TDD تقسیم نقشها را تعیین نمیکند
Red–Green–Refactor یک چرخهٔ Development است؛ نمیگوید Tester باید Test را بنویسد یا Developer «نقش تستر» را بازی میکند. تستر میتواند با Example، Risk، Oracle، property یا testability کمک کند و Developer میتواند در هر سطح Test بسازد. Ownership را از قابلیت، Context و Work بگیرید، نه از یک جدول ثابت Unit/Integration/E2E.
Shift-left همکاری را به حضور دائمی تبدیل نمیکند
بازخورد زودهنگام وقتی معنا دارد که سؤال و Artifact کافی باشد. دعوت تستر به همهٔ جلسههای طراحی میتواند صف، context switching و dependency بسازد. راهنمای نقش تستر در Shift-left انتخاب earliest economical point و اتصال آن به Countercheck دیرتر را توضیح میدهد.
CI/CD محل همکاری روی Evidence است، نه تقسیم سیلوها
| کار | قابلیتهای محتمل | خروجی مشترک |
|---|---|---|
| Test selection | change/risk/test modeling | selected/skipped scope |
| Fixture | domain/data/implementation/testing | versioned data state |
| Failure triage | implementation/environment/testing | classified observation |
| Flaky investigation | runner/test/system | hypothesis/evidence |
| Gate policy | risk/product/technical authority | policy/exception |
| Pipeline health | platform/developer/test | feedback SLI |
Developer-only Unit tests و Automation-engineer-only Integration/E2E یک تقسیم جهانی نیست. همچنین اجرای همهٔ Checkها روی هر Commit بهخودیخود همکاری یا کیفیت نیست. Subject، Trigger، Risk، cost، latency، stability و Evidence obligation باید انتخاب را هدایت کنند.
Joint Evidence از توافق شفاهی مهمتر است
jointEvidence: id: JE-18 requestRef: RQ-18 subject: BUILD-R18 / commit C18 sourceRefs: [BASIS-v5#AUTHZ-8, AUTHZ-MATRIX-v3] attempts: [RUN-C18-41, RUN-C18-42] observations: [contract PASS, component negative case FAIL] interpretations: [fixture mismatch candidate] unknowns: [deployed policy overlay] artifacts: [AUTHZ-FIXTURE-v3, TRACE-SYN-18] limitations: [synthetic identity; component environment] disposition: INVESTIGATE_FIXTURE decisionOwner: authorized-risk-owner followUp: system countercheck on BUILD-R19
Observation، Interpretation، Hypothesis و Cause را جدا کنید
| لایه | نمونه | ادعای ممنوع |
|---|---|---|
| Observation | RUN-۴۲ پاسخ ۲۰۰ داد | Developer خراب کرده |
| Interpretation | Oracle انتظار ۴۰۳ دارد | Requirement قطعاً درست است |
| Hypothesis | Fixture role mapping stale است | علت ریشهای پیدا شد |
| Cause evidence | Diff+control+reproduction | تنها علت ممکن |
| Action | Fixture را version و rerun کنید | Fix برابر Verification |
زبان شخصمحور—«کدت خراب است»، «QA گیر داده»، «فلانی این Bug را ساخته»—Evidence نیست. رفتار سیستم، Source، Attempt و اثر را ثبت کنید. این کار مسئولیت حرفهای را حذف نمیکند؛ Attribution را تا داشتن شاهد معتبر عقب میاندازد.
Bug Report نقطهٔ شروع Investigation است
Expected/Actual، Build، State، Data، Attempt و Evidence به همکاری کمک میکنند؛ Screenshot یا Log خام همیشه کافی و بیخطر نیست. Reproduction Contract و Evidence Packet مرز Observation، Hypothesis، Correlation، Redaction و Verification را پوشش میدهد. ثبت Bug مجوز خودکار برای Severity، Priority، Cause یا Release decision نیست.
Finding را رد یا قبول نکنید؛ Disposition بدهید
| Disposition | معنا | Evidence/Action |
|---|---|---|
| CONFIRMED | با Source و Subject فعلی پشتیبانی شد | Owner/priority route |
| NOT_REPRODUCED | در Attempt محدود دیده نشد | نه Invalid، نه Fixed |
| NEEDS_EVIDENCE | Oracle/Build/State ناکافی | درخواست مشخص |
| DUPLICATE | Canonical record موجود | Link/scope check |
| EXPECTED_BY_BASIS | رفتار با Source جاری سازگار | ممکن است Product concern بماند |
| DEFERRED | اقدام بعدی عقب افتاد | Authority/reason/expiry |
| CORRECTED_RECORD | گزارش قبلی اصلاح شد | supersedes/history |
تعارض Evidence را با Authority حل نکنید
Senior بودن، مالک Code بودن یا عنوان QA بهتنهایی Oracle نیست. Source hierarchy، Subject identity، comparable attempt و محدودیت را بررسی کنید. اگر تعارض رفتاری/بینفردی یا آسیب رابطهای شکل گرفته، راهنمای مدیریت تعارض در QA مسیر جداگانهای دارد؛ Collaboration Interface جای HR، grievance یا safety process نیست.
مسئولیت مشترک به معنی اختیار مشترک برای همهچیز نیست
| موضوع | Contribution | Decision owner نمونه |
|---|---|---|
| رفتار مورد انتظار | Product/Domain/Dev/Test | Product/domain authority |
| راهحل فنی | Dev/Test/Platform/Security | technical authority |
| Test evidence | هر capability مرتبط | evidence owner |
| Severity | technical/user/business evidence | policy/triage authority |
| Priority | impact/urgency/options | Product/work authority |
| Risk acceptance | evidence/recommendation | named risk owner |
| Release | multi-source readiness | authorized release owner |
QA مالک انحصاری کیفیت یا Release نیست و Developer هم تنها مالک کیفیت فنی نیست. تفکیک Contribution، Accountability و Authority در رهبری تضمین کیفیت با مالکیت همگانی با جزئیات آمده است.
Review با Approval صوری پایان نمییابد
Code/Test/Contract review باید Baseline، معیار، Finding، پاسخ، Disposition، Rework و Closure داشته باشد. Approve فقط نتیجهٔ Process تعریفشده است؛ کیفیت محصول، نبود Defect یا اجازهٔ Release را ثابت نمیکند. پروتکل کامل در Review Contract تا Finding و Closure قابل استفاده است.
Follow-up باید Owner و موعد داشته باشد
| Follow-up | Owner | Due/Exit |
|---|---|---|
| Source clarification | domain capability | Decision record |
| Fixture correction | data/test capability | versioned fixture |
| Implementation change | implementation capability | commit/build |
| Countercheck | testing capability | Attempt/Evidence |
| Risk decision | risk owner | accept/mitigate/defer |
| Record correction | record owner | superseding link |
«بعداً بررسی میکنیم» Action نیست. اگر مانع روی Sprint Goal یا تصمیم جاری اثر دارد، Update کوتاه Fact/Evidence/Impact/Ask/Owner/Due بسازید؛ قالب آن در گزارش پیشرفت و موانع تست آمده است.
Closure بدون Verification ناقص است
Merged، Fixed، Comment resolved یا Bug closed نتیجهٔ نهایی رفتار را ثابت نمیکند. Verification باید Build/Commit، Environment/Data، Oracle، Attempt، Outcome و residual Unknown را ثبت کند. اگر Source یا Evidence بعداً تغییر کرد، رکورد پیشین را پاک نکنید؛ Correction با `supersedes` و علت بسازید.
Remote و Async باید First-class باشند
- Context، Source و سؤال را پیش از جلسه قابلخواندن کنید.
- Deadline و timezone را با ISO instant ثبت کنید.
- پاسخ مستقل پیش از بحث همزمان را ممکن کنید.
- Caption، transcript، keyboard access و alternative text فراهم کنید.
- تصمیم را از تماس خصوصی به Registry مشترک منتقل کنید.
- نبود پاسخ را agreement یا consent تفسیر نکنید.
امنیت و حریم Evidence بخشی از همکاری است
| Artifact | خطر | Control |
|---|---|---|
| Screenshot/video | نام/اعلان/session | crop/redact/review |
| Log/trace | token/PII/query | allowlist/restricted access |
| HAR | URL/body/header/cookie | sanitize/quarantine |
| Database sample | واقعی/قابل بازشناسی | synthetic/minimized |
| Chat export | Context شخصی/retention | extract decision only |
| AI prompt | Source/secret leakage | classification/approved boundary |
AI میتواند Candidate بدهد، نه تصمیم همکاری
AI میتواند Request را خلاصه، سؤالهای گمشده را پیشنهاد، Diff را توضیح یا Meeting note را دستهبندی کند. Source/version، input classification، model/version، output digest و reviewer را ثبت کنید. مدل نباید رضایت Pairing، Cause، Priority، Blame، Performance فرد، Risk acceptance، Quality approval یا Release را تعیین کند و نباید Secret/PII/Production evidence مجازنشده دریافت کند.
اندازهگیری Collaboration بدون رتبهبندی افراد
| Metric | تعریف | Guardrail/Countermetric |
|---|---|---|
| Request age | created→actionable response | response quality |
| Context completeness | required fields/eligible requests | form burden |
| Decision latency | Evidence ready→decision | premature decision |
| Reopen reason | closure بعداً invalid شد | new scope/change |
| Unknown closure | dispositioned/eligible unknowns | false certainty |
| Follow-up aging | open past due | priority/context |
| Mode fitness | adopt/adapt/stop review | focus time/WIP |
تعداد پیام، جلسه، Pair hour، Bug بستهشده، Comment یا Approval سنجهٔ کیفیت همکاری نیست. Metric را برای یادگیری سیستم استفاده کنید، نه مقایسهٔ Developer و Tester، ارزیابی فرد، سهمیهٔ جلسه یا پاداش. تغییر Risk mix، Work type و reporting behavior نتیجه را جابهجا میکند.
آزمایش تکرارپذیر: آیا فعالیت زیاد یعنی همکاری سالم؟
یک Fixture کاملاً ساختگی و بدون dependency با Node.js ۲۶.۷.۰ اجرا شد. سنجهٔ سطحی فقط پنج Pair session، هجده پیام و شش Bug بستهشده را دید و PASS داد. Validator قراردادی همان رکورد را بر اساس Baseline، Request، Session، Evidence، Authority، Closure و Improvement بررسی کرد.
خروجی Validator: ۵۲ Finding
fixture: SYN-DEV-TEST-COLLABORATION-01 runtime: Node.js v26.7.0 superficial: PASS | pairSessions=5 | messages=18 | bugsClosed=6 auditedDraft: HOLD findings (52): 1 stale-initiative:INIT-17->INIT-18 2 stale-productGoal:PG-9->PG-10 3 stale-sprintGoal:SG-17->SG-18 4 stale-testBasis:BASIS-v3->BASIS-v5 5 stale-repository:checkout-web->checkout-api 6 stale-commit:C16->C18 7 stale-build:latest->BUILD-R18 8 stale-riskRegistry:RISK-v3->RISK-v6 9 stale-definitionOfDone:DOD-v3->DOD-v5 10 duplicate-request:RQ-1 11 unknown-risk:R99 12 RQ-1-missing-source 13 RQ-1-question-unbounded 14 RQ-1-trigger-rationale-missing 15 RQ-1-recipient-not-capability-based 16 RQ-1-response-due-missing 17 RQ-1-channel-missing 18 RQ-1-status-missing 19 RQ-1-evidence-access-unbounded 20 RQ-1-redaction-missing 21 RQ-1-expected-output-missing 22 session-unknown-request:RQ-X 23 session-objective-missing 24 collaboration-mode-rationale-missing 25 pairing-consent-missing 26 implementation-perspective-missing 27 roles-fixed-by-job-title 28 role-rotation-missing 29 timebox-missing 30 accessibility-controls-missing 31 recorder-missing 32 decision-authority-missing 33 artifact-missing 34 joint-output-missing 35 unknowns-missing 36 follow-up-missing 37 person-blame-language 38 observation-interpretation-mixed 39 root-cause-overclaim 40 priority-self-assigned 41 qa-exclusive-quality-ownership 42 developer-test-silo 43 automation-capability-silo 44 all-tests-every-commit 45 approval-as-quality-proof 46 closure-without-verification 47 correction-path-missing 48 quality-speed-cost-guarantee 49 improvement-baseline-missing 50 improvement-measure-missing 51 improvement-guardrail-missing 52 individual-ranking-metric corrected: READY_FOR_COLLABORATION_REVIEW | findings=0
نسخهٔ اصلاحی چه کرد؟
Baseline را روی INIT-۱۸/PG-۱۰/SG-۱۸/BASIS-v5/checkout-api/C18/BUILD-R18/RISK-v6/DOD-v5 قفل کرد؛ یک Request یکتا و Risk/Source-bound ساخت؛ Async review را پیش از Pair روی اختلاف Evidence انتخاب کرد؛ رضایت، perspective، نقش چرخشی، timebox، دسترسیپذیری، recorder، Artifact، Unknown، Decision owner و Follow-up را ثبت کرد؛ Blame، Cause overclaim، silo و QA gate را حذف کرد؛ و Improvement را به baseline/measure/guardrail بست.
`READY_FOR_COLLABORATION_REVIEW` فقط کاملبودن ساختار Fixture را میگوید. کیفیت رابطه، امنیت روانی، صحت Source/Code/Test/Evidence، علت ریشهای، کفایت Risk، سرعت رفع، کاهش هزینه، کیفیت محصول، رضایت کاربر، موفقیت Agile یا آمادگی Release را اثبات نمیکند.
آزمایشگاه فارسی و آفلاین همکاری
Lab یک Checkout خیالی بدون شبکه است: Order، PaymentAttempt، PSP Stub، Callback، Ledger و Reconciliation. Developer و Tester نام اشخاص نیستند؛ دو capability ساختگیاند که روی اختلاف Contract و Component evidence کار میکنند. هیچ شرکت، محصول، کاربر، پرداخت یا Production واقعی وجود ندارد.
| Fault | Request | Joint work | Countercheck |
|---|---|---|---|
| duplicate callback | idempotency evidence conflict | state model + replay | integration run |
| late callback | timeout Oracle unclear | timeline/example | system clock |
| wrong tenant | authorization mismatch | matrix + negative fixture | deployed policy |
| IRR/toman view | display/canonical mismatch | conversion property | UI/API reconcile |
| stale Build | Evidence disagreement | subject identity audit | same-build rerun |
- IRR کاملاً خیالی Canonical است؛ تومان فقط View صریح.
- رقم فارسی/عربی/لاتین، Unicode و RTL/LTR در Fixture کنترل میشود.
- زمان UTC instant و Asia/Tehran view است؛ جلالی فقط Presentation است.
- Tenant/Order/Attempt/Event/Ledger/Run/Build/Evidence identity جداست.
- نام/موبایل/ایمیل/IP/PAN/CVV2/OTP/cookie/token/credential/log واقعی وجود ندارد.
- هیچ ادعای بانکی، مالی، حقوقی، مالیاتی، امنیتی یا حریم خصوصی ایران ساخته نمیشود.
۲۹ ضدالگوی همکاری تستر و توسعهدهنده
- Agile بهعنوان انقلاب یا تضمین
- همکاری بهعنوان الزام بقا
- تیم سنتی همیشه متخاصم
- تستر بهعنوان Coach/Consultant دائمی
- حضور در همهٔ جلسهها
- ۱۰۰× هزینهٔ Bug بدون Context
- BDD تضمین فهم مشترک
- TDD یعنی Developer نقش Tester دارد
- Pairing همیشه کیفیت را شدیداً بالا میبرد
- Pairing بدون consent
- Keyboard monopoly
- Job title برابر Session role
- Three Amigos دقیقاً سه عنوان
- Emoji برابر Acknowledgement
- Silence برابر Agreement
- QA مالک کیفیت
- QA صاحب Release
- Developer فقط Unit test
- Automation specialist فقط E2E
- همهٔ Testها روی هر Commit
- Approve برابر Quality proof
- Bug report برابر Cause
- Not reproduced برابر Invalid
- Fixed برابر Verified
- Closed بدون Follow-up
- Screenshot/Log خام و عمومی
- تعداد پیام/جلسه KPI فردی
- نبود تعارض برابر اعتماد
- تضمین سرعت/هزینه/کیفیت/رضایت
Pilot سیروزهٔ Collaboration Interface
| بازه | کار | Exit محدود |
|---|---|---|
| روز ۱–۳ | سه interaction گمشده و Baseline | problem sample |
| روز ۴–۷ | قالب Request/Ack | سه Request محدود |
| روز ۸–۱۰ | Mode matrix | rationale ثبتشده |
| روز ۱۱–۱۵ | یک Async review و یک Pair | Joint Evidence |
| روز ۱۶–۲۰ | Decision/Follow-up/Verification | closed loop |
| روز ۲۱–۲۵ | request age + guardrail | bounded measures |
| روز ۲۶–۳۰ | Review adopt/adapt/stop | versioned learning |
Pilot موفق یعنی Context کمتر گم شده و چند درخواست به خروجی و Follow-up متصل شدهاند؛ نه اینکه سرعت، کیفیت یا رابطه حتماً بهتر شده باشد. اگر قالب، جلسه یا Pairing WIP و interruption را بالا برد، Scope را کم یا Mode را عوض کنید.
چکلیست Audit همکاری
- Goal/Basis/Repository/Commit/Build/Risk/DoD/Cutoff جاریاند.
- Request ID یکتا و Source/Risk/Subject مشخص دارد.
- Observation، سؤال، capability، output و due روشناند.
- Acknowledgement، acceptance و scheduling جدا هستند.
- Mode با ابهام/Risk/Context/cost توجیه شده است.
- Pairing رضایت، timebox، حق توقف و نقش چرخشی دارد.
- perspective غایب و independence لازم بررسی شدهاند.
- Artifact نسخهدار و Evidence به Subject/Attempt وصل است.
- Observation/Interpretation/Hypothesis/Cause جدا هستند.
- Unknown و forbidden inference ثبت شدهاند.
- QA quality/release gate یا نقشهای تستی ثابت ساخته نشده است.
- Severity/Priority/Risk/Release authority صریح است.
- Disposition دلیل و Evidence دارد.
- Follow-up Owner/Due/Exit دارد.
- Closure به Verification وصل است.
- Correction و supersedes تاریخچه را حفظ میکند.
- Evidence redaction/access/retention دارد.
- Async/timezone/accessibility و نبود consent رعایت شدهاند.
- AI فقط candidate و تحت review است.
- Metric برای یادگیری سیستم است، نه رتبهبندی فرد.
- هیچ quality/speed/cost/success guarantee ساخته نشده است.
پرسشهای متداول
آیا تستر و توسعهدهنده باید هر روز Pair کنند؟
خیر. Pairing برای مسئلهٔ مبهم، یادگیری یا Evidence conflict میتواند مفید باشد، اما تمرکز دو نفر، consent و زمان میخواهد. برای سؤال محدود Async یا Review ممکن است بهتر باشد. Mode را آزمایشی انتخاب و با focus time، WIP و کیفیت خروجی بازبینی کنید.
در Scrum مسئول تست Developer است یا Tester؟
Scrum عنوان Tester یا تقسیم تست بر اساس عنوان شغلی تعریف نمیکند. Developers همهٔ افراد متعهد به ساخت Increment قابلاستفادهاند و Scrum Team برای Increment ارزشمند accountable است. Work را بر اساس Risk، مهارت، Context و ظرفیت توزیع کنید؛ تخصص و استقلال لازم را هم حفظ کنید.
آیا BDD و Three Amigos اختلاف نیازمندی را حذف میکنند؟
خیر. آنها میتوانند Rule، Example و perspective را مرئی کنند؛ ولی Source ناقص، stakeholder غایب، Example بد یا تصمیم مبهم باقی میماند. خروجی را به Basis، Unknown، Decision و Countercheck وصل کنید و Syntax Gherkin یا تعداد شرکتکنندگان را موفقیت ندانید.
وقتی Developer و Tester درباره یک Bug اختلاف دارند چه کنیم؟
Build/State/Data/Oracle و Attempt را همتراز کنید؛ Observation را از تفسیر جدا و یک Control یا rerun قابلمقایسه بسازید. سپس Disposition بدهید. Seniority یا عنوان نقش Oracle نیست. اگر تعارض رفتاری یا آسیب رابطهای وجود دارد، مسیر حل تعارض مستقل لازم است.
چگونه همکاری را بدون شمارش جلسه و پیام بسنجیم؟
Request age، Context completeness، Decision latency، Follow-up aging، reopen reason و Mode fitness را همراه guardrailهایی مثل focus time، form burden و premature closure مشاهده کنید. این سنجهها برای یادگیری سیستماند؛ کیفیت محصول یا عملکرد فرد را ثابت نمیکنند.
جمعبندی: همکاری یک حلقهٔ Evidence است
همکاری تستر و توسعهدهنده با شعار «کیفیت وظیفه همه است» یا اجبار Pairing ساخته نمیشود. Context جاری را قفل کنید، Request محدود بفرستید، پاسخ و Mode را مذاکره کنید، نقش و consent را روشن نگه دارید، Joint Evidence و Unknown بسازید، Authority را از Contribution جدا کنید و Follow-up را تا Verification و Correction ببندید. این Interface احتمال گمشدن Context را قابلبررسی میکند؛ اما کیفیت، سرعت، هزینه، اعتماد، رضایت یا موفقیت پروژه را تضمین نمیکند.
