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

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

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

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

در این مقاله قرار نیست دوباره تمام مباحث تست نرم افزار را از ابتدا آموزش دهیم. برای بسیاری از موضوعات مانند Test Case، Test Scenario، API Testing، Automation Testing و… مقالات تخصصی جداگانه وجود دارد. تمرکز این مقاله روی این است که بدانیم برای تبدیل شدن به یک نیروی حرفه‌ای در حوزه تست نرم افزار چه مسیری را باید طی کنیم.

اگر هنوز نمی‌دانید تست نرم افزار چیست و چرا انجام می‌شود، بهتر است ابتدا مقاله «تست نرم افزار چیست؟» را مطالعه کنید. اما اگر با مفهوم تست آشنا هستید و می‌خواهید بدانید چگونه آن را به یک مسیر شغلی تبدیل کنید، ادامه این مقاله برای شماست.

کارشناس تست نرم افزار چه کاری انجام می‌دهد؟

قبل از اینکه درباره مسیر تبدیل شدن به کارشناس تست نرم افزار صحبت کنیم، باید بدانیم این فرد در یک تیم نرم افزاری دقیقاً چه کاری انجام می‌دهد.

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

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

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

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

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

یک کارشناس تست ممکن است در طول یک پروژه فعالیت‌هایی مانند موارد زیر انجام دهد:

  • بررسی و تحلیل نیازمندی‌ها
  • شناسایی موارد قابل تست
  • طراحی Test Scenario و Test Case
  • اجرای تست‌های دستی
  • بررسی رفتار سیستم در شرایط مختلف
  • ثبت و گزارش Bug
  • پیگیری وضعیت خطاها
  • انجام Retesting پس از اصلاح خطا
  • اجرای Regression Testing
  • بررسی APIها
  • بررسی داده‌های پایگاه داده
  • اجرای تست‌های خودکار
  • همکاری با توسعه‌دهندگان و سایر اعضای تیم
  • ارائه بازخورد درباره کیفیت محصول

البته همه این فعالیت‌ها در تمام موقعیت‌های شغلی با یک شدت و ساختار انجام نمی‌شوند. وظایف یک کارشناس Manual Testing با یک مهندس Automation یا یک Senior QA Engineer می‌تواند متفاوت باشد.

به همین دلیل، وقتی درباره «کارشناس تست نرم افزار» صحبت می‌کنیم، منظور فقط فردی نیست که Bug پیدا می‌کند؛ بلکه فردی است که با استفاده از روش‌ها و تکنیک‌های تست، به تیم کمک می‌کند کیفیت و ریسک‌های محصول را بهتر ارزیابی کند.

برای آشنایی عمیق‌تر با مفهوم تست نرم افزار می‌توانید به مقاله Software Testing و برای شناخت ارتباط تست با کیفیت نرم افزار به مقاله QA vs QC مراجعه کنید. همچنین مباحث Requirement و Bug Report نیز در مقالات تخصصی سایت به‌صورت جداگانه بررسی شده‌اند.

برای کارشناس تست نرم افزار شدن چه مهارت‌هایی لازم است؟

یکی از سؤال‌های مهم افرادی که می‌خواهند وارد این حوزه شوند این است که:

«برای تستر شدن دقیقاً چه چیزهایی باید بلد باشم؟»

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

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

۱. مبانی تست نرم افزار

اولین و مهم‌ترین پایه، شناخت اصول تست نرم افزار است.

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

مفاهیمی مانند Test Types، Test Levels، Verification و Validation و تفاوت Error، Defect و Failure در این مرحله اهمیت دارند.

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

برای یادگیری عمیق‌تر این بخش می‌توانید به مقالات Software Testing، Test Types، Test Levels، Verification و Validation و Error، Defect و Failure مراجعه کنید.

۲. تفکر تست و توانایی تحلیل

یکی از مهم‌ترین مهارت‌هایی که معمولاً با مطالعه صرف به دست نمی‌آید، Test Thinking یا تفکر تست است.

یک تستر باید بتواند فقط به مسیر عادی استفاده از نرم افزار فکر نکند. او باید از خود بپرسد:

اگر کاربر این کار را اشتباه انجام دهد چه می‌شود؟

اگر مقدار ورودی خیلی بزرگ یا خیلی کوچک باشد چه اتفاقی می‌افتد؟

اگر یک مرحله از فرایند ناقص انجام شود سیستم چه رفتاری دارد؟

اگر دو کاربر هم‌زمان همین عملیات را انجام دهند چه می‌شود؟

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

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

این مهارت با تمرین و تجربه رشد می‌کند و یکی از تفاوت‌های مهم بین یک فرد صرفاً آموزش‌دیده و یک تستر باتجربه است.

۳. تحلیل نیازمندی

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

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

فرض کنید در Requirement نوشته شده است:

«کاربر باید بتواند با وارد کردن اطلاعات معتبر وارد حساب کاربری خود شود.»

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

  • اطلاعات معتبر دقیقاً چه ویژگی‌هایی دارند؟
  • اگر رمز عبور اشتباه باشد چه اتفاقی باید بیفتد؟
  • اگر نام کاربری خالی باشد چه می‌شود؟
  • محدودیت تعداد تلاش برای ورود وجود دارد؟
  • حروف بزرگ و کوچک اهمیت دارند؟
  • پس از ورود موفق کاربر به کدام صفحه منتقل می‌شود؟
  • پیام خطا چگونه باید نمایش داده شود؟

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

به همین دلیل، آشنایی با Requirement، SRS، BRD، PRD، FRD، User Story و Acceptance Criteria برای یک تستر اهمیت دارد.

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

۴. مهارت طراحی تست

پس از اینکه نیازمندی را درک کردید، سؤال بعدی این است:

«چگونه این نیازمندی را تست کنیم؟»

اینجاست که مهارت طراحی تست اهمیت پیدا می‌کند.

تستر باید بتواند نیازمندی را به شرایط قابل تست تبدیل کند و برای آن Test Scenario و Test Case مناسب طراحی کند.

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

در این مرحله، آشنایی با Test Case، Test Scenario، Test Design و Test Technique اهمیت دارد.

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

۵. اجرای تست و گزارش خطا

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

اگر نتیجه با رفتار مورد انتظار تفاوت داشته باشد، باید مشخص شود که آیا واقعاً با یک Defect مواجه هستیم یا خیر.

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

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

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

در این مرحله، مفاهیمی مانند Bug Report، Bug Life Cycle، Retesting و Regression Testing اهمیت پیدا می‌کنند.

۶. مهارت‌های ارتباطی

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

تستر باید بتواند یک مشکل را شفاف، دقیق و بدون ایجاد سوءتفاهم توضیح دهد.

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

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

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

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

مسیر ورود به حوزه تست نرم افزار از کجا شروع می‌شود؟

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

بهتر است مسیر ورود به این حوزه را به چند مرحله تقسیم کنید:

مبانی تست نرم افزار → Manual Testing → تحلیل نیازمندی و طراحی تست → اجرای تست و گزارش باگ → مهارت‌های فنی مانند API و SQL → Automation Testing → پروژه عملی → Portfolio و رزومه → آمادگی مصاحبه → ورود به بازار کار

این ترتیب به این معنا نیست که همه افراد باید دقیقاً با همین سرعت یا ترتیب حرکت کنند؛ بلکه یک چارچوب منطقی برای کسی است که می‌خواهد از نقطه شروع به یک کارشناس تست نرم افزار تبدیل شود.

مرحله اول: ساختن پایه تست نرم افزار

در قدم اول باید با مفاهیم اصلی تست نرم افزار آشنا شوید. در این مرحله بهتر است بیشتر روی درک مفاهیم و منطق تست تمرکز کنید تا ابزارها.

باید بدانید تست نرم افزار چرا انجام می‌شود، تستر چه نقشی در فرایند توسعه دارد، انواع و سطوح تست چه هستند و مفاهیمی مانند Verification، Validation، Defect و Failure چه معنایی دارند.

این مرحله همان پایه‌ای است که بعداً سایر مهارت‌ها روی آن ساخته می‌شوند.

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

مرحله دوم: یادگیری Manual Testing

پس از آشنایی با مبانی، بهتر است وارد تست دستی (Manual Testing) شوید.

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

در این مرحله باید بتوانید:

  • نیازمندی را بررسی کنید.
  • موارد قابل تست را مشخص کنید.
  • Test Scenario طراحی کنید.
  • Test Case بنویسید.
  • تست‌ها را اجرا کنید.
  • نتیجه واقعی و مورد انتظار را مقایسه کنید.
  • Bug Report ایجاد کنید.
  • خطاهای اصلاح‌شده را Retest کنید.
  • در صورت نیاز Regression Testing انجام دهید.

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

مرحله سوم: تقویت تحلیل و طراحی تست

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

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

برای مثال، اگر یک فرم از کاربر عددی بین ۱ تا ۱۰۰ دریافت می‌کند، تستر نباید فقط عدد ۵۰ را امتحان کند. باید درباره مقادیری مانند ۱، ۱۰۰، صفر، ۱۰۱، اعداد منفی، مقدار خالی و ورودی‌های نامعتبر نیز فکر کند.

اینجاست که آشنایی با تکنیک‌های طراحی تست و مباحث Test Design اهمیت پیدا می‌کند.

مرحله چهارم: کسب مهارت در گزارش و پیگیری خطا

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

یک تستر حرفه‌ای فقط نمی‌گوید:

«صفحه ثبت‌نام مشکل دارد.»

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

این مهارت در محیط واقعی اهمیت زیادی دارد، زیرا Bug Report یکی از اصلی‌ترین ابزارهای ارتباط تستر با تیم توسعه است.

مرحله پنجم: اضافه کردن مهارت‌های فنی

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

در این مرحله API Testing، Database Testing و SQL گزینه‌های مهمی هستند.

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

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

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

مرحله ششم: یادگیری Automation Testing

پس از ایجاد پایه مناسب، می‌توانید تست خودکار(Automation Testing) را به مسیر خود اضافه کنید.

در این مرحله باید یاد بگیرید کدام تست‌ها برای خودکارسازی مناسب هستند، چگونه Test Script بنویسید و چگونه تست‌های خودکار را اجرا و نگهداری کنید.

برای این کار معمولاً به یک زبان برنامه‌نویسی نیز نیاز خواهید داشت. بسته به مسیر انتخابی، می‌توانید یکی از زبان‌های مناسب مانند Python، Java یا JavaScript/TypeScript را انتخاب کنید و سپس یک ابزار یا فریم‌ورک Automation را یاد بگیرید.

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

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

مرحله هفتم: انجام پروژه عملی

تا اینجا ممکن است بخش زیادی از دانش لازم را یاد گرفته باشید، اما هنوز یک سؤال مهم باقی می‌ماند:

آیا می‌توانید این دانش را روی یک محصول واقعی به کار ببرید؟

اینجاست که پروژه عملی اهمیت پیدا می‌کند.

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

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

این پروژه بعداً می‌تواند به Portfolio شما تبدیل شود.

مرحله هشتم: آماده شدن برای بازار کار

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

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

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

برای مثال، به‌جای اینکه فقط بنویسید:

API Testing: آشنایی

بهتر است بتوانید یک نمونه‌کار داشته باشید که نشان دهد روی یک پروژه مشخص، APIها را بررسی کرده‌اید، سناریوهای تست طراحی کرده‌اید و نتایج را مستند کرده‌اید.

در نتیجه، مسیر ورود به حوزه تست نرم افزار را می‌توان یک حرکت تدریجی از دانش → مهارت → تمرین → تجربه → نمونه‌کار → آمادگی شغلی در نظر گرفت.

نکته مهم این است که نباید منتظر بمانید تا تمام مباحث تست نرم افزار را یاد بگیرید و بعد تازه شروع به تمرین کنید. یادگیری و تمرین باید در کنار یکدیگر پیش بروند.

برای مثال، وقتی Test Case را یاد می‌گیرید، همان زمان چند Test Case واقعی بنویسید. وقتی Bug Report را یاد می‌گیرید، روی یک پروژه تمرینی Bug Report ایجاد کنید. وقتی API Testing را یاد می‌گیرید، یک API واقعی یا آزمایشی را بررسی کنید.

به این ترتیب، دانش شما به‌تدریج به مهارتی تبدیل می‌شود که می‌توانید آن را در پروژه، رزومه و مصاحبه شغلی نشان دهید.

آیا برای کارشناس تست نرم افزار شدن باید برنامه نویسی بلد باشیم؟

