سوالات مصاحبه QA؛ ۳۰ پرسش با جواب و تمرین عملی

مصاحبه‌کننده می‌پرسد: «صفحه Login را چگونه تست می‌کنید؟» اگر بلافاصله فهرستی از Test Caseها ردیف کنید، شاید مهم‌ترین بخش را از دست بدهید: Login برای چه کاربری، با چه روش احراز هویت، روی کدام پلتفرم و با چه ریسکی؟ در مصاحبه QA، کیفیت ساختار فکر معمولاً مهم‌تر از طول فهرست است.

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

فرمول پاسخ سناریویی: هدف و دامنه را روشن کن → کاربر و ریسک را مدل کن → تکنیک و داده تست را انتخاب کن → Oracle و شواهد را بگو → با محدودیت زمان اولویت بده → ریسک تست‌نشده را شفاف کن.

قبل از تمرین سوالات، آگهی شغلی را رمزگشایی کنید

عنوان «QA Engineer» تعریف ثابتی ندارد. یک شرکت Product QA با تحلیل دامنه می‌خواهد؛ شرکت دیگر Automation Engineer با برنامه‌نویسی و CI. آگهی را به چهار ستون تبدیل کنید:

مسئولیت	سطح مورد انتظار	شاهد من	شکاف/پرسش
تست API	طراحی و اجرای مستقل	Collection سفارش با تست منفی	Contract testing ذکر نشده
اتوماسیون UI	نگهداری Suite	Smoke کوچک در CI	Stack و حجم Suite را بپرسم
Agile collaboration	مشارکت در Refinement	مثال ابهام تخفیف	نقش QA در تیم چیست؟

برای هر ادعای رزومه یک داستان یا Artifact آماده کنید. اگر نوشته‌اید «مسلط به SQL»، انتظار Query و توضیح NULL/JOIN داشته باشید. برای سنجش واقع‌بینانه سطح خود از ماتریس مهارت‌های تست نرم‌افزار استفاده کنید.

چارچوب پاسخ به سوال سناریویی QA

1. Clarify: هدف، Scope، کاربر، پلتفرم و محدودیت را بپرسید.
2. Model: State، Rule، Data، Interface و Dependency را دسته‌بندی کنید.
3. Risk: اثر و احتمال شکست را اولویت دهید.
4. Design: تکنیک، سطح تست، داده و محیط را انتخاب کنید.
5. Oracle: درست/غلط را با چه مرجعی تشخیص می‌دهید؟
6. Evidence: Result، Log، Request ID یا Metric لازم چیست؟
7. Trade-off: با زمان محدود چه چیزی را تست نمی‌کنید و ریسک آن چیست؟

با صدای بلند فکر کنید، اما پراکنده حرف نزنید. اگر فرضی می‌سازید، آن را اعلام کنید: «فرض می‌کنم Login با رمز و OTP است؛ اگر SSO باشد، مدل تغییر می‌کند.»

سوالات مفاهیم پایه تست نرم‌افزار

۱. تست نرم‌افزار چیست و هدف آن چیست؟

پاسخ الگویی: تست مجموعه فعالیت‌هایی برای ارزیابی Artifact و محصول و تولید اطلاعات درباره کیفیت و ریسک است. هدف اثبات نبود باگ نیست؛ کشف مسئله، پیشگیری، ساخت اعتماد متناسب با شواهد و کمک به تصمیم است.

۲. تفاوت QA، QC و Testing چیست؟

پاسخ الگویی: در تعریف مفهومی، QA بیشتر فرایندمحور و پیشگیرانه است؛ QC روی ارزیابی محصول و خروجی تمرکز دارد؛ Testing یکی از فعالیت‌های ارزیابی است. در عنوان‌های شغلی مرزها یکسان نیستند، پس شرح نقش شرکت را می‌پرسم.

۳. تفاوت Verification و Validation چیست؟

پاسخ الگویی: Verification می‌پرسد Artifact مطابق مشخصات و قواعد ساخته شده است؛ Validation می‌پرسد محصول نیاز واقعی کاربر و کاربرد موردنظر را برآورده می‌کند. Review نیازمندی نمونه Verification و آزمون جریان واقعی کاربر نمونه Validation است؛ این دو مکمل‌اند.

۴. Severity و Priority چه فرقی دارند؟

