راهنمای مصاحبه شغلی مهندس تست نرم‌افزار

معرفی

شایستگی‌های مورد سنجش

برای آشنایی بهتر با این راهنما، توجه به موارد زیر می‌تواند مفید باشد.

• تحلیل نیازمندی و کشف ابهام

  توانایی تحلیل داستان کاربر، طرح رابط یا قرارداد API و تبدیل آن‌ها به سناریوهای قابل آزمون، همراه با طرح پرسش‌هایی که شرط‌های پذیرش، نقش کاربر و محدودیت‌های داده را روشن می‌کنند.

• طراحی سناریو و پوشش حالت‌های مرزی

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

• ثبت باگ قابل بازتولید

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

• تست API و فهم رفتار سرویس

  بررسی متد درخواست، کد وضعیت، بدنه پاسخ، احراز هویت، اعتبارسنجی ورودی و اثر تغییرات API بر رابط کاربری و داده‌ها.

• اولویت‌بندی بر پایه ریسک

  تفکیک شدت اثر (Severity) از اولویت رفع (Priority) و تمرکز بر مسیرهایی مانند ورود، پرداخت، ثبت سفارش، داده‌های حساس یا قابلیت‌هایی که اخیراً تغییر کرده‌اند، در زمان محدود.

• درک فنی محصول

  توانایی استفاده از Chrome DevTools، خواندن درخواست‌های شبکه، بررسی اولیه داده‌های پایگاه داده با SQL و تشخیص اینکه منشأ مشکل احتمالا در رابط کاربری، API یا داده‌ها است.

• همکاری با تیم محصول و توسعه

  بیان مشکل بدون نسبت‌دادن تقصیر، هم‌راستا شدن درباره شدت باگ، پیگیری رفع مشکل و انتقال ریسک‌های باقی‌مانده در تصمیم‌گیری برای انتشار.

• مبانی اتوماسیون تست

  در سناریوهای اتوماسیون تست، توانایی توضیح انتخاب موارد مناسب برای خودکارسازی، پایداری و نگهداری تست‌های خودکار، مدیریت کد و نقش اجرای تست‌ها در فرایند CI.

برنامه آماده‌سازی

در ادامه، مهم‌ترین موارد این بخش به تفکیک معرفی شده‌اند.

• برنامه زمانی آماده‌سازی

  اگر مبانی تست، کار با API و SQL را دارید، ۲ تا ۳ هفته با هفته‌ای ۶ تا ۸ ساعت تمرین هدفمند اختصاص دهید. خروجی قابل سنجش این بازه می‌تواند شامل ۱۲ تا ۱۵ سناریوی تست، ۳ گزارش باگ کامل، تست دست‌کم ۲ API و یک تمرین تحلیل خطا در DevTools باشد.

  اگر از صفر شروع می‌کنید، ۵ تا ۸ هفته با هفته‌ای ۸ تا ۱۰ ساعت زمان واقع‌بینانه‌تری است. ابتدا مفاهیم تست و سناریونویسی را یاد بگیرید، سپس Postman و SQL پایه را تمرین کنید. پیش از ارسال رزومه، دست‌کم ۲۰ سناریوی تست، ۵ گزارش باگ با مراحل بازتولید مشخص و یک پروژه تمرینی مستند آماده داشته باشید.

• طراحی تست برای یک قابلیت واقعی

  یک قابلیت رایج مانند ثبت‌نام، ورود، سبد خرید یا تغییر رمز عبور انتخاب کنید. برای آن پیش‌شرط، داده تست، مسیر اصلی، ورودی نامعتبر، نقش‌های کاربری، پیام خطا و شرایط مرزی بنویسید. میان «سناریوی تست» و «مورد تست» تمایز بگذارید؛ مورد تست باید نتیجه مورد انتظار مشخصی داشته باشد.

  تمرین کنید که از یک نیازمندی مبهم، پرسش‌های روشن استخراج کنید؛ مثلا حداقل طول رمز عبور، رفتار کاربر غیرفعال، محدودیت تعداد تلاش ناموفق و امکان استفاده هم‌زمان در چند دستگاه. برای مرور واژگان و مفاهیم پایه تست، واژه‌نامه و ساختار آزمون‌های سطح پایه ISTQB را در منابع رسمی ISTQB مطالعه کنید.

