سوالات مصاحبه ارشد QA و SDET؛ ۲۰ سناریو با پاسخ

در مصاحبه Senior QA می‌پرسند: «برای Checkout میکروسرویسی استراتژی تست طراحی کن.» پاسخ ضعیف با فهرست Selenium، Postman، JMeter و Jenkins شروع می‌شود. پاسخ ارشد ابتدا می‌پرسد: مسیر حیاتی کدام است، واحد پول ریال است یا تومان، پرداخت پس از Timeout چه Stateی دارد، چه کسی ریسک را می‌پذیرد و برای تصمیم انتشار چه Evidenceی لازم است. Senior بودن با تعداد ابزارهایی که نام می‌برید سنجیده نمی‌شود؛ با کیفیت سؤال، Trade-off و شواهدی که طراحی می‌کنید دیده می‌شود.

این راهنما شامل ۲۰ سوال مصاحبه ارشد QA و سوال مصاحبه SDET است. «پاسخ طلایی» واحدی وجود ندارد؛ Context شرکت، محصول و نقش فرق می‌کند. برای هر سناریو می‌بینید چه شایستگی‌ای سنجیده می‌شود، پاسخ قوی چه مسیری دارد و کدام جمله‌ها علامت خطرند.

خلاصه اجرایی: پاسخ ارشد از Context و Unknown شروع می‌شود، Risk را به Evidence و Oracle وصل می‌کند، گزینه‌ها و هزینه‌ها را مقایسه می‌کند، مالک تصمیم را روشن می‌سازد و با نتیجه/یادگیری پایان می‌دهد. اگر تجربه مستقیم ندارید، صادقانه مرز دانش را بگویید و روش اعتبارسنجی ارائه کنید؛ ادعای ساختگی، عدد بی‌منبع و «همه‌چیز را اتوماتیک می‌کنم» امتیاز فنی نیست.

Senior QA و Senior SDET دقیقاً چه تفاوتی دارند

این عنوان‌ها استاندارد جهانی با Scope ثابت نیستند. در یک شرکت Senior QA یک Test Strategist کدنویس است؛ در شرکت دیگر رهبر اجرای دستی یا Quality Coach. SDET ممکن است مالک Framework باشد، یا مهندس نرم‌افزاری که Testability، ابزار، CI و Reliability می‌سازد. به‌جای حفظ تعریف عنوان، Role Contract را روشن کنید. برای تعریف بنیادی و مسیر شغلی، راهنمای SDET را ببینید.

پیش از پاسخ، بپرسید مصاحبه‌گر کدام نسخه از نقش را می‌سنجد. «من هر دو کار QA و SDET را انجام می‌دهم» بدون Scope، پاسخ نیست.

مصاحبه ارشد را با Rubric ببینید، نه حدس ذهن مصاحبه‌گر

راهنمای Structured Interview در OPM بر پرسش‌های شغلی یکسان و Rating scale مشترک تأکید دارد. برای داوطلب، معنایش این است که پاسخ را به شایستگی قابل‌مشاهده تبدیل کند؛ برای مصاحبه‌گر، یعنی «اعتمادبه‌نفس»، شباهت به خود یا نام ابزار جای Evidence را نگیرد.

امتیازها را «جمع ساده حقیقت» ندانید. Competency و حداقل لازم باید پیش از دیدن داوطلب از Job analysis بیاید؛ یک نقش SDET کدنویس و یک QA Lead وزن یکسان ندارند.

چارچوب CARE برای پاسخ فنی و STAR+E برای تجربه

CARE برای سناریوی فنی

1. Context & Constraints: کاربر، سیستم، تصمیم، زمان، بودجه، قانون، محیط و Unknown را روشن کنید.
2. Assumptions & Risks: فرض‌ها را نام ببرید، Failure/Impact و اولویت را مدل کنید.
3. Response & Trade-offs: چند گزینه، Test level، داده، محیط، Automation، مالک و هزینه را مقایسه کنید.
4. Evidence & Evolution: Oracle، Artifact، Gate، Production feedback، معیار موفقیت و مرحله بعد را بگویید.

STAR+E برای پاسخ رفتاری

Situation و Task را کوتاه نگه دارید؛ Action را با سهم واقعی «من» از کار تیم جدا کنید؛ Result را با شواهد و بازه زمانی بیان کنید؛ سپس Evidence/Evolution را اضافه کنید: چه چیزی باعث شد نتیجه را به اقدام خود نسبت دهید، چه محدودیتی داشت و بعداً چه چیزی را تغییر دادید. اگر عدد ندارید، عدد نسازید؛ Artifact، Decision، Lead time کیفی یا بازخورد قابل‌بررسی بدهید.

نقشه ۲۰ سوال مصاحبه Senior QA و SDET

سوالات معماری تست و System Design