یکی از رایج‌ترین سؤال‌ها برای افرادی که قصد دارند وارد حوزه تست نرم افزار شوند این است که:

«آیا برای تستر شدن باید برنامه نویسی بلد باشیم؟»

پاسخ کوتاه این است که برای شروع کار در تست نرم افزار، تسلط به برنامه نویسی الزامی نیست؛ به‌خصوص اگر مسیر خود را با Manual Testing شروع کنید. یک تستر دستی می‌تواند بدون نوشتن کد، فعالیت‌هایی مانند تحلیل نیازمندی، طراحی Test Case، اجرای تست و گزارش Bug را انجام دهد.

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

برای شروع تست نرم افزار چقدر برنامه نویسی لازم است؟

اگر در ابتدای مسیر هستید، لازم نیست قبل از یادگیری تست نرم افزار چند ماه صرف یادگیری یک زبان برنامه نویسی کنید.

در شروع، مهم‌تر است بتوانید:

  • نیازمندی را تحلیل کنید.
  • رفتار مورد انتظار سیستم را درک کنید.
  • سناریوهای مختلف تست را شناسایی کنید.
  • Test Case مناسب طراحی کنید.
  • تست‌ها را اجرا کنید.
  • Bug را به‌درستی گزارش کنید.
  • نتایج تست را تحلیل کنید.

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

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

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

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

نیاز به برنامه نویسی معمولاً زمانی بیشتر می‌شود که بخواهید از تست دستی فراتر بروید و وارد حوزه‌هایی مانند Automation Testing شوید.

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

برای مثال، در یک تست خودکار ورود به سیستم ممکن است لازم باشد کدی بنویسید که:

  1. صفحه ورود را باز کند.
  2. نام کاربری را وارد کند.
  3. رمز عبور را وارد کند.
  4. روی دکمه ورود کلیک کند.
  5. نتیجه ورود را بررسی کند.
  6. در صورت مشاهده نتیجه غیرمنتظره، تست را Fail کند.

برای انجام چنین کاری باید بتوانید کد بخوانید و بنویسید و با ساختارهای پایه برنامه نویسی آشنا باشید.

علاوه بر Automation، دانش برنامه نویسی می‌تواند در فعالیت‌هایی مانند پردازش داده‌های تست، تست API، ایجاد ابزارهای کمکی، تحلیل نتایج و کار با پروژه‌های پیچیده‌تر نیز مفید باشد.

آیا تستر باید برنامه نویس حرفه‌ای باشد؟

خیر.

بین «آشنایی با برنامه نویسی» و «برنامه نویس حرفه‌ای بودن» تفاوت زیادی وجود دارد.

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

به‌عنوان مثال، بهتر است مفاهیمی مانند موارد زیر را بشناسید:

  • متغیرها
  • شرط‌ها
  • حلقه‌ها
  • توابع
  • ساختار داده‌های پایه
  • کار با رشته‌ها و داده‌ها
  • مدیریت خطا
  • مفاهیم پایه شیءگرایی
  • کار با فایل‌ها و داده‌های JSON در صورت نیاز

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

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

برای Automation Testing زبان‌های مختلفی استفاده می‌شوند و انتخاب زبان می‌تواند به تکنولوژی پروژه، ابزار مورد استفاده و بازار کار هدف بستگی داشته باشد.

از گزینه‌های رایج می‌توان به Python، Java و JavaScript/TypeScript اشاره کرد.

اگر هنوز هیچ زبان برنامه نویسی بلد نیستید، بهتر است به جای یادگیری هم‌زمان چند زبان، یک زبان را انتخاب کنید و با همان زبان پروژه‌های تستی انجام دهید.

برای مثال، Python می‌تواند برای شروع گزینه مناسبی باشد، زیرا ساختار نسبتاً ساده‌ای دارد و در حوزه‌هایی مانند Automation Testing، API Testing و پردازش داده نیز کاربرد دارد.

از طرف دیگر، اگر هدف شما فعالیت در پروژه‌هایی باشد که از Java یا JavaScript/TypeScript استفاده می‌کنند، یادگیری همان زبان می‌تواند انتخاب منطقی‌تری باشد.

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

آیا بدون برنامه نویسی می‌توان وارد بازار کار شد؟

بله، امکان شروع مسیر شغلی از Manual Testing وجود دارد.

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

اما بهتر است این موضوع را به‌عنوان یک نقطه شروع ببینید، نه لزوماً نقطه پایان.

اگر قصد دارید در بلندمدت دامنه مهارت‌های خود را افزایش دهید، یادگیری تدریجی برنامه نویسی می‌تواند گزینه مفیدی باشد. به‌خصوص اگر به Automation Testing، API Testing یا نقش‌های فنی‌تر در حوزه QA و Test Engineering علاقه داشته باشید.

در نتیجه، لازم نیست بین این دو انتخاب کنید که:

«یا برنامه نویسی بلد باشم و بعد تستر شوم»

یا:

«تستر شوم و هیچ‌وقت برنامه نویسی یاد نگیرم.»

مسیر منطقی می‌تواند این باشد:

مبانی تست → Manual Testing → تجربه عملی → یادگیری برنامه نویسی → Automation Testing → توسعه مهارت‌های فنی

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

آیا کارشناس تست نرم افزار باید Automation Testing بلد باشد؟

بعد از اینکه مشخص شد برای شروع مسیر تست نرم افزار الزاماً به برنامه نویسی حرفه‌ای نیاز ندارید، سؤال بعدی این است که آیا یک کارشناس تست نرم افزار باید حتماً Automation Testing نیز بلد باشد یا خیر.

پاسخ این سؤال به سطح شغلی، نوع پروژه و مسیر حرفه‌ای موردنظر شما بستگی دارد. برای ورود اولیه به حوزه تست، یادگیری Automation Testing یک الزام مطلق نیست و می‌توان مسیر حرفه‌ای را با Manual Testing آغاز کرد. اما با افزایش تجربه، یادگیری تست خودکار می‌تواند دامنه توانایی‌های یک تستر را گسترش دهد و او را برای موقعیت‌های فنی‌تر آماده کند.

چرا Automation Testing اهمیت دارد؟

فرض کنید یک نرم افزار دارای صدها تست مختلف است و بخشی از این تست‌ها باید با هر بار انتشار نسخه جدید دوباره اجرا شوند.

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

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

برای مثال، تستر می‌تواند تست‌های مربوط به مواردی مانند:

  • ورود کاربر
  • ثبت‌نام
  • جست‌وجوی محصول
  • اضافه کردن محصول به سبد خرید
  • ثبت سفارش
  • بررسی پاسخ API
  • بررسی برخی قوانین کسب‌وکار

را در شرایط مناسب به تست خودکار تبدیل کند.

البته این به معنی آن نیست که تمام تست‌ها باید خودکار شوند. انتخاب تست مناسب برای Automation خودش یک تصمیم تستی است.

آیا Automation جای Manual Testing را می‌گیرد؟

خیر. Automation Testing جایگزین کامل Manual Testing نیست.

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

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

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

همچنین مواردی مانند بررسی برخی جنبه‌های Usability، تجربه کاربری، رفتارهای غیرمنتظره و تست اکتشافی ممکن است به قضاوت و بررسی انسانی نیاز داشته باشند.

بنابراین Automation را بهتر است به‌عنوان یک ابزار برای اجرای مؤثرتر برخی تست‌ها در نظر بگیریم، نه جایگزینی برای تفکر تست.

چه تست‌هایی برای Automation مناسب‌تر هستند؟

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

معمولاً تست‌هایی گزینه‌های مناسبی برای Automation هستند که:

  • به‌صورت مکرر اجرا می‌شوند.
  • مراحل اجرای آن‌ها نسبتاً پایدار هستند.
  • نتیجه مورد انتظار مشخصی دارند.
  • اجرای دستی آن‌ها زمان زیادی می‌گیرد.
  • تعداد زیادی داده یا حالت مختلف دارند.
  • بخشی از Regression Testing را تشکیل می‌دهند.

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

در مقابل، اگر یک قابلیت هنوز دائماً در حال تغییر باشد، ممکن است نوشتن تست خودکار برای آن در همان مرحله ارزش کمتری داشته باشد؛ زیرا اسکریپت‌های تست نیز مرتباً نیاز به تغییر خواهند داشت.

بنابراین یک تستر حرفه‌ای فقط نمی‌پرسد:

«چگونه این تست را خودکار کنم؟»

بلکه ابتدا می‌پرسد:

«آیا اصلاً خودکار کردن این تست تصمیم مناسبی است؟»

این تفاوت مهمی بین یادگیری صرف ابزار Automation و درک واقعی Automation Testing ایجاد می‌کند.

چه زمانی Automation Testing را یاد بگیریم؟

اگر تازه وارد حوزه تست شده‌اید، معمولاً بهتر است ابتدا یک پایه مناسب در Manual Testing ایجاد کنید.

یعنی قبل از اینکه به سراغ Selenium، Playwright، Cypress یا ابزارهای مشابه بروید، باید بدانید:

  • چگونه یک نیازمندی را تحلیل کنید.
  • چگونه Test Scenario طراحی کنید.
  • چگونه Test Case بنویسید.
  • چگونه یک Bug را گزارش کنید.
  • چگونه Retesting انجام دهید.
  • چگونه Regression Testing را برنامه‌ریزی و اجرا کنید.
  • چگونه تصمیم بگیرید چه چیزی باید تست شود.

بعد از ایجاد این پایه، یادگیری Automation معنا و کاربرد بیشتری پیدا می‌کند.

برای مثال، وقتی یک تستر می‌داند یک سناریوی مشخص چرا باید تست شود، چه شرایطی دارد و نتیجه مورد انتظار آن چیست، می‌تواند همان سناریو را به شکل مناسبی خودکار کند.

اما اگر فردی بدون داشتن پایه تست، مستقیماً سراغ Automation برود، ممکن است بیشتر تمرکز او روی پیدا کردن Locator، نوشتن کد و اجرای ابزار باشد؛ در حالی که هنوز نمی‌داند آیا تستی که نوشته واقعاً ارزش تستی دارد یا خیر.

آیا برای همه موقعیت‌های شغلی باید Automation بلد باشیم؟

خیر.

موقعیت‌های شغلی مختلف ممکن است نیازمندی‌های متفاوتی داشته باشند. برخی موقعیت‌ها بیشتر روی Manual Testing تمرکز دارند و برخی دیگر Automation یا ترکیبی از تست دستی و خودکار را می‌خواهند.

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

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

از طرف دیگر، اگر هدف شما از ابتدا یک موقعیت شغلی Automation Tester، SDET یا نقش‌های فنی‌تر در حوزه تست باشد، باید Automation و برنامه نویسی را زودتر و عمیق‌تر وارد مسیر یادگیری خود کنید.

پس پاسخ این سؤال که «آیا تستر باید Automation بلد باشد؟» به این شکل دقیق‌تر است:

برای شروع تست نرم افزار، الزام مطلق نیست؛ اما برای رشد فنی و ورود به برخی مسیرهای تخصصی، مهارتی بسیار مهم است.

یک مسیر منطقی برای یادگیری Automation

اگر تصمیم دارید Automation Testing را به مهارت‌های خود اضافه کنید، می‌توانید این مسیر را دنبال کنید:

مبانی تست → Manual Testing → یک زبان برنامه نویسی → مبانی Automation → انتخاب ابزار → ساخت تست‌های واقعی → نگهداری و توسعه تست‌ها → اجرای تست‌ها در CI/CD

برای مثال، می‌توانید ابتدا Python را یاد بگیرید و سپس با یکی از ابزارهای مناسب Automation، تست‌های واقعی روی یک پروژه اجرا کنید.

در این مرحله هدف نباید صرفاً این باشد که چند اسکریپت بنویسید. باید بتوانید توضیح دهید:

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

این نگاه باعث می‌شود Automation از یک مهارت صرفاً ابزاری به بخشی از مهارت حرفه‌ای تست نرم افزار تبدیل شود.

اگر می‌خواهید این موضوع را عمیق‌تر دنبال کنید، مقاله Automation Testing در سایت می‌تواند ادامه مسیر یادگیری شما باشد.

مهارت‌های فنی مکمل برای کارشناس تست نرم افزار

بعد از یادگیری مبانی تست و کسب تجربه در Manual Testing، بهتر است به‌تدریج مهارت‌های فنی مکمل را نیز به مجموعه توانایی‌های خود اضافه کنید.

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

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

API Testing

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

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

اگر تستر فقط رابط کاربری را بررسی کند، ممکن است بخشی از مشکلات سیستم را نبیند.