• گزارش باگ و ارزیابی شدت

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

  شدت اثر (Severity) را با اولویت رفع (Priority) یکی ندانید. خطای پرداخت معمولا شدت اثر بالایی دارد، اما اولویت نهایی آن می‌تواند به تعداد کاربران درگیر، وجود راه‌حل موقت و زمان انتشار وابسته باشد. برای ساختاردهی اصطلاحات تست و گزارش‌دهی، از واژه‌نامه ISTQB استفاده کنید.

• تست API با Postman

  یک API عمومی یا پروژه تمرینی را با Postman تست کنید. درخواست‌های GET، ‏POST، ‏PUT، ‏PATCH و DELETE را متناسب با نیاز محصول تمرین کنید. کدهای وضعیت، ساختار پاسخ، خطاهای اعتبارسنجی، توکن احراز هویت و ارسال داده ناقص را بررسی کنید.

  برای ارزیابی صحیح API فقط به کد وضعیت ۲۰۰ اکتفا نکنید؛ مقدارهای بدنه پاسخ، اثر درخواست بر داده‌ها و سازگاری پیام خطا با نیازمندی‌ها را نیز کنترل کنید. راهنمای رسمی شروع کار با Postman و ارسال درخواست برای همین تمرین مناسب است.

• تحلیل خطا با ابزارهای مرورگر و SQL

  در Chrome DevTools تب‌های Network و Console را تمرین کنید. یاد بگیرید چگونه درخواست ناموفق، کد وضعیت، بدنه پاسخ و خطای جاوااسکریپت را از یکدیگر تشخیص دهید. هدف، تشخیص اولیه محل مشکل است، نه جایگزینی نقش توسعه‌دهنده.

  مبانی SQL شامل SELECT، ‏WHERE، ‏JOIN و مرتب‌سازی را مرور کنید تا بتوانید داده‌های ثبت‌شده یا نتیجه اجرای یک فرایند را با احتیاط بررسی کنید. در مصاحبه، هرگز ادعا نکنید که بدون مجوز داده‌های محیط تولید را تغییر می‌دهید. برای DevTools از راهنمای رسمی Network و برای SQL از آموزش رسمی SQL در PostgreSQL استفاده کنید.

• اتوماسیون و انتخاب سناریوی مناسب

  اگر مسیر اتوماسیون تست را انتخاب می‌کنید، با یکی از ابزارهای Selenium، Playwright یا Cypress یک سناریوی پایدار مانند ورود موفق را خودکار کنید. توضیح دهید چرا این سناریو برای رگرسیون مناسب است و چرا یک رابط کاربری ناپایدار یا سناریوی اکتشافی را نباید فوراً خودکار کرد.

  مفاهیم selector پایدار، انتظار صریح (Explicit Wait)، داده تست مستقل، گزارش شکست و نگهداری تست‌ها در Git را مرور کنید. در برخی تیم‌ها تست‌های خودکار با ابزارهایی مانند Jenkins در خط CI اجرا می‌شوند؛ لازم نیست Jenkins را بدون نیاز یاد بگیرید، اما باید بتوانید توضیح دهید اجرای خودکار تست‌ها پس از تغییر کد چه بازخوردی درباره کیفیت تغییرات به تیم ارائه می‌دهد. مستندات Playwright، ‏Cypress و Selenium برای تمرین عملی مناسب هستند.

• مرور آگهی و محصول شرکت

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

  موارد مطرح‌شده در آگهی را به سؤال تبدیل کنید؛ مثلا اگر «تست API» نوشته شده است، بپرسید APIها داخلی هستند یا عمومی، مستندات دارند یا نه و تست‌ها دستی هستند یا در خط لوله انتشار اجرا می‌شوند.