پرسش ۱ — برای محصول جدید با مستندات محدود استراتژی تست طراحی کنید

می‌سنجد: تحمل ابهام، کشف ریسک، همکاری و تبدیل Unknown به Plan.

مسیر پاسخ قوی: با هدف محصول، کاربران/ذی‌نفعان، Journeyهای بحرانی، معماری و Hard obligation شروع کنید. یک Workshop ریسک چندنقشی برگزار، System/State/Data/Dependency map بسازید و Unknownها را رتبه‌بندی کنید. Evidence را از Review/Example، Unit/Component، Contract/Integration، E2E منتخب، Exploratory و Production feedback بچینید. Entry/Exit را به Risk و Decision وصل کنید و Strategy را با یادگیری Version کنید. سیلابس رسمی ISTQB CTAL Test Management ۳.۰ نیز Risk analysis را با مشارکت ذی‌نفعان و Test monitoring پیوند می‌دهد.

علامت خطر: «اول همه Requirementها را کامل می‌کنم»، «یک Test Plan جامع می‌نویسم» یا فهرست ابزار بدون سؤال درباره Decision و ریسک. برای جزئیات عملی، راهنمای تست مبتنی بر ریسک را مرور کنید.

پرسش ۲ — معماری تست یک سامانه میکروسرویسی را طراحی کنید

می‌سنجد: Boundary، Contract، استقلال تیم، Async state و جلوگیری از E2E-heavy architecture.

مسیر پاسخ قوی: ابتدا Service/Consumer/Event/Data ownership و Critical journey را رسم کنید. Ruleها را در Unit/Component، مرز HTTP/Message را در Schema و Consumer-driven Contract، Adapter را با Service virtualization، Integration را با Dependencyهای محدود و فقط چند Journey را End-to-end پوشش دهید. Version/compatibility، provider state، message ordering، idempotency، retry، migration، observability و deployability مستقل را وارد کنید. در Consumer-driven Contract، انتظار Consumer باید به Artifact نسخه‌دار و Provider verification واقعی وصل شود؛ Mock بدون Verify شاهد سازگاری نیست.

علامت خطر: «همه سرویس‌ها را بالا می‌آورم و با Selenium تست می‌کنم»، Contract را برابر OpenAPI file دانستن، یا Mock کردن چیزی که هرگز در Provider verify نمی‌شود. استراتژی تست میکروسرویس از Contract تا E2E مرزبندی کامل‌تری دارد.

پرسش ۳ — پرداخت Async با Callback تکراری و Timeout را چگونه تست می‌کنید

می‌سنجد: State machine، distributed failure، Oracle مالی و ذهنیت ایران‌محور.

مسیر پاسخ قوی: Business transaction ID را از Request/Attempt/PSP reference جدا کنید. Stateها را Created، Pending، Paid، Declined، Unknown، Reversed/Refunded مدل کنید و Transitionهای مجاز را بنویسید. Timeout پیش و پس از Commit، Callback تکراری/دیررس/نامرتب، Signature نامعتبر، Amount mismatch، Retry کاربر، Crash consumer و Reconciliation را Failure-inject کنید. Oracle فقط UI نیست: Ledger append-only/balanced، Order، PSP inbox و گزارش مصالحه باید یک اثر مالی یکتا را تأیید کنند. ریال/تومان، رقم فارسی/لاتین، Tehran/UTC و داده مصنوعی را صریح کنید.

علامت خطر: «Exactly once را Queue تضمین می‌کند»، Retry کور، یا Pass کردن وقتی UI پیام موفق نشان می‌دهد اما Ledger/Order ناسازگار است.

پرسش ۴ — سامانه API-only بدون رابط کاربری را چگونه ارزیابی می‌کنید

می‌سنجد: فراتررفتن از Status code و ابزار Postman.

مسیر پاسخ قوی: Protocol/schema را از Business contract جدا کنید. Resource/State model، authentication/session، object/property/function/tenant authorization، input boundary، error contract، pagination، concurrency، idempotency، rate limit، timeout/retry، version compatibility و data lifecycle را پوشش دهید. Consumer/provider Evidence، Performance SLO، Security requirement، trace/correlation و Audit trail را اضافه کنید. Negative test باید Oracle و Impact داشته باشد، نه فقط «۴۰۰ برگردد».

علامت خطر: فقط Swagger import، چک ۲۰۰ و Response time، یا گفتن «چون UI ندارد تست ساده‌تر است».

پرسش ۵ — چه چیزی را اتوماتیک می‌کنید و Framework را چگونه انتخاب می‌کنید

می‌سنجد: اقتصاد Evidence، انتخاب سطح و Design for change.