آشنایی با API Testing به تستر اجازه می‌دهد درخواست‌ها و پاسخ‌های API را مستقیماً بررسی کند و مواردی مانند این‌ها را ارزیابی کند:

  • وضعیت پاسخ
  • داده‌های ورودی
  • ساختار پاسخ
  • اعتبارسنجی داده‌ها
  • رفتار سیستم در برابر ورودی‌های نامعتبر
  • خطاهای سرویس
  • منطق برخی عملیات سمت سرور

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

بنابراین API Testing مهارتی است که می‌تواند دید تستر را از رابط کاربری به منطق و سرویس‌های پشت سیستم گسترش دهد.

اگر می‌خواهید این موضوع را به‌صورت تخصصی یاد بگیرید، مقاله API Testing می‌تواند ادامه مناسبی برای این بخش باشد.

Database Testing و SQL

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

فرض کنید کاربر در یک فروشگاه اینترنتی سفارشی ثبت می‌کند. در رابط کاربری پیام «سفارش با موفقیت ثبت شد» نمایش داده می‌شود.

اما آیا واقعاً اطلاعات سفارش به‌درستی در پایگاه داده ذخیره شده است؟

ممکن است شماره سفارش اشتباه ذخیره شده باشد، مبلغ سفارش به‌درستی ثبت نشده باشد یا وضعیت سفارش مقدار نادرستی داشته باشد.

در چنین شرایطی، دسترسی به پایگاه داده و آشنایی با SQL به تستر کمک می‌کند بتواند اطلاعات پشت رابط کاربری را نیز بررسی کند.

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

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

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

مقاله Database Testing می‌تواند برای یادگیری عمیق‌تر این موضوع مورد استفاده قرار گیرد.

ابزارهای تست

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

در عمل، ابزارها می‌توانند از پروژه‌ای به پروژه دیگر تغییر کنند.

ممکن است یک تیم از یک ابزار برای مدیریت Test Case استفاده کند و تیم دیگری از ابزار متفاوتی استفاده کند. ممکن است یک پروژه برای API Testing از یک ابزار خاص استفاده کند و پروژه دیگر ابزار دیگری داشته باشد.

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

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

بنابراین بهتر است به جای اینکه از خودتان بپرسید:

«چند ابزار تست بلد هستم؟»

بیشتر روی این سؤال تمرکز کنید:

«آیا می‌توانم با استفاده از ابزار مناسب، یک فعالیت واقعی تست را به‌درستی انجام دهم؟»

این رویکرد باعث می‌شود یادگیری ابزارها هدفمندتر باشد.

Git

با ورود به پروژه‌های حرفه‌ای‌تر، آشنایی با Git نیز می‌تواند برای یک تستر مفید باشد.

Git بیشتر به‌عنوان ابزار مدیریت نسخه کد شناخته می‌شود، اما تسترهایی که در پروژه‌های Automation فعالیت می‌کنند معمولاً با Repository، Branch، Commit و سایر مفاهیم پایه Git نیز سروکار دارند.

برای مثال، ممکن است تست‌های خودکار شما در یک Repository نگهداری شوند و لازم باشد تغییرات خود را در یک Branch ثبت کنید یا کد تست را با تغییرات سایر اعضای تیم هماهنگ کنید.

در نتیجه، اگر قصد دارید به سمت Automation Testing یا نقش‌های فنی‌تر حرکت کنید، آشنایی با Git می‌تواند بخشی از مجموعه مهارت‌های فنی شما باشد.

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

CI/CD

در تیم‌های مدرن توسعه نرم افزار، تست‌ها می‌توانند بخشی از فرایند CI/CD باشند.

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

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

این موضوع به‌خصوص برای افرادی اهمیت بیشتری دارد که قصد دارند در حوزه Automation Testing یا Test Engineering فعالیت کنند.

در ابتدای مسیر، نیازی نیست CI/CD را در سطح یک DevOps Engineer یاد بگیرید. آشنایی با مفاهیم پایه و درک نقش تست در Pipeline می‌تواند نقطه شروع مناسبی باشد.

آیا باید همه این مهارت‌ها را یاد بگیریم؟

خیر.

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

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

بهتر است مهارت‌ها را مرحله‌ای اضافه کنید.

مرحله اول:
مبانی تست + Manual Testing

مرحله دوم:
Test Design + Bug Reporting + Requirement Analysis

مرحله سوم:
API Testing + SQL

مرحله چهارم:
برنامه نویسی + Automation Testing

مرحله پنجم:
Git + CI/CD و سایر مهارت‌های فنی متناسب با پروژه

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

برای مثال، اگر در یک آگهی استخدام مشخص شده باشد که تستر باید API Testing و SQL بداند، بهتر است این مهارت‌ها را زودتر وارد برنامه خود کنید. اگر موقعیت شغلی روی Automation تمرکز داشته باشد، باید برنامه نویسی و ابزارهای Automation را نیز با اولویت بیشتری دنبال کنید.

در نتیجه، هدف از یادگیری مهارت‌های فنی مکمل این نیست که یک تستر را به فردی تبدیل کنیم که همه چیز را بلد است؛ بلکه باید به‌تدریج دامنه توانایی او را گسترش دهیم تا بتواند نرم افزار را از جنبه‌های بیشتری بررسی کند.

آیا کارشناس تست نرم افزار باید SQL و پایگاه داده بداند؟

یکی دیگر از سؤال‌های رایج برای افرادی که می‌خواهند کارشناس تست نرم افزار شوند این است که آیا باید SQL و پایگاه داده را نیز یاد بگیرند یا خیر.

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

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

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

چرا SQL برای تستر مفید است؟

فرض کنید در یک فروشگاه اینترنتی، کاربر یک سفارش ثبت می‌کند و سیستم پیام زیر را نمایش می‌دهد:

«سفارش شما با موفقیت ثبت شد.»

در نگاه اول ممکن است تست موفق به نظر برسد.

اما یک تستر می‌تواند سؤال‌های بیشتری مطرح کند:

  • آیا سفارش واقعاً در پایگاه داده ایجاد شده است؟
  • آیا شناسه کاربر درست ذخیره شده است؟
  • آیا مبلغ سفارش صحیح است؟
  • آیا تعداد کالاها درست ثبت شده‌اند؟
  • آیا وضعیت سفارش مقدار صحیحی دارد؟
  • آیا اطلاعات سفارش با اطلاعات نمایش‌داده‌شده به کاربر مطابقت دارد؟

ممکن است رابط کاربری رفتار درستی نشان دهد، اما اطلاعات در پایگاه داده اشتباه ذخیره شده باشد.

در چنین شرایطی، SQL به تستر کمک می‌کند اطلاعات موردنظر را مستقیماً بررسی کند.

یک مثال ساده از کاربرد SQL در تست

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

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

در اینجا هدف تستر این نیست که پایگاه داده را مدیریت کند یا ساختار پیچیده آن را طراحی کند؛ هدف این است که بتواند درستی داده‌ها را بررسی کند.

این تفاوت مهم است.

یک تستر برای استفاده از SQL لازم نیست Database Administrator باشد. معمولاً دانستن مفاهیم پایه و توانایی اجرای Queryهای موردنیاز برای فعالیت‌های تست، نقطه شروع مناسبی است.

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

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

چه مقدار SQL برای یک تستر کافی است؟

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

برای شروع می‌توانید روی مفاهیمی مانند این موارد تمرکز کنید:

  • SELECT
  • WHERE
  • ORDER BY
  • GROUP BY
  • JOIN
  • توابع و Aggregateهای پرکاربرد
  • کار با مقادیر NULL
  • جست‌وجو و فیلتر کردن داده‌ها
  • ارتباط بین جداول
  • مفاهیم پایه کلید اصلی و کلید خارجی

همچنین بهتر است بتوانید Queryهای ساده و متوسط را بخوانید و در صورت نیاز تغییر دهید.

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

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

SQL چه ارتباطی با API Testing دارد؟

یکی از کاربردهای مهم SQL زمانی مشخص می‌شود که API Testing را نیز وارد مسیر خود کنید.

فرض کنید یک API برای ایجاد کاربر دارید. شما درخواست را ارسال می‌کنید و API پاسخ موفقیت‌آمیز برمی‌گرداند.

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

در این حالت می‌توان یک فرایند کلی مانند این داشت:

ارسال درخواست به API → بررسی Response → بررسی داده‌های پایگاه داده → مقایسه نتایج

این نوع بررسی به تستر کمک می‌کند رفتار سیستم را در چند لایه بررسی کند.

به همین دلیل، یادگیری SQL می‌تواند در کنار API Testing ارزش بیشتری پیدا کند.

آیا همه تسترها باید SQL بلد باشند؟

خیر.

نوع پروژه و موقعیت شغلی تعیین می‌کند SQL تا چه اندازه برای شما ضروری باشد.

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

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

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

بنابراین بهتر است SQL را مانند برنامه نویسی در نظر بگیرید: مهارتی که می‌توانید به‌تدریج و متناسب با مسیر حرفه‌ای خود توسعه دهید.

SQL را چه زمانی در مسیر یادگیری یاد بگیریم؟

اگر کاملاً در ابتدای مسیر هستید، بهتر است ابتدا روی مبانی تست نرم افزار، Manual Testing، تحلیل نیازمندی، طراحی تست و گزارش Bug تمرکز کنید.

بعد از ایجاد این پایه، می‌توانید SQL را به مهارت‌های خود اضافه کنید.

یک ترتیب منطقی می‌تواند این‌گونه باشد:

مبانی تست → Manual Testing → Test Design → Bug Reporting → SQL و Database Testing → API Testing → Automation

البته این ترتیب قطعی نیست و می‌تواند بر اساس نیاز پروژه تغییر کند.

برای مثال، اگر در یک موقعیت شغلی که قصد دارید برای آن درخواست دهید، SQL یکی از مهارت‌های اصلی موردنیاز باشد، منطقی است که یادگیری آن را زودتر در برنامه خود قرار دهید.

یک نکته مهم درباره یادگیری SQL

هدف شما از یادگیری SQL به‌عنوان تستر نباید این باشد که صرفاً مجموعه‌ای از Queryها را حفظ کنید.

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

برای مثال، اگر کاربر مبلغی را در نرم افزار مشاهده می‌کند، بتوانید بپرسید:

این مبلغ از کجا آمده است و آیا داده‌ای که در پایگاه داده ذخیره شده با چیزی که کاربر مشاهده می‌کند مطابقت دارد؟

یا اگر یک سفارش در وضعیت «پرداخت‌شده» نمایش داده می‌شود:

آیا وضعیت واقعی سفارش و تراکنش مرتبط با آن نیز همین مقدار را نشان می‌دهند؟

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

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

آیا ISTQB برای کارشناس تست نرم افزار ضروری است؟

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

«آیا برای کارشناس تست نرم افزار شدن حتماً باید مدرک ISTQB داشته باشیم؟»

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

با این حال، آشنایی با منابع و چارچوب ISTQB می‌تواند برای ساختن یک دانش منظم و استاندارد از تست نرم افزار مفید باشد.

ISTQB چیست و چه کمکی به تستر می‌کند؟

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

اهمیت مطالعه مباحث ISTQB برای یک تستر بیشتر از این جهت است که بسیاری از مفاهیم تست را در یک ساختار منظم کنار هم قرار می‌دهد.

برای مثال، فردی که به‌صورت پراکنده از منابع مختلف یاد گرفته است ممکن است با اصطلاحاتی مانند Test Level، Test Type، Test Technique، Defect و Risk آشنا باشد، اما ارتباط این مفاهیم را به‌صورت منسجم درک نکرده باشد.

مطالعه یک چارچوب استاندارد می‌تواند به ایجاد این تصویر منظم کمک کند.

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

آیا بدون ISTQB نمی‌توان تستر شد؟

خیر.

مدرک یک گواهی برای نشان دادن دانش یا گذراندن یک آزمون است؛ اما کار روزمره تستر به توانایی انجام فعالیت‌های واقعی نیاز دارد.

فرض کنید دو نفر برای یک موقعیت شغلی تست نرم افزار اقدام کرده‌اند. یکی از آن‌ها مدرک ISTQB دارد اما تجربه عملی محدودی دارد و دیگری مدرک ندارد اما روی چند پروژه تمرینی کار کرده، Test Case طراحی کرده، Bug Report نوشته و می‌تواند درباره نحوه تست یک قابلیت توضیح دهد.

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

بنابراین بهتر است مدرک، دانش نظری و تجربه عملی را سه موضوع جداگانه در نظر بگیریم.