پاسخ الگویی: Severity اندازه و دامنه اثر نقص است؛ Priority فوریت و ترتیب رسیدگی در زمینه کسب‌وکار و Release. یک غلط قیمت در کمپین ممکن است اثر فنی محدود اما اولویت تجاری بالا داشته باشد. تعریف و تصمیم نهایی باید در Workflow تیم روشن باشد.

۵. Retest و Regression چه تفاوتی دارند؟

پاسخ الگویی: Retest بررسی می‌کند نقص مشخص با همان شرایط یا شرایط لازم رفع شده است. Regression بررسی می‌کند تغییر، رفتارهای موجود مرتبط یا حیاتی را خراب نکرده است. Scope رگرسیون با Impact و Risk تعیین می‌شود، نه تکرار همه تست‌ها.

۶. Static و Dynamic Testing چیست؟

پاسخ الگویی: Static testing بدون اجرای کد/محصول، Artifactهایی مثل Requirement، طراحی و کد را Review یا تحلیل می‌کند. Dynamic testing با اجرای Component یا سیستم انجام می‌شود. هر دو می‌توانند نقص را زودتر یا در نوع متفاوتی آشکار کنند.

۷. Test Strategy، Test Plan و Test Case چه فرقی دارند؟

پاسخ الگویی: Strategy جهت و اصول کلی را بیان می‌کند؛ Plan هدف، Scope، Risk، منابع، محیط و معیار تصمیم یک Initiative/Release را عملیاتی می‌کند؛ Test Case ورودی، پیش‌شرط، عمل و نتیجه موردانتظار یک بررسی مشخص است. شکل سند به زمینه بستگی دارد و لازم نیست همیشه طولانی باشد.

۸. چه زمانی تست را متوقف می‌کنید؟

پاسخ الگویی: «وقتی همه تست‌ها پاس شدند» کافی نیست. Exit criteria، پوشش ریسک، نقص باز، کیفیت شواهد، زمان، تغییرها و ریسک باقی‌مانده را می‌بینم. توقف تست و تصمیم انتشار جدا هستند؛ ممکن است با پذیرش ریسک منتشر یا با شواهد ناکافی متوقف شویم.

سوالات طراحی تست و حل سناریو

۹. صفحه Login را چگونه تست می‌کنید؟

ابتدا روش‌ها و Scope را می‌پرسم: رمز، OTP، SSO، Remember me، بازیابی و MFA. سپس مدل می‌سازم:

• Function: معتبر/نامعتبر، حساب غیرفعال، رمز منقضی و Logout؛
• Security: پیام غیرقابل‌شمارش حساب، Rate limit، Session fixation، CSRF و مجوز پس از Login؛
• Data: مرز طول، Unicode، فاصله، ارقام و Case؛
• State/Time: OTP منقضی، Retry، دو Tab و Session timeout؛
• UX/A11y: Keyboard، Focus، Label، پیام قابل‌فهم و RTL؛
• Platform: مرورگر، Device و شبکه هدف.

با زمان محدود، مسیر معتبر، مجوز، Rate limit و بازیابی را بر اساس ریسک اولویت می‌دهم.

۱۰. پرداخت فروشگاه را چگونه تست می‌کنید؟

Order و Payment را دو State machine مرتبط می‌بینم. مبلغ، مالک، وضعیت مجاز، Idempotency، Redirect/Callback، Timeout، لغو، callback تکراری/دیررس، مغایرت مبلغ و Reconciliation را بررسی می‌کنم. پرداخت واقعی و تست بار فقط با مجوز و محیط مناسب انجام می‌شود.

۱۱. آسانسور یا ATM را چگونه تست می‌کنید؟

هدف این سوال فهرست طولانی نیست. Hardware/Software boundary، کاربر، ایمنی، State، ورودی، هم‌زمانی، قطعی برق/شبکه، دسترس‌پذیری، امنیت و عملیات را دسته‌بندی می‌کنم؛ سپس Scope را می‌پرسم. برای ATM، تحویل پول و ثبت Ledger باید سازگار باشند؛ برای آسانسور، سناریوی ایمنی نیازمند استاندارد و متخصص دامنه است.

۱۲. اگر فقط دو ساعت برای تست دارید چه می‌کنید؟

هدف Release و تغییر را می‌پرسم، مسیرهای بحرانی و Blast radius را مشخص می‌کنم، Smoke قطعی و اکتشاف متمرکز اجرا می‌کنم و شواهد/ریسک تست‌نشده را گزارش می‌دهم. وانمود نمی‌کنم Scope کامل شده است.