مسیر پاسخ قوی: از Risk/decision، فراوانی، Feedback deadline، ثبات Interface، Data/environment control، قدرت Oracle و هزینه نگهداری شروع کنید. سریع‌ترین سطحی را انتخاب کنید که همان Failure را آشکار می‌کند؛ Pilot با Baseline زمان/اعتماد/maintenance اجرا کنید. Framework را با Language/team fit، Debuggability، parallel isolation، artifact/report، ecosystem/security، upgrade و exit strategy بسنجید. راهنمای DORA درباره Test Automation بر Suite سریع و قابل‌اعتماد، مالکیت توسعه‌دهنده و همکاری تستر تأکید دارد.

علامت خطر: درصد Automation هدف، «همه Regressionها»، انتخاب ابزار محبوب پیش از معماری، یا نام‌بردن Singleton/POM به‌عنوان نسخه عمومی. قالب استراتژی اتوماسیون از Pilot تا Scale برای تمرین مناسب است.

پرسش ۶ — این تست UI ناپایدار را در Code Review اصلاح کنید

await page.goto('/checkout');
await page.waitForTimeout(5000);
await page.locator('.pay-btn').click();
expect(await page.locator('.success').isVisible()).toBe(true);

می‌سنجد: توان Review، Synchronization، Locator contract، Isolation و تشخیص Failure.

مسیر پاسخ قوی: پیش از Rewrite بپرسید چه رفتار کاربر و کدام State باید اثبات شود. Sleep را با انتظار شرط کسب‌وکاری حذف، Locator را به Role/Accessible name یا Test contract پایدار تبدیل و از Web-first assertion استفاده کنید. داده و Session مستقل، Currency/Order ID یکتا، Network/console/trace و Screenshot شکست را اضافه کنید. Setup را ترجیحاً از API کنترل‌شده بسازید و PSP ثالث را در این سطح Route/Stub کنید؛ Contract آن را جدا verify کنید. Best Practices رسمی Playwright نیز رفتار قابل‌مشاهده کاربر، Test isolation، Locator مقاوم و Web-first assertion را توصیه می‌کند.

علامت خطر: فقط افزایش Timeout/Retry، XPath طولانی، shared account، Assertion روی جزئیات DOM یا مخفی‌کردن Flake با سه بار اجرا.

پرسش ۷ — تست‌ها را در CI/CD چگونه به Lane و Gate تبدیل می‌کنید

می‌سنجد: Feedback architecture، Execution economics، Evidence و عملیات Failure.

مسیر پاسخ قوی: از Feedback deadline و Risk class شروع کنید: Static/Unit/Component سریع روی هر Change؛ Contract/Integration هدفمند؛ E2E کم و بحرانی؛ Performance/Security/Accessibility در Event مناسب؛ و Canary/Monitoring پس از Deploy. Build یک‌بار ساخته و با Digest/Provenance Promote شود. Run identity، JUnit/Artifact، First-attempt result، Infra retry، Flaky quarantine، timeout، cancellation و owner/gate روشن باشند. Passing را اثبات Reliability ندانید؛ Google SRE Testing for Reliability Testing و Production evidence را کاهش‌دهنده بخش‌های متفاوت عدم‌قطعیت می‌داند.

برای سامانه توزیع‌شده، Testability را با Correlation ID، Clock/Randomness تزریقی، Dependency port، State inspection و Telemetry طراحی کنید. Observability Primer در OpenTelemetry نقش Metrics، Logs و Trace را در فهم رفتار و Unknown unknownها توضیح می‌دهد. برای پیاده‌سازی اختصاصی، راهنمای تست خودکار در GitLab CI را تمرین کنید.

علامت خطر: Pipeline خطی Build/Test/Deploy بدون Decision policy، Retry تمام Failureها، E2E روی هر Commit بدون بودجه، یا عبارت «اگر سبز شد خودکار Production می‌رود» بدون Risk/rollback.

پرسش ۸ — تست عملکرد فروشگاه پرترافیک را طراحی کنید

می‌سنجد: Workload modeling، SLO، اندازه‌گیری معتبر و Correctness under load.

مسیر پاسخ قوی: Journey و SLO کاربر را تعریف کنید؛ Checkout با Search یک Budget ندارد. از Telemetry معتبر، Mix تراکنش، Arrival model باز/بسته، Concurrency، Burst، Think time، داده/Hot key، Cache state و Dependency quota بسازید. Baseline، Load، Spike، Stress، Soak، Capacity و Recovery سؤال‌های متفاوت‌اند. p50/p95/p99 latency، Goodput، error taxonomy، saturation، queue age و backlog drain را همراه Correctness مالی بسنجید. Warm-up، Repeat، noise و versioned Run manifest را کنترل و نقطه Knee/Operating bound را گزارش کنید.

علامت خطر: «هزار کاربر با JMeter»، Average response time، TPS بدون error/correctness، یا تست روی Production بدون Limit و مجوز. راهنمای تست عملکرد و تفاوت Load/Stress/Scalability پایه لازم را مرور می‌کند.