ISTQB چه چیزی را جایگزین نمی‌کند؟

مدرک ISTQB به‌تنهایی جایگزین مواردی مانند این‌ها نمی‌شود:

  • تمرین عملی
  • تجربه کار با یک محصول
  • توانایی تحلیل نیازمندی
  • طراحی Test Case
  • گزارش Bug
  • کار با API
  • کار با پایگاه داده
  • Automation Testing
  • تجربه کار تیمی
  • توانایی توضیح تصمیم‌های تستی

برای مثال، ممکن است فردی تعریف Boundary Value Analysis را به‌خوبی بداند، اما وقتی یک فرم واقعی در اختیارش قرار می‌گیرد نتواند تصمیم بگیرد چه مقادیری را باید برای تست انتخاب کند.

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

آیا بهتر است ISTQB را قبل از شروع کار بخوانیم؟

لزومی ندارد.

اگر تازه وارد حوزه تست شده‌اید، می‌توانید ابتدا با مبانی تست و Manual Testing آشنا شوید و چند پروژه عملی انجام دهید. بعد از اینکه مفاهیم برای شما ملموس‌تر شدند، مطالعه ISTQB می‌تواند به منظم‌تر شدن دانش شما کمک کند.

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

بنابراین یک ترتیب ثابت که برای همه افراد مناسب باشد وجود ندارد.

مهم این است که مطالعه نظری از تمرین عملی جدا نشود.

چه زمانی دریافت مدرک ISTQB می‌تواند مفید باشد؟

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

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

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

این کار کمک می‌کند زمان و انرژی خود را بر اساس نیاز واقعی مسیر شغلی موردنظر اولویت‌بندی کنید.

یک اشتباه رایج: تبدیل مدرک به هدف اصلی

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

دوره آموزشی → ISTQB → استخدام

اما مسیر حرفه‌ای معمولاً پیچیده‌تر از این است.

بهتر است مسیر را به شکل زیر ببینید:

یادگیری مفاهیم → تمرین → کسب تجربه → ساخت نمونه‌کار → تقویت مهارت‌ها → آمادگی شغلی

ISTQB می‌تواند در بخش دانش نظری و ساختار ذهنی به شما کمک کند، اما تجربه عملی و توانایی انجام تست را به‌تنهایی ایجاد نمی‌کند.

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

در نهایت ISTQB را در کجای مسیر قرار دهیم؟

می‌توان ISTQB را یکی از اجزای مسیر حرفه‌ای در نظر گرفت، نه تمام مسیر.

برای مثال:

مبانی تست → تمرین Manual Testing → مطالعه ساختارمند ISTQB → پروژه عملی → توسعه مهارت‌های فنی → Portfolio → ورود به بازار کار

یا حتی می‌توانید پروژه عملی را زودتر شروع کنید و در کنار آن مباحث ISTQB را مطالعه کنید.

نکته مهم این است که دانش نظری و تجربه عملی یکدیگر را تکمیل کنند.

در نتیجه، برای کارشناس تست نرم افزار شدن بهتر است روی سه بخش اصلی تمرکز کنید:

دانش نظری + مهارت عملی + تجربه پروژه‌ای

چطور تجربه عملی تست نرم افزار کسب کنیم؟

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

ممکن است مفاهیم تست را یاد گرفته باشید، با Test Case و Bug Report آشنا باشید، API Testing و SQL را تمرین کرده باشید و حتی در Automation Testing چند پروژه انجام داده باشید؛ اما وقتی یک موقعیت شغلی از شما «تجربه» می‌خواهد، این سؤال مطرح می‌شود که:

اگر هنوز در یک شرکت کار نکرده‌ام، چطور تجربه کسب کنم؟

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

هدف این است که از مرحله «می‌دانم تست نرم افزار چیست» به مرحله «می‌توانم یک نرم افزار را واقعاً تست کنم» برسید.

پروژه تمرینی؛ اولین قدم برای تجربه عملی

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

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

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

انتخاب محصول → شناخت قابلیت‌ها → تحلیل نیازمندی → طراحی سناریو → طراحی Test Case → اجرای تست → گزارش Bug → Retesting → Regression Testing

این کار باعث می‌شود فعالیت شما به فرایند واقعی تست نزدیک شود.

پروژه تمرینی را چگونه انجام دهیم؟

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

ابتدا باید قابلیت‌های مهم آن را شناسایی کنید؛ مثلاً:

  • ثبت‌نام و ورود
  • جست‌وجوی محصول
  • مشاهده جزئیات محصول
  • افزودن به سبد خرید
  • تغییر تعداد کالا
  • ثبت سفارش
  • پرداخت
  • مشاهده وضعیت سفارش

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

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

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

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

در اینجا دیگر صرفاً در حال مطالعه Test Scenario نیستید؛ بلکه دارید واقعاً از آن استفاده می‌کنید.

فقط Test Case ننویسید

یکی از اشتباهات رایج در پروژه‌های تمرینی این است که فرد ده‌ها Test Case می‌نویسد اما هیچ‌کدام را اجرا نمی‌کند.

هدف از پروژه تمرینی، پر کردن یک فایل Excel با تعداد زیادی تست کیس نیست.

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

برای مثال، اگر یک Test Case مشخص می‌کند:

«کاربر باید بتواند با اطلاعات معتبر وارد حساب کاربری شود.»

آن را واقعاً اجرا کنید و ببینید سیستم چه رفتاری دارد.

اگر نتیجه مورد انتظار با نتیجه واقعی تفاوت داشت، بررسی کنید آیا با یک Defect مواجه هستید و در صورت تأیید، Bug Report ایجاد کنید.

این تفاوت مهمی بین تمرین تئوری و تجربه عملی ایجاد می‌کند.

Bug Report واقعی ایجاد کنید

یکی از بهترین بخش‌های پروژه تمرینی می‌تواند ایجاد نمونه Bug Report باشد.

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

به‌جای اینکه فقط بنویسید:

«ثبت‌نام مشکل دارد.»

باید مشکل را به شکل حرفه‌ای مستند کنید.

برای مثال، مشخص کنید:

  • عنوان Bug چیست؟
  • در چه محیطی مشاهده شده است؟
  • مراحل بازتولید چیست؟
  • نتیجه مورد انتظار چیست؟
  • نتیجه واقعی چیست؟
  • شدت مشکل چقدر است؟
  • در چه شرایطی مشکل رخ می‌دهد؟
  • آیا مشکل همیشه قابل تکرار است؟

این نوع مستندسازی بعداً می‌تواند بخشی از Portfolio شما نیز باشد.

تست API و پایگاه داده را نیز وارد پروژه کنید

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

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

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

در این حالت، پروژه تمرینی شما می‌تواند شامل چند لایه شود:

UI Testing + API Testing + Database Testing

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

Automation را نیز روی همان پروژه تمرین کنید

اگر Automation Testing را یاد گرفته‌اید، لازم نیست یک پروژه کاملاً جدا برای آن ایجاد کنید.

می‌توانید بخشی از تست‌های پروژه قبلی را خودکار کنید.

برای مثال، تست‌های مربوط به:

  • ورود کاربر
  • ثبت‌نام
  • جست‌وجو
  • افزودن محصول به سبد خرید
  • برخی APIها

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

این روش یک مزیت مهم دارد: به‌جای اینکه Automation را به‌صورت جدا از Manual Testing یاد بگیرید، می‌بینید که چگونه تستی که قبلاً طراحی کرده‌اید به تست خودکار تبدیل می‌شود.

پروژه متن‌باز و همکاری واقعی

پروژه‌های تمرینی تنها گزینه موجود نیستند.

در صورت امکان می‌توانید در پروژه‌های Open Source نیز مشارکت کنید یا با پروژه‌ها و تیم‌های کوچک همکاری داشته باشید.

برای مثال، ممکن است یک پروژه متن‌باز نیاز به بررسی یک قابلیت جدید، گزارش Bug، بررسی Issue یا نوشتن تست داشته باشد.

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

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

مستندسازی تجربه بسیار مهم است

هر پروژه‌ای که انجام می‌دهید، فعالیت‌های خود را مستند کنید.

برای مثال، می‌توانید مشخص کنید:

پروژه: فروشگاه اینترنتی

فعالیت‌ها:

  • تحلیل نیازمندی
  • طراحی Test Scenario
  • طراحی Test Case
  • اجرای Manual Testing
  • Bug Reporting
  • Regression Testing
  • API Testing
  • Database Testing
  • Automation Testing

سپس نمونه‌هایی از خروجی این فعالیت‌ها را نگهداری کنید.

این مستندات بعداً می‌توانند به Portfolio شما تبدیل شوند.

تجربه عملی فقط برای رزومه نیست

یک نکته مهم این است که پروژه تمرینی را فقط برای این انجام ندهید که چیزی داخل رزومه بنویسید.

هدف اصلی، ساختن مهارت واقعی است.

فرض کنید در یک پروژه تمرینی هنگام تست یک قابلیت متوجه می‌شوید که یک Requirement مبهم است. مجبور می‌شوید درباره آن سؤال کنید و رفتار مورد انتظار را مشخص کنید.

یا هنگام اجرای تست متوجه می‌شوید Test Case شما یک حالت مهم را پوشش نداده است.

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

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

چه زمانی می‌توان گفت تجربه عملی داریم؟

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

تجربه پروژه تمرینی و تجربه شغلی یکسان نیستند.

اما پروژه عملی می‌تواند به شما کمک کند:

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

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

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

بعد از اینکه چند پروژه تمرینی یا عملی انجام دادید، سؤال مهم بعدی این است که چگونه این تجربه را به شکلی قابل ارائه به کارفرما نشان دهیم؟

اینجاست که Portfolio اهمیت پیدا می‌کند.

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

برای فردی که هنوز سابقه کاری زیادی ندارد، Portfolio می‌تواند راهی برای نشان دادن توانایی‌هایی باشد که هنوز فرصت استفاده از آن‌ها را در یک شرکت نداشته است.

آیا برای ساخت Portfolio باید چندین پروژه داشته باشیم؟

خیر.

تعداد پروژه‌ها به‌اندازه کیفیت و نحوه ارائه آن‌ها اهمیت ندارد.

یک پروژه تمرینی که از ابتدا تا انتها به‌صورت منظم تست شده باشد، می‌تواند ارزش بیشتری از چندین پروژه ناقص داشته باشد که در هرکدام فقط چند Test Case نوشته‌اید.

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

اگر بتوانید نشان دهید که:

  • نیازمندی را چگونه تحلیل کرده‌اید.
  • چه سناریوهایی طراحی کرده‌اید.
  • چه Test Caseهایی نوشته‌اید.
  • تست‌ها را چگونه اجرا کرده‌اید.
  • چه Bugهایی پیدا کرده‌اید.
  • Bugها را چگونه گزارش کرده‌اید.
  • چه تست‌هایی را بعد از اصلاح دوباره انجام داده‌اید.
  • API مربوط به فرایند را چگونه بررسی کرده‌اید.
  • داده‌های مرتبط را چگونه با SQL بررسی کرده‌اید.
  • چه بخش‌هایی را Automation کرده‌اید.

در واقع یک نمونه‌کار نسبتاً کامل برای نمایش مهارت‌های خود ساخته‌اید.

Portfolio کارشناس تست نرم افزار شامل چه چیزهایی باشد؟

بسته به سطح و مسیر شغلی شما، Portfolio می‌تواند بخش‌های مختلفی داشته باشد.

۱. تحلیل نیازمندی

اگر برای پروژه، Requirement یا User Story در اختیار داشته‌اید، می‌توانید نشان دهید چگونه آن را تحلیل کرده‌اید و چه مواردی را برای تست شناسایی کرده‌اید.

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

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

۲. Test Scenario و Test Case

نمونه‌هایی از Test Scenario و Test Caseهایی که طراحی کرده‌اید می‌توانند بخش مهمی از Portfolio باشند.

اما بهتر است فقط فایل Test Case را قرار ندهید.

توضیح دهید این Test Caseها برای چه قابلیتی طراحی شده‌اند و چه شرایطی را پوشش می‌دهند.

مثلاً اگر قابلیت موردنظر «ثبت‌نام کاربر» است، می‌توانید نشان دهید که علاوه بر ثبت‌نام موفق، مواردی مانند اطلاعات ناقص، ایمیل نامعتبر، ایمیل تکراری و شرایط مرزی را نیز در نظر گرفته‌اید.

این موضوع نشان می‌دهد که طراحی تست شما صرفاً به مسیر Happy Path محدود نیست.

۳. Bug Report