۱۳. با Requirement مبهم چه می‌کنید؟

ابهام را با مثال مشخص می‌کنم، نه جمله «نیازمندی واضح نیست». Rule، حالت خطا، داده مرزی و Oracle را به سؤال تبدیل می‌کنم؛ Decision owner و موعد پاسخ می‌خواهم. اگر پاسخ دیر است، فرض ثبت‌شده و تست برگشت‌پذیر می‌سازم.

۱۴. چگونه پوشش تست را ارزیابی می‌کنید؟

پوشش را چندبعدی می‌بینم: Risk، Requirement، Rule، State، Data، Interface، Platform و Code. درصد فقط وقتی معنی دارد که مخرج روشن باشد. تعداد Test Case یا Code coverage بالا کیفیت Oracle و ریسک پوشش‌نداده را ثابت نمی‌کند.

۱۵. با تست Flaky چه می‌کنید؟

Fail اولیه را با Rerun پنهان نمی‌کنم. علت را Product/Test/Data/Environment/Unknown دسته‌بندی، Artifact را حفظ، مالک و مهلت Quarantine تعیین و ریسک پوشش ازدست‌رفته را گزارش می‌کنم. Sleep یا Retry بی‌حد راه‌حل نیست.

۱۶. اگر باگ مهمی به Production فرار کرد چه می‌کنید؟

ابتدا اثر مشتری و Mitigation، سپس Timeline و شواهد را بررسی می‌کنم. نمی‌گویم «QA شکست خورد». می‌پرسم کدام Signal/Decision ناکافی بود و اقدام قابل‌پیگیری می‌سازم: Test، Observability، Requirement یا Rollout. Retrospective بدون سرزنش به معنی بدون مسئولیت نیست.

برای پاسخ سناریویی، مدل و تکنیک را در راهنمای طراحی Test Case و Charter را در راهنمای تست اکتشافی تمرین کنید.

سوالات API، SQL، Git و اتوماسیون

۱۷. در تست API چه چیزهایی را بررسی می‌کنید؟

قرارداد و Schema، Status/Headers، Rule کسب‌وکار، Authentication/Authorization، State، Idempotency، Pagination، خطا، Concurrency، Performance و Observability. فقط 200 OK کافی نیست؛ Side effect و مالکیت منبع را نیز می‌سنجم.

۱۸. Authentication و Authorization چه فرقی دارند؟

Authentication هویت را بررسی می‌کند؛ Authorization اجازه انجام عمل روی منبع را. کاربر می‌تواند Login شده باشد اما نباید سفارش کاربر دیگر را بخواند. برای تست، ماتریس Role × Action × Resource می‌سازم.

۱۹. تفاوت PUT و PATCH چیست؟

در معنای HTTP، PUT معمولاً وضعیت کامل منبع هدف را جایگزین/ایجاد می‌کند و Idempotent تعریف شده است؛ PATCH تغییر جزئی را بیان می‌کند و خودبه‌خود همیشه Idempotent نیست. قرارداد واقعی API را نیز بررسی می‌کنم؛ نام Method جای Spec محصول را نمی‌گیرد. مرور HTTP methods در MDN مرجع خوبی است.

۲۰. یک API را در مصاحبه عملی چگونه تست می‌کنید؟

Schema/Rule را می‌خوانم، Environment و Secret را جدا می‌کنم، Happy path کوچک می‌سازم، ID را از پاسخ Correlate می‌کنم، تست منفی/مجوز اضافه می‌کنم و Cleanup می‌نویسم. Assertion هم فنی و هم کسب‌وکار دارد. فرایند کامل در راهنمای تست API آمده است.

۲۱. تفاوت INNER JOIN و LEFT JOIN چیست؟

INNER JOIN فقط ردیف‌های دارای Match در هر دو سمت را برمی‌گرداند. LEFT JOIN همه ردیف‌های سمت چپ و Matchهای سمت راست را می‌دهد؛ در نبود Match ستون‌های سمت راست NULL می‌شوند. باید اثر شرط در WHERE را هم توضیح دهم، چون ممکن است LEFT JOIN ناخواسته شبیه INNER شود.

۲۲. NULL را در SQL چگونه بررسی می‌کنید؟