پرسش ۹ — امنیت را چگونه در چرخه توسعه و تست ادغام می‌کنید

می‌سنجد: Security requirement، threat/risk، پوشش لایه‌ای و مرز تخصص.

مسیر پاسخ قوی: Asset، Actor، Trust boundary و Abuse case را مدل کنید؛ Requirementهای Verifyable را بر اساس Context و تعهد انتخاب کنید. Review/Threat modeling، dependency/secret/config checks، Unit/negative tests، authentication/session/recovery، object/property/function/tenant authorization، Contract، DAST و Pen test مجاز را در Laneهای مناسب قرار دهید. نتیجه Scanner را Finding نیازمند Triage بدانید؛ Severity، exploitability، exposure و business impact را جدا کنید. OWASP ASVS 5.0 یک Catalog کنترل قابل‌راستی‌آزمایی است، نه تضمین امنیت کامل.

علامت خطر: Security برابر ZAP/SonarQube، «Shift Left پس امن است»، اجرای Pen test بدون Scope/Consent، یا ادعای تخصص عمیق خارج از تجربه. داوطلب ارشد می‌داند چه زمانی Security engineer یا ارزیاب مستقل لازم است.

پرسش ۱۰ — آیا از AI برای تولید و نگهداری تست استفاده می‌کنید

می‌سنجد: بهره‌گیری مسئولانه از ابزار نو، Privacy، provenance و قدرت Oracle.

مسیر پاسخ قوی: Use case را محدود کنید: ایده Hypothesis، Fixture، پیش‌نویس Test code، Log clustering یا Review assistant. داده/کد مجاز، مدل/نسخه، Prompt/context، Artifact provenance و Human review را ثبت کنید. خروجی را با Contract/Requirement مستقل اجرا، Assertion را با Mutation/known bug بسنجید و hallucination/API ساختگی را Triage کنید. Baseline زمان خالص، acceptance/edit rate، Defect signal و maintenance را مقایسه کنید؛ تعداد Test تولیدشده KPI نیست. NIST AI Risk Management Framework زبان Govern/Map/Measure/Manage را برای چنین تصمیمی فراهم می‌کند.

علامت خطر: ارسال PII/Secret به مدل، Copy/paste بدون Review، ادعای پوشش خودکار Requirement یا اینکه AI «تستر را حذف می‌کند».

سوالات رهبری QA، تصمیم انتشار و بهبود سیستم

پرسش ۱۱ — مدیر انتشار امروز را می‌خواهد اما Evidence ناقص است

می‌سنجد: قضاوت، ارتباط ریسک، Decision rights و توان ساخت گزینه.

مسیر پاسخ قوی: ابتدا Hard obligation و ریسک‌های Blocker را جدا کنید. دقیق بگویید چه Scopeی تست شده، Evidence چقدر تازه/قابل‌اعتماد است و چه Unknownی مانده. گزینه بسازید: تأخیر محدود برای شاهد بحرانی؛ Rollout کوچک با Feature flag/Canary، سقف Exposure، Monitoring و Rollback؛ یا عدم انتشار اگر پیامد/تعهد اجازه نمی‌دهد. پذیرنده Residual risk باید اختیار نام‌دار داشته باشد و Waiver محدوده/Expiry داشته باشد. QA اطلاعات و Challenge مستقل می‌دهد؛ اختیار تجاری را جعل نمی‌کند.

علامت خطر: «من اجازه Release نمی‌دهم» بدون اختیار، «کسب‌وکار تصمیم می‌گیرد» بدون Evidence، یا عبارت مبهم «تعادل سرعت و کیفیت». برای مسئولیت و تصمیم، مدل مالکیت همگانی کیفیت را مرور کنید.

پرسش ۱۲ — با توسعه‌دهنده درباره Severity و Priority باگ اختلاف دارید

می‌سنجد: تفکیک مفهوم، مذاکره مبتنی بر Evidence و Escalation سالم.

مسیر پاسخ قوی: Failure را با Build/Environment/Data/Steps/Artifact بازتولید و Observation را از Inference جدا کنید. Severity را Impact فنی/کاربری در Context و Priority را ترتیب اقدام بر اساس Impact، likelihood، exposure، deadline و فرصت بدانید. معیار مشترک و مثال مرزی را باز کنید؛ اگر اختلاف باقی ماند، Decision owner محصول/امنیت/عملیات را بر اساس نوع ریسک وارد کنید و نتیجه را ثبت کنید. تغییر Priority نباید Severity تاریخی را بازنویسی کند.

علامت خطر: «به مدیر ارجاع می‌دهم» به‌عنوان اولین اقدام، استفاده از Title برای بردن بحث، یا یکی‌گرفتن شدت با فوریت.