نمونه Bug Report یکی از مهم‌ترین بخش‌های Portfolio یک تستر است.

یک گزارش مناسب می‌تواند شامل:

  • عنوان
  • محیط تست
  • Preconditions
  • مراحل بازتولید
  • نتیجه مورد انتظار
  • نتیجه واقعی
  • Severity
  • Priority
  • شواهد مانند Screenshot یا Video در صورت نیاز

باشد.

البته لازم نیست Portfolio را با ده‌ها Bug Report پر کنید. چند نمونه با کیفیت که نشان‌دهنده توانایی شما در تشخیص، تحلیل و مستندسازی مشکل باشند، کافی است.

۴. نمونه Regression و Retesting

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

برای مثال:

Bug پیدا شد → گزارش شد → اصلاح شد → Retesting انجام شد → بخش‌های مرتبط Regression شدند

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

۵. API Testing

اگر API Testing بلد هستید، چند نمونه از فعالیت‌های خود را نیز می‌توانید در Portfolio قرار دهید.

برای مثال:

  • درخواست‌های مختلف API
  • بررسی Status Code
  • بررسی Response
  • اعتبارسنجی داده‌ها
  • تست ورودی‌های نامعتبر
  • بررسی Error Response
  • سناریوهای مختلف API

می‌توانید نتایج تست را نیز مستند کنید.

هدف این نیست که تعداد زیادی Request در Portfolio قرار دهید؛ بلکه باید مشخص باشد که چه چیزی را تست کرده‌اید و منطق تست شما چه بوده است.

۶. SQL و Database Testing

اگر در پروژه تمرینی خود پایگاه داده را نیز بررسی کرده‌اید، می‌توانید نمونه‌هایی از Queryها و نتایج بررسی خود را اضافه کنید.

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

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

۷. Automation Testing

اگر Automation Testing را یاد گرفته‌اید، کد تست‌های خودکار نیز می‌تواند بخشی از Portfolio باشد.

در اینجا GitHub می‌تواند گزینه مناسبی برای نمایش کد باشد.

اما بهتر است Repository شما فقط شامل چند فایل کد بدون توضیح نباشد.

یک Repository مناسب می‌تواند شامل مواردی مانند:

  • توضیح پروژه
  • ابزارها و تکنولوژی‌های استفاده‌شده
  • نحوه اجرای تست‌ها
  • ساختار پروژه
  • نمونه Test Caseهای خودکار
  • گزارش یا Screenshot از نتایج اجرا
  • توضیح مختصر درباره رویکرد Automation

باشد.

به این ترتیب، کسی که پروژه را بررسی می‌کند فقط کد نمی‌بیند؛ بلکه متوجه می‌شود شما چرا و چگونه آن کد را نوشته‌اید.

Portfolio را کجا قرار دهیم؟

برای قرار دادن نمونه‌کارها گزینه‌های مختلفی وجود دارد.

اگر کدهای Automation یا پروژه‌های فنی دارید، GitHub می‌تواند انتخاب مناسبی باشد.

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

مهم‌تر از پلتفرم، قابل دسترس و قابل فهم بودن نمونه‌کارها است.

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

  • چه چیزی را تست کرده‌اید؟
  • چه فعالیت‌هایی انجام داده‌اید؟
  • از چه ابزارهایی استفاده کرده‌اید؟
  • چه مشکلاتی پیدا کرده‌اید؟
  • چه چیزی از این پروژه یاد گرفته‌اید؟

Portfolio نباید تبدیل به فهرست ابزارها شود

یکی از اشتباهات رایج این است که Portfolio به یک فهرست بلند از ابزارها تبدیل شود:

Selenium، Playwright، Postman، Jira، Git، SQL، …

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

فرض کنید در Portfolio نوشته‌اید:

Playwright: Advanced

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

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

بنابراین Portfolio باید بیشتر از اینکه بگوید:

«چه ابزارهایی بلدم؟»

نشان دهد:

«با این مهارت‌ها چه کاری انجام داده‌ام؟»

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

برای مثال، یک Portfolio ساده می‌تواند حول یک فروشگاه اینترنتی ساخته شود:

پروژه: تست فروشگاه اینترنتی

بخش Manual Testing

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

بخش Test Design

  • Test Scenario
  • Test Case
  • Boundary Value Analysis
  • Equivalence Partitioning

بخش Bug Reporting

  • چند Bug Report مستند
  • Severity و Priority
  • شواهد مربوط به خطا

بخش API

  • تست APIهای ورود و ثبت سفارش
  • بررسی Response
  • تست ورودی‌های نامعتبر

بخش Database

  • بررسی داده‌های کاربران
  • بررسی سفارش‌ها
  • اجرای Queryهای SQL

بخش Automation

  • خودکارسازی چند سناریوی تکرارشونده
  • اجرای تست‌ها
  • مستندسازی نتایج

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

Portfolio را به رزومه و مصاحبه متصل کنید

Portfolio زمانی ارزش بیشتری پیدا می‌کند که با رزومه و مصاحبه شما ارتباط داشته باشد.

برای مثال، اگر در رزومه نوشته‌اید:

API Testing

باید بتوانید در Portfolio یک نمونه کار مرتبط نشان دهید.

اگر در رزومه نوشته‌اید:

Automation Testing با Playwright

باید بتوانید پروژه‌ای داشته باشید که در آن واقعاً از Playwright استفاده کرده‌اید و در مصاحبه نیز بتوانید درباره ساختار و تصمیم‌های خود توضیح دهید.

این هماهنگی باعث می‌شود رزومه، Portfolio و مصاحبه شما یک تصویر واحد از مهارت‌هایتان ارائه کنند.

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

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

چگونه رزومه کارشناس تست نرم افزار بسازیم؟

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

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

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

رزومه تستر باید چه چیزی را نشان دهد؟

یک رزومه مناسب باید بتواند به چند سؤال اصلی پاسخ دهد:

  • چه کسی هستید؟
  • در چه سطحی از تست نرم افزار فعالیت می‌کنید؟
  • چه مهارت‌هایی دارید؟
  • با چه ابزارهایی کار کرده‌اید؟
  • چه تجربه یا پروژه‌هایی انجام داده‌اید؟
  • برای چه موقعیت شغلی درخواست می‌دهید؟

بنابراین بهتر است رزومه را متناسب با موقعیت شغلی هدف تنظیم کنید.

اگر برای یک موقعیت Manual Tester اقدام می‌کنید، باید مهارت‌های مرتبط با Manual Testing، Test Design، Bug Reporting و Requirement Analysis به‌وضوح دیده شوند.

اگر برای موقعیت Automation Tester اقدام می‌کنید، مهارت‌هایی مانند برنامه نویسی، ابزار Automation، API Testing، Git و CI/CD اهمیت بیشتری پیدا می‌کنند.

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

این یکی از مهم‌ترین چالش‌های افراد تازه‌وارد است.

نداشتن سابقه کاری رسمی به این معنی نیست که رزومه شما باید تقریباً خالی باشد.

اگر پروژه‌های تمرینی یا شخصی انجام داده‌اید، می‌توانید آن‌ها را در بخش Projects قرار دهید.

برای مثال، به جای اینکه فقط بنویسید:

آشنایی با Manual Testing

می‌توانید یک پروژه مشخص معرفی کنید:

پروژه تست فروشگاه اینترنتی

  • تحلیل قابلیت‌های اصلی و شناسایی موارد قابل تست
  • طراحی Test Scenario و Test Case
  • اجرای تست‌های Functional و Regression
  • ثبت و مستندسازی Bugها
  • بررسی APIهای مرتبط
  • اعتبارسنجی داده‌ها با SQL

این نوع توضیح نشان می‌دهد که مهارت موردنظر را در عمل استفاده کرده‌اید.

البته باید بین «پروژه تمرینی» و «سابقه کاری» تفاوت را کاملاً حفظ کنید. پروژه شخصی را نباید به شکلی در رزومه بنویسید که سابقه استخدامی واقعی به نظر برسد.

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

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

برای مثال، فهرستی مانند:

Selenium، Playwright، Cypress، Postman، SQL، Git، Jira، Python، Java، Docker، Jenkins و…

به‌تنهایی اطلاعات چندانی درباره توانایی واقعی شما ارائه نمی‌دهد.

بهتر است مهارت‌ها را دسته‌بندی کنید.

Software Testing

  • Manual Testing
  • Functional Testing
  • Regression Testing
  • Exploratory Testing

Test Design

  • Test Case
  • Test Scenario
  • Test Technique

API & Database

  • API Testing
  • SQL
  • Database Testing

Automation

  • Python
  • Playwright

Tools

  • Git
  • ابزار مدیریت Bug
  • ابزار مدیریت Test Case

این ساختار باعث می‌شود رزومه خواناتر باشد و ارتباط بین مهارت‌ها نیز بهتر مشخص شود.

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

نه.

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

فرض کنید در حال حاضر با ده ابزار مختلف آشنا هستید، اما موقعیت شغلی موردنظر شما بیشتر روی Manual Testing و API Testing تمرکز دارد.

در چنین شرایطی بهتر است مهارت‌های مرتبط با آن موقعیت را واضح‌تر و برجسته‌تر کنید.

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

اصل مهم این است:

رزومه باید تصویر دقیقی از توانایی واقعی شما ارائه دهد.

پروژه‌ها را در رزومه چگونه معرفی کنیم؟

برای هر پروژه بهتر است مشخص کنید:

  • چه چیزی را تست کردید؟
  • چه فعالیت‌هایی انجام دادید؟
  • از چه ابزارهایی استفاده کردید؟
  • نتیجه کار چه بود؟

برای مثال، به جای نوشتن:

تست یک فروشگاه اینترنتی

می‌توان توضیح دقیق‌تری ارائه کرد:

پروژه تست فروشگاه اینترنتی
طراحی و اجرای سناریوهای تست برای ثبت‌نام، ورود، جست‌وجوی محصول، سبد خرید و ثبت سفارش؛ مستندسازی Test Caseها و Bug Reportها؛ بررسی APIهای مرتبط و اعتبارسنجی داده‌های سفارش با SQL.

در این حالت، خواننده رزومه متوجه می‌شود شما واقعاً چه فعالیت‌هایی انجام داده‌اید.

آیا ISTQB را در رزومه بنویسیم؟

اگر گواهینامه ISTQB یا گواهینامه مرتبط دیگری دارید، می‌توانید آن را در بخش Certifications رزومه قرار دهید.

اما بهتر است گواهینامه‌ها جای مهارت و تجربه عملی را نگیرند.

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

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

رزومه را برای هر موقعیت شغلی تغییر دهید

یکی از کارهای مهم هنگام ورود به بازار کار این است که برای تمام آگهی‌ها دقیقاً یک رزومه یکسان ارسال نکنید.

برای مثال، فرض کنید یک آگهی استخدامی روی این موارد تأکید دارد:

  • Manual Testing
  • API Testing
  • SQL
  • Agile

و آگهی دیگری بیشتر روی:

  • Automation Testing
  • Python
  • Playwright
  • Git

تمرکز دارد.

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

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

این کار به معنای تغییر یا اغراق در سابقه نیست؛ فقط یعنی اطلاعات مرتبط را بهتر در معرض دید قرار دهید.

لینک Portfolio را در رزومه قرار دهید

اگر Portfolio، GitHub یا نمونه‌کار آنلاین دارید، بهتر است لینک آن را در رزومه قرار دهید.

برای مثال، اگر در رزومه نوشته‌اید که Automation Testing انجام داده‌اید، وجود یک Repository قابل مشاهده می‌تواند نمونه عملی این مهارت باشد.

همچنین اگر مستندات تست، Bug Report یا پروژه‌های تمرینی دارید، می‌توانید آن‌ها را در Portfolio قرار دهید و لینک مربوطه را در رزومه ارائه کنید.

این ارتباط بین رزومه و نمونه‌کار اهمیت زیادی دارد.

رزومه می‌گوید چه مهارت‌هایی دارید؛ Portfolio می‌تواند نشان دهد چگونه از آن مهارت‌ها استفاده کرده‌اید.

رزومه خوب، طولانی‌ترین رزومه نیست

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

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

رزومه باید مختصر، مرتبط و قابل بررسی باشد.

اگر کارفرما برای یک موقعیت Manual Tester در حال بررسی رزومه‌هاست، بهتر است در همان نگاه اول متوجه شود که شما:

  • مبانی تست را می‌دانید.
  • Manual Testing انجام داده‌اید.
  • Test Case و Test Scenario طراحی کرده‌اید.
  • Bug Report نوشته‌اید.
  • پروژه عملی دارید.
  • با فرایند توسعه نرم افزار آشنا هستید.