چک‌لیست آماده‌سازی

موارد زیر را یک‌به‌یک بررسی کنید تا چیزی جا نماند:

• برنامه آماده‌سازی خود را با توجه به سطح فعلی، بین ۲ تا ۸ هفته و با ساعت تمرین هفتگی مشخص کرده‌ام.
• سه سناریوی تست کامل برای یک قابلیت وب یا موبایل نوشته‌ام.
• دو گزارش باگ شامل مراحل بازتولید، نتیجه مورد انتظار و سایر جزئیات لازم آماده دارم.
• تفاوت شدت اثر باگ و اولویت رفع آن را می‌توانم توضیح دهم.
• یک API را با Postman برای ورودی معتبر و نامعتبر بررسی کرده‌ام.
• کاربرد تب‌های Network و Console در Chrome DevTools را تمرین کرده‌ام.
• مبانی SELECT، ‏WHERE و JOIN در SQL را مرور کرده‌ام.
• آگهی شغلی و محصول شرکت را خوانده‌ام و ریسک‌های اصلی آن را یادداشت کرده‌ام.
• برای هر ابزار نوشته‌شده در رزومه، یک تجربه عملی قابل توضیح دارم.
• اگر موقعیت اتوماسیون است، یک تست خودکار کوچک و قابل اجرا دارم.
• پرسش‌هایم درباره فرایند تست، محیط‌ها و تصمیم انتشار را آماده کرده‌ام.

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

• فنی

  برای قابلیت ثبت‌نام کاربر جدید، چه سناریوهای تستی می‌نویسید؟

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

  راهنمای پاسخ و نمونه پاسخ

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

  پیش از تعیین رفتار مورد انتظار، ابهام‌های مهم را مطرح کنید؛ آیا فعال‌سازی با پیامک یا ایمیل انجام می‌شود؟ کاربر غیرفعال می‌تواند دوباره ثبت‌نام کند؟ محدودیت نرخ ارسال کد وجود دارد؟

  ابتدا شرایط پذیرش را روشن می‌کنم؛ کاربر پس از ثبت‌نام فوراً وارد حساب کاربری می‌شود یا باید حساب خود را فعال کند؟ سپس مسیر موفق را با داده معتبر بررسی می‌کنم و مطمئن می‌شوم حساب ایجاد شده و پیام مناسب نمایش داده می‌شود.

  برای حالت‌های خطا، ایمیل تکراری، فرمت نامعتبر، رمز عبور کوتاه، خالی بودن فیلدهای اجباری و عدم تطابق تکرار رمز را تست می‌کنم. ارسال سریع و چندباره فرم را نیز بررسی می‌کنم تا حساب تکراری یا درخواست تکراری ایجاد نشود. اگر کد تأیید وجود داشته باشد، انقضا، تلاش ناموفق و درخواست مجدد کد را در سناریوهای تست لحاظ می‌کنم.

• فنی

  یک گزارش باگ خوب چه اجزایی دارد؟

  ارزیابی توانایی تولید گزارش قابل اقدام برای توسعه‌دهنده و پرهیز از گزارش‌های مبهم.

  راهنمای پاسخ و نمونه پاسخ

  عنوان باید رفتار خطا و محل بروز آن را روشن کند. سپس محیط اجرا، نسخه نرم‌افزار یا بیلد، نقش کاربر، پیش‌شرط‌ها، مراحل بازتولید، نتیجه مورد انتظار، نتیجه واقعی و شواهد را ذکر کنید.

  شدت اثر (Severity) پیشنهادی را همراه با دلیل بنویسید. اگر باگ متناوب است، فراوانی مشاهده، داده‌های استفاده‌شده و هر نشانه فنی مانند پاسخ ناموفق API را اضافه کنید.

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

  نتیجه واقعی، شناسه سفارش و تصویر یا ویدئو را ضمیمه می‌کنم. چون ممکن است کاربر هزینه را پرداخت کرده باشد اما سفارش ثبت نشود، شدت اثر (Severity) را بالا ارزیابی می‌کنم و وجود یا نبود راه‌حل موقت را نیز مشخص می‌کنم.