با IS NULL یا IS NOT NULL، نه = NULL. SQL منطق سه‌ارزشی دارد و NULL با رشته خالی یا صفر یکسان نیست. برای یادگیری و تمرین از Tutorial رسمی PostgreSQL استفاده می‌کنم.

۲۳. چه تستی را خودکار می‌کنید؟

تستی با تکرار زیاد، رفتار نسبتاً پایدار، ارزش ریسک، Oracle روشن و قابلیت تشخیص خوب. هزینه ساخت، اجرا، داده و نگهداری را می‌بینم. تست یک‌باره، UX قضاوتی یا Feature بسیار ناپایدار ممکن است کاندید خوبی نباشد.

۲۴. یک Framework اتوماسیون خوب چه ویژگی‌هایی دارد؟

خوانا، نسخه‌بندی‌شده، مستقل، قابل‌پیکربندی، دارای Setup/Cleanup، گزارش تشخیصی، اجرای محلی/CI و مالکیت روشن است. Abstraction باید تغییر را محصور کند، نه اینکه لایه‌های بی‌فایده بسازد. اصول انتخاب و نگهداری در راهنمای اتوماسیون تست آمده است.

سوالات رفتاری مصاحبه QA

از STAR-L استفاده کنید: Situation، Task، Action، Result و Learning. داستان واقعی بگویید؛ اگر نتیجه عددی معتبر ندارید، عدد نسازید. سهم خود را با «من» و همکاری را با «ما» روشن کنید.

۲۵. با توسعه‌دهنده‌ای که باگ را قبول ندارد چه می‌کنید؟

هدف مشترک و شواهد را محور قرار می‌دهم: Build، داده، مراحل، Actual/Expected و اثر. شاید Oracle مبهم یا محیط متفاوت باشد؛ Pair reproduction پیشنهاد می‌کنم. اگر اختلاف Risk/Priority باقی ماند، Decision owner طبق Workflow تصمیم می‌گیرد.

۲۶. از اشتباه خودتان بگویید

یک مورد واقعی با اثر محدود انتخاب می‌کنم، دفاع نمی‌کنم و توضیح می‌دهم چه Signalی را ندیدم، چگونه اثر را مدیریت کردم و چه تغییر سیستمی ساختم. پاسخ «من بیش از حد دقیق هستم» یادگیری را نشان نمی‌دهد.

۲۷. وقتی چند کار فوری دارید چگونه اولویت می‌دهید؟

اثر مشتری/کسب‌وکار، احتمال، فوریت Release، Dependency و هزینه تأخیر را روشن می‌کنم؛ WIP را محدود و Trade-off را با ذی‌نفع ثبت می‌کنم. «همه را انجام می‌دهم» پاسخ واقع‌بینانه نیست.

۲۸. نمونه‌ای از بهبود فرایند بگویید

پاسخ باید Before، مشکل قابل‌اندازه‌گیری، آزمایش، Guardrail و نتیجه داشته باشد. مثلاً دسته‌بندی Fail نشان داد بیشتر زمان صرف داده ناپایدار می‌شود؛ Factory داده ساختیم و p95 بازخورد کم شد، در حالی که پوشش مسیر حیاتی حفظ شد.

۲۹. اگر کسب‌وکار بخواهد با Risk منتشر کند چه می‌کنید؟

QA صاحب حق وتوی عمومی نیست مگر Policy مشخص باشد. شواهد، اثر، احتمال، Mitigation، Monitoring، Rollback و Unknownها را شفاف می‌کنم. صاحب مجاز ریسک تصمیم می‌گیرد و تصمیم ثبت می‌شود.

۳۰. اگر جواب سوالی را ندانید چه می‌گویید؟

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

چگونه یک Bug report را در مصاحبه ارائه کنیم؟

ممکن است صفحه‌ای برای تست یا ویدیوی کوتاه داده شود. این ترتیب را حفظ کنید:

1. Title با عمل، محل و شکست؛
2. Build، Environment و Account type؛
3. Precondition و داده حداقلی؛
4. Steps مستقل و کوتاه؛
5. Actual و Expected با Oracle؛
6. اثر، دامنه و پیشنهاد Severity؛
7. Artifact پاک‌سازی‌شده و Correlation ID؛
8. Repro rate و موارد مقایسه‌شده.

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

آزمون عملی و Live Coding؛ چگونه فکر خود را نشان دهیم؟

پیش از شروع