و اگر مهارت‌های فنی مانند API، SQL یا Automation نیز دارید، آن‌ها را متناسب با نیاز موقعیت نشان دهید.

برای مصاحبه کارشناس تست نرم افزار چه چیزهایی یاد بگیریم؟

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

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

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

ابتدا مبانی تست را مرور کنید

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

برای مثال ممکن است درباره موضوعاتی مانند این‌ها سؤال شود:

  • تفاوت Verification و Validation
  • تفاوت Error، Defect و Failure
  • انواع تست
  • سطوح تست
  • Functional و Non-Functional Testing
  • Regression Testing
  • Retesting
  • Exploratory Testing
  • Test Case و Test Scenario
  • Test Technique
  • Severity و Priority
  • Bug Life Cycle

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

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

این نوع پاسخ نشان می‌دهد مفهوم را درک کرده‌اید و فقط تعریف آن را حفظ نکرده‌اید.

برای سؤالات سناریومحور آماده باشید

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

ممکن است مصاحبه‌کننده بگوید:

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

یا:

«اگر بخواهید یک فروشگاه اینترنتی را تست کنید، از کجا شروع می‌کنید؟»

در چنین شرایطی، بهتر است بلافاصله شروع به فهرست کردن Test Caseها نکنید.

ابتدا مسئله را تحلیل کنید.

برای مثال، درباره صفحه Login می‌توانید ابتدا مشخص کنید:

  • رفتار مورد انتظار چیست؟
  • چه ورودی‌هایی دریافت می‌شود؟
  • شرایط موفقیت چیست؟
  • شرایط شکست چیست؟
  • محدودیت‌های ورودی چیست؟
  • چه خطاهایی ممکن است رخ دهد؟
  • چه ریسک‌هایی مهم‌تر هستند؟

بعد می‌توانید Test Caseهای مختلف را مطرح کنید.

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

در این نوع سؤال، مصاحبه‌کننده معمولاً فقط به دنبال تعداد Test Case نیست؛ بلکه می‌خواهد ببیند چگونه مسئله را به بخش‌های مختلف تقسیم می‌کنید.

به جای حفظ کردن، با صدای بلند فکر کنید

در یک سؤال عملی ممکن است از شما پرسیده شود:

«این قابلیت را چگونه تست می‌کنی؟»

بهتر است پاسخ خود را مرحله‌به‌مرحله بیان کنید.

برای مثال:

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

چنین پاسخی نشان می‌دهد که شما یک فرایند فکری مشخص برای تست دارید.

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

Test Design را برای مصاحبه جدی بگیرید

سؤالات مربوط به طراحی تست نیز می‌توانند در مصاحبه مطرح شوند.

برای مثال ممکن است از شما بخواهند یک فیلد را که فقط اعداد بین ۱ تا ۱۰۰ را قبول می‌کند تست کنید.

در چنین شرایطی باید بتوانید از تکنیک‌هایی مانند Boundary Value Analysis و Equivalence Partitioning استفاده کنید.

به جای اینکه تعداد زیادی مقدار تصادفی انتخاب کنید، می‌توانید مقادیری مانند:

۰، ۱، ۲، ۹۹، ۱۰۰، ۱۰۱

را بررسی کنید.

این نوع سؤال‌ها نشان می‌دهند که آیا می‌توانید از تکنیک‌های طراحی تست در یک مسئله واقعی استفاده کنید یا خیر.

به همین دلیل، برای مصاحبه فقط تعریف Test Techniqueها را نخوانید؛ تمرین کنید که در یک مسئله واقعی از آن‌ها استفاده کنید.

Bug Reporting را تمرین کنید

ممکن است در مصاحبه از شما بخواهند یک Bug Report بنویسید یا توضیح دهید یک Bug خوب چه ویژگی‌هایی دارد.

در این شرایط باید بتوانید درباره مواردی مانند:

  • عنوان مناسب
  • مراحل بازتولید
  • نتیجه مورد انتظار
  • نتیجه واقعی
  • محیط اجرا
  • Severity
  • Priority
  • شواهد خطا

توضیح دهید.

همچنین ممکن است از شما سؤال شود:

«اگر توسعه‌دهنده بگوید این Bug قابل تکرار نیست، چه کار می‌کنید؟»

در چنین شرایطی، بهتر است به جای برخورد احساسی، سراغ شواهد و اطلاعات قابل بررسی بروید.

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

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

درباره API و SQL آماده باشید

اگر در رزومه خود API Testing یا SQL نوشته‌اید، باید انتظار داشته باشید درباره آن‌ها نیز سؤال شود.

برای API ممکن است درباره موضوعاتی مانند:

  • HTTP Methods
  • Status Code
  • Request و Response
  • Header
  • Authentication
  • اعتبارسنجی داده‌ها
  • تست ورودی‌های نامعتبر

سؤال شود.

در SQL نیز ممکن است از شما بخواهند یک Query ساده بنویسید یا داده خاصی را از چند جدول پیدا کنید.

بنابراین هر مهارتی که در رزومه قرار می‌دهید، بهتر است واقعاً بتوانید درباره آن صحبت کنید.

یک قانون ساده می‌تواند این باشد:

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

اگر برای Automation Testing مصاحبه می‌دهید

در موقعیت‌های Automation، معمولاً سؤال‌ها فنی‌تر می‌شوند.

علاوه بر مفاهیم تست، ممکن است درباره مواردی مانند:

  • زبان برنامه نویسی
  • ساختار کد تست
  • Locatorها
  • Assertion
  • Test Data
  • Page Object Model
  • مدیریت خطا
  • اجرای تست‌ها
  • Parallel Testing
  • گزارش تست
  • Git
  • CI/CD

سؤال شود.

در اینجا نیز صرفاً دانستن نام مفاهیم کافی نیست.

اگر مثلاً در رزومه نوشته‌اید Playwright، باید بتوانید توضیح دهید چگونه با آن یک سناریوی واقعی را تست کرده‌اید و هنگام شکست تست چگونه مشکل را بررسی می‌کنید.

پروژه‌های داخل رزومه خود را دوباره مرور کنید

قبل از مصاحبه، پروژه‌هایی را که در رزومه و Portfolio خود آورده‌اید، دوباره بررسی کنید.

ممکن است مصاحبه‌کننده درباره یکی از آن‌ها سؤال کند:

  • چرا این قابلیت را به این شکل تست کردید؟
  • چرا این Test Case را نوشتید؟
  • چرا این Bug را با این Severity گزارش کردید؟
  • چرا این تست را Automation کردید؟
  • چرا یک تست خاص را خودکار نکردید؟
  • اگر دوباره پروژه را انجام دهید، چه چیزی را تغییر می‌دهید؟

اگر پروژه واقعاً توسط خودتان انجام شده باشد، پاسخ دادن به این سؤال‌ها بسیار ساده‌تر خواهد بود.

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

سؤالات رفتاری را فراموش نکنید

مصاحبه تست نرم افزار فقط درباره مباحث فنی نیست.

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

برای مثال:

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

در این شرایط بهتر است پاسخ شما بر تحلیل، شواهد، ارتباط مؤثر و اولویت‌بندی بر اساس ریسک استوار باشد.

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

قبل از هر مصاحبه، آگهی استخدام را دوباره بخوانید

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

اگر در آگهی روی مواردی مانند:

Manual Testing، API Testing، SQL، Agile

تأکید شده است، این مباحث را مرور کنید.

اگر موقعیت موردنظر مربوط به Automation است، باید برنامه نویسی، ابزار Automation و مباحث مرتبط با CI/CD را نیز جدی‌تر مرور کنید.

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

مصاحبه را فرصتی برای نشان دادن روش فکر کردن خود بدانید

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

مهم‌تر این است که بتوانید نشان دهید:

  • چگونه یک نیازمندی را تحلیل می‌کنید؟
  • چگونه ریسک‌ها را شناسایی می‌کنید؟
  • چگونه Test Case طراحی می‌کنید؟
  • چگونه یک Bug را بررسی و گزارش می‌کنید؟
  • چگونه درباره اولویت تست‌ها تصمیم می‌گیرید؟
  • چگونه از ابزارهای فنی برای بررسی عمیق‌تر سیستم استفاده می‌کنید؟

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

۱۴. نقش Agile در کار کارشناس تست نرم افزار

کارشناس تست نرم افزار در یک شرکت معمولاً به‌صورت مستقل و جدا از تیم توسعه کار نمی‌کند. تست بخشی از فرایند توسعه نرم افزار است و تستر باید با افراد مختلفی مانند توسعه‌دهنده، Product Owner، Business Analyst و سایر اعضای تیم همکاری داشته باشد.

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

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

چرا Agile برای کارشناس تست مهم است؟

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

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

اگر تستر فقط بعد از پایان کامل توسعه وارد پروژه شود، ممکن است در آن زمان متوجه شود که:

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

در این حالت، اصلاح مشکل ممکن است زمان بیشتری نیاز داشته باشد.

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

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

آشنایی با User Story و Acceptance Criteria

در بسیاری از تیم‌های Agile، نیازمندی‌ها ممکن است در قالب User Story و Acceptance Criteria بیان شوند.

برای مثال:

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

این User Story به‌تنهایی تمام جزئیات قابل تست را مشخص نمی‌کند.

برای مثال باید مشخص شود:

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

این موارد می‌توانند در قالب Acceptance Criteria مشخص‌تر شوند.

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

نقش تستر در Sprint

در یک تیم Agile، کارشناس تست می‌تواند در مراحل مختلف یک Sprint درگیر باشد.

ابتدای Sprint:
بررسی User Storyها، نیازمندی‌ها و Acceptance Criteria و مطرح کردن ابهام‌ها.

در زمان توسعه:
آماده کردن سناریوها و Test Caseها، بررسی Test Data و هماهنگی با اعضای تیم.

بعد از آماده شدن قابلیت:
اجرای تست‌ها، ثبت Bugها، انجام Retesting و در صورت نیاز Regression Testing.

در پایان Sprint:
ارائه بازخورد درباره وضعیت کیفیت و مشکلات شناسایی‌شده.

این یعنی تست فعالیتی نیست که فقط در چند ساعت پایانی Sprint انجام شود.

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

یکی از مهارت‌های مهم در محیط Agile، همکاری با توسعه‌دهنده است.

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

هدف نباید صرفاً این باشد که Bug را ثبت کنیم و منتظر بمانیم توسعه‌دهنده آن را اصلاح کند.

تستر باید بتواند اطلاعات لازم را به‌صورت واضح منتقل کند:

  • مشکل دقیقاً چیست؟
  • در چه شرایطی رخ می‌دهد؟
  • چگونه می‌توان آن را بازتولید کرد؟
  • نتیجه مورد انتظار چه بوده است؟
  • نتیجه واقعی چه بوده است؟
  • آیا مشکل همیشه رخ می‌دهد یا فقط در شرایط خاص؟

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

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

خیر.

آشنایی تستر با Agile به این معنی نیست که باید تمام وظایف توسعه‌دهنده را انجام دهد.

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

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

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

آشنایی با Definition of Done

در برخی تیم‌های Agile، Definition of Done نیز نقش مهمی در مشخص کردن شرایط تکمیل یک کار دارد.

برای مثال، ممکن است تیم توافق کرده باشد که یک قابلیت زمانی Done محسوب شود که:

  • پیاده‌سازی انجام شده باشد.
  • Code Review انجام شده باشد.
  • تست‌های لازم اجرا شده باشند.
  • Bugهای مهم برطرف شده باشند.
  • معیارهای پذیرش برآورده شده باشند.

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

البته Definition of Done در هر تیم می‌تواند متفاوت باشد و تستر باید با قواعد همان تیم آشنا شود.

Agile را فقط به Scrum محدود نکنید

Agile یک روش واحد و یکسان برای اجرای پروژه نیست.

Scrum یکی از چارچوب‌های شناخته‌شده در محیط‌های Agile است، اما آشنایی با Agile نباید صرفاً به حفظ کردن اصطلاحاتی مانند Sprint، Daily، Backlog یا Retrospective محدود شود.

برای یک کارشناس تست، مهم‌تر این است که درک کند:

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

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

برای ورود به بازار کار چقدر Agile یاد بگیریم؟

برای شروع کار به‌عنوان کارشناس تست، لازم نیست در Agile متخصص باشید.