• فنی

  تفاوت تست رگرسیون با تست مجدد رفع باگ چیست؟

  سنجش درک تفاوت بررسی یک اصلاح مشخص با بررسی اثر جانبی تغییرات بر قابلیت‌های قبلی.

  راهنمای پاسخ و نمونه پاسخ

  تست مجدد پس از رفع باگ (Retest) بررسی می‌کند که همان خطای گزارش‌شده با همان مراحل بازتولید دیگر رخ نمی‌دهد. تست رگرسیون (Regression Testing) بررسی می‌کند تغییر انجام‌شده، قابلیت‌های مرتبط یا مسیرهایی که قبلا سالم بوده‌اند را خراب نکرده باشد.

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

  اگر باگ مربوط به این باشد که کد تخفیف در سفارش اول اعمال نمی‌شود، تست مجدد (Retest) یعنی همان شرایط بازتولید را دوباره اجرا کنم و تأیید کنم تخفیف اعمال شده است. تست رگرسیون (Regression Testing) یعنی بررسی کنم تغییر منطق تخفیف باعث نشده قابلیت‌های مرتبط مانند کدهای تخفیف دیگر، مبلغ نهایی، مالیات یا پرداخت سفارش‌های عادی دچار مشکل شوند.

• فنی

  هنگام تست یک API، علاوه بر کد وضعیت، چه چیزهایی را بررسی می‌کنید؟

  سنجش نگاه فراتر از پاسخ سطحی HTTP و توانایی بررسی قرارداد، داده و خطاهای API.

  راهنمای پاسخ و نمونه پاسخ

  متد درخواست، پارامترها، هدرها، احراز هویت، ساختار و نوع داده‌های پاسخ، پیام خطا، زمان پاسخ در بررسی اولیه و اثر عملیات بر داده را بررسی کنید. برای عملیات تغییر‌دهنده داده، تکرار درخواست و رفتار API در صورت ارسال دوباره آن را نیز بررسی کنید.

  ورودی‌های معتبر و نامعتبر را تفکیک کنید؛ مثلا ورودی نامعتبر نباید صرفا با پاسخ موفق و پیام نامشخص برگردد.

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

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

• موقعیتی

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

  سنجش توانایی ارزیابی ریسک، اطلاع‌رسانی سریع، ثبت شواهد و مشارکت مسئولانه در تصمیم انتشار.

  راهنمای پاسخ و نمونه پاسخ

  ابتدا با محیط و داده تست مشخص، باگ را بازتولید کنید و دامنه اثر آن را بسنجید؛ آیا همه کاربران تحت تأثیر هستند یا فقط یک روش پرداخت؟ آیا همه سفارش‌ها مشکل دارند یا فقط یک وضعیت خاص؟ شواهد، شناسه‌های مرتبط و نتیجه API را جمع‌آوری کنید.

  موضوع را سریع به ذی‌نفعان مرتبط مانند لید QA، مدیر محصول و توسعه‌دهنده مربوط اطلاع دهید. شدت اثر، راه‌حل موقت، امکان غیرفعال‌سازی قابلیت و ریسک انتشار را مشخص کنید. تصمیم‌گیری برای انتشار باید بر اساس اطلاعات کامل از ریسک‌ها انجام شود و مشکلات مهم نباید پنهان بمانند.

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

  چون مسیر پرداخت حساس است، منتظر جلسه بعدی نمی‌مانم و سرپرست QA و مدیر محصول را مطلع می‌کنم. بررسی می‌کنیم آیا راه‌حل موقت، غیرفعال‌کردن روش پرداخت یا بازگرداندن تغییر اخیر امکان‌پذیر است. پس از رفع مشکل، ابتدا تست مجدد رفع باگ و سپس تست رگرسیون مسیرهای مرتبط مانند ثبت سفارش و تغییر وضعیت پرداخت را انجام می‌دهم.