پرسش ۱۳ — Suite کند و Flaky اعتماد تیم را از بین برده است

می‌سنجد: تحول مرحله‌ای، داده، Root cause و توان حذف کار کم‌ارزش.

مسیر پاسخ قوی: Baseline بسازید: p50/p95 feedback، queue/execute، First-attempt failure، Pass-after-retry، quarantine age، triage time و failure taxonomy. Suite را بر Risk/value، سطح، runtime و علت Flake بخش‌بندی کنید. محصول، Test code، data collision، clock/randomness، dependency و infra را جدا کنید. Testهای Duplicate/بی‌Oracle را حذف، Failure را به سریع‌ترین سطح پایین ببرید، محیط/داده را مستقل، Telemetry را غنی و Quarantine را مالک‌دار/منقضی کنید. تغییر را Pilot و Outcome را با Baseline مقایسه کنید.

علامت خطر: خرید Framework جدید، افزایش Retry، Parallel کردن فوری، یا وعده «صفر Flaky» بدون تعریف و Trend.

پرسش ۱۴ — چگونه یک مهندس QA را Mentor می‌کنید

می‌سنجد: رشد قابلیت، Feedback، واگذاری و رهبری بدون Heroism.

مسیر پاسخ قوی: هدف رشد را با فرد و نیاز نقش تعریف کنید؛ مثلاً «طراحی Charter و دفاع از Oracle» نه «Senior شدن». Baseline با Work sample بگیرید، یک مسیر Practice→Pair→Independent→Teach بسازید، Feedback مشاهده‌پذیر و سریع بدهید و Challenge را تدریجی افزایش دهید. فرصت تصمیم واقعی با Safety net ایجاد کنید. پیشرفت را با کیفیت Artifact، استقلال، انتقال یادگیری و Outcome تیم بسنجید؛ نه ساعات آموزش یا تعداد Course.

علامت خطر: «همیشه در دسترسش بودم»، حل‌کردن همه مسئله‌ها برای فرد، نقشه یکسان برای همه یا نسبت‌دادن رشد او به خود.

پرسش ۱۵ — یک نقص بحرانی از تست عبور کرده و به Production رسیده است

می‌سنجد: Incident response، صداقت، Systems thinking و اقدام قابل‌راستی‌آزمایی.

مسیر پاسخ قوی: ابتدا Safety: Stop/rollback/disable، حفاظت از داده و اطلاع‌رسانی مالک‌دار. Evidence را حفظ، Timeline و Blast radius را بسازید و فرضیه‌ها را با Trace/Log/Replay بیازمایید. از سؤال «چه کسی جا انداخت؟» به «کدام شرایط و کنترل‌ها اجازه دادند؟» بروید: Requirement، design، testability، data، environment، selection، gate، monitoring و decision. Actionها باید مالک، موعد، Verification و ضد‌اثر جانبی داشته باشند؛ ممکن است شامل تغییر معماری/Policy/Telemetry باشد، نه فقط Test بیشتر. Regression باید ابتدا Failure قدیمی را بازتولید کند.

علامت خطر: مقصرکردن فرد، گفتن «QA باید می‌گرفت»، افزودن E2E برای هر Incident، یا داستانی که هیچ سهم/اشتباه شخصی ندارد.

پرسش ۱۶ — اثربخشی QA را با چه معیارهایی می‌سنجید

می‌سنجد: Measurement design، Outcome، مخرج و Goodhart awareness.

مسیر پاسخ قوی: شاخص‌ها را به Decision وصل کنید و چهار سبد بسازید: Outcome کاربر/Production (impact، recurrence، unplanned work)، Flow (feedback/triage/recovery percentiles)، Risk evidence (critical risk coverage، freshness، unknown) و Test system health (first-run، flake، diagnosis، quarantine). تعریف، Cohort، منبع و محدودیت را نسخه‌دار و هر KPI را با Guardrail همراه کنید. برای مثال کاهش Pipeline time فقط اگر Flake/Risk coverage بدتر نشود.

علامت خطر: Bug count، Test case count، Automation percentage، Pass rate خام یا هدف «Defect leakage صفر» به‌عنوان امتیاز فرد/تیم.

سوالات رفتاری و حل مسئله برای سطح Senior

پرسش ۱۷ — بزرگ‌ترین شکست حرفه‌ای شما چه بوده است

می‌سنجد: خودآگاهی، صداقت، Attribution و یادگیری قابل‌انتقال.

مسیر پاسخ قوی: یک رخداد واقعی با Scope قابل‌بیان انتخاب کنید. Situation/Task را کوتاه، تصمیم و فرض خود را دقیق و سهم تیم را منصفانه جدا کنید. Result را بدون عددسازی بگویید: Incident، تأخیر، Rework، بازخورد یا Decision ثبت‌شده. سپس Evidence و Evolution: چه چیزی فرض شما را رد کرد، چه کنترل سیستمی تغییر کرد، آیا Action بعداً verify شد و اگر تکرار شود چه کار متفاوتی می‌کنید.