اما بهتر است مفاهیم پایه مانند موارد زیر را بشناسید:

  • Agile
  • Scrum
  • Sprint
  • Product Backlog
  • User Story
  • Acceptance Criteria
  • Definition of Done
  • Daily Stand-up
  • Sprint Review
  • Sprint Retrospective

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

برای مثال، اگر در یک مصاحبه از شما پرسیده شود:

«تستر در ابتدای Sprint چه کاری می‌تواند انجام دهد؟»

بهتر است بتوانید درباره بررسی نیازمندی، شناسایی ابهام‌ها، بررسی Acceptance Criteria، شناسایی ریسک‌ها و آماده‌سازی فعالیت‌های تست صحبت کنید.

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

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

۱۵. اشتباهات رایج در مسیر کارشناس تست نرم افزار شدن

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

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

شروع کردن با ابزارها به جای مفاهیم تست

یکی از اشتباهات رایج این است که فرد از همان ابتدا سراغ ابزارهایی مانند Selenium، Playwright، Postman یا ابزارهای مدیریت تست می‌رود، بدون اینکه بداند دقیقاً چه چیزی را باید تست کند.

ابزار فقط وسیله‌ای برای انجام فعالیت تست است.

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

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

به همین دلیل بهتر است ابتدا تفکر تست و مبانی تست نرم افزار را یاد بگیرید و سپس ابزارهای موردنیاز را به مسیر خود اضافه کنید.

تلاش برای یادگیری همه چیز به‌صورت هم‌زمان

تست نرم افزار حوزه گسترده‌ای است.

Manual Testing، Automation Testing، API، SQL، Performance، Security، ابزارهای مختلف، برنامه نویسی، CI/CD و موضوعات بسیار دیگری وجود دارند که می‌توانند بخشی از مسیر حرفه‌ای یک تستر باشند.

اما لازم نیست همه آن‌ها را از روز اول یاد بگیرید.

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

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

برای مثال:

مبانی تست → Manual Testing → Test Design و Bug Reporting → پروژه عملی → API و SQL → برنامه نویسی → Automation

این مسیر الزاماً تنها مسیر ممکن نیست، اما از پراکندگی یادگیری جلوگیری می‌کند.

فقط مطالعه کردن و تمرین نکردن

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

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

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

مثلاً بعد از یادگیری Test Case، برای یک قابلیت واقعی Test Case بنویسید.

بعد از یادگیری Bug Report، یک نرم افزار یا وب‌سایت را بررسی کنید و Bug Report واقعی ایجاد کنید.

بعد از یادگیری API Testing، یک API واقعی را بررسی کنید.

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

منتظر ماندن برای اولین شغل قبل از کسب تجربه

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

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

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

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

همچنین در مصاحبه می‌توانید درباره تصمیم‌هایی که در پروژه گرفته‌اید صحبت کنید.

تصور اینکه وظیفه تستر فقط پیدا کردن Bug است

یک تستر فقط Bug پیدا نمی‌کند.

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

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

هدف اصلی تست، کمک به ارائه اطلاعات مفید درباره کیفیت و ریسک‌های محصول است؛ نه صرفاً تولید تعداد زیادی Bug Report.

تمرکز بیش از حد روی مدرک و گواهینامه

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

اگر فردی چند گواهینامه داشته باشد اما نتواند یک قابلیت ساده را تحلیل کند، Test Case طراحی کند یا یک Bug را به‌درستی گزارش دهد، هنوز بخش مهمی از مهارت عملی موردنیاز را کسب نکرده است.

بهتر است گواهینامه را در کنار سه جزء دیگر ببینید:

دانش نظری + مهارت عملی + تجربه پروژه‌ای

ترکیب این موارد تصویر کامل‌تری از آمادگی شغلی ایجاد می‌کند.

رفتن زودهنگام سراغ Automation

Automation Testing بخش مهمی از مسیر حرفه‌ای بسیاری از تسترهاست، اما شروع آن بدون داشتن پایه مناسب می‌تواند باعث شود فرد بیشتر روی کدنویسی ابزار تمرکز کند تا خود تست.

برای مثال ممکن است بتوانید یک دکمه را با Playwright پیدا کنید و روی آن کلیک کنید، اما هنوز ندانید چه سناریوهایی برای آن قابلیت باید تست شوند.

به همین دلیل، بهتر است ابتدا با اصول تست، طراحی تست و اجرای Manual Testing آشنا شوید و سپس Automation را به‌عنوان یک مهارت فنی به آن اضافه کنید.

البته افراد با پیش‌زمینه برنامه نویسی می‌توانند این دو مسیر را تا حدی هم‌زمان پیش ببرند؛ نکته اصلی این است که Automation جایگزین تفکر تست نشود.

یادگیری ابزارهای زیاد به جای ساختن مهارت

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

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

به جای اینکه هدف خود را «یادگیری ده ابزار» قرار دهید، بهتر است هدف را «توانایی حل یک مسئله تست با ابزار مناسب» قرار دهید.

بی‌توجهی به مهارت‌های ارتباطی

تستر باید بتواند با توسعه‌دهنده، Product Owner، تحلیلگر و سایر اعضای تیم ارتباط برقرار کند.

اگر یک Bug را پیدا کنید اما نتوانید آن را واضح توضیح دهید، ارزش عملی آن گزارش کاهش پیدا می‌کند.

همچنین اگر در یک نیازمندی ابهامی وجود دارد، باید بتوانید سؤال مناسب را مطرح کنید.

بنابراین مهارت‌هایی مانند نوشتن واضح، توضیح مسئله، پرسیدن سؤال مناسب، گوش دادن و همکاری تیمی را نباید مهارت‌های فرعی و بی‌اهمیت در نظر گرفت.

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

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

اگر در رزومه نوشته‌اید:

Advanced SQL

ممکن است در مصاحبه از شما بخواهند یک Query پیچیده بنویسید.

اگر در رزومه نوشته‌اید:

Playwright

ممکن است درباره ساختار پروژه Automation، Locatorها، Assertion یا مدیریت Test Data سؤال شود.

بنابراین بهتر است سطح مهارت خود را صادقانه بیان کنید.

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

مقایسه مداوم خود با دیگران

افرادی که وارد حوزه تست می‌شوند ممکن است خود را با کسانی مقایسه کنند که چند سال سابقه دارند و با Automation، API، Cloud، CI/CD و ابزارهای مختلف کار می‌کنند.

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

در حالی که رشد حرفه‌ای مرحله‌ای است.

ممکن است فردی مسیر خود را با Manual Testing شروع کند، سپس API و SQL را یاد بگیرد و بعد وارد Automation شود.

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

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

نداشتن مسیر مشخص برای ورود به بازار کار

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

برای مثال:

«وقتی SQL را کامل یاد گرفتم شروع می‌کنم.»

بعد:

«وقتی Automation را کامل یاد گرفتم.»

و بعد:

«وقتی همه ابزارها را یاد گرفتم.»

چنین نقطه‌ای ممکن است هیچ‌وقت نرسد.

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

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

در کنار یادگیری، Portfolio بسازید، رزومه آماده کنید و برای موقعیت‌های متناسب با سطح خود درخواست ارسال کنید.

ممکن است از بازخورد مصاحبه‌ها نیز متوجه شوید که باید روی چه مهارت‌هایی بیشتر کار کنید.

در نهایت، هدف این نیست که قبل از ورود به بازار کار، تمام حوزه تست نرم افزار را به پایان برسانید؛ چنین نقطه پایانی وجود ندارد.

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

۱۶. مسیر رشد شغلی کارشناس تست نرم افزار

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

در ابتدای مسیر، تمرکز اصلی معمولاً روی یادگیری اصول تست، اجرای تست‌های دستی، طراحی Test Case، گزارش Bug و آشنایی با فرایند توسعه نرم افزار است. اما با افزایش تجربه، مسئولیت‌ها و سطح فنی فرد نیز می‌توانند گسترده‌تر شوند.

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

شروع مسیر؛ Junior Tester

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

یک Junior Tester معمولاً باید بتواند:

  • نیازمندی‌های ساده را درک کند.
  • سناریو و Test Case طراحی کند.
  • تست‌های مختلف را اجرا کند.
  • Bugها را به‌صورت دقیق گزارش کند.
  • Retesting و Regression Testing انجام دهد.
  • با ابزارهای مدیریت تست و Bug آشنا باشد.
  • با اعضای تیم ارتباط مؤثر داشته باشد.

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

هدف این مرحله، فقط «پیدا کردن Bug» نیست؛ بلکه ساختن یک پایه حرفه‌ای برای کار در تیم نرم افزاری است.

رشد به سمت Test Engineer یا QA Engineer

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

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

برای مثال، وقتی یک قابلیت جدید به محصول اضافه می‌شود، بتواند تشخیص دهد:

  • چه بخش‌هایی باید تست شوند؟
  • چه ریسک‌هایی وجود دارد؟
  • چه تست‌هایی باید اول اجرا شوند؟
  • چه بخش‌هایی نیاز به Regression دارند؟
  • آیا API یا Database نیز باید بررسی شود؟
  • چه تست‌هایی ارزش Automation دارند؟

در این سطح، مهارت‌های فنی مانند API Testing، SQL، Git و Automation نیز می‌توانند نقش مهم‌تری پیدا کنند.

البته عنوان شغلی در شرکت‌های مختلف می‌تواند متفاوت باشد و مسئولیت‌های یک عنوان مشخص همیشه یکسان نیست.

رشد به سمت Senior

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

یک Senior Tester یا Senior QA Engineer باید بتواند مسائل پیچیده‌تر را تحلیل کند و در تصمیم‌گیری‌های مربوط به کیفیت نقش مؤثرتری داشته باشد.

برای مثال:

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

در این مرحله، توانایی تصمیم‌گیری و تحلیل اهمیت بیشتری پیدا می‌کند.

مسیر تخصصی Automation Testing

یکی از مسیرهای تخصصی برای افرادی که به برنامه نویسی و ابزارهای فنی علاقه دارند، Automation Testing است.

در این مسیر، فرد علاوه بر دانش تست، باید مهارت برنامه نویسی و کار با ابزارهای Automation را توسعه دهد.

مسیر می‌تواند از مفاهیم پایه شروع شود و به موضوعاتی مانند:

  • طراحی ساختار Automation Framework
  • مدیریت Test Data
  • Page Object Model
  • Parallel Testing
  • گزارش‌گیری
  • Git
  • CI/CD
  • نگهداری تست‌های خودکار

برسد.

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

مسیر تخصصی API و Backend Testing

برخی تسترها به سمت تست API و بخش‌های Backend سیستم علاقه‌مند می‌شوند.

در این مسیر، مهارت‌هایی مانند:

  • HTTP
  • API Testing
  • Authentication
  • SQL
  • Database Testing
  • بررسی Request و Response
  • Integration Testing

اهمیت بیشتری پیدا می‌کنند.

این تخصص به‌خصوص برای پروژه‌هایی که Backend و سرویس‌های متعدد دارند می‌تواند بخش مهمی از فعالیت تست باشد.

مسیر تخصصی Performance Testing

یکی دیگر از مسیرهای تخصصی، Performance Testing است.

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

برای ورود جدی‌تر به این حوزه، علاوه بر مفاهیم تست، باید با مباحثی مانند Load Testing، Stress Testing، تحلیل نتایج و ابزارهای مرتبط نیز آشنا شد.

این مسیر معمولاً به دانش فنی بیشتری درباره معماری و رفتار سیستم نیاز دارد.

مسیر تخصصی Security Testing

Security Testing نیز یک حوزه تخصصی دیگر است.

در این مسیر، تمرکز روی شناسایی ضعف‌ها و رفتارهای امنیتی سیستم قرار می‌گیرد.

تستر می‌تواند در ادامه مسیر با موضوعاتی مانند:

  • Authentication و Authorization
  • مدیریت Session
  • اعتبارسنجی ورودی‌ها
  • کنترل دسترسی
  • آسیب‌پذیری‌های رایج
  • تست امنیت API

آشنا شود.

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

مسیر Test Management و رهبری تیم

همه افراد قرار نیست مسیر خود را به سمت برنامه نویسی و Automation ادامه دهند.

برخی افراد به سمت مدیریت تست و رهبری تیم QA حرکت می‌کنند.

در این مسیر، مهارت‌هایی مانند:

  • Test Strategy
  • Test Planning
  • مدیریت ریسک
  • برآورد زمان و منابع
  • مدیریت تیم
  • گزارش‌دهی
  • ارتباط با ذی‌نفعان
  • بهبود فرایند کیفیت

اهمیت بیشتری پیدا می‌کنند.

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

آیا باید از ابتدا یک تخصص را انتخاب کنیم؟