• فنی

  شدت اثر باگ و اولویت رفع آن چه تفاوتی دارند؟

  ارزیابی توانایی تصمیم‌گیری کیفیت بر پایه اثر کسب‌وکاری و زمینه انتشار، نه فقط برچسب‌های ابزار مدیریت باگ.

  راهنمای پاسخ و نمونه پاسخ

  شدت اثر (Severity) به میزان تأثیر باگ بر کاربر، داده، امنیت یا عملکرد قابلیت اشاره دارد. اولویت رفع (Priority) به زمان و ترتیب رسیدگی با توجه به عواملی مانند زمان انتشار، تعداد کاربران درگیر، وجود راه‌حل موقت، اهمیت تجاری و هزینه رفع مربوط است.

  نمونه‌ای بیاورید که این دو یکسان نیستند؛ مثلا یک خطای ظاهری در صفحه اصلی کمپین ممکن است نزدیک زمان انتشار، اولویت رفع بالایی داشته باشد، در حالی که شدت اثر فنی آن پایین است.

  شدت اثر (Severity) نشان می‌دهد باگ چه میزان به محصول آسیب می‌زند؛ مثلا حذف ناخواسته داده شدت اثر بالایی دارد. اولویت رفع (Priority) مشخص می‌کند تیم چه زمانی و با چه ترتیبی باید آن را برطرف کند. ممکن است یک باگ با شدت اثر متوسط در صفحه اصلی یک کمپین، در شرایط فعلی اولویت رفع بالایی داشته باشد، چون کاربران زیادی آن را مشاهده می‌کنند.

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

• نمونه‌کار

  یکی از پروژه‌های تمرینی یا نمونه‌کارهای تست خود را توضیح دهید. چه چیزی را، با چه روشی و با چه نتایجی تست کردید؟

  سنجش واقعی‌بودن تجربه عملی، توانایی توضیح تصمیم‌های تست و ارتباط میان سناریو، باگ و شواهد.

  راهنمای پاسخ

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

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

• فنی

  چه تست‌هایی را برای خودکارسازی انتخاب می‌کنید و چه تست‌هایی را نه؟

  ارزیابی فهم ارزش اتوماسیون، هزینه نگهداری و تفاوت آن با تست اکتشافی.

  راهنمای پاسخ و نمونه پاسخ

  سناریوهای پرتکرار، پایدار، حساس و دارای نتیجه قابل پیش‌بینی مانند ورود، ایجاد سفارش یا بررسی APIهای کلیدی، کاندیدای مناسب‌تری برای اتوماسیون هستند. ارزش این سناریوها در اجرای مکرر تست‌های رگرسیون و ارائه بازخورد سریع است.

  برای رابط‌های کاربری که دائما تغییر می‌کنند، ارزیابی جزئیات ظاهری، ابهام در نیازمندی‌ها یا کشف رفتارهای پیش‌بینی‌نشده، تست دستی و اکتشافی معمولا مناسب‌تر است. هزینه نگهداری تست و پایداری داده تست را نیز در تصمیم‌گیری خود در نظر بگیرید.

  برای خودکارسازی ابتدا سناریوهای پرتکرار و پرریسک را انتخاب می‌کنم؛ مثلا ورود، ثبت سفارش و APIهای اصلی، چون در هر انتشار باید دوباره بررسی شوند و نتیجه قابل پیش‌بینی دارند. پیش از نوشتن تست، پایداری selectorها و امکان ایجاد داده تست مستقل را بررسی می‌کنم.

  یک قابلیت تازه یا سناریوی اکتشافی را فورا خودکار نمی‌کنم، چون هدف آن کشف مسئله است و نیازمندی‌ها یا رفتار محصول ممکن است هنوز تغییر کند. اتوماسیون مکمل تست دستی است، نه جایگزین آن.