علامت خطر: شکست جعلی مانند «بیش از حد کمال‌گرا بودم»، مقصرکردن مدیر/توسعه‌دهنده، داستانی که به موفقیت قهرمانانه تبدیل می‌شود یا نقض محرمانگی شرکت قبلی.

پرسش ۱۸ — اگر پاسخ فنی را ندانید چه می‌کنید

می‌سنجد: مرز دانش، Reasoning و روش کاهش عدم‌قطعیت.

مسیر پاسخ قوی: مستقیم بگویید «با X تجربه عملی ندارم؛ بخش Y را می‌دانم.» سؤال را برای Scope روشن کنید، از اصول نزدیک Hypothesis بسازید و بین Fact/Inference علامت بگذارید. راه اعتبارسنجی بدهید: مستند رسمی، Spike کوچک، Test، Peer/domain expert و Exit criterion. اگر مصاحبه‌گر اجازه دهد با فرض‌های صریح مسئله را ادامه دهید.

نمونه: «Pact Broker را عملی اداره نکرده‌ام؛ Consumer/provider verification را می‌شناسم. برای پاسخ دقیق درباره can-I-deploy، نسخه محصول و Workflow شما را می‌پرسم، مستند نسخه را بررسی و یک Pipeline آزمایشی با دو نسخه ناسازگار می‌سازم.»

علامت خطر: Bluff، تغییر موضوع، نام‌بردن ابزارهای مشابه به‌عنوان تجربه یا وعده «سریع یاد می‌گیرم» بدون روش و Evidence.

پرسش ۱۹ — تعداد جایگاه‌های سوخت تهران را تخمین بزنید

می‌سنجد: شکستن مسئله، Range، Sensitivity و Validation؛ نه حفظ عدد واقعی.

مسیر پاسخ قوی: نخست تعریف کنید «جایگاه» یا «نازل»، شهر یا کل استان، فعال یا ثبت‌شده. دو مدل مستقل بسازید: Top-down از تعداد خودرو × دفعات سوخت‌گیری ÷ ظرفیت روزانه هر جایگاه؛ Bottom-up از مساحت/منطقه × چگالی. هر ورودی را Range بنویسید، بازه خروجی و متغیر حساس را نشان دهید و بگویید با چه داده‌ای—آمار حمل‌ونقل، نقشه نمونه یا گزارش شرکت پخش—آن را Calibration می‌کنید. هدف، Trace فرض تا نتیجه است.

علامت خطر: یک عدد دقیق بدون واحد/بازه، طولانی‌شدن محاسبه بدون تعریف سؤال، یا دفاع از فرض پس از دریافت داده مخالف.

پرسش ۲۰ — تست سامانه خودران یا Safety-critical را طراحی کنید

می‌سنجد: تشخیص مرز صلاحیت، Hazard-based assurance و مسئولیت.

مسیر پاسخ قوی: بگویید یک پاسخ مصاحبه جای Safety case، Standard، Regulatory interpretation و متخصص دامنه را نمی‌گیرد. ODD، Hazard/Severity/Exposure/Controllability، Safe state و Acceptance authority را روشن کنید. Requirement traceability و استقلال V&V را با تحلیل ایستا/مدل، Unit/Component، Software/Hardware-in-the-loop، Simulation سناریومحور، Fault injection، Proving ground کنترل‌شده و Field evidence مجاز لایه‌بندی کنید. Sensor degradation، weather/lighting، localization، cybersecurity، timing, human factors، update/rollback و monitoring را وارد کنید. Coverage کیلومتر یا Scenario count را اثبات ایمنی ندانید؛ Residual risk و limitation باید در Assurance argument آشکار باشد.

علامت خطر: «همه شرایط را Simulation می‌کنم»، شروع Test جاده‌ای بدون مجوز/کنترل، فهرست دوربین و Sensor بدون Hazard model، یا ادعای صفر ریسک.

نمونه پاسخ کامل: استراتژی تست Checkout ایرانی

سؤال: «برای Checkout یک Marketplace ایرانی با دو PSP، تخفیف، کیف پول و Refund چه استراتژی‌ای پیشنهاد می‌دهید؟»

Context و Constraints

«پیش از طراحی، هدف تصمیم را روشن می‌کنم: Release اولیه است یا Migration PSP؟ حجم و SLO، سهم هر روش پرداخت، مدل کیف پول، مسئول Ledger، Contract تسویه، تعهد حقوقی/امنیتی و قابلیت Rollback چیست؟ مبلغ Canonical ریال است یا تومان؟ Callback Sync/Async است؟ Sandbox هر PSP چه تفاوتی با Production دارد؟ Unknownها را ثبت می‌کنم.»

