«استارتاپ بهتر است یا بانک؟» پرسش جذابی است، اما واحد تصمیم اشتباهی دارد. نام صنعت یا نوع مالکیت، قرارداد، مدیر، دامنهٔ نقش، پرداخت بهموقع، بار On-call یا بلوغ تست یک پیشنهاد مشخص را تضمین نمیکند. برای انتخاب شغل QA در ایران باید دو Offer واقعی را با تعریف، تاریخ و شاهد یکسان مقایسه کرد؛ نه دو تصویر ذهنی را.
این راهنما یک فرایند Due Diligence برای بازار کار تست نرمافزار میسازد: نیازهای شما، Hard Gateها، Role Charter، Capability، جبران خدمات، قرارداد، ریسک کار، رشد و امکان خروج را ثبت میکند؛ Unknown را پنهان نمیکند؛ و نتیجه را در Decision Record قابلبازبینی نگه میدارد. مقاله رتبهبندی کارفرما، مشاورهٔ حقوقی/مالی یا تضمین استخدام نیست.
پاسخ کوتاه: Offer را انتخاب کنید، نه برچسب سازمان را
- استارتاپ ممکن است Role محدود، فرایند منظم و پرداخت پایدار داشته باشد؛ یا برعکس.
- بانک، شرکت پیمانکار بانکی و دستگاه دولتی سه رابطهٔ استخدامی یکسان نیستند.
- ابزار جدید، مستندات زیاد، عنوان Senior یا حقوق اسمی هیچکدام بهتنهایی کیفیت شغل را نشان نمیدهند.
- مقایسه فقط وقتی معتبر است که دوره، واحد پول، ناخالص/خالص، ساعات، Scope و سطح نقش همسان باشند.
- هر ادعای بدون سند باید `UNKNOWN` بماند و در سناریوی محافظهکارانه امتیاز نگیرد.
Decision = HardGatesPass AND EvidenceEnough AND PreferredScenarioAcceptable Label(startup|bank|government) != Decision UNKNOWN != YES InterviewPromise != WrittenOffer
مالکیت موضوع و مرز این مقاله
این صفحه مالک «مقایسهٔ پیشنهاد شغلی QA» است. تعیین عدد حقوق و مذاکره، ساخت رزومه، پاسخ مصاحبه، پورتفولیو و نقشهٔ بلندمدت هرکدام فرایند جدا دارند. اینجا خروجی آن فرایندها را به یک انتخاب Offer متصل میکنیم و از تکرار نسخههای عمومی مانند «اول استارتاپ، بعد بانک» پرهیز میکنیم.
مرز زمانی بازار ایران
حقوق، مزایا، حداقلهای قانونی، مالیات، بیمه، وضعیت دورکاری و دسترسی ابزار در ایران زمانحساساند. Snapshot منابع این مقاله ۲۳ مرداد ۱۴۰۵، برابر با ۱۴ اوت ۲۰۲۶ است. هر عدد باید با `source_as_of`، شهر، سطح، جامعه، نوع عدد و واحد نگهداری شود. دادهٔ پارسال یا عدد بدون تعریف نباید با Offer امروز جمع یا مقایسه شود.
منابع چه میگویند و چه نمیگویند؟
گزارش حقوق و دستمزد ۱۴۰۵ ایرانتلنت میگوید داده از خوداظهاری شاغلان و فهرست حقوق بینام شرکتها گردآوری، پاکسازی و بر اساس گروه/رده طبقهبندی شده و آخرین بهروزرسانی آن مرداد ۱۴۰۵ است. این روششناسی برای Benchmark مفید است، اما نمایندهٔ قطعی تمام کارفرمایان، شهرها و تخصصها نیست.
صفحهٔ حقوق میدلول تست نرمافزار ۱۴۰۵ در Snapshot حاضر مقدار ۶۰ میلیون تومان را برای تهران/میدلول نمایش میدهد و خود صفحه میان «میانگین» و «میانهٔ مورد انتظار» واژهگذاری یکدستی ندارد. پس آن را رقم تضمینی، حقوق خالص، نرخ تمام ایران یا تفاوت استارتاپ و بانک تلقی نکنید؛ تعریف فیلد و نمونه را پیش از استفاده ثبت کنید.
واژگان پایه: Employer، Workplace و Client
- Legal Employer: شخص حقوقی درجشده در Offer/قرارداد و فهرست بیمه.
- Workplace: محل یا سازمانی که کار روزانه در آن انجام میشود.
- Client: مشتری محصول یا پیمانکار؛ ممکن است بانک باشد ولی کارفرمای شما نباشد.
- Role: مجموعهٔ Outcome، مسئولیت، اختیار و Interface؛ نه فقط عنوان.
- Offer: پیشنهاد تاریخدار با اقلام روشن؛ نه وعدهٔ شفاهی Recruiter.
اگر شرکتی شما را برای کار در یک بانک میگیرد، سیاست مزایا، تمدید، دسترسی و خروج ممکن است متعلق به پیمانکار باشد. عبارت «کار در بانک» بدون Employer و Contract Chain، دادهٔ تصمیم نیست.
چرا نوع سازمان Proxy ضعیفی است؟
«استارتاپ» اندازه، مرحلهٔ تأمین مالی، محصول، runway، سبک مدیریت یا بلوغ QA را دقیق تعریف نمیکند. «بانکی» نیز میتواند بانک، هلدینگ فناوری، پیمانکار، شرکت پرداخت یا تیم محصول مستقل باشد. «دولتی» نوع استخدام، بودجه، قرارداد یا سرعت تصمیم را روشن نمیکند. برچسب برای ساخت فرضیه خوب است؛ برای نتیجه کافی نیست.
| ادعای کلیشهای | شاهد لازم در Offer مشخص | اگر شاهد نبود |
|---|---|---|
| استارتاپ سریع یاد میدهد | Task واقعی، Mentor، زمان Practice، دسترسی و Feedback | UNKNOWN |
| بانک امنیت شغلی دارد | Employer، نوع/مدت قرارداد، تمدید، سابقهٔ پرداخت و پروژه | بدون تضمین امنیت شغلی |
| دولت تعادل کار و زندگی دارد | ساعت، حضور، Shift، On-call، اضافهکار و دادهٔ تیم | UNKNOWN |
| استارتاپ ابزار مدرن دارد | Repository/CI/Test Stack، نسخه، Owner و Maintenance | نام ابزار کافی نیست |
| بانک مستند است | نمونهٔ Sanitized از Requirement/Test/Evidence و Freshness | حجم سند ≠ کاربردپذیری |
گردش کار تصمیم از Intake تا Review
- Decision Intake و محدودیتهای شخصی را پیش از دیدن برند ثبت کنید.
- برای هر پیشنهاد Offer Snapshot همنسخه بسازید.
- Hard Gateها را پیش از امتیاز وزنی اجرا کنید.
- ادعاها را به `DOCUMENT`، `OBSERVATION`، `REFERENCE` یا `UNKNOWN` برچسب بزنید.
- جبران خدمات، زمان و هزینهها را به دوره/واحد یکسان نرمال کنید.
- Scenario LOW/BASE/HIGH و حساسیت وزنها را اجرا کنید.
- Decision Record را با فرضها، Dissent و تاریخ انقضا امضا کنید.
- در صورت پیوستن، وعدهها را در روزهای ۷، ۳۰ و ۹۰ بازبینی کنید.
مرحلهٔ صفر: Decision Intake شخصی
وزن خوب برای همه وجود ندارد. رفتوآمد، مسئولیت مراقبتی، نیاز نقدینگی، تحمل نوسان، سلامت، دسترسپذیری، هدف تخصصی و زمان یادگیری را جدا ثبت کنید. جنسیت، تأهل، سن یا «تیپ شخصیتی استارتاپی» جای این دادهها را نمیگیرد و نباید برای امتیازدهی افراد استفاده شود.
DECISION-INTAKE decision_id: DI-... candidate_owner: SELF as_of / review_at: must_have[] / must_not[]: constraints: location, schedule, access, care, health, cashflow goals_12m[] / goals_36m[]: risk_capacity: LOW | MEDIUM | HIGH weight_owner / rationale:
Hard Gate پیش از جمع امتیاز
امتیاز بالا نباید یک ممنوعیت بنیادی را بپوشاند. Gate ممکن است شامل قرارداد قابلخواندن، Employer روشن، پرداخت قابلقبول، دامنهٔ قانونی/اخلاقی کار، دسترسی موردنیاز، ساعت سازگار، عدم درخواست Secret/PII در تمرین استخدامی و نبود تناقض حلنشده باشد. نتیجه فقط `PASS`، `FAIL` یا `UNKNOWN-HOLD` است.
HARD-GATE gate_id / statement: evidence_required: evidence_ref / captured_at: status: PASS | FAIL | UNKNOWN-HOLD exception_owner / rationale / expires_at: recheck_trigger:
Offer Snapshot؛ یک نسخه، یک منبع حقیقت
آگهی، پیام Recruiter، جلسه و فایل Offer ممکن است با هم فرق کنند. Snapshot باید آخرین نسخه و تفاوتها را نگه دارد. وعدهای که در سند نیامده «تأییدشده» نیست؛ با این حال نبودن در سند نیز همیشه به معنی بدعهدی نیست و باید سؤال/اصلاحیه درخواست شود.
OFFER-SNAPSHOT offer_id / version / captured_at / expires_at: legal_employer / workplace / client / location: role_title / level / manager / team: contract_type / start / duration / probation / notice: fixed / variable / benefits / currency / period / gross_net: hours / attendance / remote / shift / oncall / overtime: source_refs[] / conflicts[] / unknowns[]:
هویت کارفرما و زنجیرهٔ قرارداد
- نام و شناسهٔ Legal Employer با امضاکننده، پرداختکننده و بیمهکننده همخوان است؟
- اگر Vendor/پیمانکار وجود دارد، دستور کار، ارزیابی، تمدید و Exit را چه کسی کنترل میکند؟
- محل انجام کار و امکان جابهجایی بین Clientها چیست؟
- مالک تجهیزات، حسابها، داده و Work Product کیست؟
- در پایان قرارداد، دسترسی، مدارک، تسویه و سابقهٔ قابلاثبات چگونه تحویل میشود؟
Role Charter؛ عنوان شغلی را باز کنید
QA Engineer در یک Offer ممکن است تحلیل ریسک و API داشته باشد و در دیگری اجرای چکلیست یا پشتیبانی. Outcome، In-scope/Out-of-scope، Decision rights، پاسخگویی و Handoff را بنویسید. «مسئول کیفیت کل محصول» بدون اختیار و منابع یک ریسک است، نه ارتقای جایگاه.
ROLE-CHARTER-PROBE outcomes[]: in_scope[] / out_of_scope[]: accountabilities[] / authorities[]: interfaces: product, dev, ops, security, support quality_or_release_decision_owner: first_30_60_90_day_outputs: success_evidence / prohibited_people_metrics:
محصول، دامنه و ریسک واقعی
نوع کارفرما را با Product Context عوض نکنید. B2C پرترافیک، Core Banking، پنل داخلی، سامانهٔ سلامت یا محصول آزمایشی Failure Modeهای متفاوت دارند. معماری، تعداد Integrationها، چرخهٔ انتشار، دادهٔ حساس، RTO/RPO، ساعات اوج و Regulatory Interface را در حد مجاز بپرسید؛ اطلاعات محرمانه لازم نیست.
ماتریس Capability، نه فهرست ابزار
راهنمای Testing در SFIA ۹ Functional، Non-functional و Process Testing را جدا میکند و میگوید مهارت بالا در یکی، دیگری را اثبات نمیکند. پس «Selenium بلد باشد» یا «بانک امنیت میخواهد» پروفایل شایستگی نیست.
| Capability | Task/Output قابلمشاهده | سطح استقلال | شاهد محیط |
|---|---|---|---|
| تحلیل/طراحی | Risk، Condition، Oracle، Coverage | Observe تا Lead | Artifact نمونه |
| Functional | UI/API/Integration behavior | با/بدون راهنما | Test environment |
| Non-functional | Performance/Security/Accessibility | اجرا تا طراحی | Tool، data، authority |
| Process/Domain | Workflow و Rule | Clarify تا challenge | SME و source |
| Automation/CI | Oracle، diagnosis، maintenance | Contribute تا own | Repository و pipeline |
| Communication | Finding، risk، decision support | تطبیق با مخاطب | Feedback loop |
CTFL ۴.۰.۱ رسمی نیز مهارت فنی، دانش دامنه، تحلیل/تفکر انتقادی/خلاقیت، ارتباط و کار تیمی را کنار هم میگذارد و استقلال تست را Context-dependent میداند. این منبع شرح شغل شما نیست؛ فقط مانع تقلیل Role به یک Tool یا یک مدل توسعه میشود.
بلوغ سیستم QA را با سؤال رفتاری بسنجید
- یک ریسک کیفیت اخیر چگونه کشف، تصمیم و Follow-up شد؟
- آخرین Pipeline قرمز چگونه از Product failure جدا شد؟
- وقتی Requirement مبهم است، Authority و مسیر Clarification چیست؟
- Test data و Environment چگونه Provision و Reset میشوند؟
- Flake، Test debt و Maintenance چه Owner و ظرفیت دارند؟
- چه کسی Release را تصمیم میگیرد و QA چه Evidence میدهد؟
MATURITY-EVIDENCE question_id / capability: recent_example: artifact_or_observation: owner / cadence / exception: claim_status: CONFIRMED | PARTIAL | UNKNOWN confidence / expiry:
Tool Stack و دسترسی؛ نصب بودن کافی نیست
نسخه، License، دسترسی از ایران، شبکهٔ داخلی، Repository، CI، Browser/device، Environment، Test data، Secret handling و Owner نگهداری را بپرسید. ابزار متنباز الزاماً بدون هزینه و ابزار Enterprise الزاماً مناسب نیست. هیچ حساب، Token یا نمونهٔ Production را برای اثبات ادعا درخواست نکنید.
چرخهٔ تحویل، Shift و On-call
Release روزانه یا سهماهه بهخودیخود خوب/بد نیست. Ask: پنجرهٔ انتشار، Freeze، Hotfix، آخرهفته، Shift، On-call، دفعات واقعی فراخوان، Compensation، Recovery time، Escalation، Backup و اختیار توقف. «گاهی لازم میشود» را به frequency range و دورهٔ مشاهده تبدیل کنید.
WORKLOAD-SNAPSHOT normal_hours / timezone / attendance: release_windows / shift_rotation: oncall_frequency_range / callout_history_period: overtime_request_authority / consent / compensation: recovery_time / backup / escalation: unknowns / source:
مدیر، تیم و Feedback Loop
- مدیر مستقیم کیست و چند گزارش مستقیم دارد؟
- ۱:۱، بازخورد Artifactمحور و مسیر اختلاف چگونه است؟
- Team topology و Interface با Product/Dev/Ops چیست؟
- خطا یا گزارش بدخبر چگونه بدون Blame بررسی میشود؟
- مرخصی، غیبت، Incident و حجم کار چگونه پوشش داده میشود؟
جبران خدمات را به Total Offer تبدیل کنید
حقوق پایه فقط یک مؤلفه است. Fixed، Variable، پاداش تضمینشده/مشروط، زمان پرداخت، بیمه، مالیات/کسورات، اضافهکار، Shift/On-call، کمکهزینه، تجهیزات، مرخصی، وام، سهام، دورهٔ بازبینی و هزینههای رفتوآمد/اینترنت/غذا را جدا نگه دارید. ارزش ادعایی مزایا را با نقد برابر نکنید.
COMPENSATION-LEDGER component_id / label: amount / currency: IRR display_unit: toman (presentation only; 1 toman = 10 IRR) period / gross_net_unknown: fixed_variable / probability / vest_or_payment_date: tax_insurance_treatment_unknown: source / confidence / expiry:
Snapshot حقوق ۱۴۰۵ را درست بخوانید
عدد ۶۰ میلیون تومان صفحهٔ تست میدلول، در تاریخ این ممیزی، برای «مورد انتظار ۱۴۰۵، تهران، Mid-level» است. Offer یک Junior در شیراز، Lead پیمانکار، Senior با On-call یا قرارداد پروژهای Comparator همسان نیست. Sample size، تعریف Mid-level، Fixed/Variable، Gross/Net و صدکهای موردنیاز اگر روشن نیستند، در Comparison Sheet بهصورت Unknown بمانند.
- Median را با Mean جابهجا نکنید.
- Expected pay را با received pay یکی ندانید.
- گروه گستردهٔ IT را نرخ اختصاصی QA معرفی نکنید.
- عدد تهران را بدون تعدیل شهر/دورکاری تعمیم ندهید.
- رشد اسمی را رشد قدرت خرید یا تضمین افزایش Offer ندانید.
ریال، تومان، دوره و زمان پرداخت
واحد قراردادی را canonical IRR نگه دارید و تومان را فقط نمایش با نسبت صریح `۱ تومان = ۱۰ ریال` بدانید. مبلغ ماهانه را بدون دانستن ۱۲/۱۳/۱۴ پرداخت، عیدی/پاداش، تأخیر، تاریخ اولین حقوق و کسورات به سالانه تبدیل نکنید. نرخ تورم یا ارز را برای پیشگویی قطعی Offer به کار نبرید؛ Scenario و تاریخ بازبینی بسازید.
قرارداد و قانون: فقط لایهٔ بررسی، نه فتوا
نسخهٔ فارسی قانون کار ذخیرهشده در NATLEX متن ۲۰۳ مادهای را با حوزههایی مانند قرارداد، شرایط کار، ایمنی، حل اختلاف و شورای عالی کار در دسترس میگذارد. ترجمهٔ انگلیسی ذخیرهشده در NATLEX برای جهتیابی مفید است، اما رکورد NATLEX آن را ترجمهٔ غیررسمی معرفی میکند.
برای Checklist اولیه، هویت طرفین، نوع کار، مزد و لواحق، ساعات/تعطیلات/مرخصی، محل، تاریخ، مدت، دورهٔ آزمایشی، خاتمه، اضافهکار، بیمه و نسخهٔ قرارداد را بررسی کنید. این مقاله مشاورهٔ حقوقی نیست؛ شمول قانون، استثناها، مقررات خاص دستگاهها/مناطق، متن فارسی جاری و محاسبهٔ حق باید در زمان امضا با مرجع رسمی و متخصص واجد صلاحیت تأیید شود.
CONTRACT-CHECK legal_regime / applicability: UNKNOWN until verified parties / job / wage_components / hours / location: start / duration / probation / termination / notice: leave / overtime / shift / insurance / tax: IP_confidentiality_noncompete / equipment / dispute_route: official_source_as_of / qualified_review_ref:
Variable، پاداش، سهام و وام
پاداشی که Formula، Authority، دوره، سابقهٔ تحقق و تاریخ پرداخت ندارد، Fixed نیست. سهام یا Option به تعداد خام محدود نمیشود: نوع ابزار، درصد Fully Diluted، Vesting، Cliff، Exercise، Dilution، Liquidity، مالیات/قانون، خروج و سناریوی صفر را لازم دارد. وام نیز نرخ، وثیقه، قسط، شرط ماندگاری و تسویه هنگام خروج دارد. در نبود پاسخ، ارزش محافظهکارانه میتواند صفر باشد.
مزایا و هزینههای پنهان را همواحد کنید
| مولفه | پرسش نرمالسازی | ریسک Double-count |
|---|---|---|
| بیمه/درمان | پوشش، افراد، سقف، انتظار، سهم کارمند | ارزش تبلیغی ≠ هزینهٔ جایگزین |
| رفتوآمد | روز حضور، زمان، IRR، نوسان | زمان و پول جدا |
| ناهار/اینترنت | واقعاً قابلاستفاده؟ سقف/رسید؟ | داخل Fixed حساب نشده؟ |
| آموزش | بودجه، زمان کاری، Approval، بازپرداخت | وعده ≠ مصرف |
| مرخصی | حق، امکان استفاده، Carry/settlement | روز اسمی ≠ دسترسپذیر |
| دورکاری | سیاست، بازنگری، تجهیزات، محل مجاز | کاهش رفتوآمد ≠ صفر هزینه |
Work Risk و سلامت را فردیسازی نکنید
راهنمای WHO دربارهٔ سلامت روان در کار علاوه بر آموزش فرد/مدیر، مداخلههای سازمانی را پوشش میدهد. بنابراین بار مزمن، کنترل کم، ابهام نقش، رفتار نامناسب، On-call و کمبود حمایت را با توصیهٔ «تابآوری بیشتر» پنهان نکنید. این بخش تشخیص سلامت نیست؛ برای خطر فوری یا نیاز درمانی از مسیر حرفهای/محلی مناسب کمک بگیرید.
WORK-RISK-REGISTER risk_id / observed_condition: exposure_frequency / duration / affected_work: organizational_control / owner: worker_support / confidential_route: signal / counter_signal / review_at: status: OPEN | CONTROLLED | UNKNOWN
رشد را با Practice و Evidence بسنجید
تنوع وظایف میتواند یادگیری یا فقط Context switching باشد. برای هر Capability بنویسید چه Task واقعی، Feedback، Mentor capacity، زمان، Environment و Artifact قابلحملی وجود دارد. دسترسی به Production یا دادهٔ حساس «رشد» نیست. خروجی قابلاثبات باید با NDA، مالکیت فکری و پاکسازی سازگار باشد.
GROWTH-CLAIM capability / current_level / target_level: task_opportunity / frequency: mentor_or_reviewer / feedback_sla: practice_time / tool_access: permitted_sanitized_evidence: transfer_test / review_at:
ثبات شغلی را به Signalهای قابلبررسی تبدیل کنید
- نوع/مدت قرارداد و وابستگی به پروژه یا Client؛
- سابقهٔ پرداخت بهموقع در دورهٔ مشخص، نه شایعه؛
- Turnover نقش/تیم و دلیل خروجها در حد قابلاشتراک؛
- Vacancy جدید یا Replacement و تاریخچهٔ خالی ماندن نقش؛
- بودجه/Runway فقط اگر منبع و مجوز افشا دارد؛
- دانش قابلانتقال، Notice، تسویه و برنامهٔ Exit شخصی.
هیچیک تضمین امنیت شغلی نیست. حتی سازمان بزرگ میتواند پروژه، پیمانکار یا ساختار را عوض کند؛ شرکت کوچک نیز ممکن است قرارداد و جریان نقدی منظم داشته باشد. Confidence و تاریخ انقضا را کنار هر Signal نگه دارید.
مصاحبه را دوطرفه و Evidenceمحور کنید
- یک سؤال در هر نوبت بپرسید و Purpose را بدانید.
- بهجای «فرهنگ خوب است؟» آخرین مثال و Artifact غیرمحرمانه بخواهید.
- پاسخ افراد مختلف را با زمینه و تاریخ ثبت کنید.
- تعارض را به Clarification ببرید، نه اتهام.
- عدم امکان افشای جزئیات محرمانه را محترم بشمارید و شاهد جایگزین بخواهید.
- وعدهٔ مهم را در Offer یا پیوست رسمی درخواست کنید.
Reference Check با رضایت و حداقلگرایی
شبکهسازی برای یافتن تجربهٔ گذشته مفید است، اما نام کارمند، پیام خصوصی، حقوق، وضعیت سلامت یا اتهام را بدون رضایت جمع/منتشر نکنید. یک تجربه شاهد قطعی کل سازمان نیست. Role، بازهٔ زمانی، Team و نوع رابطه را ثبت و Fact را از برداشت جدا کنید.
REFERENCE-NOTE consent_ref / source_relation / period / context: question: fact_or_direct_observation: interpretation: unknown / counterevidence: retention / access / delete_at:
ماتریس امتیاز وزنی با Guardrail
بعد از Gate، معیارها را تعریف کنید: وزنها جمعاً ۱۰۰، جهت امتیاز روشن، شاهد همنسخه و Unknown دارای Penalty یا بازه. معیارهای همپوشان مانند «حقوق»، «رفاه» و «مزایا» را سه بار نشمارید. امتیاز فقط ابزار توضیح است؛ دقت اعشاری به معنی حقیقت نیست.
SCORE-ROW criterion_id / definition / direction: weight / weight_rationale: offer_A_score_range / offer_B_score_range: evidence_refs / confidence: unknown_policy: double_count_check / reviewer:
عدمقطعیت و Scenario LOW/BASE/HIGH
برای Variable، رفتوآمد، On-call، تمدید و زمان یادگیری نقطهٔ واحد نسازید. در `Scenario LOW` تحقق حداقلی و هزینهٔ بالا؛ در BASE شواهد میانی؛ و در HIGH نتیجهٔ خوشبینانه ولی ممکن را قرار دهید. اگر برنده با تغییر کوچک وزن یا یک Unknown عوض میشود، تصمیم Fragile است و Clarification ارزش بیشتری از محاسبه دارد.
SCENARIO scenario: LOW | BASE | HIGH assumptions[] / evidence_refs[]: total_cash_range / time_cost_range: growth_score_range / work_risk_range: result / margin: flip_variables[] / next_information_value:
Red Flag، Yellow Flag و Unknown را جدا کنید
- Red: جعل/فریب روشن، درخواست Secret/دادهٔ واقعی، کار غیرمجاز، تناقض بنیادی حلنشده یا Gate fail.
- Yellow: ابهام قابلحل، فرایند نارس، وابستگی بالا یا وعدهٔ بدون Owner.
- Unknown: داده نداریم؛ نه اتهام و نه امتیاز مثبت.
- Trade-off: عیب مطلق نیست؛ مثلاً حضور بیشتر در برابر دسترسی بهتر به تیم.
فشار برای پاسخ سریع ممکن است واقعی باشد؛ زمان انقضای Offer را ثبت و تمدید محدود بخواهید. نامطمئن بودن را با انتشار عمومی اتهام یا استخراج اطلاعات محرمانه جبران نکنید.
Decision Record؛ چرا این Offer؟
DECISION-RECORD decision_id / decided_at / offer_versions: hard_gate_result: chosen_option / rejected_options: top_evidence[] / assumptions[] / unknowns[]: scenario_results / sensitivity: dissent / residual_risks / mitigations: decision_owner / review_trigger / expires_at:
«Offer A انتخاب شد چون در BASE پنج امتیاز بیشتر بود» کافی نیست. دلیل، Margin، متغیرهای Flip، ریسک باقیمانده و برنامهٔ کاهش را بنویسید. زندگی تغییر میکند؛ تصمیم خوب لزوماً Outcome خوب ایجاد نمیکند و Outcome بد نیز بهتنهایی فرایند تصمیم را باطل نمیکند.
Clarification، مذاکره و Handoff
ابهامها را اولویتبندی و برای هرکدام سؤال، Owner و Deadline بسازید. تغییر Role، مبلغ، تاریخ شروع، دورکاری یا On-call باید در نسخهٔ جدید سند ثبت شود. Acceptance شفاهی، ایمیل، امضای قرارداد و شروع کار Stateهای جدا هستند. تا زمانی که الزام فعلی روشن نشده، استعفا یا تعهد برگشتناپذیر را بر فرض شفاهی بنا نکنید.
CLARIFICATION-HANDOFF question_id / affected_gate_or_score: asked_to / asked_at / due_at: response / evidence_ref: offer_version_changed: accepted_by / acceptance_scope: state: OPEN | ANSWERED | SUPERSEDED | EXPIRED
رد محترمانه و نگهداری داده
برای رد Offer، پیام کوتاه و بدون افشای Scorecard کافی است. دادهٔ مصاحبهکننده، شماره، ایمیل، سند محرمانه و Reference Note را فقط تا مدت لازم و با دسترسی محدود نگه دارید. Decision Record شخصی میتواند ادعاها را خلاصه کند، اما نباید به پروندهٔ مخفی افراد یا رتبهبندی عمومی کارفرمایان تبدیل شود.
بازبینی پس از پیوستن
- روز ۷: Employer، دسترسی، مدیر، Role و ساعت با Snapshot همخوان است؟
- روز ۳۰: Capability opportunity، QA flow، On-call و Feedback چه شاهدی دارد؟
- روز ۹۰: وعدهها Confirm/Dispute/Unknown و Riskها Keep/Adapt/Escalate/Exit شوند.
- تفاوت مادی را با تاریخ و سند اصلاح کنید؛ حافظه را Source of Record نکنید.
- بازبینی برای یادگیری فرایند است، نه اثبات «انتخاب درست» یا امتیازدهی افراد.
آزمایشگاه آفلاین ایرانی SYN-QA-OFFER-IR-۰۱
دو Offer کاملاً ساختگی A و B برای یک Candidate خیالی ساخته میشوند. هیچ نام شرکت/بانک/دستگاه، فرد، آگهی، حساب، قرارداد، حقوق واقعی، Repository، Production یا دادهٔ شخصی وجود ندارد. مبالغ صرفاً Fixture و canonical IRR هستند؛ تومان فقط نمایش ۱:۱۰. تاریخها UTC و نمایش Asia/Tehran دارند و جلالی فقط Presentation است.
LAB SYN-QA-OFFER-IR-01 A: fictional product team; IRR 720,000,000 fixed; variable UNKNOWN B: fictional regulated vendor; IRR 650,000,000 fixed; benefit use UNKNOWN digits: 720000000 | ۷۲۰۰۰۰۰۰۰ | ٧٢٠٠٠٠٠٠٠ unicode: ی/ي, ک/ك, ZWNJ, RTL/LTR/Bidi time: 2026-08-14T08:30:00Z -> Asia/Tehran view real_entity=false; real_person=false; application_sent=false
Checker سطحی فقط برچسبها را میبیند و `STARTUP_FAST_LEARNING_BANK_STABLE_HIGH_SALARY_GOVERNMENT_WORK_LIFE_MIGRATION_READY` برمیگرداند. ممیزی قرارداد ناقص ۱۲۸ کنترل هویت، Role، جبران، کار، شاهد، عدمقطعیت، حریم خصوصی و تصمیم را نمییابد و `HOLD-ONE-TWO-EIGHT` میدهد. سپس همهٔ Fieldهای Fixture با دادهٔ ساختگی، Source و Unknown policy کامل میشوند.
خروجی Validator و مرز ادعا
Safety rule مستقل نتیجه میدهد: `NO_REAL_EMPLOYER_CANDIDATE_JOB_APPLICATION_CONTRACT_SALARY_PII_ACCOUNT_CREDENTIAL_PRODUCTION_SYSTEM_OR_HIRING_DECISION_PASS`. پس از تکمیل ساختار، خروجی فقط `READY_FOR_QA_JOB_OFFER_EVIDENCE_REVIEW-ZERO` است؛ نه اثبات صداقت Offer، ثبات شغلی، درآمد آینده، سلامت محیط، رشد، رضایت، مهاجرت، انطباق حقوقی یا درستبودن انتخاب.
Anti-patternهایی که باید حذف شوند
- انتخاب بر اساس لوگو، صنعت یا توصیهٔ یک نفر؛
- تعمیم «استارتاپ سریع/بانک امن/دولت آرام»؛
- مقایسهٔ Gross با Net یا IRR با تومان؛
- جمع Fixed و Variable با احتمال ۱۰۰٪؛
- ارزشگذاری سهام بدون سناریوی صفر؛
- نادیده گرفتن رفتوآمد، On-call و تأخیر پرداخت؛
- امتیاز مثبت دادن به Unknown؛
- پوشاندن Gate fail با حقوق بالاتر؛
- عنوان شغلی بهجای Role Charter؛
- نام ابزار بهجای Task و Maintenance؛
- وعدهٔ مصاحبه بهجای Offer version؛
- تشخیص شخصیت/سلامت یا توصیه بر مبنای تأهل؛
- جمعآوری PII و اطلاعات محرمانه برای Reference؛
- تضمین مهاجرت از نوع کارفرما؛
- تبدیل Score به حقیقت اعشاری یا رتبهبندی عمومی.
چکلیست Owner پیش از پاسخ
- Decision Intake و وزنها قبل از برند ثبت شد.
- Legal Employer، Workplace و Client جدا هستند.
- Offer نسخه، انقضا و تعارض منابع دارد.
- Hard Gateها PASS یا Hold شدهاند.
- Role Outcome/Scope/Authority روشن است.
- Capability با Task و Evidence سنجیده شد.
- QA maturity مثال رفتاری دارد.
- ساعت، Shift، On-call و Recovery ثبت شد.
- Fixed/Variable/Benefit جدا و همدورهاند.
- IRR canonical و تومان presentation-only است.
- Benchmark سال/شهر/سطح/نمونه/تعریف دارد.
- قرارداد از منبع جاری و متخصص بررسی میشود.
- Work Risk کنترل سازمانی و مسیر حمایت دارد.
- رشد با Practice/Feedback/Transfer سنجیده شد.
- ثبات تضمین نشده و Signal تاریخدار است.
- Reference با رضایت و حداقل داده است.
- Unknown policy و LOW/BASE/HIGH اجرا شد.
- Double-count و حساسیت وزن بررسی شد.
- Decision Record ریسک/فرض/Dissent/Review دارد.
- هیچ اقدام واقعی یا افشای محرمانه در Lab نبود.
مطالعهٔ بعدی در خوشهٔ شغلی QA
برای مسیر کلی از نقشهٔ مسیر شغلی QA، برای مرزبندی نقش از Role Charter مهندس QA و برای Benchmark و توافق از حقوق تست نرمافزار در ایران استفاده کنید.
در مرحلهٔ اقدام، رزومهٔ QA مبتنی بر Evidence، پروتکل پاسخ مصاحبه و پورتفولیوی امن QA را ببینید. برای افق مهارتی و ریسک کار نیز Capability Portfolio آیندهٔ QA و راهنمای Work Risk و فرسودگی QA مکملاند.
سؤالات متداول بازار کار تست نرمافزار
آیا برای تستر تازهکار، استارتاپ همیشه انتخاب بهتری است؟
خیر. تازهکار به Task امن، Mentor دارای ظرفیت، Feedback، دسترسی و Scope متناسب نیاز دارد. یک شرکت بزرگ ممکن است اینها را بهتر فراهم کند و یک استارتاپ ممکن است فقط چند نقش را روی یک نفر بگذارد؛ یا برعکس. Offer مشخص را با Growth Claim و Role Charter بسنجید.
حقوق QA در بانک بیشتر است یا استارتاپ؟
از نوع سازمان نمیتوان نتیجه گرفت. Employer، سطح، شهر، Fixed/Variable، مزایا، ساعات، پیمانکاری و تاریخ مهماند. گزارش ۱۴۰۵ فقط Benchmark نمونهای است؛ دو Offer را با Compensation Ledger و سناریوی همسان مقایسه کنید.
آیا بانک و دولت امنیت شغلی و تعادل بیشتری دارند؟
تضمینی نیست. نوع قرارداد، Client dependency، پرداخت، Shift، On-call، حضور و دادهٔ همان تیم لازم است. «بزرگ» یا «دولتی» میتواند یک Signal زمینهای باشد، اما جای Contract Chain و Workload Snapshot را نمیگیرد.
چطور وعدههای شفاهی مصاحبه را لحاظ کنیم؟
آنها را با گوینده، تاریخ، Scope و Confidence ثبت کنید، اما `DOCUMENTED` ننامید. برای موارد مادی Clarification کتبی یا نسخهٔ اصلاحشدهٔ Offer بخواهید. اگر پاسخ ممکن نیست، Unknown policy و Scenario محافظهکارانه اجرا شود.
آیا سابقهٔ استارتاپی مهاجرت کاری را آسانتر میکند؟
نوع کارفرما تضمین مهاجرت نیست. Route، کشور، Occupation، زبان، Eligibility، Sponsor، Evidence وظایف و زمان تصمیم میگیرند. تجربهٔ قابلاثبات و انتقالپذیر ممکن است کمک کند، اما باید مستقل از برچسب سازمان بررسی شود.
جمعبندی: انتخاب خوب، پروندهٔ قابل اصلاح دارد
بازار کار تست نرمافزار ایران یک دوگانهٔ ساده نیست. استارتاپ، بانک، دولت، پیمانکار و شرکت محصولی فقط Context اولیهاند. تصمیم قابلدفاع از Offer Snapshot، Hard Gate، Role/Capability، قرارداد، Total Compensation، Work Risk، Evidence، Unknown و Scenario ساخته میشود. پرونده را تاریخدار نگه دارید، از دادهٔ شخصی و محرمانه محافظت کنید و وقتی شاهد عوض شد، نتیجه را بدون شرم اصلاح کنید.