• رفتاری

  اگر توسعه‌دهنده بگوید باگ ثبت‌شده قابل بازتولید نیست، چگونه پیگیری می‌کنید؟

  سنجش همکاری بدون تقابل، دقت در گردآوری شواهد و توانایی محدودکردن شرایط رخداد باگ.

  راهنمای پاسخ و نمونه پاسخ

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

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

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

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

• موقعیتی

  نیازمندی یک قابلیت، مبهم است و مدیر محصول در دسترس نیست. تست را چگونه شروع می‌کنید؟

  سنجش توانایی مدیریت ابهام بدون ساختن فرض‌های پنهان و حفظ حرکت کار.

  راهنمای پاسخ

  ابهام‌ها را شناسایی و فهرست کنید و آن‌ها را بر اساس تأثیر بر رفتار محصول اولویت دهید. از طرح رابط کاربری (UI)، داستان‌های مشابه، قرارداد API یا رفتار نسخه فعلی برای ساخت فرضیه اولیه استفاده کنید، اما فرضیه را به‌عنوان تصمیم قطعی مطرح نکنید.

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

• فنی

  با Chrome DevTools چگونه برای تشخیص اولیه یک خطای وب استفاده می‌کنید؟

  ارزیابی توانایی استفاده عملی از ابزار مرورگر برای تولید شواهد و تفکیک مسئله رابط از سرویس.

  راهنمای پاسخ و نمونه پاسخ

  در Console خطاهای جاوااسکریپت را بررسی کنید. در Network درخواست مرتبط را پیدا کنید و متد HTTP، کد وضعیت، زمان پاسخ، داده ارسالی درخواست و پاسخ دریافتی را با رفتار مورد انتظار مقایسه کنید.

  نتیجه را با احتیاط گزارش کنید. مثلا بگویید «رابط، پاسخ ۴۰۳ از API دریافت می‌کند» نه اینکه بدون بررسی قطعی، ریشه مشکل را به یک تیم یا بخش خاص نسبت دهید.

  ابتدا با بازتولید خطا، Console را برای پیام‌های خطا بررسی می‌کنم. سپس در Network درخواست مرتبط با اقدام کاربر را پیدا می‌کنم و URL، متد HTTP، ‏Payload، کد وضعیت و بدنه پاسخ را بررسی می‌کنم. اگر پاسخ API موفق است اما رابط کاربری نتیجه را نادرست نمایش می‌دهد، این تفاوت را در گزارش ثبت می‌کنم.

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

• فرهنگی

  وقتی تیم برای انتشار عجله دارد، چگونه هم کیفیت را حفظ می‌کنید و هم مانع بی‌دلیل ایجاد نمی‌کنید؟

  سنجش نگاه واقع‌بینانه به کیفیت، شفافیت درباره ریسک و توانایی کار در چرخه‌های انتشار فشرده.

  راهنمای پاسخ

  پاسخ باید نشان دهد کیفیت فقط «تأیید یا رد انتشار» نیست. مسیرهای حساس و تغییر داده‌شده را بر اساس ریسک اولویت دهید، موارد تست‌شده و تست‌نشده را روشن کنید و باگ‌های باز را همراه با اثر و ریسک آن‌ها گزارش دهید.

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

• نمونه‌کار

  اگر یک تست خودکار شما گاهی بدون تغییر محصول شکست می‌خورد، چگونه آن را بررسی می‌کنید؟

  سنجش درک پایداری تست، تشخیص تست ناپایدار و نگاه نگهداری‌پذیر به اتوماسیون.

  راهنمای پاسخ و نمونه پاسخ

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

  به‌جای افزودن تأخیر ثابت، شرط انتظار را به یک رویداد یا وضعیت معنادار متصل کنید. داده تست را مستقل کنید و مشخص کنید آیا شکست ناشی از باگ محصول است یا تست ناپایدار (Flaky Test).

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

  هم‌زمان بررسی می‌کنم داده تست بین اجراها مشترک نباشد و تست به ترتیب اجرای تست‌های دیگر وابسته نباشد. اگر API یا محیط ناپایدار است، آن را جداگانه ثبت می‌کنم تا شکست تست به‌اشتباه به‌عنوان باگ محصول ثبت نشود.

