آگهی «مهندس QA» میتواند در یک شرکت به معنی تست دستی رابط کاربری، در شرکتی دیگر توسعه زیرساخت تست و در تیمی دیگر تسهیل ریسک و شواهد انتشار باشد. بنابراین پاسخ حرفهای به سؤال «مهندس تضمین کیفیت چه میکند؟» فهرست ثابت ابزارها یا هفت شعار معکوس نیست. باید Product، ریسک، مدل تیم، مرحله چرخه عمر، تصمیمها و خروجیهای مورد انتظار را پین کرد.
این راهنما یک QA Role & Capability Charter میسازد: عنوان را از نقش واقعی جدا میکند، Outcome و مسئولیت را به فعالیت و Work Product وصل میکند، اختیار و مرز را شفاف میسازد، قابلیت لازم را از روی کار استخراج میکند و اثربخشی Contribution را بدون نسبتدادن کیفیت محصول به یک فرد بازبینی میکند.
پاسخ کوتاه: نقش مهندس QA چیست؟
- درباره کیفیت و ریسک سؤالهای تصمیمپذیر میسازد.
- برای Claimها شواهد متناسب طراحی، تولید، اعتبارسنجی و محدود میکند.
- سیستم، Build، محیط، داده، Oracle و رفتارهای مورد انتظار/نامعلوم را مدل میکند.
- با Design، Development، Product، Operations و نقشهای تخصصی همکاری میکند.
- یافته، عدمقطعیت، پوشش و ریسک باقیمانده را برای صاحب تصمیم قابل استفاده میکند.
- قابلیتهای تست و بازخورد را در چرخه عمر، نه فقط انتهای توسعه، بهبود میدهد.
- در Production از telemetry، support، incident و outcome یاد میگیرد؛ بدون اینکه monitoring را Testing بنامد.
- تنها در محدوده اختیار تعریفشده Pause، Gate، Sign-off یا Escalate میکند؛ عنوان QA اختیار جهانی نمیسازد.
یک تعریف جهانی برای QA Engineer وجود ندارد
QA Engineer، Quality Engineer، Software Tester، Test Engineer، SDET، QA Analyst و Test Automation Engineer در بازار یکسان استفاده نمیشوند. حتی در یک سازمان، عنوان ثابت ممکن است در دو محصول کار متفاوتی داشته باشد. بهجای استنتاج از Title، RoleID، سطح، Outcomes، critical tasks، Work Products، authority، interfaces، constraints و review date را بخوانید.
| عنوان رایج | تمرکز محتمل | چیزی که از عنوان ثابت نمیشود |
|---|---|---|
| Software Tester / QA Analyst | تحلیل، طراحی/اجرای تست، بررسی و گزارش | فقط manual، junior یا بدون کدنویسی بودن |
| QA Engineer / Quality Engineer | تست بهعلاوه قابلیت/فرایند/ابزار/سیستم کیفیت | مالک همه کیفیت یا معمار همه فرایندها بودن |
| Test Automation Engineer | طراحی و نگهداری checks/framework/pipeline | پوشش همه ریسکها یا حذف کار انسانی |
| SDET | Software engineering برای testability/tooling/evidence | تعریف ثابت صنعت یا برتری نسبت به Tester |
| QA Lead/Manager | رهبری capability/people/strategy/operations | Release authority، درمانگر یا universal gate بودن |
مالکیت محتوایی: این مقاله چه چیزی را حل میکند؟
این مقاله مالک Role Context → Outcomes/Risks → Responsibilities/Activities → Work Products/Evidence → Authority/Interfaces → Capability → Allocation/Support → Review/Change است. راهنمای باورهای غلط تست Mythهای عمومی Testing را پوشش میدهد؛ ماتریس مهارتهای تستر Capability را عمیق میکند؛ مدل عملیاتی QA ساختار Central/Embedded/Federated را طراحی میکند؛ و رهبری کیفیت و مالکیت همگانی تصمیمحقوق سازمانی را میبندد.
QA Role & Capability Charter
RoleCharterID: QARC-SYN-001 Version / Status / EffectiveFrom: v1 / PILOT / 2026-08-13 RoleTitle / Level / Mode: QA Engineer / Contextual-L2 / Embedded Product / Service / RiskClass: Fake Checkout / Payment result / HIGH-SYN Mission: کاهش عدمقطعیت تصمیم Release با شواهد محدود و قابل ردیابی ExpectedOutcomes: Risk visible; evidence reviewable; feedback timely NonOutcomes: defect-free, quality guarantee, universal approval CriticalTasks: risk analysis, state model, test design, exploration, reporting WorkProducts: Charter, Test Model, Evidence Manifest, Finding, Decision Input Authority: Pause test on unsafe fixture; Escalate missing Oracle NoAuthority: accept business risk; approve legal/security claims; ship alone Interfaces: Product, Design, Dev, SRE, Security, Support Capabilities: domain, testing, technical, evidence, communication Constraints: synthetic data only; no Production write; Asia/Tehran support window SuccessEvidence / Guardrails: contract completeness / no people scoring ReviewAt / Owner / ChangeRoute: 2026-09-13 / Quality-Capability-A / RFC-QA
مرحله صفر: Context نقش را پین کنید
- Product/Service، کاربران/طرفهای متاثر و Outcomeهای هدف؛
- ریسکهای کیفیت، safety/security/privacy/regulatory و طبقه بحرانیبودن؛
- مرحله Discovery/Build/Operate و cadence انتشار؛
- معماری، platform، third party، data و environment؛
- اندازه/ترکیب تیم، timezone، remote/on-site، vendor و on-call؛
- روش delivery و الزامات واقعی، نه برچسب Agile/DevOps؛
- زبان/Locale، بازار ایران، accessibility و support context؛
- منبع authority، محدودیت بودجه/زمان/مهارت و تاریخ بازبینی.
یک QA در firmware پزشکی، marketplace ایرانی، بازی موبایل و کتابخانه متنباز Role یکسان ندارد. Risk class و Outcome نوع Evidence، استقلال، مهارت، Documentation و Stop authority را تغییر میدهد. «Best practice» بدون Context ممکن است فقط انتقال هزینه یا ریسک باشد.
Testing، QA، QC و Debugging را به دوگانه ساده تقلیل ندهید
واژگان سازمانها و استانداردها تفاوت دارند. برای قرارداد تیم، تعریف عملیاتی و منبع بنویسید. ISTQB CTFL 4.0 دانش بنیادی Testing را حول اهداف، فعالیتها، نقشها، ریسک و گزارش پوشش میدهد؛ استفاده از آن به معنی الزام Certification یا پذیرش یک مدل استخدامی نیست.
| مفهوم | تعریف عملیاتی نمونه | مرز مهم |
|---|---|---|
| Testing | مجموعه فعالیتهای ارزیابی Work Product/System و تولید اطلاعات | فقط اجرای UI یا پیدا کردن defect نیست |
| QA | فعالیتهای اطمینان/توانمندسازی کیفیت در سیستم کار | لزومًا department یا مالک همه processها نیست |
| QC | کنترلهای تعریفشده برای بررسی خروجی در Context سازمان | لزومًا reactive/end-stage یا مترادف Testing نیست |
| Debugging | یافتن، تحلیل و رفع علت failure/defect | میتواند توسط Developer/Engineer مشترک انجام شود |
| Verification/Validation | بررسی نسبت به specification و intended use/context | دو شعار «درست ساختن/چیز درست» همه مرزها را حل نمیکند |
هفت کلیشه را با هفت سؤال جایگزین کنید
در ادامه، به جای «باور غلط/واقعیت قطعی» یک سؤال طراحی نقش داریم. پاسخ هر تیم باید در Charter و با Evidence محلی ثبت شود.
۱) آیا نقش فقط پیدا کردن باگ است؟
ممکن است defect discovery یک Outcome مهم باشد، اما Role میتواند risk analysis، requirement/design review، test modelling، environment/data/oracle، automation، observability، incident learning و decision support نیز داشته باشد. برعکس، گفتن «QA پیشگیریکننده باگ و معمار فرایند است» هم بیشادعاست: هیچ فردی همه defectها را پیشگیری نمیکند و Process authority ممکن است جای دیگری باشد.
ResponsibilityRecord: ResponsibilityID / OutcomeOrRisk Task / Trigger / Frequency / Complexity Inputs / Method / WorkProduct / Evidence AccountableRole / ResponsibleRoles / Consulted / Informed DecisionAuthority / PauseOrEscalateRight Dependencies / Handoff / ServiceExpectation NotResponsible / ClaimLimit / Review
۲) آیا QA ساده است یا «هر کسی» میتواند انجامش دهد؟
«هر کسی میتواند تست کند» و «فقط متخصص خاص میتواند» هر دو بدون Task مبهماند. یک کاربر، Developer، Support agent یا Domain expert ممکن است Contribution ارزشمند Testing داشته باشد؛ اما مسئولیت حرفهای به مهارت، Context، استقلال، ابزار، Evidence و پیامد خطا نیاز دارد. تجربه زیاد نیز تضمین competence نیست و تازهکار نباید کار پرریسک را بدون support بگیرد.
| Task | Capability لازم | Evidence قابلیت | Support |
|---|---|---|---|
| بازبینی Rule پرداخت | Domain + test analysis + Oracle | نمونه model/question با بازخورد | Domain owner review |
| API contract checks | HTTP/schema/code/tooling | PR کوچک با failure diagnosis | pairing/code review |
| Usability study | research protocol/consent/analysis | study plan و moderated practice | User researcher |
| Release risk brief | evidence synthesis/uncertainty | Decision brief با Dissent/limits | Risk authority |
۳) آیا QA آخرین مرحله است؟
Testing میتواند در Discovery، Design، Code، Pipeline، Pre-production، Rollout، Production و Incident رخ دهد؛ اما لازم نیست یک QA در همه جلسهها یا هر مرحله حاضر باشد. Shift-left درباره زودترکردن سؤال/بازخورد مناسب است، نه انتقال همه تستها به چپ. بعضی Evidenceها فقط با Build، integration، workload، کاربر یا Production قابل دستیابیاند.
DORA درباره Continuous Delivery Continuous Testing را Testing در سراسر چرخه بهجای فاز جدا پس از «Dev complete» توصیف میکند. این یک capability سازمانی/فنی است، نه دستور اینکه QA مالک همه pipeline یا حاضر در تمام رویدادها باشد؛ تناسب با Domain و کنترلهای محلی لازم است.
۴) آیا QA سرعت تیم را کم یا زیاد میکند؟
QA ذاتاً مانع یا شتابدهنده نیست. یک Gate صفساز، suite ناپایدار یا handoff مبهم میتواند latency و rework بسازد؛ یک Oracle روشن، feedback سریع یا ریسک زودآشکارشده میتواند تصمیم را بهتر کند. اثر را در system boundary با baseline، نوع تغییر، WIP، wait، rework، defect/failure، evidence latency و guardrail بسنجید. استعاره «ترمز خودروی مسابقه» Evidence نیست.
عدد «باگ Production صد برابر گرانتر است» قانون عمومی نیست. هزینه به نوع defect، detectability، exposure، recovery، data loss، support، architecture و زمان بستگی دارد. برای ارزیابی درست Contribution از راهنمای سنجش اثربخشی QA استفاده کنید؛ correlation یا نتیجه Product را به یک نقش نسبت ندهید.
۵) آیا Automation جای تست انسانی را میگیرد؟
Manual در برابر Automated یک تقسیمبندی ناکافی است. ابزار میتواند stimulus، setup، observation، comparison، generation، execution و reporting را خودکار کند؛ انسان سؤال، مدل، Oracle، interpretation، exploration و تصمیم را در Context طراحی/بازبینی میکند. بعضی بررسیها کاملاً ماشینی، بعضی انسانی و بسیاری ترکیبیاند. هیچکدام «بیرقیب»، بدون خطا یا همیشه سریعتر نیستند.
راهنمای DORA درباره Test Automation هم suiteهای سریع و قابل اعتماد و هم فعالیتهای انسانی مانند exploratory، usability و acceptance را در طول delivery مطرح میکند و بر مسئولیت Developerها در تست کد تأکید دارد. این منبع یک معماری Test Automation عمومی تجویز نمیکند. چرخه Check/Evidence/Maintenance را در راهنمای اتوماسیون تست ببینید.
۶) آیا QA و Testing یکساناند؟
گاهی عنوان واحد هر دو نوع کار را دربرمیگیرد؛ گاهی QA نام department و Tester نقش است؛ گاهی Quality Engineering یک capability توزیعشده است. بحث واژگانی بدون اثر عملی کمارزش است. برای هر Responsibility بنویسید چه کسی چه Task/Work Product/Decision را با چه authority انجام میدهد. دوگانه «QA فرایندمحور و پیشگیرانه، Testing محصولمحور و واکنشی» مواردی مانند static testing، design review و Production experimentation را بد طبقهبندی میکند.
۷) آیا کیفیت فقط مسئولیت QA است؟
کیفیت حاصل تصمیمها و رفتار یک سیستم اجتماعی-فنی است، اما «همه مسئولاند» بدون accountability هم خطرناک است. Product درباره Outcome و priority، Design درباره interaction، Development درباره implementation، Operations درباره service operation، Security/Privacy درباره capability تخصصی، QA درباره Contribution تعریفشده و یک صاحب اختیار درباره residual risk تصمیم میگیرد. مسئولیت مشترک، نقشها را حذف نمیکند.
| موضوع | Contributionهای نمونه | تصمیم/Accountability نمونه |
|---|---|---|
| Product outcome | Product/Research/Design/Data/QA | Product authority |
| Implementation quality | Developer/Reviewer/Platform/QA | Engineering ownership + DoD |
| Test evidence | Developer/QA/Specialist/User research | Evidence owner؛ sufficiency by named authority |
| Security/privacy/legal | QA input + qualified specialists | تعریفشده در governance، نه QA پیشفرض |
| Release/residual risk | همه Evidence providers | Named release/risk decision owner |
| Production learning | SRE/Support/Product/Data/QA | Service/outcome owner |
Activity، Output، Outcome و Authority را تفکیک کنید
| لایه | مثال | ادعای نامعتبر |
|---|---|---|
| Activity | اجرای exploratory session | پس QA productive/موثر است |
| Output | Test model، Finding، Evidence manifest | پس کیفیت محصول بالاست |
| Intermediate effect | ابهام پیش از Build تصمیم گرفت | پس حتماً هزینه کم شد |
| Outcome | تغییر در support load یا task success | پس QA علت آن است |
| Decision | Release مشروط با rollback | پس QA Release را تأیید کرد |
| Authority | صاحب ریسک تصمیم را امضا کرد | پس Evidence یا Outcome درست است |
Capability را از Critical Task استخراج کنید
CapabilityRecord: CapabilityID / Name / Definition / Context CriticalTaskRefs / RiskIfMissing ObservableBehaviors / WorkProducts Level0=NotRequired | 1=WithGuidance | 2=Independent | 3=GuidesSystem CurrentEvidence / EvidenceFreshness / Confidence EssentialNow / Trainable / ToolSubstitutable Primary / Backup / BusFactor LearningTask / Practice / Feedback / Transfer Assessor / Privacy / Review / Correction
از واژههای مبهم «ذهنیت کیفیت»، «چشم تیزبین»، «کنجکاوی بیپایان» یا «مهارت نرم عالی» به رفتار قابل مشاهده برسید: سؤال Oracle را روشن میکند؛ Fact و Assumption را جدا میکند؛ Test را با Risk توجیه میکند؛ Evidence قابل بازتولید میسازد؛ Unknown را حفظ میکند؛ با شواهد نظر خود را اصلاح میکند؛ اختلاف را محترمانه route میکند.
آیا مهندس QA باید برنامهنویسی بلد باشد؟
به Role بستگی دارد. اگر Critical Task شامل framework، API contract، CI، data tooling، fault injection یا code-level testability است، برنامهنویسی ممکن است Essential-now باشد. برای Role پژوهش کاربردپذیری، Domain acceptance یا process audit ممکن است قابلیت دیگری مهمتر باشد. «کدنویسی مزیت بزرگ/ضرورت همه» و «تستر دستی به کد نیاز ندارد» هر دو بدون Task غلطاند.
- زبان یا ابزار را به Work Product واقعی وصل کنید، نه trend بازار.
- سطح لازم را تعریف کنید: خواندن، تغییر، طراحی، debug، review یا ownership.
- جایگزینهای Tool/Platform/Pairing و هزینه وابستگی را بسنجید.
- مهارت را با نمونه کار نزدیک به شغل و Rubric ارزیابی کنید، نه self-rating.
- یادگیری نقشلازم را در ظرفیت رسمی قرار دهید، نه وقت شخصی.
- کدنویسی را شاخص هوش، seniority یا ارزش انسان ندانید.
مهارتهای Domain، Testing، Technical و Human-System
| خانواده | نمونه Capability | نمونه Work Product |
|---|---|---|
| Domain/Product | Rule، user journey، harm، operation | Domain model، risk claim، Oracle source |
| Test craft | analysis/design/exploration/coverage | Test charter/model/case/evidence |
| Technical | API/data/code/CI/environment/observability | check/framework/manifest/diagnostic |
| Quality attributes | accessibility/security/performance/reliability | bounded specialist evidence |
| Evidence/Decision | uncertainty/synthesis/reporting | Finding، brief، residual-risk input |
| Collaboration | listening/questioning/dissent/handoff | confirmed decision/action/repair |
| Learning/System | experiment/RCA/tool evaluation/coaching | hypothesis، trial، review، change |
سطح شغلی را با استقلال و اثر تعریف کنید، نه ابزار
Junior/Mid/Senior را با تعداد سال، Selenium یا تعداد باگ نبندید. Complexity، ambiguity، consequence، autonomy، scope، dependency، decision support، coaching و system impact را ببینید. Senior الزاماً manager یا تنها coder نیست؛ میتواند در Domain، accessibility، performance، exploratory یا evidence governance عمق داشته باشد.
LevelProfile: LevelID / Context / EffectiveFrom TaskComplexity / Ambiguity / Consequence GuidanceNeeded / DecisionBoundary / Escalation Scope: item|feature|service|portfolio EvidenceQuality / CrossRoleInterface ImprovementAndCoaching / PrimaryBackupExpectations Examples / Counterexamples / AlternativePaths PromotionEvidence / NotUsedFor / Review
کار QA در طول چرخه عمر
| مرحله | سؤال QA | Work Product محتمل |
|---|---|---|
| Discovery | کدام Outcome/Assumption/Harm نامعلوم است؟ | Quality question، risk map |
| Design | چه state/error/recovery/evidence جا افتاده؟ | model، example، design contribution |
| Code/Review | چه check/testability/diagnostic نزدیک لازم است؟ | PR input، unit/contract evidence |
| Pipeline | کدام feedback قابل اعتماد و با چه failure policy؟ | suite manifest، gate rule، triage |
| Pre-production | چه risk فقط در integration/system دیده میشود؟ | exploration/performance/security evidence |
| Rollout/Production | چه guardrail/telemetry/stop/rollback؟ | experiment/release evidence |
| Incident/Learning | کدام control/assumption/evidence شکست؟ | timeline، action، regression/monitor update |
Role interface و Handoff را طراحی کنید
«همکاری نزدیک» قرارداد نیست. برای Product، Design، Development، Platform/SRE، Security/Privacy، Data، Support و Release authority مشخص کنید چه ورودی تحویل میشود، Ready چیست، چه کسی Ack میدهد، زمان پاسخ چقدر است، اختلاف کجا route میشود و چه دادهای نباید منتقل شود.
InterfaceID / Parties / Purpose Trigger / Input / Ready / WorkProduct / Acceptance QuestionOwner / EvidenceOwner / DecisionOwner Authority / Stop / Escalation / Fallback Channel / ResponseExpectation / TimeZone HandoffState / Ack / Unknown / Dissent PrivacySecurity / Retention / Correction Measure / Review / Version
QA Gate، Sign-off و Stop authority پیشفرض نیست
Gate باید Subject، criteria، evidence، result vocabulary، owner، override/exception، expiry و consequence داشته باشد. QA ممکن است Evidence provider، reviewer، independent challenger یا در دامنهای صاحب Stop authority باشد؛ ولی Test pass یا امضای QA بهتنهایی Release، انطباق، امنیت، نبود defect یا پذیرش Risk را ثابت نمیکند.
- Pause: توقف موقت برای Safety، integrity یا Evidence نامعتبر با trigger روشن.
- Hold: معیار تعریفشده برآورده نیست؛ صاحب action و reevaluation دارد.
- Recommend: گزینه پیشنهادی با Evidence/Unknown/Trade-off.
- Accept risk: فقط صاحب اختیار مشخص، با Scope/Condition/Expiry.
- Release: تصمیم governance با guardrail/stop/rollback؛ نه مترادف Passed.
مدل تخصیص Role را انتخاب کنید
| مدل | مزیت محتمل | ریسک |
|---|---|---|
| Embedded | Context و feedback نزدیک | انزوای حرفهای یا استقلال کم |
| Central QA | تخصص/استاندارد/استقلال مشترک | صف، handoff و فاصله Product |
| Chapter/Federated | ترکیب نزدیکی و capability sharing | دوگانگی priority/manager |
| Enabling/Platform | tooling، environment و self-service مقیاسپذیر | ساخت platform بدون نیاز واقعی |
| Independent assurance | challenge در Risk بالا | هزینه و late gate اگر بد طراحی شود |
| No dedicated tester | مالکیت مستقیم team | شکاف capability/independence نامرئی |
مدل را بر اساس Risk، coupling، skill scarcity، cadence، regulation، product knowledge و نیاز استقلال انتخاب کنید، نه مد روز. عنوان «DevOps» وجود QA یا Testing را حذف نمیکند؛ Dedicated Tester نداشتن نیز یعنی capability باید جای دیگری صاحب، تأمین و بازبینی شود.
Automation ownership مشترک و صریح باشد
اگر QA تنها مالک suite باشد، تغییر code میتواند pipeline را منتظر تیم دیگر بگذارد؛ اگر Developer تنها مالک باشد، risk model و exploration ممکن است ضعیف شود. مسئولیت را بر حسب layer تقسیم کنید: production code/unit، contract/component، test platform، end-to-end critical path، specialty tests، data/environment، triage و retirement. Ownership شامل build، maintain، operate و respond است.
استقلال Testing طیف است
خودِ سازنده Context و سرعت دارد؛ peer نگاه دیگر؛ تیم مستقل challenge و separation؛ متخصص بیرونی independence بیشتر اما Context کمتر. استقلال میتواند bias را کاهش دهد و همزمان latency/هزینه/handoff بسازد. سطح را برای Claim/Risk انتخاب و conflict of interest، access، feedback و authority را ثبت کنید. «Developer نمیتواند کار خود را تست کند» و «استقلال همیشه بهتر است» هر دو غلطاند.
Evidence Pack نقش QA
RoleEvidencePack: PackID / RoleCharterVersion / Product / Window OutcomeRiskRefs / ResponsibilityRefs / TaskRefs WorkProducts / EvidenceManifests / Findings / Unknowns DecisionsInfluenced (نه owned مگر authority ثبت شده) Interfaces / Handoffs / Response / Blockers CapabilityEvidence / Support / LearningTransfer SystemMeasures / Denominators / Guardrails IncidentsEscapes / AlternativeExplanations ContributionClaim / Confidence / NotClaimed ReviewDecision / Actions / Owners / Correction
اثربخشی Role را چگونه بازبینی کنیم؟
Bug count، Test case count، automation percentage، pass rate و سرعت execution بهتنهایی اثربخشی یا عملکرد فرد نیستند. از Outcome/Risk سؤال شروع کنید، Contribution و mechanism را تعریف کنید، Context و Alternative explanation را نگه دارید و Activity→Output→Intermediate effect→Outcome/Guardrail را با Confidence گزارش کنید.
- زمان Quality Question تا پاسخ/تصمیم با window و علت انتظار؛
- Riskهای واجد Evidence معتبر ÷ Riskهای در Scope؛
- Findingهای قابل بازتولید/تصمیم ÷ Findings تحویلشده؛
- سهم blocked/flake/invalid evidence با علت سیستم؛
- تصمیمهای دارای Unknown/Dissent/expiry/rollback؛
- بازگشت finding یا incident به control/test/monitor و closure action؛
- Capability coverage و Bus Factor بدون public people ranking؛
- burden/latency/rework و privacy/safety به عنوان guardrail.
شرح شغل QA را قابل اجرا بنویسید
JobRoleID / Title / Level / LocationMode / Version ProductContext / Mission / ExpectedOutcomes / NonOutcomes CriticalTasks / DecisionsSupported / WorkProducts Authority / NoAuthority / Interfaces / OnCall EssentialCapabilities / TrainableCapabilities / EvidenceExamples ToolsAsContext (نه proxy مهارت) / WorkingConditions AccessibilityAccommodationRoute / LanguageTimeZone PerformanceEvidence / Privacy / GrowthPaths SalaryContractLegal fields: by qualified local owner ReviewAt / HiringAssessmentTrace / ChangeHistory
فهرست ۲۰ ابزار، «توجه به جزئیات»، «تحمل فشار»، «rockstar» و «مسئول تضمین محصول بدون باگ» شرح نقش نیست. Task و Outcome را بنویسید، Essential را از Trainable جدا کنید، accommodation را ممکن سازید و ابزار را فقط وقتی الزام کنید که Work Product بدون آن ممکن نیست. درباره قرارداد، حقوق، ساعت و قوانین ایران یا استخدام فرامرزی از نقش واجد صلاحیت جاری استفاده کنید.
رشد شغلی: IC و Manager را جدا نگه دارید
تنها مسیر رشد QA نباید مدیریت افراد یا «Automation coder شدن» باشد. مسیر IC میتواند Test Architecture، Domain، Performance، Accessibility، Security testing، Reliability، Data/AI evaluation، Research operations یا Evidence governance باشد. مسیر Manager شامل people system، capacity، hiring، feedback و organizational design است. انتقال مسیر نیازمند تجربه و support، نه فقط عنوان است.
سناریوی ایرانی: Role مبهم در Checkout
آگهی میگوید QA «مسئول کیفیت پرداخت، نوشتن Automation، تأیید Release و پاسخ Production» است. در تحلیل، Payment Provider شخص ثالث، callback دیر/تکراری، IRR/تومان، Persian digits، UTC/Tehran و reconciliation ریسکاند. یک نفر نه authority تجاری دارد، نه دسترسی Production و نه تخصص امنیت/حقوق. Charter مسئولیت را بازطراحی میکند.
- QA: state/risk/test model، integration/fault evidence، finding و release brief؛
- Developers: unit/contract checks، idempotency implementation و diagnostic؛
- Platform/SRE: environment، observability، rollout/rollback و incident operation؛
- Product/Risk: Outcome، priority و residual-risk decision؛
- Security/Privacy/Legal: Claimهای تخصصی در دامنه اختیار خود؛
- Support/Finance operations: settlement/reconciliation feedback با داده حداقلی؛
- Release owner: تصمیم مشروط با Evidence/Unknown/guardrail؛
- هیچکس: تضمین نبود defect، موفقیت یا انطباق مطلق.
آزمایشگاه آفلاین: عنوان Senior QA مساوی Role کامل نیست
آزمایشگاه کاملاً ساختگی و بدون شبکه است؛ هیچ فرد، کارمند، سازمان، Product، شغل، ارزیابی عملکرد، استخدام، پرداخت یا Outcome واقعی ندارد. Checkout/PSP Stub/Ledger فقط fixture است. IRR خیالی و تومان صرفاً نمایشی، ارقام فارسی/عربی/لاتین، ی/ی، ک/ک، نیمفاصله، Bidi، UTC، Asia/Tehran و جلالی نمایشی در داده حضور دارند.
// Node.js 24+ — no network, real worker/org/job/performance/payment
const fixture = {
id: "SYN-QA-ROLE-CAPABILITY-01",
title: "Senior QA Engineer",
superficial: ["find bugs", "prevent defects", "write automation",
"approve releases", "everyone owns quality", "know programming", "shift left"],
system: "Fake Checkout/PaymentAttempt/PSP Stub/Callback/Ledger",
events: ["timeout-before-fake-commit", "timeout-after-fake-commit",
"retry", "duplicate", "late", "reordered"],
money: {canonical: "IRR-FAKE", view: "تومانِ صرفاً نمایشی"},
glyphs: ["۱۲۳", "١٢٣", "123", "کیفیت", "كيفيت", "نیمفاصله"],
time: {instant: "2026-08-13T09:00:00Z", zone: "Asia/Tehran",
jalali: "نمایشی/غیرمحاسباتی"},
realPersonWorkerOrgProductJobPerformanceHiringPaymentOutcome: false
};
const groups = {
identity: ["roleCharterId","version","status","effectiveFrom","asOf","owner","reviewAt","supersedes","sourceOfRecord","correctionRoute"],
context: ["roleTitle","level","mode","product","service","beneficiaries","desiredOutcomes","riskClass","lifecycle","cadence","architecture","platform","thirdParties","data","environment","teamSize","timeZone","locale","constraints","unknowns"],
mission: ["mission","expectedOutcomes","nonOutcomes","qualityAttributes","riskClaims","harmFloor","evidencePurpose","notClaimed"],
responsibility: ["responsibilityId","outcomeOrRisk","task","trigger","frequency","complexity","inputs","method","workProduct","evidence","accountableRole","responsibleRoles","consulted","informed","dependencies","handoff","serviceExpectation","notResponsible","claimLimit"],
authority: ["decisionType","decisionOwner","authoritySource","qaAuthority","qaNoAuthority","pauseRight","stopRight","escalation","fallback","riskAcceptanceOwner","releaseOwner","override","exception","exceptionExpiry","dissent","conflictOfInterest"],
terminology: ["testingDefinition","qaDefinition","qcDefinition","debuggingDefinition","verificationDefinition","validationDefinition","glossarySource","localUsage","noProcessReactiveBinary","noTitleInference"],
capability: ["capabilityId","name","definition","criticalTaskRefs","riskIfMissing","observableBehaviors","workProducts","levelScale","currentEvidence","freshness","confidence","essentialNow","trainable","toolSubstitutable","primary","backup","busFactor","learningTask","practice","feedback","transfer","assessor","privacy","capabilityReview"],
skills: ["domain","product","testAnalysis","testDesign","exploration","automation","api","dataSkill","codeSkill","ci","environmentSkill","observability","accessibility","security","performance","reliability","evidenceSynthesis","uncertainty","reporting","listening","questioning","dissentSkill","handoffSkill","systemsLearning"],
level: ["levelId","taskComplexity","ambiguity","consequence","guidanceNeeded","decisionBoundary","levelEscalation","scope","evidenceQuality","crossRoleInterface","improvement","coaching","levelPrimaryBackup","examples","counterexamples","alternativePaths","promotionEvidence","levelNotUsedFor"],
lifecycle: ["discovery","design","codeReview","unit","contract","pipeline","preproduction","explorationLifecycle","specialty","rollout","production","monitoring","incident","supportFeedback","outcomeReview","feedbackToControl"],
interface: ["interfaceId","parties","purpose","interfaceTrigger","interfaceInput","ready","interfaceWorkProduct","acceptance","questionOwner","evidenceOwner","interfaceDecisionOwner","interfaceAuthority","interfaceStop","interfaceEscalation","interfaceFallback","channel","responseExpectation","interfaceZone","handoffState","ack","interfaceUnknown","interfaceDissent","privacySecurity","retention","interfaceCorrection","interfaceMeasure","interfaceReview"],
allocation: ["embedded","central","federated","enabling","platformTeam","independentAssurance","noDedicatedTester","modelFit","modelRisk","skillScarcity","independenceNeed","queueRisk","priorityConflict","modelReview"],
automation: ["automationPurpose","checkVsTest","stimulus","setup","execution","observation","comparison","generation","reporting","productionCodeOwner","unitOwner","contractOwner","frameworkOwner","platformOwner","e2eOwner","specialtyOwner","dataOwner","environmentOwner","triageOwner","retirementOwner","buildMaintainOperateRespond","tco","falseResults","automationLimit"],
independence: ["creatorTest","peerTest","teamTest","independentTeam","externalSpecialist","independenceBenefit","independenceCost","contextLoss","biasRisk","independenceLevel","independenceRationale","independenceReview"],
evidence: ["packId","charterVersion","window","outcomeRiskRefs","responsibilityRefs","taskRefs","workProductRefs","evidenceManifests","findings","evidenceUnknowns","decisionsInfluenced","interfaces","blockers","capabilityEvidence","support","learningTransfer","systemMeasures","denominators","guardrails","incidentsEscapes","alternatives","contributionClaim","contributionConfidence","evidenceNotClaimed"],
metrics: ["metricId","question","definition","unit","numerator","denominator","population","window","exclusions","source","schema","missing","late","threshold","owner","limitation","countermetric","noBugCountPerformance","noCaseCountPerformance","noAutomationPercentPerformance","noPassRatePerformance","noPeopleRanking"],
job: ["jobRoleId","jobTitle","jobLevel","locationMode","jobVersion","jobMission","jobOutcomes","jobNonOutcomes","jobCriticalTasks","decisionsSupported","jobWorkProducts","jobAuthority","jobNoAuthority","jobInterfaces","onCall","essentialCapabilities","trainableCapabilities","evidenceExamples","toolsAsContext","workingConditions","accommodationRoute","language","jobTimeZone","performanceEvidence","jobPrivacy","growthPaths","qualifiedLocalFields","hiringAssessmentTrace","jobReview","changeHistory"],
growth: ["icPath","managerPath","domainPath","technicalPath","specialistPath","evidencePath","peopleManagementBoundary","roleExperiment","sponsorship","trainingInCapacity","growthEvidence","growthReview"],
governance: ["sharedContribution","explicitAccountability","productAuthority","designAuthority","engineeringOwnership","operationsOwnership","securityAuthority","privacyAuthority","legalAuthority","testCapabilityOwner","qualityLeaderBoundary","managerBoundary","qualifiedSpecialistRoute","noUniversalGate"],
locale: ["utf8","rtl","ltr","bidi","zwnj","persianYeh","arabicYeh","persianKaf","arabicKaf","persianDigits","arabicDigits","latinDigits","irrCanonical","tomanLabel","utcInstant","ianaZone","jalaliPresentationOnly"],
review: ["reviewId","plannedAt","heldAt","participants","charterStillFit","responsibilitiesDelivered","authorityGaps","capabilityGaps","interfaceFailures","allocationFit","evidenceQuality","burden","privacy","safety","sideEffects","decision","actions","actionOwners","due","reopen","correction","reissue","affectedRecords"],
limits: ["notDefectFreeProof","notQualityProof","notPreventionProof","notSpeedProof","notRoiProof","notCostSavingProof","notCustomerSatisfactionProof","notSuccessProof","notIndividualPerformanceProof","notCompetenceProof","notHiringDecision","notLegalAdvice","notIranCompliance","notUniversalRole","noRealTarget"]
};
const required = Object.entries(groups).flatMap(([g,xs]) => xs.map(x => `${g}.${x}`));
const supplied = new Set(fixture.controls || []);
const missing = required.filter(x => !supplied.has(x));
const superficial = fixture.superficial.length === 7
? "STRATEGIC_QA_ENGINEER_PRODUCT_QUALITY_GUARANTEED" : "INCOMPLETE";
console.log(superficial);
console.log(`HOLD-${missing.length}`);
console.log(new Set(required).size === required.length ? "UNIQUE" : "DUPLICATE");
console.log(fixture.realPersonWorkerOrgProductJobPerformanceHiringPaymentOutcome === false
? "NO_REAL_TARGET_PASS" : "STOP_REAL_TARGET");
fixture.controls = [...required];
const remaining = required.filter(x => !new Set(fixture.controls).has(x));
console.log(remaining.length === 0
? "READY_FOR_QA_ROLE_CAPABILITY_REVIEW-0" : `HOLD-${remaining.length}`);
Checker سطحی هفت شعار را میبیند و بهاشتباه STRATEGIC_QA_ENGINEER_PRODUCT_QUALITY_GUARANTEED میسازد. اجرای مستقل، دقیقاً ۳۹۹ کنترل یکتا را غایب یافت و HOLD-399 داد؛ آزمون جدا نیز با NO_REAL_TARGET_PASS نبود هر فرد، کارمند، سازمان، Product، شغل، عملکرد، استخدام، پرداخت یا Outcome واقعی را تأیید کرد. پس از pin شدن همه کنترلهای خیالی، READY_FOR_QA_ROLE_CAPABILITY_REVIEW-0 فقط آمادگی fixture برای Review است.
ضدالگوهای تعریف نقش QA
- QA به عنوان نگهبان، پلیس، بازرس نهایی، ترمز یا لایه محافظ؛
- QA به عنوان معمار همه فرایند و پیشگیریکننده همه defectها؛
- تستر به عنوان کاربر واقعی یا صدای همه کاربران؛
- عنوان شغلی به جای Task/Outcome/Authority؛
- QA=process/proactive و Testing=product/reactive به صورت مطلق؛
- هر کسی بدون skill/support یا فقط متخصص QA مجاز به Testing؛
- برنامهنویسی به عنوان ضرورت همه یا نشانه seniority؛
- Manual و Automation به عنوان دو رقیب کامل؛
- انسان بیرقیب یا Automation دقیق/سریع/پوششبالا به صورت ذاتی؛
- Shift-left مساوی حضور QA از روز اول در همه جلسهها؛
- صد برابر هزینه defect به عنوان قانون جهانی؛
- QA ذاتاً مانع یا accelerator؛
- suite سبز مساوی اعتماد، quality یا release safety؛
- QA approval مساوی Risk acceptance یا Release؛
- کیفیت مسئولیت همه بدون accountable owner؛
- Dedicated QA مساوی انتقال Testing از Developer؛
- No QA team مساوی نبود نیاز به test capability؛
- استقلال کامل همیشه بهتر؛
- Bug/Case/Pass/Automation count برای رتبهبندی فرد؛
- Tool list بلند به جای Capability؛
- توجه به جزئیات/ذهنیت/همدلی به عنوان trait قابل سنجش؛
- Senior مساوی سال، manager یا automation coder؛
- یک مسیر رشد اجباری از manual به automation به management؛
- مسئولیت بدون اختیار، capacity، input یا handoff؛
- Role Charter بدون review/change/correction؛
- تضمین ROI، کیفیت، رضایت، برند یا موفقیت پروژه.
چکلیست بازبینی Role Charter
- RoleID، version، status، effectiveFrom، owner و review ثبت شدهاند.
- Product/Service/Outcome/Risk/Lifecycle/Architecture/Locale پین شدهاند.
- Mission، Expected outcome و Non-outcome روشناند.
- هر Responsibility به Task/Trigger/Input/Method/Work Product/Evidence وصل است.
- Accountable/Responsible/Consulted/Informed و dependency مشخصاند.
- Decision، Pause، Stop، Escalation، Override و Risk owner مبهم نیستند.
- عنوان QA به authority یا competence تبدیل نشده است.
- Testing/QA/QC/Debugging واژگان محلی و منبع دارند.
- هفت کلیشه با سؤال Contextual جایگزین شدهاند.
- Capability از Critical Task و Risk استخراج شده است.
- سطح capability رفتار/Work Product و Evidence دارد.
- Essential-now، Trainable و Tool-substitutable جدا هستند.
- کدنویسی فقط در سطح لازمِ Task درخواست شده است.
- Primary/Backup/Bus Factor و یادگیری در ظرفیت وجود دارد.
- Level با complexity/ambiguity/consequence/autonomy تعریف شده است.
- Discovery تا Production/Incident برای Evidence مناسب route شده است.
- Interfaceها Ready/Ack/SLA/Handoff/Unknown/Dissent دارند.
- Gate/Sign-off/Release/Acceptance مرز صریح دارند.
- Allocation model با fit/risk/queue/independence بازبینی شده است.
- Automation ownership ساخت/نگهداری/عملیات/پاسخ/بازنشستگی دارد.
- Independence با benefit/cost/context loss انتخاب شده است.
- Evidence Pack Contribution را از Outcome attribution جدا میکند.
- Metricها سؤال/تعریف/مخرج/window/limit/guardrail دارند.
- هیچ people ranking از Activity count ساخته نمیشود.
- Job description قابل اجرا، accessible و دارای local-qualified fields است.
- IC/Manager/Specialist growth paths معتبرند.
- Review اثر جانبی، burden، privacy و authority gap را میبیند.
- Correction/Reissue/Affected records و Change history فعالاند.
Pilot سیروزه بدون کارمند یا شغل واقعی
با تیم و محصول کاملاً ساختگی شروع کنید. هفته اول Context/Outcome/Risk و واژگان را تثبیت کنید. هفته دوم Responsibility/Authority/Interface را برای Checkout خیالی بسازید. هفته سوم Capability/Level/Allocation/Automation ownership را tabletop کنید. هفته چهارم Evidence Pack، تغییر Role، metric safeguards و validator را ممیزی کنید.
- روز ۱–۵: Title را کنار بگذارید و Critical Task/Decision/Work Product استخراج کنید.
- روز ۶–۱۰: RACI+Authority+Stop+Escalation و no-authority را بنویسید.
- روز ۱۱–۱۵: Capability/level/evidence/backup و job description خیالی بسازید.
- روز ۱۶–۲۰: Embedded/Central/Federated/No-dedicated نقش را روی یک Risk مقایسه کنید.
- روز ۲۱–۲۵: Automation/interface/evidence pack و incident feedback را تمرین کنید.
- روز ۲۶–۳۰: Role را تغییر، stale records را پیدا و correction/reissue را اجرا کنید.
جمعبندی
نقش مهندس تضمین کیفیت نه «فقط باگیاب» است و نه به طور خودکار استراتژیست، معمار فرایند، وکیل کاربر یا تضمینکننده کیفیت. Role از Context، Outcome، Risk، Task، Work Product، Authority، Interface و Capability ساخته میشود. یک عنوان خوب نمیتواند جای این قرارداد را بگیرد.
سازمان بالغ Contribution کیفیت را توزیع و accountability را نامگذاری میکند. QA میتواند سؤال، مدل، testability، Evidence، challenge و learning را تقویت کند؛ Developer و دیگر نقشها Testing خود را حفظ میکنند؛ و صاحب ریسک تصمیم میگیرد. نتیجه، قابلیت قابل بازبینی است—نه وعده محصول بدون defect، سرعت بیشتر یا موفقیت قطعی.
سؤالات متداول درباره نقش مهندس QA
تفاوت QA Engineer و Software Tester چیست؟
تعریف جهانی ثابتی ندارد. بعضی شرکتها آنها را مترادف و بعضی QA Engineer را دارای مسئولیت tooling/process/capability گستردهتر میدانند. Title را کافی ندانید؛ Critical tasks، Outcomes، Work Products، Authority، Level و interfaces شرح نقش را مقایسه کنید.
آیا مهندس QA حتماً باید کدنویسی بلد باشد؟
فقط اگر Critical Taskهای نقش به آن نیاز دارند. نوع و سطح را روشن کنید: خواندن، تغییر، نوشتن check، طراحی framework، debug یا review. برای برخی Roleها Domain، پژوهش، accessibility یا evidence synthesis مهمتر است؛ یادگیری لازم باید در ظرفیت رسمی قرار گیرد.
اگر کیفیت مسئولیت همه است، چرا QA لازم است؟
مسئولیت مشترک تخصص را حذف نمیکند. QA میتواند در risk/test modelling، exploration، evidence، tooling و independent challenge عمق بیاورد. اما نیاز به Dedicated QA به Risk و capability تیم بستگی دارد؛ اگر این عنوان وجود ندارد، باید مالک و Evidence تامین همان قابلیتها معلوم باشد.
آیا QA باید انتشار را تأیید کند؟
نه به صورت پیشفرض. QA معمولاً Evidence و recommendation میدهد و ممکن است در دامنه تعریفشده Gate یا Stop authority داشته باشد. Release و پذیرش residual risk باید صاحب اختیار، criteria، Unknown، condition، expiry، guardrail و rollback روشن داشته باشد.
چطور اثربخشی مهندس QA را بسنجیم؟
از Outcome/Risk و Contribution مورد انتظار شروع کنید؛ Activity، Output، Evidence quality، decision use، feedback latency، system burden و guardrail را با تعریف/مخرج/window بسنجید. Bug count، تعداد Test Case، Pass rate یا Automation percentage را به امتیاز فرد تبدیل نکنید و Outcome مشترک را علیت QA ننامید.
