تفاوت Test Lead و QA Manager را نمیتوان با «اولی تاکتیکی، دومی استراتژیک» برای همهٔ سازمانها تعیین کرد. عنوانها محلیاند: یک QA Lead ممکن است People Manager باشد، یک Test Manager ممکن است بدون Direct report یک برنامهٔ آزمون پرریسک را اداره کند، و در تیم Product کوچک ممکن است هیچکدام از این عنوانها وجود نداشته باشد اما همهٔ مسئولیتهای لازم میان اعضا توزیع شده باشد. برعکس، داشتن هر دو عنوان بدون مرز اختیار میتواند تصمیم را کند و پاسخگویی را مبهم کند.
این راهنما یک QA Role Boundary & Span Contract میسازد: Context و Purpose را ثبت میکند؛ Role را از Position/Person/Title جدا میکند؛ Responsibility، Accountability، Authority و No-authority را دقیق مینویسد؛ Decision right، Interface، Handoff، Span، Capacity، Evidence و Conflict را طراحی میکند؛ و بعد تصمیم میگیرد مسئولیتها در یک نقش ترکیب، میان چند نقش تفکیک یا به تیمهای Product توزیع شوند. هدف تجویز چارت، حقوق، استخدام یا موفقیت سازمانی نیست؛ هدف حذف Gap، Overlap و اختیار بیپاسخ است.
پاسخ کوتاه: فرق سرپرست تست و مدیر QA چیست؟
در یک الگوی رایج، Test Lead جریان آزمون و Evidence یک Product/Release/Program محدود را هماهنگ میکند؛ QA Manager قابلیت، افراد، سرمایهگذاری و Governance را در Span بزرگتر اداره میکند. اما این فقط الگوی شروع است. تعریف معتبر باید بگوید هر نقش برای کدام Outcome و Risk، در چه Scope و Horizon، با چه Work product و Decision authority پاسخگو است. عنوان بهتنهایی نمیگوید چه کسی Test Plan، Release recommendation، بودجه، Hiring، Performance، Standard یا پذیرش Residual risk را مالک است.
| پرسش | Test Lead نمونه | QA Manager نمونه | قاعده |
|---|---|---|---|
| Scope | یک Product/Release/Program | چند تیم/Practice/Capability | محلی و نسخهدار |
| Outcome | Evidence تصمیم بهموقع | قابلیت پایدار و ظرفیت مناسب | تضمین کیفیت نیست |
| Work | Risk plan، coordination، status، closure | operating model، people، budget، standards | میتواند همپوشان باشد |
| Authority | مثلاً اولویت کار تست | مثلاً تخصیص ظرفیت/بودجه | از Title استنتاج نشود |
| Horizon | Release تا چند فصل | فصل تا چندسال | دوگانهٔ ثابت نیست |
| People management | ممکن/ناممکن | اغلب، نه همیشه | صریح نوشته شود |
مرز این مقاله با نقش مهندس، مدیر Agile و مدل عملیاتی
راهنمای Role & Capability مهندس QA نقش Contributor و Work productهای آن را طراحی میکند. راهنمای مدیر QA در Agile Mandate و Enablement/Assurance/Delegation همان نقش را عمیق میکند. مدل عملیاتی QA انتخاب Centralized/Embedded/Federated و Service contract را پوشش میدهد. این صفحه مالک مرز میان دو خوشهٔ مسئولیت Lead/Manager و تصمیم ترکیب یا تفکیک آنهاست.
Title، Role، Position و Person را جدا کنید
Role مجموعهٔ Outcome/Accountability/Authority در Context است. Position جایگاه مصوبی است که یک یا چند Role را حمل میکند. Person فردی است که Position را برای بازهای بر عهده دارد. Title برچسب بازار/HR است. یک Person میتواند موقتاً دو Role داشته باشد؛ یک Role میتواند میان چند Position توزیع شود؛ و دو شرکت با Title یکسان Contract متفاوت دارند. آگهی یا رزومه را از روی Title مقایسه نکنید.
| Object | شناسه نمونه | تغییر مستقل | نباید فرض شود |
|---|---|---|---|
| Role | ROLE-TEST-LEAD-v4 | Scope/authority | شغل تماموقت |
| Position | POS-QA-07 | Grade/reporting line | یک Role فقط |
| Person | synthetic-holder-A | assignment/leave | Capability دائمی |
| Title | QA Lead | market/HR naming | Decision right |
| Work assignment | RELEASE-R8 | timebox/capacity | تغییر Position |
Context را پیش از مقایسهٔ نقشها ثبت کنید
Product/Service، Risk class، lifecycle، cadence، architecture، team topology، demand، تعداد جریانهای همزمان، third party، regulation، independence، timezone/locale، sourcing، maturity، budget horizon و constraints شکل نقش را عوض میکند. Test Lead در مهاجرت بانکی چندسامانهای با Lead یک اپ کوچک یک Role یکسان ندارد؛ QA Manager یک Practice مستقل با Manager مهندسهای Embedded در Productها نیز یکسان نیست.
RoleContext context_id/version: CTX-QA-07/v3 product/service: SYN-CHECKOUT (fictional) risk/cadence: payment-like simulation; weekly candidate builds topology: two product teams + shared automation platform demand: three work classes; arrival/seasonality recorded constraints: UTC handoff; Asia/Tehran display; offline lab independence_need: targeted review, not universal separation non_claimed: real organization, banking, legal compliance, success
از Purpose، Outcome و Non-outcome شروع کنید
Role برای پرکردن Box سازمانی نیست. Purpose میگوید چرا وجود دارد؛ Outcome تغییر قابلمشاهدهای است که باید به آن کمک کند؛ Non-outcome وعدهٔ ناممکن را حذف میکند. Test Lead ممکن است «هماهنگکردن Risk-to-Evidence در Window انتشار» را Purpose داشته باشد. QA Manager ممکن است «تأمین قابلیت آزمون پایدار و تصمیمپذیر در چند تیم» را دنبال کند. هیچکدام بهتنهایی Product بینقص، Release موفق، رضایت کاربر یا ROI را تضمین نمیکنند.
RolePurpose role_id: ROLE-TEST-LEAD-v4 purpose: keep risk, test work, evidence and release interface coherent outcomes: explicit risk gaps; timely evidence packet; owned deviations non_outcomes: no-defects, full coverage, release approval, team productivity beneficiaries: product/delivery/risk decision makers horizon: RELEASE-R8 through closure/correction review_due: on topology, risk, demand or authority change
Responsibility، Accountability و Authority یکی نیستند
Responsibility انجام یا هماهنگی کار است؛ Accountability پاسخگویی نهایی برای یک Outcome/Decision مشخص؛ Authority حق تصمیم/تخصیص/توقف در Boundary؛ و Contribution کمک تخصصی بدون مالکیت نهایی. RACI ساده ممکن است چند «A» یا واژههای مبهم بسازد؛ برای هر تصمیم، یک Accountable authority، Evidence provider، Consulted role، affected parties و Escalation تعریف کنید.
| موضوع | Responsibility ممکن | Accountability ممکن | Authority لازم |
|---|---|---|---|
| Test approach Release | Test Lead + contributors | Test Lead/Program owner | تغییر scope در budget |
| Residual risk | Lead شواهد میدهد | Product/Service owner | پذیرش/رد ریسک |
| Capability investment | QA Manager case میسازد | Budget owner | اختصاص سرمایه |
| Performance review | Manager evidence/feedback | Line manager/HR process | تصمیم رسمی محدود |
| Security exception | QA یافته را ثبت میکند | Security/Risk authority | استثنا/انقضا |
No-authority از Authority مهمتر است
Role Charter باید صریحاً بگوید چه کاری مجاز نیست: Test Lead شاید نتواند Feature scope، موعد Release، استخدام/اخراج یا پذیرش ریسک حقوقی را یکجانبه تعیین کند. QA Manager شاید نتواند روش کار Product team، معماری، Outcome یا Gate را بدون مالک مربوط تحمیل کند. «توصیهٔ توقف» با «اختیار توقف» فرق دارد؛ «Sign-off شواهد» با «قبول Residual risk» یکی نیست.
DecisionRight decision_id: DEC-RELEASE-EVIDENCE-04 question: is the evidence packet complete against agreed minimum? accountable: Test Lead may: request evidence; mark gap; recommend pause; escalate may_not: accept product/security/legal risk; set business release date evidence_minimum: versioned risk/evidence/deviation/unknown packet fallback: Product owner + Risk authority decide with explicit gap audit/correction: preserve dissent and superseded decision
Test Lead را با Work package تعریف کنید
Test Lead نمونه میتواند برای یک Product/Release/Program، Context را روشن، Riskها را به Strategy/Plan/Evidence وصل، تقاضا و ظرفیت را هماهنگ، Readiness و Environment/Data dependency را آشکار، Execution/Defect/Evidence flow را دنبال، Deviation/Unknown را Escalate و Closure/Learning را تحویل دهد. Control Loop استراتژی، برنامه و خلاصهٔ تست Work productهای این جریان را توضیح میدهد. طراحی Test Case یا اجرای همهٔ تستها الزام Role نیست.
| Work package | Work product | Evidence پذیرش | Claim limit |
|---|---|---|---|
| Risk alignment | Risk→Test→Evidence map | owner/version/gap | ریسک را حذف نمیکند |
| Planning | Test Plan/deviation log | scope/budget/dependency | واقعیت را تضمین نمیکند |
| Coordination | queue/owner/handoff board | ack/age/escalation | بهرهوری فرد نیست |
| Status | decision-oriented report | fresh result/unknown | Release approval نیست |
| Closure | summary/correction/learning | traceable disposition | موفقیت Product نیست |
QA Manager را با Capability system تعریف کنید
QA Manager نمونه میتواند Demand و Capability gap را ببیند؛ Operating model و Service boundaries را طراحی؛ People/skills/capacity/budget/supplier/tool/platform را اداره؛ Standardهای حداقلی و Exception mechanism را نگه دارد؛ cross-team risk/evidence را تجمیع؛ مدیران و تیمها را Enable کند؛ و Sustainability/continuity/correction را پاسخ دهد. این Role الزاماً «معمار کل کیفیت»، مالک همهٔ Processها یا نمایندهٔ انحصاری کیفیت نیست.
CapabilityResponsibility capability_id: CAP-TEST-EVIDENCE-v5 demand/population: defined work classes across named products service: consult | enable | embedded | independent review | platform outcome: needed evidence capability available within agreed boundaries inputs/outputs: request contract → accepted work product/evidence capacity/SLO: ranges, queue policy, WIP and escalation owner/backup: named roles; no “QA department” placeholder not_responsible: product outcome, all testing, universal release gate
تاکتیکی و استراتژیک یک طیفاند، نه دو صندوق
Test Lead میتواند تصمیم استراتژیک دربارهٔ testability یا evidence architecture پیشنهاد دهد؛ QA Manager نیز در Incident یا Hiring به کار عملیاتی وارد شود. تمایز مفیدتر بر اساس Decision scope، consequence، time horizon، recurrence، number of teams، capital/people impact و reversibility است. «Lead همیشه چگونه» و «Manager همیشه چرا/چه» واقعیت را مخدوش میکند.
| Dimension | Local delivery end | Capability/organization end |
|---|---|---|
| Population | یک Release/flow | چند Product/Practice |
| Horizon | روز/هفته/فصل | فصل/سال |
| Consequence | Evidence gap/queue | capacity/cost/people/system |
| Decision | reversible sequencing | structural investment |
| Interface | Delivery/Product/Engineering | Leadership/HR/Finance/Supplier |
| Cadence | continuous/release | portfolio/workforce/budget |
مقایسهٔ عملی در ۱۶ بُعد
| بعد | Test Lead ممکن | QA Manager ممکن | باید Contract شود |
|---|---|---|---|
| Purpose | coherent delivery evidence | sustainable capability | بله |
| Scope | Product/Release | multiple teams/practice | بله |
| Risk | identify/communicate | govern/escalate system gaps | acceptance authority جدا |
| Plan | test work/deviation | capability/portfolio | نسخه و horizon |
| Execution | coordinate/occasionally contribute | rarely default executor | capacity allocation |
| People | task lead/mentor ممکن | line management ممکن | HR authority |
| Capability | local gaps | cross-team system | make/buy/learn |
| Budget | estimate/use | case/allocate ممکن | budget owner |
| Supplier | delivery interface | commercial/service governance | contract authority |
| Metrics | decision packet | system trends/countermetrics | no people score |
| Standards | apply/adapt/escalate | minimum/exception/review | local autonomy |
| Release | evidence recommendation | portfolio escalation | release owner |
| Independence | review role ممکن | design assurance model | risk-based |
| Hiring | technical evidence | workforce process ممکن | fair authority |
| Career | leadership without management | people/capability path | parallel tracks |
| Success | bounded outcome evidence | capability evidence | not product success |
چه زمانی نقشها را ترکیب کنیم؟
ترکیب وقتی قابلدفاع است که Demand و Span محدود، تصمیمها همزمانپذیر، تعارض اختیار کنترلشده، Capability موجود، People load کم، Backup حاضر و Evidence service قابلحفظ باشد. «شرکت کوچک است» کافی نیست؛ یک تیم کوچک با Risk بالا، چند Vendor یا Incident load ممکن است تفکیک یا حمایت تخصصی بخواهد. ترکیب را timeboxed و capacity-aware کنید، نه اینکه یک نفر دو شغل نامحدود بگیرد.
CombinedRoleDecision position: POS-QA-LEAD-MGR-01 roles: ROLE-TEST-LEAD-v4 + ROLE-QA-MANAGER-v3 eligible_scope: one product; one active release; six people (fictional) capacity_split: delivery / people / capability / contingency conflicts: self-review, task urgency vs development, leave coverage controls: delegated evidence review; HR calibration; backup; WIP limits expiry/review: 60 days or second-team/incident/demand trigger exit: split responsibilities before named thresholds are exceeded
چه زمانی تفکیک لازم میشود؟
- چند Product/Release همزمان و Context switching مزمن؛
- People management، hiring، performance و care بار قابلتوجه دارد؛
- Capability/platform/budget/supplier تصمیمهای پایدار میخواهد؛
- استقلال Review با مالک Delivery تعارض دارد؛
- Lead در Queue روزانه غرق و Manager از Evidence واقعی دور میشود؛
- Span باعث تأخیر در ۱:۱، feedback، risk escalation یا decision میشود؛
- Bus factor یک و absence بدون fallback است؛
- یک Position هم درخواست، اجرا، ارزیابی و قبول Risk را کنترل میکند.
تفکیک لزوماً ساخت دو لایهٔ مدیریتی نیست. میتوان Delivery Test Lead چرخشی، Capability Lead بدون Direct report، QA Manager مشترک، Embedded quality engineer، Platform owner یا Independent reviewer داشت. Structure را از Demand/Interface/Risk بسازید، نه از Org-chart استاندارد.
Span را با Headcount تنها نسنجید
Span تابع تعداد افراد نیست؛ تعداد تیم/محصول/جریان، تنوع Skill، Risk، location/timezone، seniority، onboarding، vendor، interrupt، people-case، hiring، change rate و coordination dependency هم اثر دارد. عدد جادویی برای Direct report یا تیمهای تحت پوشش وجود ندارد. Service load و management load را جدا و Queue/age/missed obligations را مشاهده کنید.
| Load | Demand unit | Evidence | Failure signal |
|---|---|---|---|
| Delivery lead | release/risk/change | queue/touch/blocked/age | unknown دیرهنگام |
| People | 1:1/growth/case/hiring | due/quality/follow-up | لغو/تأخیر/بیپشتیبانی |
| Capability | service/request/gap | SLO/adoption/owner | shadow process |
| Governance | risk/exception/review | expiry/escalation | auto-renew/تجمع |
| Interrupt | incident/escalation | arrival/time/recovery | کار برنامهای displaced |
Demand، Capacity و WIP را در Role Contract بیاورید
Role نامحدود با جملهٔ «هر کاری برای کیفیت لازم است» قابلاجرا نیست. Work class، arrival، service expectation، priority rule، WIP، reserved capacity، expedite policy و displaced work را تعریف کنید. Task leadership، people care، capability investment و incident support از یک ظرفیت مصرف میکنند. اضافهشدن مسئولیت باید حذف/تفویض کار دیگر یا افزایش ظرفیت داشته باشد.
RoleCapacity role/period: ROLE-QA-MANAGER-v3 / 2026-Q3 work_classes: people, capability, governance, supplier, interrupt demand: arrival ranges by class; no fabricated precision capacity: available ranges minus leave/meetings/operations WIP/priority: explicit; expedite with authority and displaced item service_expectation: acknowledgement/decision windows by class overload_signal: queue age + missed obligation + recovery debt action: reduce scope | delegate | add support | change service level
Interface و Handoff را مانند API طراحی کنید
مرز Lead/Manager اغلب نه در شرح وظیفه، بلکه در Handoff میشکند: چه زمانی Local risk به Portfolio risk تبدیل میشود؟ چه کسی Capability gap را میپذیرد؟ چه Evidenceای برای بودجه لازم است؟ Interface باید Request/Ready/Input/Output/Acceptance/System of record/Owner/Authority/SLA/Ack/Escalation/Fallback/Timezone/Privacy/Correction داشته باشد.
RoleInterface interface_id: IF-LEAD-MANAGER-07 trigger: repeated evidence gap exceeds local repair boundary requester/provider: Test Lead → QA Manager capability service input: context, risk, attempts, impact, alternatives, local actions acceptance: ACK | NEEDS_INFO | ACCEPTED | DECLINED_WITH_REASON output: owner, option, decision date, interim fallback escalation: Risk/Product authority when exposure exceeds mandate record: single source; UTC event + Asia/Tehran display
Release Gate و پذیرش ریسک را پیشفرض به QA ندهید
راهنمای مسئولیت مشترک و Decision rights کیفیت توضیح میدهد چرا «کیفیت مسئولیت همه» بدون مالک تصمیم ناکافی است. Test Lead/QA Manager میتواند Evidence minimum را تعریف، Gap را آشکار و Pause/Stop را توصیه یا در Scope مصوب enforce کند؛ اما Release date، Product trade-off و Residual legal/security/business risk باید Authority صریح داشته باشد. Green sign-off کیفیت یا آینده را تضمین نمیکند.
People Manager بودن را جداگانه Contract کنید
Task allocation، technical guidance، mentoring، coaching، feedback، performance management، compensation، promotion، leave approval، wellbeing support، disciplinary process و employment decision یک چیز نیستند. Test Lead ممکن است Task lead و Mentor باشد ولی هیچ HR authority نداشته باشد. QA Manager ممکن است Line manager باشد یا فقط Practice manager. محرمانگی و دسترسی Evidence باید با هر نوع مسئولیت همراستا باشد.
| People activity | Role possible | Authority/Evidence | خطر |
|---|---|---|---|
| Daily work sequencing | Test Lead/team | work policy | micromanagement |
| Technical feedback | Lead/peer/specialist | specific work product | شخصیتداوری |
| Growth coaching | Manager/mentor | consented goal/evidence | اجبار مسیر مدیریت |
| Performance decision | line manager/process | fair multi-source record | metric gaming/bias |
| Compensation/promotion | authorized panel | policy/market/internal equity | وعدهٔ Lead |
| Health/accommodation | qualified confidential path | minimum access | تشخیص توسط Lead |
Capability را از Task و Evidence استخراج کنید
Test Lead الزاماً استاد همهٔ Automation/Performance/Security/Mobile/Database/Network نیست و QA Manager نیز با مهارت عمومی مدیریت جای تخصص لازم را نمیگیرد. Critical task → complexity/risk → observable behavior → Work product/Evidence → level/support را نگاشت کنید. Essential-now، trainable، shared-specialist و tool-substitutable را جدا و Primary/Backup/Bus factor را ثبت کنید.
CapabilityRequirement task: resolve cross-team Oracle disagreement for RELEASE-R8 context/risk: payment-like invariant; two services; fictional data behavior: separates fact/assumption; elicits basis; preserves dissent work_product: versioned Oracle decision record with claim limit level: independent in this scope; escalation for security/legal meaning evidence: recent comparable artifact, review quality and correction support/backup: domain owner + senior engineer; not tool-name checklist
Coaching، Mentoring و Management را مخلوط نکنید
Mentor تجربه و گزینه عرضه میکند؛ Coach به تفکر و عمل فرد کمک میکند؛ Manager Context، expectation، resources و پاسخگویی رسمی را اداره میکند؛ Sponsor فرصت و visibility میسازد. یک Person میتواند چند کلاه داشته باشد، اما باید اعلام کند اکنون با کدام نقش، چه محرمانگی و چه Authority صحبت میکند. Feedback امن نباید خودکار به پروندهٔ Performance منتقل شود.
Performance را از Outputهای قابلبازی نسازید
Bug/Test case/Automation/Meeting/Report count، Pass rate، Coverage یا Deadline hit برای ارزیابی فردی مناسب نیستند. راهنمای ارزیابی Contribution و اثربخشی QA Activity→Output→Outcome و Confidence را جدا میکند. Role evidence باید Context، Assignment، expected behavior، Work product، review، impact محدود، Alternatives، constraints و opportunity را حفظ کند؛ Outcome مشترک را به یک Person نسبت ندهد.
RoleEvidence evidence_id: RE-LEAD-04 assignment/context: named fictional release and constraints expected_behavior: escalate unknown before decision cutoff artifact: risk/evidence packet v3 observation: gap recorded with owner and alternative evidence feedback: specific reviewer roles; disagreement retained claim: demonstrated behavior in this scope/window only not_claimed: leadership potential, product success, personal productivity
بودجه و تأمینکننده Decision interface جدا میخواهند
QA Manager ممکن است Business case، demand forecast و option/TCO بسازد ولی Budget authority نداشته باشد. Test Lead ممکن است Vendor delivery را بپذیرد ولی Contract، payment، security exception یا renewal را امضا نکند. Scope، forecast range، assumptions، currency/rate date، procurement/legal/security/finance owners، service acceptance، change، dispute، continuity و Exit را مشخص کنید. قیمت ابزار یا حقوق فرد نتیجهٔ نقش نیست.
Governance باید حداقل لازم و قابل استثنا باشد
QA Manager نباید برای نمایش هماهنگی یک Process ثابت را بر تمام Productها تحمیل کند. Minimum control، local choice، exception reason/authority/expiry، evidence، review و correction را جدا کنید. Test Lead نیز نباید هر Deviation را بیقاعده محلی کند. Standard زمانی ارزش دارد که Decision/Risk/Interoperability یا Evidence را بهتر کند، نه چون «Best practice» نامیده شده است.
GovernanceRule rule_id/version: GOV-EVIDENCE-07/v2 purpose/risk: preserve build/attempt/evidence trace for decisions minimum: immutable identities + missing/unknown disclosure local_choice: tool, format and workflow may differ exception: reason, scope, alternative control, authority, expiry measurement: completeness/correction, not compliance theatre review/correction: affected teams participate; silent change forbidden
Independence را Risk-based طراحی کنید
جدایی کامل همیشه بهتر نیست و self-review همیشه کافی نیست. Independence میتواند در Author، Reviewer، Reporting line، Budget، Evidence custody یا Acceptance authority باشد. Benefit کاهش bias را کنار latency، cost، context loss و handoff ببینید. برای Risk بالا شاید reviewer مستقل لازم باشد؛ برای تغییر کمریسک peer review کافی؛ و در هر دو حالت Decision authority باید جدا از «چه کسی تست کرد» تعریف شود.
Conflict of interest و Dissent را ثبت کنید
Role ترکیبی ممکن است هم موعد Delivery را پاسخ دهد و هم Evidence کفایت را ارزیابی کند؛ Manager ممکن است Supplier یا ابزار پیشنهادی خود را ارزیابی کند؛ Lead ممکن است Work product خودش را sign-off کند. Conflict را افشا، reviewer/authority جایگزین، recusal، dissent و escalation تعریف کنید. حذف مخالفت از Summary برای «یکصدایی» Audit trail را ضعیف میکند.
ConflictRecord conflict_id: COI-ROLE-03 role/person: synthetic combined holder decision: evidence minimum exception for own delayed work interest/tension: delivery deadline vs independent adequacy review control: alternate reviewer; Product/Risk authority decides exception dissent: preserved with evidence and claim limits expiry/review: applies to RELEASE-R8 only; no precedent by default
Escalation را شکست رهبری ندانید
Escalation وقتی Boundary اختیار یا ظرفیت عبور میشود، یک Control است. Trigger، severity/urgency، evidence minimum، route، acknowledgment، decision clock، interim action، fallback و no-retaliation را تعریف کنید. Test Lead نباید Risk را در Queue پنهان کند چون «خودش باید حل کند»؛ QA Manager هم نباید هر اختلاف فنی را به hierarchy ببرد. Local repair و escalation boundary باید روشن باشد.
Continuity، Backup و Succession سه مسئلهاند
Backup پوشش absence کوتاه است؛ Continuity حفظ Service در اختلال؛ Succession آمادگی بلندمدت برای انتقال Position/Role. Shadow کردن جلسه بدون دسترسی، Work product و trial کافی نیست. Decision register، runbook، stakeholder map، access، calendar، open risks، queue، authority delegation، emergency fallback و revocation/transfer را قابلآزمایش کنید.
| سناریو | Control | آزمون | شاهد |
|---|---|---|---|
| مرخصی Lead | named backup/delegation | یک Release rehearsal | decision/ack timing |
| خروج Manager | service/people/budget handover | tabletop | open items/authority |
| Tool/vendor outage | fallback/export | restore/replay | continuity result |
| تغییر ساختار | role mapping | gap/overlap audit | new charter |
| Position خالی | interim bounded role | capacity/conflict review | expiry/split trigger |
مسیر شغلی خطی Tester→Senior→Lead→Manager نیست
Management ارتقای طبیعی یا تنها شکل رشد نیست. مسیرها میتوانند IC تخصصی/Staff/Principal، Delivery/Test Lead، Automation/Testability/Performance/Security specialist، Capability/Practice lead، People manager، Product/Delivery یا Consulting باشند. Lead شدن Trial یک Scope است، نه آزمون وفاداری؛ Manager شدن نیازمند علاقه و Evidence کار People/System است، نه صرفاً بهترین Tester بودن.
راهنمای آمادگی رهبری QA Scope، Evidence و Trial امن/جبرانشده را پوشش میدهد. مسیر رشد باید parallel tracks، level criteria، compensation parity، امکان برگشت، mentoring و accessibility داشته باشد. نپذیرفتن مدیریت نباید سقف اعتبار یا حقوق فنی بسازد.
Readiness را با Trial محدود بسنجید
LeadershipTrial trial_id: TRIAL-LEAD-07 scope/window: one synthetic release; four weeks expected: clarify decision, coordinate evidence, repair handoff authority/no_authority: written before start support: sponsor, backup, time, access, feedback route evidence: work products and observed behavior, not hero hours safety: compensated; reversible; no hidden promotion promise review: participant voice + context limits + next option
حقوق و بازار کار را از Title نتیجه نگیرید
نمیتوان گفت QA Manager همیشه حقوق بیشتری دارد. Compensation به Scope، level، location، employment type، company stage، scarcity، currency/date، benefits، on-call، equity، tax و internal equity وابسته است؛ یک Principal IC ممکن است بالاتر از Manager باشد. برای ایران، دادهٔ زماندار و منبعدار محلی، IRR و تومان برچسبدار، نوع قرارداد و مزایا را جدا کنید و دربارهٔ قانون کار/مالیات از متخصص ذیصلاح کمک بگیرید.
Job Description را با Outcome و Authority بنویسید
آگهی «Test Lead با تسلط کامل بر Selenium/Cypress/JMeter/Security/DB/DevOps و رهبری ذاتی» هم مبهم است هم دایرهٔ متقاضی را بیدلیل محدود میکند. Context، Purpose، critical tasks/decisions، Work products، authority/no-authority، interfaces، essential-now/trainable capabilities، support/conditions، location/timezone/language، accessibility/accommodation، hiring process، compensation range و privacy را بنویسید. ابزار را فقط اگر واقعاً شرط کار است ذکر کنید.
RoleProfile title/local mapping: Test Lead / Delivery Quality Lead context/purpose/outcomes/non_outcomes: versioned critical tasks/decisions: with frequency, complexity and evidence authority/no_authority/interfaces: explicit capabilities: essential-now | trainable | shared-specialist conditions: timezone, on-call, travel, language, accessibility hiring: structured work sample; scoring rubric; data retention growth/pay: level and range with date/currency/context
Hiring را با Work sample اخلاقی و نماینده اجرا کنید
- سؤال ثابت و rubric مرتبط با Critical task؛
- نمونهٔ synthetic کوتاه، پرداختشده یا غیرقابلاستفادهٔ تجاری؛
- گزینه، Risk، Evidence، Unknown، dissent و repair را بسنجید؛
- Trivia ابزار، سال سابقه، لهجه، حضور فیزیکی و charisma را Proxy شایستگی نکنید؛
- مصاحبهکنندگان آموزشدیده و Evidence مستقل پیش از جمعبندی؛
- Accommodation، زمان/پهنایباند و زبان روشن؛
- Conflict، nepotism، privacy، retention و appeal کنترل شود؛
- هیچ تصمیم استخدام/حقوق واقعی از Lab این مقاله گرفته نشود.
Accessibility و Inclusion بخشی از طراحی Role است
Requirementهایی مثل «انرژی بالا»، «همیشه آنلاین»، «ارتباط عالی»، «توان مدیریت فشار» یا «فرهنگپذیر» را به رفتار و شرایط ضروری تبدیل کنید. Channel ناهمگام، caption، keyboard/screen-reader compatible artifacts، timezone fairness، predictable schedule، focus time، accommodation path و عدماجبار افشای تشخیص را در Role service بگنجانید. کیفیت رهبری با ساعات طولانی یا سبک ارتباطی واحد سنجیده نمیشود.
ملاحظات فارسی و ایران
- Title فارسی/انگلیسی و معنای محلی را کنار هم بنویسید؛ «سرپرست» لزوماً Line manager نیست.
- Remote/hybrid، overlap، تعطیلات و Asia/Tehran را صریح کنید؛ Event time در سیستم UTC بماند.
- حقوق/بودجه را با Currency/date و IRR در برابر تومان برچسبدار گزارش کنید.
- ی/ی، ک/ک، ZWNJ، RTL/LTR/Bidi و رقم فارسی/عربی/لاتین را در HR/Identity/Reporting تست کنید.
- ابزار SaaS، account/region/payment/export و fallback را واقعاً بسنجید؛ دورزدن محدودیت Plan نیست.
- دادهٔ کارکنان/نامزدها، ضبط مصاحبه و Health/Performance record کمینه و دسترسیمحدود باشد.
- این مقاله مشاورهٔ قانون کار، مالیات، حقوق یا بازار ایران نیست.
Security و Privacy در مرز نقش
Role title نباید دسترسی Admin دائمی بسازد. Joiner/Mover/Leaver، least privilege، time-bound elevation، separation of duties، service identity، secret custody، evidence/employee/candidate data classification، retention/deletion، audit، incident و emergency access را به Decision right وصل کنید. Manager برای People data و Lead برای Test artifact دسترسی متفاوت دارد؛ «هر دو QA هستند» دلیل دسترسی مشترک نیست.
منابع رسمی و مرز انتقال آنها
- ISTQB CTAL Test Management v3.0 مدیریت تست را به Context، stakeholder، planning، monitoring/control، risk و team مرتبط میکند؛ یک Job title جهانی، چارت سازمانی یا Certification اجباری تجویز نمیکند.
- SFIA 9 Testing guidance Testing را به مهارتهای متمایز و levelهای مسئولیت وصل میکند و تنوع entry/career را میپذیرد؛ SFIA شرح شغل آماده، ارزیابی فرد یا قانون حقوق نیست.
- پروفایلهای illustrative در SFIA ۹ Testing practice management را ترکیبی از skills نشان میدهند؛ خود منبع آنها را نقطهٔ شروع illustrative میداند، نه نسخهٔ ثابت Test Lead/QA Manager.
- چارچوب فعلی Government Digital & Data Role و skill levelهای Context دولت بریتانیا از جمله Test Manager را عرضه میکند؛ Grade/Role آن قابل کپی مستقیم به شرکت ایرانی نیست.
- GOV.UK multidisciplinary-team guidance ترکیب تیم را متناسب با مرحله و نیاز Service میبیند؛ این Policy عمومی بریتانیاست، نه الزام ساختار QA در هر سازمان.
Role Boundary loop، Stateها، فیلدها و آستانههای این مقاله synthesis مهندسی نویسندهاند. استفاده از منبع به معنی تأیید این Template، کفایت HR/Legal یا موفقیت سازمانی نیست.
آزمایش مستقل: چهار کلیشه در برابر ۵۶۰ کنترل
Fixture ساختگی فقط گفت Test Lead تاکتیکی، QA Manager استراتژیک، هر دو برای موفقیت ضروری و مسیر Tester→Lead→Manager طبیعی است. Checker سطحی چهار عبارت را دید و اعلام آمادگی کرد:
TACTICAL_LEAD_STRATEGIC_MANAGER_BOTH_REQUIRED_READY
ممیزی مستقل دقیقاً ۵۶۰ کنترل یکتای group-qualified را در ۴۰ گروه identity، context، purpose، outcome، scope، title، accountability، responsibility، authority، decision_right، no_authority، interface، handoff، service، span، capacity، demand، planning، evidence، risk، people، capability، coaching، performance، budget، supplier، governance، independence، conflict، escalation، continuity، succession، career، compensation، hiring، accessibility، locale، security، correction و limits مطالبه کرد. Fixture هیچکدام را نداشت:
HOLD-560 NO_REAL_TARGET_PASS
Rule جداگانه تأیید کرد Organization، Worker، Candidate، Employee، Salary، Contract، Product یا Outcome واقعی وجود ندارد. پس از Pin کردن تمام کنترلهای ساختاری، نتیجه فقط آمادگی بازبینی انسانی بود:
READY_FOR_QA_ROLE_BOUNDARY_REVIEW-0
صفر Finding ساختاری، درستی نقش، Capability یا Evidence فرد، انصاف استخدام/عملکرد/حقوق، کفایت ظرفیت، امنیت، انطباق، سلامت کارکنان، کیفیت Product یا موفقیت سازمان را ثابت نمیکند. Validator فقط کاملبودن فیلدهای خیالی را میسنجد.
آزمایشگاه آفلاین فارسی: دو تیم Checkout ساختگی
Lab با شناسهٔ SYN-QA-ROLE-BOUNDARY-01 شامل دو تیم Product خیالی، یک Automation Platform و Release R8 است. نام Personها، Positionها و Salary وجود ندارد. Order، PaymentAttempt، PSP Stub، Callback، Ledger و Reconciliation همگی fake و بدون شبکه/Production/بانک/PSP واقعیاند. IRR ساختگی canonical و تومان فقط نمایش برچسبدار است.
Lab conditions Roles: delivery test lead | capability/people manager | product/risk owner Demand: releases, people work, capability request, incident interrupt Faults: timeout-before/after-fake-commit, duplicate/late/reordered callback Locale: ی/ي، ک/ك، ZWNJ، RTL/LTR/Bidi، ۱۲۳/١٢٣/123 Time: UTC event, Asia/Tehran display, presentation-only Jalali Money: fictional IRR, labelled presentation-only toman Targets absent: real org/worker/candidate/employee/salary/contract/product/outcome
مدل ساده گفت یک «QA Lead» هر دو Role را بگیرد. Audit نشان داد همان Position هم Work را اولویت میدهد، هم Evidence خود را تأیید میکند، هم Performance را میسنجد و هم Risk exception پیشنهاد میدهد؛ علاوه بر آن Backup و ظرفیت People work ندارد. Lab بهجای حکم «دو نفر استخدام کنید»، گزینههای delegation، alternate reviewer، WIP، shared manager و split trigger را مقایسه میکند. این یک تمرین ساختاری است، نه نتیجهٔ نیروی انسانی واقعی.
برنامهٔ ۳۰روزهٔ طراحی مرز نقش بدون کارکنان واقعی
| بازه | کار | خروجی | Gate |
|---|---|---|---|
| روز ۱–۵ | Context/Demand/Decision inventory | Role map v1 | Title≠Role |
| روز ۶–۱۰ | Purpose/Outcome/RACI+Authority | Charters | No-authority روشن |
| روز ۱۱–۱۵ | Interface/Handoff/Service/Span | service contracts | Gap/overlap صفر ساختاری |
| روز ۱۶–۲۰ | Capacity/conflict/continuity | combine/split options | backup/expiry |
| روز ۲۱–۲۵ | synthetic role trials | Evidence/dissent | بدون فرد/HR واقعی |
| روز ۲۶–۳۰ | Decision/correction/review | Role Boundary Pack | human/legal review needed |
پیش از اعمال به کارکنان واقعی، consultation، employment law، compensation، privacy، accommodation، union/worker representation در صورت ارتباط، security، workload و transition impact باید توسط مالکان واجد صلاحیت بررسی شود. Pilot خیالی مجوز تغییر شغل، حقوق، گزارشدهی یا دسترسی کسی نیست.
۲۸ ضدالگوی Test Lead و QA Manager
- Title را تعریف جهانی Role دانستن؛
- فرمانده/ژنرال و جنگ بهجای Contract؛
- Lead=تاکتیک و Manager=استراتژی بهصورت مطلق؛
- ضروری دانستن هر دو Position برای هر شرکت؛
- «کیفیت بالا» بهعنوان Outcome قابلتضمین؛
- QA مالک همهٔ Processها و کیفیت؛
- چند Accountability برای یک Decision؛
- Responsibility بدون Authority/Capacity؛
- Authority بدون پاسخگویی و Audit؛
- نداشتن No-authority؛
- Sign-off را پذیرش Risk دانستن؛
- شرح وظیفهٔ «هر کار لازم برای کیفیت»؛
- Span فقط برحسب Headcount؛
- ترکیب دو Role بدون Capacity/Conflict/expiry؛
- تفکیک Role با افزودن hierarchy غیرضروری؛
- Handoff در پیام خصوصی و بدون Ack؛
- Lead بهعنوان بهترین Tester و همهفنحریف؛
- Manager بهعنوان مالک استاندارد واحد؛
- Task lead را People manager فرض کردن؛
- Mentoring را Evidence عملکرد رسمی کردن؛
- Bug/Test/Automation count برای People score؛
- حقوق Manager را همیشه بالاتر دانستن؛
- مسیر Tester→Lead→Manager بهعنوان تنها رشد؛
- Hero hours و Availability دائمی بهعنوان رهبری؛
- آگهی مبتنی بر Tool list/صفات مبهم؛
- Role title بهعنوان دسترسی Admin؛
- Backup اسمی بدون Trial/authority؛
- ویرایش خاموش Charter و Decision.
چکلیست مالک نقش: ۳۴ سؤال
- Role/Position/Person/Title جدا شدهاند؟
- Context و نسخه معلوم است؟
- Purpose و beneficiary روشن است؟
- Outcome و Non-outcome نوشته شده؟
- Scope/Boundary/Horizon دارد؟
- Critical tasks و Work products معلوماند؟
- Evidence پذیرش هر Work product تعریف شده؟
- Responsibility از Accountability جداست؟
- هر Decision یک Accountable authority دارد؟
- No-authority صریح است؟
- Release/Risk/Sign-off مرز دارد؟
- Interface trigger/input/output/ack دارد؟
- Handoff owner/SLA/escalation/fallback دارد؟
- Service class و expectation تعریف شده؟
- Demand class/arrival دیده میشود؟
- Capacity/WIP/interrupt/displaced work ثبت شده؟
- Span فراتر از Headcount سنجیده میشود؟
- ترکیب/تفکیک گزینه و trigger دارد؟
- People/Task/Coach/Mentor authority جداست؟
- Capability از Task/Evidence استخراج شده؟
- Primary/Backup/Bus factor داریم؟
- Performance metric ضدبازی و Contextual است؟
- Budget/Supplier/Contract authority روشن است؟
- Governance minimum/local choice/exception دارد؟
- Independence متناسب Risk است؟
- Conflict/recusal/dissent ثبت میشود؟
- Escalation بدون retaliation و با clock است؟
- Continuity/Backup/Succession آزمایش شده؟
- Career parallel track و reversible trial دارد؟
- Compensation context/date/currency دارد؟
- Hiring structured/fair/privacy-aware است؟
- Accessibility/accommodation/timezone لحاظ شده؟
- Security/access/JML با Role همراستاست؟
- Review/correction/supersession فعال است؟
Correction و تغییر نقش را بیصدا انجام ندهید
تغییر Product، Demand، reporting line، People load، Risk، supplier یا authority میتواند Charter را منقضی کند. Correction باید نسخهٔ قبلی، Gap/Overlap/Conflict، تصمیمهای متاثر، interim control، consultation، transition، access change، effective date، owner، communication و rollback/reopen را ثبت کند. افزودن مسئولیت در پیامرسان بدون ظرفیت و Compensation/HR review، تغییر رسمی و منصفانه نیست.
RoleCorrection correction_id: COR-ROLE-07-v2 supersedes: ROLE-BOUNDARY-PACK-v1 trigger: second product + people-load threshold exceeded error/gap: combined position lacks capacity and independent reviewer affected: release evidence, 1:1 service, risk exceptions transition: delegate lead; retain manager; transfer access/queue consult/review: affected holders + HR/legal/security authorities history: v1 readable; v2 current; rollback/reopen criteria stored
خروجی Role Boundary Pack
- Context/Demand/Operating-model map؛
- Role/Position/Title mapping؛
- Purpose/Outcome/Non-outcome Charters؛
- Responsibility/Accountability/Authority/No-authority؛
- Decision rights و Risk/Release interface؛
- Work package/Work product/Evidence catalogue؛
- Interface/Handoff/Service contracts؛
- Span/Capacity/WIP/Conflict analysis؛
- People/Capability/Career/Continuity boundaries؛
- Combine/Split options، decision، expiry و Correction.
این Pack باید با دارندگان نقش و تیمهای متاثر مرور شود، نه پشت در بسته به آنها تحویل شود. راهنمای عملی رهبری تیم QA بخش People system و cadenceهای تیم را تکمیل میکند. Role clarity یکبار برای همیشه حل نمیشود؛ با Context و Evidence بازبینی میشود.
جمعبندی
فرق Test Lead و QA Manager در عنوان، ارشدیت یا استعارهٔ جنگی نیست؛ در Scope، Outcome، Work product، Accountability، Authority، Interface، Span و Evidence محلی است. از Context و Demand شروع کنید، Role را از Position/Person جدا سازید، No-authority و Risk acceptance را بنویسید، ظرفیت و تعارض را بسنجید و بعد ترکیب یا تفکیک کنید. مسیر رشد را چندشاخه، Trial را امن و جبرانشده، People data را خصوصی و هر تغییر را نسخهدار و قابلاصلاح نگه دارید.
سؤالات متداول
آیا Test Lead از QA Manager پایینتر است؟
لزومی ندارد. Title و level محلیاند. Test Lead ممکن است یک Role موقت/Delivery، یک Position مدیریتی یا Staff-level leadership بدون Direct report باشد. QA Manager نیز ممکن است People، Practice یا Capability scope داشته باشد. Level را با Scope، consequence، autonomy، authority و Evidence تعریف کنید، نه نام عنوان.
آیا شرکت کوچک به هر دو نقش نیاز دارد؟
به هر دو عنوان یا Position نه؛ به پوشش مسئولیتهای لازم بله. یک Position میتواند Roleها را timeboxشده ترکیب کند اگر Capacity، Conflict، Backup، No-authority و split trigger روشن باشد. بعضی مسئولیتها نیز میتواند میان Product team، manager مشترک یا specialist service توزیع شود.
چه کسی باید Release را تأیید کند؟
عنوان جهانی وجود ندارد. Test Lead/QA Manager میتواند Evidence completeness را تأیید، Gap را ثبت و توصیه کند؛ Product/Service/Risk authority باید trade-off و Residual risk را در Scope خود بپذیرد. Security، legal یا regulatory exception نیز صاحب اختیار جدا میخواهد. Sign-off QA نباید همهٔ اینها را پنهان کند.
آیا QA Manager باید فنیتر از Test Lead باشد؟
رتبهبندی عمومی معنا ندارد. Capability موردنیاز از Critical task، Context و Risk میآید. Lead ممکن است عمق فنی محلی و Manager breadth سیستم/people/commercial بخواهد؛ در سازمان دیگر ترکیب متفاوت است. هیچکس لازم نیست همهٔ تخصصها را داشته باشد اگر service، specialist، backup و escalation معتبر موجود است.
مسیر تبدیل تستر به مدیر QA چیست؟
مسیر واحد نیست. ابتدا Scope هدف و Taskهای People/Capability/Decision را مشخص، Evidence مرتبط بسازید و Trial محدود با authority/support/feedback انجام دهید. Coaching و آموزش را متناسب Gap بگیرید. در کنار مسیر مدیریت، IC/Staff/Specialist/Lead track باید همارزش بماند؛ Manager شدن شرط رشد حرفهای نیست.