• رفتاری

  نمونه‌ای از زمانی بگویید که پس از انتشار، خطایی پیدا شد که در تست‌ها ندیده بودید.

  سنجش مسئولیت‌پذیری، توانایی تحلیل شکاف پوشش تست و تبدیل رخداد به بهبود فرایند.

  راهنمای پاسخ

  یک رخداد واقعی یا تمرینی را با دامنه اثر مشخص بیان کنید؛ کدام مسیر کاربر، در چه شرایطی و با چه اثری رخ داده است. توضیح دهید چرا در پوشش تست شناسایی نشده بود؛ مثلا به دلیل داده غیرمعمول، نقش کاربری متفاوت، وابستگی به محیط یا ابهام در نیازمندی.

  روی اقدام اصلاحی تمرکز کنید؛ افزودن مورد تست رگرسیون، بهبود داده تست، شفاف‌سازی شرط پذیرش یا افزودن پایش پس از انتشار. مقصر دانستن توسعه‌دهنده یا کاربر، پاسخ را ضعیف می‌کند.

• فرهنگی

  از تیم QA و فرایند تست این شرکت چه انتظاری دارید؟

  سنجش تناسب انتظارهای شما با واقعیت کار تیمی و علاقه او به مشارکت در کیفیت محصول.

  راهنمای پاسخ

  انتظارات متناسب با نقش را بیان کنید؛ دسترسی به نیازمندی‌ها و محیط تست، امکان طرح پرسش پیش از شروع توسعه، کانال روشن برای ثبت و پیگیری باگ و همکاری محترمانه با تیم توسعه و محصول.

  هم‌زمان نشان دهید که بلوغ فرایند را یک شرط مطلق نمی‌دانید. در تیم‌های کوچک ممکن است مستندسازی یا اتوماسیون کامل وجود نداشته باشد و شما باید در ایجاد و بهبود تدریجی آن مشارکت کنید.

پرسش‌های شما از پنل مصاحبه

• در این موقعیت، سهم تست دستی، تست API و اتوماسیون تست چگونه است؟

  عنوان QA به‌تنهایی دامنه کار را روشن نمی‌کند و پاسخ، تناسب موقعیت با مسیر حرفه‌ای شما را مشخص می‌سازد.

• پیش از انتشار، چه کسی درباره ریسک‌های باز و تأیید نهایی نسخه تصمیم می‌گیرد؟

  نشان می‌دهد آیا کیفیت به‌عنوان یک مسئولیت مشترک در تیم پذیرفته شده است یا مسئولیت تصمیم انتشار به‌طور ناعادلانه بر عهده یک تستر قرار می‌گیرد.

• نیازمندی‌ها و شرط‌های پذیرش معمولا چه زمانی در اختیار QA قرار می‌گیرند؟

  مشارکت زودهنگام QA تأثیر مستقیمی بر پیشگیری از خطا و کیفیت سناریوهای تست دارد.

• محیط تست، داده آزمایشی و دسترسی به لاگ‌ها چه وضعیتی دارند؟

  بدون محیط تست و داده تست مناسب، بازتولید باگ و اطمینان از اعتبار نتایج تست دشوار می‌شود.

• بیشترین ریسک کیفیت محصول در حال حاضر در کدام جریان کاربر یا پلتفرم است؟

  به شما کمک می‌کند مسئله‌های واقعی تیم، چالش‌های فرآیند تست و نیازهای محصول را بهتر بشناسید و نشان می‌دهد نگاهتان فقط به ابزارها محدود نیست.

