گذار یک تستر به محیط Agile با یادگیری چهار ابزار، حضور در همهٔ رویدادها یا تغییر عنوان به Quality Coach اثبات نمیشود. ممکن است فرد شش دوره و دو مدرک داشته باشد اما هنوز نداند کدام مهارت قبلی برای Work جدید قابل استفاده است، کدام باید Adapt شود، چه Capability واقعاً غایب است و آیا تمرین به رفتار کاری انتقال یافته یا نه.
این راهنما «تستر سنتی» و «تستر چابک» را دو هویت متضاد نمیسازد. یک Capability Translation & Transfer Contract میدهد: Work demand را مشاهده کنید؛ مهارت موجود را با Work sample بسنجید؛ دربارهٔ `REUSE / ADAPT / ADD / RETIRE` تصمیم بگیرید؛ Target behavior و Practice امن بسازید؛ Feedback بگیرید؛ و Transfer را در Task واقعی و محدود بررسی کنید. Course completion یا Tool count جای Transfer evidence را نمیگیرد.
مسیر کوتاه انتقال مهارت در هشت گام
| گام | پرسش | خروجی |
|---|---|---|
| Work | چه Task/Risk/Constraint واقعی تغییر کرده؟ | Work demand |
| Evidence | فرد اکنون چه رفتاری را نشان میدهد؟ | Current work sample |
| Translate | Reuse، Adapt، Add یا Retire؟ | Translation decision |
| Target | رفتار قابلمشاهدهٔ بعدی چیست؟ | Target behavior |
| Practice | چه تمرین امن و مشابهی لازم است؟ | Practice design |
| Feedback | با چه Rubric و از چه Capability؟ | Feedback record |
| Transfer | در کدام Task واقعی امتحان میشود؟ | Transfer evidence |
| Review | Keep/Adapt/Add/Stop/Retire؟ | Decision/Correction |
مسئله «سنتی در برابر چابک» نیست
| دوگانهٔ سطحی | سؤال Contextual |
|---|---|
| Waterfall دیر، Agile زود | Feedback برای این Risk کجا و با چه Artifact معنا دارد؟ |
| سنتی واکنشی، Agile پیشگیرانه | کدام prevention/detection/recovery evidence لازم است؟ |
| مستندات سنگین، گفتوگوی سبک | چه Memory/Trace/Authority برای این Work لازم است؟ |
| Manual قدیمی، Automation مدرن | کدام سؤال human judgment یا machine repetition میخواهد؟ |
| Gatekeeper بد، Coach خوب | چه Capability و Decision right در این Context لازم است؟ |
| Scripted محدود، Exploratory خلاق | چه Degree از پیشتعریف و یادگیری حین اجرا لازم است؟ |
مدل Sequential میتواند Review زودهنگام، Automation و Testing مستقل داشته باشد؛ تیم Agile نیز میتواند تست را تا پایان Sprint عقب بیندازد، مستندات بیفایده تولید کند یا QA gate بسازد. برچسب Process رفتار واقعی را اثبات نمیکند. ابتدا Flow، Decision، Risk و Evidence را مشاهده کنید.
منابع رسمی چه میگویند و چه نمیگویند؟
Agile Manifesto افراد و تعاملات، نرمافزار کارا، همکاری با مشتری و پاسخ به تغییر را نسبت به سوی دیگر ارزشمندتر میداند؛ اما صریحاً میگوید موارد سمت دیگر هم ارزش دارند. بنابراین «گفتوگو بهجای مستندات» یا «مستندات سبک همیشه بهتر است» برداشت دقیقی نیست.
اصول Agile همکاری روزانهٔ افراد Business و Development، ریتم پایدار، تعالی فنی، سادگی و بازاندیشی منظم را مطرح میکند. Tester، Automation tool، Test Pyramid، حضور در همهٔ جلسهها، Quality Coach یا شیوهٔ آموزش را تجویز نمیکند و آمادگی یک فرد خاص را اثبات نمیکند.
Scrum Guide 2020 Scrum Team را cross-functional و self-managing میداند؛ Tester عنوان رسمی Scrum نیست و افراد دارای تخصص تست که Increment میسازند در معنای Scrum جزو Developers هستند. Guide اجبار حضور فرد تست در هر رویداد، ترفیع به Coach یا تقسیم ثابت Unit/Integration/E2E را تعریف نمیکند.
ISTQB CTFL 4.0.1 Whole-team approach، Early testing، Test-first، Test pyramid، Testing quadrants و context-dependent استقلال تست را معرفی میکند؛ اینها technique/principle هستند، نه roadmap شغلی اجباری یا تضمین outcome. همان Syllabus تأکید میکند رویکرد تست به Context وابسته است.
مالکیت این مقاله: Capability Translation Contract
Product / Goal / Work Demand / Risk / Architecture / Test Strategy -> Existing Capability + Current Work Evidence -> REUSE | ADAPT | ADD | RETIRE -> Target Observable Behavior -> Safe Representative Practice -> Feedback / Rubric / Support -> Real Transfer Task -> Transfer Evidence + Limitation -> Keep | Adapt | Add | Stop | Retire | Correct
Translation Contract برای هر مهارت یا فرد یک نسخهٔ دائمی نمیسازد. یک رابطهٔ محدود بین Work demand و Capability است. مثلاً «طراحی State Transition» ممکن است از Test case مفصل به Model کوتاه در Refinement Adapt شود؛ خود مهارت تحلیل State منسوخ نشده است.
Baseline گذار را قفل کنید
| هویت | نمونهٔ ساختگی | اگر نباشد |
|---|---|---|
| Transition | TR-AGILE-19 | هدف مبهم |
| Product/Goal | SYN-CHECKOUT/PG-12 | مهارت نامرتبط |
| Sprint Goal | SG-20 | Task غیرواقعی |
| Work Demand | WORK-v5 | Gap حدسی |
| Risk Registry | RISK-v8 | اولویت Courseمحور |
| Architecture | ARCH-v4 | Tool/سطح نامناسب |
| Test Strategy | TEST-STRAT-v4 | Practice بیمصرف |
| Team Policy | TEAM-POL-v3 | Authority مبهم |
| Facts cutoff | ISO instant | Demand قدیمی |
capabilityTransitionBaseline: transition: TR-AGILE-19 product: SYN-CHECKOUT productGoal: PG-12 sprintGoal: SG-20 workDemand: WORK-v5 riskRegistry: RISK-v8 architecture: ARCH-v4 testStrategy: TEST-STRAT-v4 teamPolicy: TEAM-POL-v3 factsCutoff: 2026-08-13T06:00:00Z
از عنوان شغلی به Work Demand بروید
| Roadmap عنوانمحور | Demand کارمحور |
|---|---|
| تستر Agile باید کدنویسی بداند | Fixture callback نیاز به clock/seed control دارد |
| باید Automation یاد بگیرد | تکرار ۴۰ حالت stable به feedback سریع نیاز دارد |
| باید Coach شود | تیم برای Example workshop facilitator کم دارد |
| باید DevOps بداند | Evidence به Build/Run/Artifact وصل نیست |
| باید API تست کند | UI تنها مسیر مشاهدهٔ Rule نیست |
| باید Soft skill قوی کند | Findingها Observation و Ask روشن ندارند |
Demand باید Task، Trigger، Context، Constraint، Risk، Output و success/guardrail داشته باشد. «Agile tester competency» بیش از حد کلی است. اگر Work تغییر نکرده، Training ممکن است راهحل مسئلهٔ دیگری باشد یا صرفاً signaling شغلی تولید کند.
قالب Work Demand
workDemand: id: WD-1 source: WORK-v5 / RISK-v8#R3 task: model late and duplicate callback behavior trigger: during refinement before implementation choice locks context: checkout-api / stateful async flow constraints: no network; synthetic data; 45-minute feedback budget expectedOutput: bounded state model + quality questions currentFailure: examples omit retry ordering supportAvailable: domain + implementation + test-modeling transferMeasure: model obligations dispositioned guardrail: focus time and review load
Current capability را با Work sample بسنجید
خوداظهاری، سال سابقه، مدرک یا نظر Manager بهتنهایی نشان نمیدهد فرد در Context هدف چه رفتاری دارد. یک نمونهٔ موجود و رضایتمندانه از Work را بررسی کنید: Test design، Charter، Review، Model، Bug evidence، Script، Facilitated decision یا Investigation. اطلاعات شخصی/حساس را کمینه و دسترسی را محدود کنید.
| Evidence | میگوید | نمیگوید |
|---|---|---|
| Course completion | محتوا طی شده | Transfer به Work |
| Certificate | شرط آزمون/ارزیابی خاص | رفتار همهٔ Contextها |
| Tool demo | Task محدود اجرا شده | نگهداشت/انتخاب درست |
| Work sample | رفتار در Sample مشخص | توانایی جهانی |
| Peer feedback | Observation طبق Rubric | حقیقت شخصیت |
| Transfer task | کاربرد در Work نزدیک | Outcome بلندمدت/شغلی |
چهار تصمیم: REUSE، ADAPT، ADD، RETIRE
| تصمیم | معنا | نمونه |
|---|---|---|
| REUSE | همان قابلیت با تغییر ناچیز | Boundary analysis روی API rule |
| ADAPT | هسته مفید، Artifact/زمان/Context تازه | State model کوتاه در Refinement |
| ADD | Capability لازم و Evidence فعلی ناکافی | خواندن Trace correlation |
| RETIRE | رفتار/Artifact دیگر ارزش یا ایمنی ندارد | کپی دستی Result به Sheet موازی |
RETIRE دربارهٔ فرد نیست و پاککردن دانش هم نیست. ممکن است یک Template یا Handoff حذف شود ولی reasoning، traceability یا review skill آن reuse شود. ADD نیز لزوماً Course نمیخواهد؛ pairing، guided practice، documentation، simulation یا job aid میتواند بهتر باشد.
قالب Capability Translation
capabilityTranslation: id: CAP-19 demandRef: WD-1 existingCapability: state-transition test design currentEvidence: WORK-SAMPLE-STATE-v2 workSample: late/duplicate callback model classification: ADAPT rationale: same reasoning; smaller artifact and earlier feedback point targetBehavior: bounded state model + linked later countercheck practice: synthetic STATE-KATA-v3 feedback: STATE-RUBRIC-v2 / peer capability transferTask: INC-20 callback story transferEvidence: TRANSFER-EV-20 measure: model-obligation closure guardrail: focus time + review load supportOwner: test-modeling capability reviewDue: 2026-08-27T06:00:00Z
مهارتهای کلاسیک معمولاً دورریختنی نیستند
| قابلیت موجود | Translation محتمل | Artifact تازه |
|---|---|---|
| Equivalence/Boundary | REUSE/ADAPT | example/property/data partition |
| Decision table | REUSE | rule examples/contract obligations |
| State transition | ADAPT | model/invariant/replay |
| Test case writing | ADAPT | condition/charter/procedure/script برحسب نیاز |
| Traceability | ADAPT | Risk→Question→Evidence links |
| Defect investigation | REUSE/ADD | reproduction/evidence contract |
| Independent perspective | REUSE | risk-based countercheck |
| Domain knowledge | REUSE/UPDATE | examples/oracles/unknowns |
«Test caseهای دقیق در Agile از بین میروند» ادعای درستی نیست. Artifact را با Risk، تکرار، audit، transfer، volatility، skill و automation انتخاب کنید. راهنمای سناریو، Test case، Charter و Script سطح جزئیات را Contextual انتخاب میکند.
Target behavior باید قابلمشاهده باشد
| هدف مبهم | رفتار قابلمشاهده |
|---|---|
| Agile mindset داشته باشد | در WD-۱ Source/Question/Unknown را پیش از Lock تصمیم ثبت کند |
| همکارتر باشد | Request محدود با Evidence و موعد بفرستد |
| فنیتر شود | Build/Run/Trace identity را از Manifest استخراج کند |
| Automation یاد بگیرد | یک Check پایدار را با Oracle و CI result contract بسازد |
| Coach شود | یک Workshop را با objective/output/decision تسهیل کند |
| Exploratory بهتر شود | Charter/notes/coverage/learning/debrief بسازد |
Practice باید شبیه Work باشد، اما امنتر
- Task، Trigger و Constraint هدف را حفظ کنید.
- دادهٔ کاملاً ساختگی و محیط بدون دسترسی حساس بسازید.
- Difficulty را از ساده به نزدیک Work افزایش دهید.
- Rubric و Feedback deadline را پیش از تمرین بدهید.
- حق سؤال، تکرار، توقف و Accommodation را فراهم کنید.
- تمرین را Performance surveillance یا کار رایگان نکنید.
Tutorial دیدن، Quiz و Toy demo ممکن است Knowledge ایجاد کنند، اما Transfer فقط در Task مشابهتر دیده میشود. تمرین Production یا دادهٔ واقعی نیز لزوماً authenticتر نیست؛ میتواند ناامن، غیرمنصفانه و غیرقابلتکرار باشد.
Feedback را به Behavior و Rubric ببندید
| Feedback ضعیف | Feedback قابلاستفاده |
|---|---|
| هنوز Agile نیستی | State model دو transition دیررس را ندارد؛ Rubric M2 |
| بیشتر Technical شو | Evidence به Build/Run وصل نیست؛ identity field اضافه شود |
| Communication خوب نیست | Request سؤال و Due ندارد؛ C1/C3 |
| Automationت ضعیف است | Oracle و cleanup nondeterministicاند؛ A2/A5 |
| مثل Senior فکر کن | سه Unknown بدون disposition ماندهاند؛ R4 |
Feedback باید Observation، Context، اثر، Target و فرصت پاسخ داشته باشد. Personality label و مدل بلوغ مبهم، Repair را سخت میکند. Manager تنها منبع حقیقت نیست؛ capability peer، domain stakeholder، artifact evidence و self-reflection میتوانند perspectiveهای محدود و مکمل بدهند.
Transfer با Completion فرق دارد
| مرحله | Evidence | Claim limit |
|---|---|---|
| Exposure | منبع دیده شد | فهم/کاربرد معلوم نیست |
| Recall | Quiz/explanation | Work behavior نیست |
| Guided practice | Task با کمک | استقلال معلوم نیست |
| Independent practice | synthetic task | Work context محدود است |
| Near transfer | Task واقعی مشابه | Contextهای دیگر معلوم نیست |
| Sustained use | چند Task در زمان | Outcome/causality محدود |
چرخهٔ عمومی Gap→Source→Practice→Feedback→Transfer و تصمیم Keep/Adapt/Stop/Retire در راهنمای یادگیری مستمر تستر آمده است. این مقاله روی ترجمهٔ Capability موجود هنگام تغییر Operating model تمرکز دارد.
Agile Testing یک مجموعه رفتار است، نه شخصیت تازه
ممکن است Work جدید Feedback کوچکتر، مشارکت زودتر، Automation انتخابی، Evidence سریع، Adaptation و مسئولیت تیمی بیشتری بخواهد. اینها باید به Demandهای قابلمشاهده تبدیل شوند. راهنمای Agile Testing جریان عملی Story و Quadrantها را پوشش میدهد؛ «چابکبودن» را KPI شخصیتی نکنید.
حضور در همهٔ رویدادها مهارت نیست
Scrum Eventها هدف و participant/accountability دارند؛ ارزش تستر با دقیقههای جلسه سنجیده نمیشود. فرد دارای تخصص تست میتواند با Artifact async، Pair، Question، Evidence یا حضور هدفمند Contribution کند. نقش QA در Planning، Daily، Review و Retro مرز هر رویداد را بدون Gatekeeping توضیح میدهد.
Shift-left یعنی Skill را در هر جلسه تکرار نکنید
تحلیل Basis، Example design یا Testability ممکن است به نقطهٔ زودتری Adapt شود، اما هر Skill در چپترین نقطه ارزش ندارد. Security config، system interaction، usability و Production behavior Countercheck دیرتر میخواهند. Quality Interface در Shift-left earliest economical point را به Evidence دیرتر وصل میکند.
همکاری یک Capability قابلترجمه است
| مهارت موجود | Adaptation | Evidence |
|---|---|---|
| گزارش رسمی | Request/Update کوتاه و traceable | response/action closure |
| Triage جلسهای | Async pre-read + focused decision | Disposition record |
| Test handoff | Joint evidence construction | same-subject artifact |
| QA recommendation | option/trade-off/authority separation | decision record |
| Review checklist | criterion/finding/closure contract | review evidence |
راهنمای همکاری تستر و توسعهدهنده Request→Mode→Joint Evidence→Decision→Verification را تعریف میکند. «مهارت ارتباطی» را به حرفزدن بیشتر یا صفت برونگرایی تقلیل ندهید.
Automation Capability از Tool name شروع نمیشود
| Demand | Capability | Tool-independent behavior |
|---|---|---|
| Feedback تکرارشونده | Check design | Subject/trigger/oracle/result |
| State control | Fixture engineering | seed/clock/reset/isolation |
| CI reliability | Execution engineering | determinism/retry/timeout/artifact |
| Diagnosis | Evidence literacy | Build/Run/trace/log correlation |
| Maintenance | Change design | abstraction/ownership/deletion |
| Selection | Risk economics | value/latency/cost/unknown |
Selenium، Cypress یا Playwright میتوانند در Context وب مفید باشند، اما «اولین Skill Agile» نیستند. ابتدا Task و System interface را مشخص کنید؛ سپس کوچکترین Stack قابلاثبات را انتخاب کنید. Manual regression هم فقط وقتی Automate/Retire میشود که value، repeatability، oracle، change rate، maintenance، coverage و alternatives توجیه کنند.
Test Pyramid نقشهٔ سازمانی و شغلی نیست
Pyramid یک heuristic برای فکرکردن به ترکیب Checkهاست، نه درصد جهانی یا تقسیم Unit به Developer و UI به Tester. Architecture، Risk، testability، feedback deadline، maintenance و confidence shape را تغییر میدهند. Capability ترجمهشده باید بتواند trade-off را توضیح دهد؛ حفظ شکل مثلث هدف یادگیری نیست.
Exploratory و Scripted دو دشمن نیستند
Exploratory testing یادگیری، طراحی و اجرا را بهشکل درهمتنیده انجام میدهد، اما میتواند Charter، notes، data، coverage outline و debrief داشته باشد. Scripted testing هم میتواند judgment و adaptation بخواهد. تیم میتواند از Script به Exploration و دوباره به Check پایدار حرکت کند. خلاقیت یا «هوش» را صفت انحصاری یک Technique نکنید.
BDD و Gherkin مهارت مستقل از معنا نیستند
تبدیل Test case به Given/When/Then بهتنهایی Adaptation نیست. فرد باید Rule، Example، Counterexample، Source، Oracle، Unknown و Automation boundary را بفهمد. راهنمای Gherkin در BDD Syntax را به Discovery و Example Mapping وصل میکند؛ Scenario count سنجهٔ انتقال نیست.
Quality Coach مقصد اجباری نیست
Coaching، facilitation، test modeling، automation، performance، security، accessibility، data یا exploration مسیرهای capability متفاوتاند. تغییر Operating model فرد را خودکار به Coach/Consultant/Strategic partner ترفیع نمیدهد. عنوان بدون mandate، skill evidence، time و authority میتواند کار پنهان و accountability مبهم بسازد.
کیفیت هم مسئولیت مشترک است اما هر Decision و Risk owner لازم دارد؛ مدل رهبری QA بدون ابهام مانع تبدیل «توانمندسازی» به QA gate یا مسئولیت بیاختیار میشود.
تستر صدای مشتری نیست
تستر میتواند از User model، research، analytics، support evidence، accessibility perspective و domain knowledge برای پرسش استفاده کند؛ اما نمایندهٔ خودکار کاربران متنوع نیست. «صدای مشتری» بدون Source ممکن است projection باشد. Capability هدف باید پرسیدن و حفظ Unknown را تقویت کند، نه ادعای نمایندگی.
مهارتهای نرم را به رفتارهای کاری ترجمه کنید
| برچسب مبهم | رفتار قابلتمرین | Evidence |
|---|---|---|
| Communication | Observation/Impact/Ask/Due | actionable update |
| Collaboration | Context/request/joint output | closed interface |
| Negotiation | options/trade-offs/authority | agreement record |
| Critical thinking | source/assumption/counterexample | revised decision |
| Adaptability | signal→hypothesis→small change | experiment review |
| Empathy | perspective inquiry/consent | not personality score |
سازمان باید شرایط Transfer را بسازد
- زمان یادگیری و Practice در Workload واقعی باشد.
- Tool، Sandbox، Documentation و mentor/peer feedback در دسترس باشد.
- Task انتقالی محدود و Failure آن recoverable باشد.
- Manager از رفتار تازه در Flow حمایت کند، نه فقط Course بخواهد.
- Accommodation، Accessibility و روشهای مختلف مشارکت فراهم شود.
- هدف یادگیری از Performance rating و redundancy decision جدا بماند.
اگر صف، Role boundary، access، architecture یا incentive اجازهٔ رفتار تازه نمیدهد، نبود Transfer صرفاً «مقاومت فرد» نیست. Training نمیتواند Constraint سازمانی را پنهان کند. Improvement باید هم capability و هم system condition را بررسی کند.
رضایت، عدالت و مرز کار
| ریسک | کنترل |
|---|---|
| یادگیری خارج ساعات بدون جبران | time/budget/compensation policy |
| اجبار به مسیر شغلی واحد | choice/alternative/appeal |
| ارزیابی با دادهٔ حساس Work | consent/minimization/access/retention |
| سوگیری Manager | rubric/multiple evidence/right of response |
| مانع دسترسی | caption/text/keyboard/pacing/accommodation |
| رتبهبندی با مدرک/ابزار | system learning; no leaderboard |
| Practice بهعنوان کار رایگان Production | explicit labor boundary |
Evidence انتقال را امن نگه دارید
Work sample ممکن است Code، Log، Screenshot، customer data، chat یا review history داشته باشد. برای Learning record فقط بخش لازم، synthetic substitute، redaction، access، retention و deletion را نگه دارید. Evidence نباید مخزن دائمی surveillance یا پروندهٔ پنهان Performance شود. Correction و حق پاسخ باید وجود داشته باشد.
اندازهگیری بدون Goodhart و رتبهبندی
| Metric | تعریف | Guardrail |
|---|---|---|
| Demand coverage | translated / eligible demands | fake decomposition |
| Practice feedback age | attempt→actionable feedback | review load |
| Near transfer | evidenced / eligible tasks | task difficulty/context |
| Sustained use | valid repeats over time | forced use |
| Support latency | ask→available help | dependency creation |
| Retire benefit | removed waste/eligible | lost necessary trace |
| Equity | access/time/support distribution | privacy/small groups |
Course count، certificate count، tool count، line of automation، جلسه، Story point یا Bug found شایستگی یا Transfer را ثابت نمیکند. افراد را با این اعداد رتبهبندی، تهدید یا پاداش ندهید. Metric برای یافتن Constraint و اصلاح سیستم است.
AI در ترجمهٔ مهارت: Candidate، نه قاضی آمادگی
AI میتواند Work demand را خوشهبندی، Practice candidate یا feedback prompt پیشنهاد و Artifact را با Rubric مقایسه کند. Source/version، input classification، model/version، output digest و reviewer را ثبت کنید. مدل نباید شخصیت، Agile mindset، استعداد، ارتقا، اخراج، حقوق، readiness یا ارزش فرد را تعیین کند؛ Work sample حساس و PII/Secret را بدون مجوز دریافت نکند.
آزمایش تکرارپذیر: شش دوره و چهار ابزار کافیاند؟
یک Fixture کاملاً ساختگی و بدون dependency با Node.js ۲۴.۱۸.۰ اجرا شد. سنجهٔ سطحی شش Course، چهار Tool و دو Certificate را دید و نتیجهٔ READY داد. Validator قراردادی Baseline، Work demand، Translation، Practice، Feedback، Transfer، governance و improvement را بررسی کرد.
خروجی Validator: ۶۰ Finding
fixture: SYN-TESTER-CAPABILITY-TRANSLATION-01 runtime: Node.js v24.18.0 superficial: READY | courses=6 | tools=4 | certificates=2 auditedDraft: HOLD findings (60): 1 stale-transition:TR-AGILE-17->TR-AGILE-19 2 stale-product:SYN-CART->SYN-CHECKOUT 3 stale-productGoal:PG-10->PG-12 4 stale-sprintGoal:SG-18->SG-20 5 stale-workDemand:WORK-v2->WORK-v5 6 stale-riskRegistry:RISK-v5->RISK-v8 7 stale-architecture:ARCH-v2->ARCH-v4 8 stale-testStrategy:TEST-STRAT-v2->TEST-STRAT-v4 9 stale-teamPolicy:TEAM-POL-v1->TEAM-POL-v3 10 stale-factsCutoff:2026-06-01T00:00:00Z->2026-08-13T06:00:00Z 11 duplicate-capability:CAP-1 12 unknown-work-demand:WD-99 13 CAP-1-current-evidence-missing 14 CAP-1-work-sample-missing 15 CAP-1-classification-invalid 16 CAP-1-rationale-missing 17 CAP-1-target-behavior-missing 18 CAP-1-practice-missing 19 CAP-1-feedback-missing 20 CAP-1-transfer-task-missing 21 CAP-1-transfer-evidence-missing 22 CAP-1-measure-missing 23 CAP-1-guardrail-missing 24 CAP-1-support-owner-missing 25 CAP-1-review-due-missing 26 traditional-testing-caricature 27 agile-testing-universalized 28 traditional-documentation-caricature 29 agile-documentation-universalized 30 automation-misrepresented-as-mandatory 31 all-ceremonies-attendance-prescribed 32 exploratory-scripted-false-opposition 33 quality-coach-promotion-universalized 34 tester-claims-customer-voice 35 manual-regression-removal-prescribed 36 popular-ui-tool-first 37 test-pyramid-universalized 38 bug-prevention-guarantee 39 learning-completion-as-transfer 40 target-capability-fixed-by-title 41 unpaid-learning-expectation 42 forced-learning-or-ceremony-participation 43 unsafe-work-data-in-practice 44 learning-accessibility-missing 45 manager-opinion-as-readiness-proof 46 people-ranked-by-course-tool-count 47 organization-support-missing 48 learning-time-budget-missing 49 tool-access-missing 50 mentor-or-feedback-access-missing 51 informed-consent-missing 52 learning-evidence-retention-missing 53 readiness-appeal-path-missing 54 accommodation-path-missing 55 learning-labor-boundary-missing 56 career-speed-quality-guarantee 57 improvement-baseline-missing 58 improvement-measure-missing 59 improvement-guardrail-missing 60 correction-path-missing corrected: READY_FOR_TRANSFER_REVIEW | findings=0
نسخهٔ اصلاحی چه کرد؟
نسخهٔ اصلاحی Transition/Product/Goals/WORK-v5/RISK-v8/ARCH-v4/TEST-STRAT-v4/TEAM-POL-v3/Cutoff را جاری کرد؛ یک Work demand معتبر ساخت؛ State-transition design موجود را با Work sample به `ADAPT` طبقهبندی کرد؛ Target behavior، synthetic Practice، peer Rubric، Task واقعی INC-۲۰، Transfer evidence، Measure/Guardrail، Support owner و Review due افزود؛ دوگانههای Agile/سنتی و نسخههای Automation/Pairing/Coach را حذف کرد؛ و زمان/دسترسی/رضایت/Retention/Appeal/Accommodation/Labor boundary را ثبت کرد.
`READY_FOR_TRANSFER_REVIEW` فقط کاملبودن ساختار را میگوید. مهارت واقعی فرد، کیفیت Work sample، صحت Feedback، انتقال پایدار، آمادگی نقش، ارتقا، حقوق، استخدام، سرعت تیم، کیفیت محصول، جلوگیری از Bug، رضایت مشتری یا موفقیت Agile را ثابت نمیکند.
آزمایشگاه فارسی و آفلاین Capability
Lab یک Checkout خیالی بدون شبکه است: Order، PaymentAttempt، PSP Stub، Callback، Ledger و Reconciliation. افراد واقعی ارزیابی نمیشوند؛ `learner-۱۹` فقط شناسهٔ ساختگی است. Taskها دربارهٔ duplicate/late/reordered callback، timeout، tenant و Evidence identity هستند.
| Demand | Existing capability | Translation | Transfer task |
|---|---|---|---|
| stateful callback | state transition design | ADAPT | bounded model |
| repeated stable checks | manual procedure | ADAPT/ADD | deterministic fixture |
| evidence correlation | bug investigation | ADAPT | Build/Run/Trace manifest |
| early rule feedback | decision table | REUSE | example workshop |
| duplicate reporting | parallel spreadsheet | RETIRE | single registry |
- 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 واقعی وجود ندارد.
- هیچ ادعای بانکی، مالی، حقوقی، مالیاتی، امنیتی، حریم خصوصی یا بازار کار ایران ساخته نمیشود.
۳۰ ضدالگوی گذار مهارت تستر
- Waterfall همیشه دیر/بد
- Agile همیشه مستمر/خوب
- سنتی فقط کشف، Agile فقط پیشگیری
- مستندات سنتی همیشه سنگین
- Agile یعنی مستندات سبک یا صفر
- عنوان Agile Tester بهعنوان شخصیت
- حضور در همهٔ رویدادها
- Shift-left در هر نقطه
- Automation الزام همهٔ تسترها
- UI tool بهعنوان شروع جهانی
- Manual regression باید حذف شود
- Pyramid بهعنوان درصد ثابت
- Unit فقط Developer، E2E فقط QA
- Exploratory نقطهٔ مقابل Scripted
- Exploratory همیشه Bug پیچیده مییابد
- Gherkin برابر Adaptation
- Quality Coach مقصد همه
- تستر صدای مشتری
- Soft skill بهعنوان صفت شخصیت
- سال سابقه برابر Capability
- Certificate برابر Readiness
- Course completion برابر Transfer
- Tool count برابر مهارت
- Manager opinion برابر Evidence
- Training برای Constraint سازمانی
- یادگیری اجباری خارج ساعات
- Practice با دادهٔ واقعی حساس
- رتبهبندی افراد با سنجهها
- AI بهعنوان قاضی استعداد/آمادگی
- تضمین career/speed/quality/bug prevention
Pilot سیروزهٔ Capability Translation
| بازه | کار | Exit محدود |
|---|---|---|
| روز ۱–۳ | سه Work demand و Baseline | demand records |
| روز ۴–۷ | Work samples رضایتمندانه | current evidence |
| روز ۸–۱۰ | Reuse/Adapt/Add/Retire | translation decisions |
| روز ۱۱–۱۵ | Target/Practice/Rubric | safe attempts |
| روز ۱۶–۲۰ | Feedback/repair/retry | practice evidence |
| روز ۲۱–۲۵ | Near-transfer Task | transfer evidence |
| روز ۲۶–۳۰ | Guardrail/equity/review | Keep/Adapt/Stop |
Pilot موفق یعنی یک Capability در یک Task نزدیک با Evidence مشاهده شده یا فرض Gap اصلاح شده است؛ نه اینکه فرد «Agile شده»، ارتقا گرفته یا کیفیت تیم بالا رفته باشد. اگر Practice یا Review به Workload، عدالت یا تمرکز آسیب میزند، Scope و Support را Adapt کنید.
چکلیست Audit انتقال مهارت
- Transition/Product/Goals/Work/Risk/Architecture/Strategy/Policy/Cutoff جاریاند.
- Work demand به Task/Trigger/Context/Constraint/Output وصل است.
- Gap از عنوان شغلی یا Trend ابزار نیامده است.
- Current capability با Work sample محدود و رضایتمندانه سنجیده شده است.
- Classification یکی از REUSE/ADAPT/ADD/RETIRE و دارای rationale است.
- Target behavior قابلمشاهده و Context-bound است.
- Practice به Work شبیه، synthetic و recoverable است.
- Rubric، Feedback source، right of response و retry روشناند.
- Transfer task واقعی اما محدود و پشتیبانیشده است.
- Transfer evidence محدودیت و Unknown دارد.
- Course/Certificate/Tool count جای Transfer نیست.
- Automation/Pairing/Ceremony/Coach/Pyramid اجباری نشدهاند.
- Exploratory، Scripted، Manual و Automated Contextualاند.
- مسیرهای تخصصی متنوع حفظ شدهاند.
- زمان، Tool، Sandbox، mentor و organizational support وجود دارد.
- یادگیری جبرانشده و از کار رایگان جداست.
- Consent، access، retention، appeal و accommodation روشناند.
- Metric افراد را رتبهبندی نمیکند.
- AI فقط Candidate و تحت review است.
- Correction و Keep/Adapt/Add/Stop/Retire وجود دارد.
- نتیجه career/readiness/speed/quality/success guarantee نمیسازد.
پرسشهای متداول
آیا مهارتهای تست سنتی در Agile منسوخ میشوند؟
معمولاً نه بهصورت کلی. Boundary، state، decision table، domain، investigation و independent perspective میتوانند Reuse یا Adapt شوند. Artifact، timing و collaboration mode ممکن است عوض شود. فقط رفتار یا خروجیای را Retire کنید که در Work فعلی ارزش/ایمنی ندارد.
آیا هر تستر Agile باید Automation بلد باشد؟
هیچ الزام جهانی وجود ندارد. Work demand ممکن است Check design، Fixture، CI، API، UI، Evidence یا هیچ کدنویسی مستقیمی بخواهد. Capability لازم را از Product/Risk/Architecture و Team skills بگیرید. آشنایی فنی میتواند مفید باشد، اما Tool name یا line count معیار آمادگی نیست.
برای گذار به Agile از کدام ابزار شروع کنیم؟
از ابزار شروع نکنید. یک Task پرتکرار یا feedback delay واقعی را مشخص کنید، Capability و interface لازم را بنویسید، سپس کوچکترین Practice و Stack مناسب را آزمایش کنید. ممکن است راهحل یک State model، API client، Test harness، query، checklist یا گفتوگوی بهتر باشد.
آیا تستر باید در همهٔ رویدادهای Scrum شرکت کند؟
خیر. Accountabilities و هدف هر Event را رعایت کنید و contribution را بر اساس Risk/Question/Output انتخاب کنید. حضور، async pre-read، Pair یا Artifact هرکدام میتوانند مناسب باشند. Attendance count مهارت یا همکاری را نشان نمیدهد و حضور بیهدف context switching میسازد.
چگونه بفهمیم یادگیری به کار منتقل شده است؟
Target behavior را در یک Near-transfer Task واقعی و محدود با Source، Work sample، Rubric و Feedback مشاهده کنید. یک بار موفقیت ادعای جهانی نمیسازد؛ تکرار، Context و Support را نگه دارید. Course یا مدرک Exposure/assessment خاص است، نه Transfer خودکار.
جمعبندی: مهارت را ترجمه کنید، هویت را تعویض نکنید
گذار به Agile پروژهٔ حذف «تستر سنتی» و ساخت Quality Coach نیست. Work demand جاری را pin کنید، Capability موجود را با Evidence ببینید، دربارهٔ Reuse/Adapt/Add/Retire تصمیم بگیرید، Target behavior و Practice امن بسازید، Feedback و Support بدهید و Transfer را در Task نزدیک بررسی کنید. سازمان باید زمان، دسترسی، عدالت و حق پاسخ را فراهم کند. این Contract یادگیری را قابلبررسی میکند؛ آمادگی شغلی، ارتقا، سرعت، کیفیت یا موفقیت را تضمین نمیکند.