Assumption و Risk

«ریسک‌های اولیه من اثر مالی تکراری/گمشده، Amount/unit mismatch، پرداخت موفق با Order ناموفق، Timeout پس از Commit، Callback تکراری/دیررس/نامرتب، Refund جزئی، تخفیف هم‌زمان، موجودی/کیف پول Race، Signature/Replay، Tenant authorization، رقم/حرف فارسی-عربی و اختلاف UTC/Tehran/Jalali است. با محصول، پرداخت، مالی، امنیت و عملیات Likelihood/Impact و Hard obligation را Calibration می‌کنم.»

Response و Trade-off

«Ruleهای پول/تخفیف/State را Unit و Property-based، API و Eventها را Contract، Adapter PSP را با Stub قراردادمحور و Failure injection، Database/Queue را Integration و فقط Journeyهای بحرانی را E2E می‌گذارم. Ledger append-only/balanced و Reconciliation Oracle مستقل‌اند. Security شامل Signature/timestamp/nonce، authz و Abuse case است. Performance با Mix واقعی و Correctness زیر بار سنجیده می‌شود. برای هر MR Lane سریع بدون Secret تولیدی؛ Sandbox PSP در Lane محافظت‌شده؛ Release با Canary، سقف Exposure، Alert اختلاف Ledger و Rollback.»

Evidence و Evolution

«Run manifest شامل Commit، Contract، Environment، Data/Seed، Clock، Attempt و Artifact است. Gate بر Risk evidence، Blocked/Unknown، Defect impact و Rollback readiness تکیه دارد؛ نه Pass Rate خام. مالک انتشار Residual risk را با حدود و Expiry می‌پذیرد. پس از Canary، Payment success، duplicate effect، Unknown age، reconcile mismatch و support signal را با Baseline مقایسه می‌کنم و Suite/Strategy را از Incident واقعی به‌روزرسانی می‌کنم.»

این پاسخ ابزار کم نام می‌برد اما Decision، Failure model، Oracle، لایه، عملیات و مالکیت را به هم وصل می‌کند؛ سیگنال Senior همین اتصال است.

Portfolio مصاحبه SDET و QA ارشد

به‌جای اسلاید پر از لوگوی ابزار، سه تا پنج Artifact کوچک و Sanitized آماده کنید:

• Strategy one-pager: Context، Risk، Lane، Evidence، Gate و Unknown.
• Code + Review: یک Test قابل‌نگهداری و Diffی که Flakiness/Oracle را بهبود داده است.
• Pipeline: YAML/Jenkinsfile با Exit، JUnit، Cache/Artifact، Retry و Trust boundary.
• Incident learning: Timeline، control gap، Action owner و Verification—بدون داده محرمانه.
• Decision memo: Release/Residual risk با گزینه و Trade-off.
• Mentoring artifact: Rubric مهارت، تمرین و Evidence رشد فرد/تیم.

در README هر نمونه بنویسید چه چیزی را خودتان انجام دادید، چه چیزی تیمی بود، چه گزینه‌ای رد شد، محدودیت چیست و امروز چه چیزی را تغییر می‌دهید. اگر Artifact متعلق به کارفرمای قبلی است، بدون اجازه منتشر نکنید؛ نمونه مصنوعی هم می‌تواند Judgment شما را نشان دهد.

برنامه هفت‌روزه آمادگی مصاحبه

1. روز ۱: شرح شغل را به Role Contract و هشت بعد Rubric تبدیل کنید.
2. روز ۲: پنج داستان STAR+E بنویسید: Failure، conflict، improvement، leadership و ambiguity.
3. روز ۳: سه System design را روی کاغذ تمرین کنید: Checkout، Microservice و Data/Async flow.
4. روز ۴: یک Test code review و یک Pipeline review با صدای بلند انجام دهید.
5. روز ۵: Performance، Security و Production evidence را با Risk/Oracle مرور کنید.
6. روز ۶: Mock interview ۶۰دقیقه‌ای ضبط؛ پاسخ‌ها را با Rubric امتیاز و Filler/tool-list را حذف کنید.
7. روز ۷: Portfolio، سؤال‌های شرکت، محدودیت محرمانگی و Setup جلسه آنلاین را نهایی کنید.

اگر هنوز مفاهیم پایه یا سؤال‌های عمومی را تمرین نکرده‌اید، ۳۰ سوال مصاحبه QA با جواب و تمرین نقطه شروع مناسب‌تری است.

سؤال‌هایی که داوطلب ارشد باید از شرکت بپرسد