• تست‌های خودکار در کجا اجرا می‌شوند و مسئول نگهداری آن‌ها چه کسی است؟

  برای موقعیت‌های اتوماسیون، وضعیت واقعی اجرای تست‌ها در CI، مالکیت نگهداری تست‌ها و هزینه نگهداری آن‌ها را روشن می‌کند.

• وقتی توسعه‌دهنده و QA درباره شدت یا اولویت یک باگ اختلاف دارند، فرایند تصمیم‌گیری چیست؟

  پاسخ، کیفیت همکاری تیمی و نحوه مدیریت اختلاف‌نظرها در دوره‌های نزدیک به انتشار را نشان می‌دهد.

• موفقیت فردی که این نقش را بر عهده می‌گیرد، در سه ماه نخست با چه شاخص‌ها و خروجی‌های کیفی سنجیده می‌شود؟

  انتظارات واقعی از میزان پوشش تست، شناخت محصول، گزارش‌دهی و مشارکت QA در فرآیند را مشخص می‌کند.

اشتباه‌های رایج

در ادامه تعدادی از اشتباهاتی که اغلب افراد در مصاحبه شغل «مهندس تست نرم‌افزار» انجام می‌دهند، آمده است. پرهیز از انجام این اشتباهات، می‌تواند شانس شما را برای پذیرفته شدن از مصاحبه و استخدام نهایی بیشتر کند.

• محدودکردن تست به کلیک‌کردن روی مسیر عادی

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

• الزام به رفع همه باگ‌ها پیش از انتشار

  درباره ارزیابی ریسک، شدت اثر، راه‌حل موقت و تصمیم‌گیری مشترک میان محصول و تیم فنی توضیح دهید.

• یکی دانستن شدت اثر و اولویت باگ

  با یک مثال توضیح دهید که اولویت رفع باگ، علاوه بر شدت اثر، به زمان انتشار، تعداد کاربران درگیر و شرایط کسب‌وکار نیز وابسته است.

• فهرست‌کردن ابزارها بدون تجربه قابل توضیح

  برای هر ابزار درج‌شده در رزومه، یک سناریوی عملی مشخص مانند ساخت Collection در Postman یا تحلیل یک درخواست در DevTools آماده کنید.

• نوشتن گزارش باگ بدون داده و محیط بازتولید

  نسخه یا بیلد، نقش کاربر، داده ورودی، مراحل بازتولید، نتیجه مورد انتظار، نتیجه واقعی و شواهد مرتبط را در پاسخ خود ذکر کنید.

• جایگزینی تست دستی با اتوماسیون

  کاربرد اتوماسیون در رگرسیون پایدار را از نقش تست اکتشافی و ارزیابی تجربه کاربر تفکیک کنید.

• نسبت‌دادن قطعی علت باگ به توسعه‌دهنده

  رفتار مشاهده‌شده و شواهد موجود را گزارش کنید؛ مثلا پاسخ API یا خطای رابط را بیان کنید و علت قطعی را بدون بررسی و شواهد کافی اعلام نکنید.

• نادیده‌گرفتن ابهام نیازمندی

  پیش از طراحی تست، ابهام‌های مربوط به مجوزها، محدودیت‌ها، پیام‌های خطا و رفتار پس از موفقیت را مطرح و شفاف کنید.

پس از مصاحبه

پرسش‌های پرتکرار

در این بخش، به تعدادی از پرسش‌های رایج درباره این راهنما پاسخ داده شده است.

آموزش‌های مرتبط در فرادرس

• آموزش آشنایی با مبانی توسعه و تست نرم افزار + گواهینامه آموزش ویدئویی
• آموزش پستمن Postman، ابزار تست ای پی آی API + گواهینامه آموزش ویدئویی
• آموزش تست نویسی با Jest و TypeScript در Node.js + پروژه‌های کاربردی + گواهینامه آموزش ویدئویی

منابع پیشنهادی

• ISTQB Glossary: Search وب‌سایتglossary.istqb.org
• OWASP API Security Project وب‌سایتowasp.org