خیر.

در ابتدای مسیر لازم نیست تصمیم بگیرید که در آینده حتماً Automation Engineer، Performance Tester یا Test Manager خواهید شد.

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

ممکن است فردی بعد از مدتی متوجه شود که به برنامه نویسی و Automation علاقه بیشتری دارد.

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

شخص دیگری نیز ممکن است به Performance یا Security Testing علاقه پیدا کند.

این شناخت معمولاً با تجربه واقعی پروژه بهتر از مطالعه تئوری به دست می‌آید.

رشد حرفه‌ای فقط با یادگیری ابزارهای بیشتر اتفاق نمی‌افتد

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

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

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

  • مسئله را سریع‌تر تحلیل کند.
  • ریسک‌های مهم را زودتر تشخیص دهد.
  • تست‌های مؤثرتری طراحی کند.
  • نتایج را بهتر تحلیل کند.
  • مشکلات را واضح‌تر گزارش کند.
  • با تیم بهتر همکاری کند.
  • تصمیم بگیرد چه چیزی را، چه زمانی و با چه روشی تست کند.

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

بعد از Senior چه می‌شود؟

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

بسته به ساختار شرکت و علاقه فرد، ممکن است مسیر به سمت نقش‌هایی مانند:

  • Lead QA
  • Test Lead
  • QA Manager
  • Automation Architect
  • تخصص‌های فنی مانند Performance یا Security
  • یا نقش‌های نزدیک‌تر به Product و Engineering

ادامه پیدا کند.

هیچ مسیر واحدی برای همه افراد وجود ندارد.

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

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

۱۷. نقشه راه تبدیل شدن به کارشناس تست نرم افزار

تا اینجا درباره مهارت‌ها، تجربه عملی، Portfolio، رزومه، مصاحبه، Agile و مسیر رشد شغلی صحبت کردیم. این مسیر را می‌توان در قالب یک نقشه راه ساده جمع‌بندی کرد.

این نقشه راه قرار نیست جایگزین توضیحات بخش‌های قبلی باشد؛ بلکه یک تصویر کلی از ترتیب منطقی مراحل ارائه می‌دهد.

مرحله ۱: آشنایی با تست نرم افزار

ابتدا باید بدانید تست نرم افزار چیست، چرا انجام می‌شود و تستر در فرایند توسعه چه نقشی دارد.

در این مرحله مفاهیم پایه مانند انواع تست، سطوح تست، Verification و Validation و مفاهیم مرتبط با خطا و نقص نرم افزار را یاد بگیرید.

مرحله ۲: یادگیری Manual Testing

در قدم بعد، فعالیت‌های اصلی یک تستر را یاد بگیرید:

  • تحلیل نیازمندی
  • طراحی Test Scenario و Test Case
  • اجرای تست
  • ثبت Bug
  • Retesting
  • Regression Testing

در این مرحله هدف اصلی، ساختن تفکر تست است.

مرحله ۳: یادگیری Test Design و تحلیل نیازمندی

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

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

مرحله ۴: انجام پروژه عملی

یک وب‌سایت، اپلیکیشن یا پروژه واقعی را انتخاب کنید و آن را مانند یک پروژه تست واقعی بررسی کنید.

برای آن:

  • نیازمندی‌ها را بررسی کنید.
  • سناریو و Test Case بنویسید.
  • تست‌ها را اجرا کنید.
  • Bug Report ایجاد کنید.
  • Retesting و Regression انجام دهید.

هدف این مرحله تبدیل دانش تئوری به مهارت عملی است.

مرحله ۵: یادگیری API و SQL

بعد از ایجاد پایه مناسب در تست، مهارت‌های فنی مکمل را اضافه کنید.

API Testing به شما کمک می‌کند فقط به رابط کاربری محدود نباشید و ارتباط بین بخش‌های مختلف سیستم را بررسی کنید.

SQL و Database Testing نیز به شما امکان می‌دهند داده‌های پشت رابط کاربری و API را بررسی و اعتبارسنجی کنید.

مرحله ۶: یادگیری برنامه نویسی

اگر قصد دارید در ادامه وارد Automation شوید، یک زبان برنامه نویسی را به سطح موردنیاز یاد بگیرید.

برای مثال می‌توانید Python، Java یا JavaScript/TypeScript را متناسب با مسیر شغلی و نیاز پروژه انتخاب کنید.

در این مرحله هدف، تبدیل شدن به یک Software Developer نیست؛ بلکه باید بتوانید منطق برنامه نویسی را در حدی یاد بگیرید که برای نوشتن و نگهداری تست‌های خودکار آماده باشید.

مرحله ۷: ورود به Automation Testing

بعد از ایجاد پایه مناسب، یک ابزار Automation را انتخاب کنید و ابتدا روی پروژه‌های کوچک کار کنید.

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

در ادامه می‌توانید Git و CI/CD را نیز به مهارت‌های خود اضافه کنید.

مرحله ۸: ساخت Portfolio و رزومه

نمونه‌کارهای خود را منظم کنید و نشان دهید که در پروژه‌ها دقیقاً چه فعالیت‌هایی انجام داده‌اید.

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

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

مرحله ۹: آمادگی برای مصاحبه و ورود به بازار کار

مفاهیم اصلی تست را مرور کنید و برای سؤالات سناریومحور آماده شوید.

تمرین کنید که بتوانید یک قابلیت را تحلیل کنید، تست‌های مناسب پیشنهاد دهید، یک Bug را بررسی کنید و درباره تصمیم‌های تستی خود توضیح دهید.

هم‌زمان آگهی‌های استخدامی را بررسی کنید تا بدانید شرکت‌ها برای سطح موردنظر شما چه مهارت‌هایی می‌خواهند.

مرحله ۱۰: رشد بعد از ورود به بازار کار

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

با افزایش تجربه می‌توانید بر اساس علاقه و نیاز بازار به سمت حوزه‌هایی مانند:

  • Automation Testing
  • API و Backend Testing
  • Performance Testing
  • Security Testing
  • Test Management
  • QA Leadership

حرکت کنید.

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

خلاصه مسیر

اگر بخواهیم تمام این مراحل را در یک خط خلاصه کنیم، می‌توان گفت:

مبانی تست نرم افزار → Manual Testing → تحلیل نیازمندی و Test Design → پروژه عملی → API و SQL → برنامه نویسی → Automation → Portfolio و رزومه → مصاحبه → ورود به بازار کار → تخصص و رشد حرفه‌ای

البته این مسیر کاملاً خطی نیست.

ممکن است فردی در هنگام یادگیری Manual Testing هم‌زمان کمی برنامه نویسی یاد بگیرد یا بعد از ورود به بازار کار، یادگیری Automation و SQL را ادامه دهد.

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

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

۱۸. جمع‌بندی

برای پاسخ به سؤال «چگونه کارشناس تست نرم افزار شویم؟» نمی‌توان یک ابزار، دوره یا مدرک مشخص را به‌عنوان پاسخ نهایی معرفی کرد.

تبدیل شدن به یک کارشناس تست نرم افزار، نتیجه ترکیب چند عامل است: دانش تست، تفکر تحلیلی، مهارت عملی، آشنایی با ابزارهای فنی، تجربه پروژه‌ای و توانایی همکاری با تیم.

مسیر را می‌توان با یادگیری مبانی تست نرم افزار و Manual Testing شروع کرد. سپس باید یاد بگیرید چگونه نیازمندی‌ها را تحلیل کنید، سناریو و Test Case طراحی کنید، تست‌ها را اجرا کنید و Bugها را به شکل دقیق گزارش دهید.

بعد از ایجاد این پایه، مهارت‌های فنی مانند API Testing، SQL، Database Testing و برنامه نویسی می‌توانند به‌تدریج به مسیر شما اضافه شوند. اگر قصد فعالیت در Automation Testing دارید، یادگیری برنامه نویسی و ابزارهای Automation اهمیت بیشتری پیدا می‌کند.

اما یادگیری به‌تنهایی کافی نیست.

یکی از مهم‌ترین مراحل این مسیر، تمرین روی پروژه‌های واقعی یا شبیه‌سازی‌شده است. باید بتوانید دانشی را که یاد گرفته‌اید در عمل به کار ببرید؛ یک محصول را بررسی کنید، Test Case بنویسید، Bug پیدا کنید، گزارش دهید، اصلاح آن را بررسی کنید و در صورت نیاز Regression انجام دهید.

در ادامه، همین تجربه‌ها می‌توانند به Portfolio تبدیل شوند و در کنار رزومه، به شما کمک کنند توانایی‌های خود را بهتر به کارفرما نشان دهید.

از طرف دیگر، ورود به بازار کار پایان یادگیری نیست. یک کارشناس تست نرم افزار در طول مسیر حرفه‌ای خود می‌تواند به سمت تخصص‌هایی مانند Automation، API و Backend Testing، Performance Testing، Security Testing یا Test Management حرکت کند.

بنابراین بهتر است مسیر شغلی را به‌صورت یک فرایند تدریجی ببینید:

یادگیری → تمرین → پروژه → Portfolio → رزومه → مصاحبه → ورود به بازار کار → تجربه → تخصص و رشد حرفه‌ای

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

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

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

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

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

منابع

سؤالات متداول

چگونه کارشناس تست نرم افزار شویم؟

برای تبدیل شدن به کارشناس تست نرم افزار، ابتدا باید مبانی تست نرم افزار و Manual Testing را یاد بگیرید، سپس مهارت‌هایی مانند تحلیل نیازمندی، طراحی تست، اجرای تست و گزارش باگ را تقویت کنید. در ادامه یادگیری API، SQL، برنامه‌نویسی و Automation Testing، انجام پروژه عملی، ساخت Portfolio و آمادگی برای مصاحبه به ورود به بازار کار کمک می‌کند.

آیا برای ورود به حوزه تست نرم افزار باید برنامه نویسی بلد باشیم؟

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

آیا Automation Testing برای کارشناس تست نرم افزار ضروری است؟

خیر. برای شروع فعالیت در تست نرم افزار، Automation Testing الزام عمومی نیست. اما برای بسیاری از موقعیت‌های شغلی و رشد حرفه‌ای، یادگیری اتوماسیون تست می‌تواند مهارت‌های فنی بیشتری در اختیار تستر قرار دهد.

آیا یادگیری SQL برای کارشناس تست نرم افزار لازم است؟

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

آیا داشتن مدرک ISTQB برای استخدام به‌عنوان تستر نرم افزار ضروری است؟

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

اگر هنوز استخدام نشده باشیم، چگونه تجربه عملی تست نرم افزار کسب کنیم؟

می‌توان یک وب‌سایت یا اپلیکیشن واقعی را به‌عنوان پروژه تمرینی انتخاب کرد و فرآیند تست را روی آن اجرا کرد؛ از تحلیل نیازمندی و طراحی تست گرفته تا اجرای تست، ثبت Bug Report، Retesting، Regression Testing و در صورت امکان API، SQL و Automation Testing.

برای Portfolio یک تستر نرم افزار چه چیزهایی باید داشته باشیم؟

یک Portfolio مناسب می‌تواند شامل تحلیل نیازمندی، Test Scenario، Test Case، گزارش‌های باگ، نمونه Retesting و Regression، تست API، نمونه SQL و پروژه‌های Automation باشد. هدف Portfolio این است که نشان دهد مهارت‌های تست را در یک پروژه واقعی یا تمرینی به‌صورت عملی به کار گرفته‌اید.

برای شروع کار به‌عنوان تستر نرم افزار از کجا شروع کنیم؟

بهتر است مسیر را با یادگیری مبانی تست نرم افزار و Manual Testing شروع کنید و هم‌زمان با یادگیری، تمرین عملی داشته باشید. پس از تقویت مهارت‌های اصلی، می‌توانید API، SQL، برنامه نویسی، Automation Testing و سایر مهارت‌های فنی را متناسب با هدف شغلی خود اضافه کنید.

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

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

مسیر رشد شغلی کارشناس تست نرم افزار چگونه است؟

مسیر رشد می‌تواند از موقعیت‌هایی مانند Junior Tester یا Junior QA شروع شود و با افزایش تجربه و مسئولیت به نقش‌هایی مانند QA Engineer، Test Engineer و Senior QA یا Senior Test Engineer برسد. همچنین امکان تخصص در حوزه‌هایی مانند Automation Testing، Performance Testing، Security Testing، API Testing یا مدیریت تست وجود دارد.

طبقه بندی شده در:

تست نرم افزار,

اخرین بروزرسانی: مهر 10, 1405