• Scope، زمان، امکان استفاده از مستند و معیار ارزیابی را بپرسید.
• محیط و حساب تست را تأیید کنید.
• روی Production تست امنیت/بار یا داده مخرب اجرا نکنید.
• اگر Repository داده شده، دستور Setup را پیش از تغییر بخوانید.

حین کار

• یک مسیر کوچک End-to-end بسازید و سپس Edgeها را اضافه کنید.
• فرض و Trade-off را کوتاه با صدای بلند بگویید.
• نام‌گذاری، Error handling، Cleanup و Assertion معنادار را رعایت کنید.
• اگر گیر کردید، مسئله را کوچک، Log را بخوانید و فرضیه بسازید.

در پایان

• اجرا یا Demo کنید؛
• محدودیت و کار بعدی را صادقانه بگویید؛
• README کوتاه با دستور اجرا، انتخاب‌ها و Known issues بنویسید؛
• Secret و فایل تولیدی را Commit نکنید.

برای Automation role ممکن است کیفیت کد و تشخیص Fail مهم‌تر از تعداد Test باشد. برای Product QA ممکن است مدل ریسک، اکتشاف و گزارش وزن بیشتری داشته باشد.

اگر سابقه رسمی QA نداریم چه ارائه کنیم؟

• یک پروژه Demo مجاز با Risk map و Scope؛
• چند Test design مبتنی بر تکنیک، نه فهرست تصادفی؛
• Session report و سه Bug report امن؛
• Collection API و Queryهای Read-only؛
• Smoke کوچک در Git و CI؛
• Test summary شامل ریسک باقی‌مانده.

دوره و گواهی‌نامه می‌تواند ساختار یادگیری بدهد، اما جای Artifact و قضاوت را نمی‌گیرد. راه ساخت این مجموعه در مسیر شغلی QA آمده است.

سوالاتی که شما باید از مصاحبه‌کننده بپرسید

• موفقیت این نقش در ۹۰ روز اول چگونه دیده می‌شود؟
• QA چه زمانی وارد Requirement و Design می‌شود؟
• تصمیم Release و پذیرش Risk با چه کسی است؟
• بزرگ‌ترین گلوگاه فعلی بازخورد چیست؟
• نسبت فعالیت‌ها و نه فقط «Manual/Automation» چگونه است؟
• Flaky، Environment و Test data چه مالکیتی دارند؟
• On-call، Release خارج ساعت و اضافه‌کاری چگونه مدیریت می‌شود؟
• مسیر رشد فنی و مدیریتی چیست؟
• برای ابزار خارجی، Export و برنامه تداوم دسترسی چیست؟
• مرحله بعد فرایند استخدام و زمان تقریبی پاسخ چیست؟

پرسش «فرهنگ شرکت چگونه است؟» کلی است. مثال بخواهید: «آخرین اختلاف درباره کیفیت چگونه حل شد؟» پاسخ رفتاری، واقعیت بیشتری نشان می‌دهد.

نکات مصاحبه آنلاین برای متقاضیان ایران

• اینترنت و برق جایگزین، هدفون و محیط را پیش‌تر تست کنید.
• Timezone را با نام منطقه و تاریخ میلادی تأیید کنید.
• Repository، ابزار جلسه و لینک‌ها را از نظر دسترسی بررسی کنید.
• Screen sharing را روی پنجره لازم محدود و اعلان‌ها را خاموش کنید.
• رزومه، آگهی و چند Artifact را محلی و بدون Secret آماده داشته باشید.
• اگر قطع ارتباط شد، کانال و زمان تلاش مجدد را از قبل مشخص کنید.

برای حقوق، عدد ثابت مقاله قابل‌اتکا نیست. درباره Range، خالص/ناخالص، بیمه، دوره آزمایشی، اضافه‌کاری، تجهیزات، دورکاری و تاریخ بازبینی جبران خدمت شفاف بپرسید.

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

روز ۱: نقش و شواهد

آگهی را به ماتریس تبدیل و برای هر ادعا یک مثال آماده کنید.

روز ۲: مبانی و توضیح کوتاه

۸ سوال پایه را در پاسخ‌های ۶۰ تا ۹۰ثانیه‌ای تمرین کنید.

روز ۳: طراحی و سناریو

Login، Checkout و یک محصول ناآشنا را با چارچوب Clarify→Risk→Design حل کنید.

روز ۴: API و SQL