• سه Outcome اصلی این نقش در ۹۰ روز اول چیست و چگونه مشاهده می‌شود؟
• بزرگ‌ترین ریسک کیفیت/عملیات فعلی چیست و چه Evidenceی کم دارید؟
• عنوان QA/SDET اینجا چه Scope کد، Strategy، on-call و People leadership دارد؟
• چه کسی Release و Residual risk را می‌پذیرد؟ QA چه اختیار توقفی دارد؟
• توسعه‌دهنده مالک کدام Testها است و Test failure چگونه Triage می‌شود؟
• نسبت Product/Test/Infra/Data failure و وضعیت Flaky/Quarantine چگونه است؟
• برای Runner، Environment، Test data و Observability چه محدودیت‌هایی دارید؟
• آخرین Incident مهم چه تغییری در سیستم یا فرایند ساخت؟
• رشد IC و مسیر Leadership چگونه ارزیابی می‌شود؟
• آیا Work sample، Rubric و مراحل تصمیم‌گیری مصاحبه شفاف‌اند؟

علامت‌های خطر در مصاحبه از هر دو طرف

چک‌لیست پاسخ ارشد

• □ پیش از راه‌حل، Decision، Context و Constraint را روشن کردم.
• □ Fact، Assumption و Unknown را جدا کردم.
• □ Risk را به Condition/Event/Impact یا مثال ملموس وصل کردم.
• □ سریع‌ترین سطح Evidence مناسب را انتخاب کردم.
• □ Oracle و Artifact مستقل/قابل‌بررسی را توضیح دادم.
• □ Data، Environment، Version، Time و Dependency را دیدم.
• □ گزینه و Trade-off گفتم، نه Best practice مطلق.
• □ مالک Action و Decision right روشن است.
• □ Production feedback، failure response و rollback را فراموش نکردم.
• □ سهم شخصی را از کار تیم جدا کردم.
• □ عدد یا تجربه ساختگی نساختم.
• □ نتیجه، محدودیت و یادگیری بعدی را بیان کردم.

سؤالات متداول مصاحبه ارشد QA و SDET

آیا پاسخ سوالات مصاحبه Senior QA را حفظ کنیم؟

خیر. ساختار CARE، واژگان دقیق و نمونه‌های خود را تمرین کنید؛ پاسخ ثابت با تغییر Context می‌شکند. برای هر سناریو چند سؤال روشن‌کننده، Risk، گزینه، Evidence و محدودیت آماده داشته باشید.

تفاوت مصاحبه Senior QA و Senior SDET چیست؟

به Role Contract شرکت بستگی دارد. SDET معمولاً عمق بیشتری در Coding، Testability، Framework و CI دارد؛ Senior QA ممکن است وزن بیشتری در Risk، Strategy، Exploratory work، Stakeholder و Leadership داشته باشد. هم‌پوشانی زیاد است؛ شرح شغل و Rubric را مبنا بگیرید.

اگر تجربه مستقیم یک ابزار را نداریم چه بگوییم؟

مرز تجربه را صریح کنید، مفهوم نزدیک را توضیح دهید و روش یادگیری/اعتبارسنجی بدهید. «Pact عملی نه، Contract testing و provider verification بله» بسیار معتبرتر از ادعای مبهم است. اگر ابزار Requirement اصلی نقش است، Gap و زمان/تمرین لازم را صادقانه بگویید.

برای پاسخ رفتاری STAR کافی است؟

STAR نظم روایت می‌دهد، اما برای سطح ارشد Evidence و Evolution را اضافه کنید: نتیجه را چگونه می‌دانید، سهم شما چه بود، محدودیت/Counterfactual چیست و سیستم پس از یادگیری چگونه تغییر کرد. عدد نسازید و محرمانگی را حفظ کنید.

در مصاحبه QA ارشد از چه پروژه‌ای نمونه بیاوریم؟

نمونه‌ای انتخاب کنید که تصمیم، Trade-off و یادگیری نشان دهد: Strategy one-pager، Test code review، Pipeline، Incident learning یا Release memo. پیچیدگی لوگو و ابزار مهم نیست؛ Context، نقش شما، Evidence، محدودیت و Outcome باید قابل‌توضیح باشد.

جمع‌بندی: پاسخ ارشد یعنی استدلال قابل‌بررسی

مصاحبه ارشد آزمون حفظ ابزار نیست. پاسخ قوی نشان می‌دهد چگونه از ابهام به Risk model، از Risk به Evidence و از Evidence به Decision و یادگیری می‌رسید. اگر سؤال را روشن می‌کنید، فرض را علامت می‌زنید، Oracle و Trade-off می‌سازید، اختیار را جعل نمی‌کنید و Failure خود را صادقانه تحلیل می‌کنید، سیگنال Senior را ارائه داده‌اید؛ حتی اگر پاسخ نهایی شما با ترجیح مصاحبه‌گر متفاوت باشد.