یک API را با تست منفی و Permission بررسی و JOIN/NULL را تمرین کنید.

روز ۵: Role-specific

برای Automation کد/CI؛ برای Product QA اکتشاف/دامنه؛ برای Performance/Security مبانی تخصصی مجاز را تمرین کنید.

روز ۶: رفتاری و Mock

پنج داستان STAR-L واقعی بسازید و یک مصاحبه آزمایشی ضبط کنید.

روز ۷: شرکت، سؤال و استراحت

محصول و تیم را بررسی، سؤال‌های خود را نهایی و Setup را تست کنید. شب آخر ابزار تازه یاد نگیرید.

اشتباه‌های رایج داوطلبان

• حفظ تعریف بدون مثال و Trade-off؛
• شروع سناریو بدون پرسیدن Scope؛
• ادعای «تست کامل» یا «بدون باگ»؛
• نام‌بردن ابزارهایی که نمی‌توانند درباره‌شان توضیح دهند؛
• مساوی‌گرفتن QA با آخرین Gate انتشار؛
• سرزنش توسعه‌دهنده در داستان تعارض؛
• ساختن عدد نتیجه یا تجربه غیرواقعی؛
• پنهان‌کردن ندانستن با پاسخ طولانی؛
• اجرای تست مخرب روی محصول عمومی شرکت؛
• نداشتن سؤال درباره نقش، Risk و شرایط کار.

چک‌لیست روز مصاحبه

• آگهی، رزومه و سه شاهد اصلی را مرور کرده‌ام.
• معرفی ۶۰ثانیه‌ای متناسب با نقش دارم.
• برای هر ادعای فنی مثال و محدودیت دارم.
• چارچوب پاسخ سناریویی را تمرین کرده‌ام.
• پنج داستان STAR-L واقعی آماده است.
• محیط Live task و دسترسی‌ها بررسی شده‌اند.
• زمان، Timezone و کانال جایگزین روشن است.
• پنج سؤال اولویت‌دار برای تیم دارم.
• می‌توانم «نمی‌دانم» را همراه با روش بررسی بگویم.

پرسش‌های متداول

برای مصاحبه Junior QA چه چیزهایی مهم‌تر است؟

مبانی تست، استخراج سؤال و ریسک از Requirement، طراحی تست مرزی، Bug report، HTTP/API و SQL پایه، ارتباط روشن و یک پروژه قابل‌بررسی. ابزارهای پیشرفته بدون این پایه اولویت کمتری دارند.

آیا باید جواب سوالات مصاحبه QA را حفظ کنیم؟

خیر. تعریف کوتاه را بدانید، اما پاسخ را با مثال، زمینه و Trade-off بسازید. سوال سناریویی عمداً برای دیدن روش فکر است و یک فهرست ثابت جواب کامل نیست.

برای مصاحبه Automation QA چه کدنویسی‌ای لازم است؟

به Stack و سطح نقش بستگی دارد. معمولاً ساختار داده، تابع، OOP در حد کاربرد، Error handling، تست‌پذیری، API، Git و CI مهم‌اند. از آگهی و مصاحبه‌کننده Scope آزمون را بپرسید.

اگر در مصاحبه یک باگ پیدا نکردیم چه می‌شود؟

در تمرین محدود، روش مشاهده و پوشش نیز مهم است. Scope، ریسک، تست‌های انجام‌شده، شواهد و چیزهای تست‌نشده را شفاف کنید. ساختن Bug یا ادعای بی‌پایه بدتر از گزارش «یافته قطعی ندارم» است.

بعد از مصاحبه چه زمانی پیگیری کنیم؟

اگر زمان پاسخ اعلام شده، پس از همان بازه پیگیری کنید. در غیر این صورت یک پیام کوتاه تشکر و سپس پیگیری محترمانه پس از چند روز کاری مناسب است. کانال ترجیحی Recruiter را رعایت کنید.

جمع‌بندی

برای مصاحبه QA، ۳۰ پاسخ را حفظ نکنید؛ ساختار تصمیم را تمرین کنید. نقش را تحلیل، شواهد خود را آماده، سناریو را با سؤال و ریسک مدل و محدودیت را صادقانه بیان کنید. مصاحبه فقط آزمون شما نیست؛ فرصتی است تا بفهمید تیم چگونه کیفیت، مسئولیت و رشد را مدیریت می‌کند.