راه اندازی تست نرم افزار

اهمیت انجام تست حرفه ای و داشتن فلوی استاندارد SQA یا همون Software Quality Assurance به معنای تضمین کیفیت نرم افزار بر کسی پوشیده نیست. درسته که در قدم اول باید کدبیس ما شامل تست های Unit و Integration با کاوریج بالا باشه ولی در نهایت باید محصول رو از دیدگاه کاربر بررسی کنیم و برای رسیدن به این هدف نیاز به راه اندازی QA داریم. ممکنه که ما:

1. به تازگی به عنوان صاحب بیزینس، پروژه یا استارتاپی رو شروع کرده باشیم و میخوایم تست منوآل و در ادامه اتومیشن رو بهش اضافه کنیم.
2. اخیرا به عنوان کارشناس تست به پروژه یا شرکتی ملحق شدیم که فلوی مشخص QA، تیم تست و انجام اون به صورت استاندارد در این تیم وجود نداره. حتی ممکنه تنها نیروی QA اون مجموعه باشیم.
3. تا به حال تست رو به روش های غیر استاندارد و به هر نحوی که ذهنمون رسیده بود انجامش داده بودیم و حالا میخوایم فلوی صحیح رو ایجاد کنیم.

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

نکته

عنوان Test و QA در تمام این مقاله به یک معنیه و به پروسه تست نرم افزار اشاره می کنن

QA Engineering (QE)

در ابتدای هرچیز باید با مفهوم مهندسی کیفیت آشنا باشیم. به طور خلاصه یعنی بیایم هرکاری که میتونیم انجام بدیم تا کیفیت نرم افزاری که رسیده دست کاربر ما بره بالا و مشکلاتش کمتر بشه. درسته که تحقق این هدف بخش عمده ای ش میشه تست و QA ولی واحدها و دپارتمان های دیگه هم درگیر این موضوع هستن. IT, Devops, Security officer, Product manager نمونه ای از اینا هست.

QA Mindset

ذهنیت QA داشتن چند تا وجه داره. یکیش اینه که فکر کنیم ببینیم چی باعث میشه کاربر ما راضی تر بشه و نرم افزارمون بهتر عمل کنه؟ این یعنی اصلا شما قبل از اینکه تست رو شروع کنی باید هرکاری که لازمه انجام بدی تا رضایت کاربر بره بالاتر.

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

من خیلی چیزا رو بررسی کردم از فلوی SDLC تا ورکفلوی CI. از داکیومنت های نیازمندی تا راهنماهای سایت برای کاربر. در این بین رفتم سراغ بررسی نحوه پشتیبانی کاربرشون. چیزی که کسی بهش توجه زیادی نمیکنه وقتی حرف QA میشه اما از نظر من یکی از مهمترین قسمت ها بود چون مستقیما با مشتری ما در ارتباط بودن. متوجه شدم که هر روز و هر هفته تعداد زیادی مشکل توسط بچه های پشتیبانی شنیده و ثبت میشه که بخش زیادی شون هم باگ های ریز و درشت تو نسخه ها و پلتفرم های متفاوت بود.

از پروداکت منیجر پرسیدم شما این مشکلات رو چجوری متوجه میشین؟ به من گفت تقریبا ماهی یه بار یه جلسه کلی بین Development و پشتیبانی برگزار میشه و اونا مشکلاتشون رو مطرح میکنن. پرسیدم تیکت ش چی؟ و گفت تیکت براشون نداریم! اینجا بود که مشکل رو پیدا کردم. این همه هزینه برای QA داره انجام میشه تا باگ ها رفع بشه در صورتی که با ایجاد یه پل ارتباطی ساده بین پشتیبانی و توسعه، کلی مشکلات مطرح و حل میشه.

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

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

این رو گفتم تا بگم راجع به کیفیت باید این شکلی و Out of the box فکر کرد. اصلا در ابتدا کاری به تست نداشته باشیم و ببینیم چه کارهایی رو میتونیم برای راضی نگه داشتن کاربرمون و بهبود مشکلات اپلیکیشن مون در حال حاضر انجام بدیم!

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

Softwrare Testing Life Cycle

همونطور که چرخه توسعه نرم افزار (SDLC) داریم، چرخه تست نرم افزار یا همون STLC هم داریم که شامل مراحل زیر میشه:

1. Requirement Analysis
2. Test Planning
3. Test case development
4. Test Environment setup
5. Test Execution
6. Test Cycle closure

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

نقش های مختلف در تست نرم افزار

عنوان	وظایف
QA Engineer / QA Analyst مهندس تست / تحلیل نرم افزار	- تحلیل نیازمندی ها و تست استاتیک - طراحی و بروزرسانی تست کیس ها - اجرای تایپ های مختلف تست منوآل و تهیه گزارش - گزارش باگ ها و مشکلات نرم افزار - تعامل و همکاری با دولوپرها و دیگر اعضای تیم برای رفع خطاها - توانایی طراحی Test Plan و همکاری با Test Architect برای توسعه آن - تحلیل عملکرد نرم افزار، بیزینس و تسط به تمام فیچرها و ارتباط آنها
QA Automation Engineer مهندس تست اتومیشن نرم افزار	- توسعه و نگهداشت تست اتومیشن - همکاری در اینتگریت کردن تست ها با CI و Cloud - تحلیل گزارش های اتومیشن و گزارش خطاهای دیده شده - همکاری با Test Automation Architect در طراحی فریمورک اتومیشن - تعامل با QA Engineer ها و دیگر اعضای تیم برای بهبود اتومیشن
QA Architect معمار تست	- تهیه Test Startegy و Test Plan - ایجاد فلوی تست و بروزرسانی آن - رهبری فنی تیم QA برای فعالیت های مرتبط با تست - تحقیق و توسعه در رابطه با ترندهای تست و Best practice ها - اطمینان از پایداری و توسعه پذیری زیرساخت و محیط تست
QA Automation Architect معمار تست اتومیشن	- ایجاد فریمورک تست اتومیشن و بروزرسانی آن - افزودن تکنولوژی و فیچرهای جدید به فریمورک اتومیشن - اینتگریت کردن اتومیشن با CI و Cloud
QA Lead لیدر تیم تست	- اساین تسک به اعضای تیم و بررسی عملکرد آن ها - مصاحبه و جذب اعضای جدید تیم - چینش تیم QA - مانیتور کردن پروژه و اطمینان از Meet شدن Milestone های تست - ایفای نقش رهبر، رفع اختلاف های داخلی تیم و هدایت اعضا در شرایط بحران - ایجاد رودمپ و منتورینگ/آموزش افراد تیم
QA Manager مدیر تست	- برنامه ریزی و هدایت فعالیت های QA در تمام مراحل SDLC - پیاده سازی پروسه های استاندارد QA و Best practice ها - تعریف OKR و KPI برای QA - تصمیم گیرنده نهایی در امور مرتبط با QA
SDET مهندس توسعه تست در نرم افزار	- اضافه کردن تست های Unit و Integration - اضافه کردن نیازمندی های تیم اتومیشن به اپلیکیشن - محاسبه کاوریج برای تایپ های مختلف تست - ایفای نقش به عنوان دولوپر با تمرکز بر تست - همکاری با Test Automation Architect برای ایجاد فریمورک
Performance Testing Engineer مهندس تست پرفورمنس	- پلن، طراحی، نگهداشت و اجرای تست های پرفورمنس - تشخیص و تحلیل نقاط ضعف پرفورمنسی سیستم و ارائه راهکار برای بهبود آن ها - تهیه گزارش و ایجاد دشبورد از نتایج اجرای تست - اینتگریت کردن تست های پرفورمنس با CI و Cloud
Security Testing Engineer (Penetration Tester) مهندس تست امنیت	- اجرای مدل های مختلف تست های نفوذ - تشخیص آسیب پذیری ها و تهدیدهای امنیتی نرم افزاری - اطمینان از رعایت استانداردهای امنیتی مانند OWASP10 - همکاری و تعامل با دولوپرها برای اصلاح مشکلات امنیتی نرم افزار - همکاری نزدیک با واحد Information Security به خصوص در زمینه مقابله و دفع حملات امنیتی - اطلاع و بروز بودن از آخرین تهدیدهای امنیتی و آپدیت کردن دیگر اعضای تیم در این ارتباط

قدم اول: اهداف و نیازمندی های بیزینس

ما باید در ابتدا بدونیم چه هدفی رو از پیاده سازی QA دنبال میکنیم. درسته که رسیدن به یه سری استاندارد ها و نتایجی که QA به صورت کلی داره اولین هدف ماست. اما باید بدونیم از نظر بیزینسی دنبال چی هستیم؟

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

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

قدم دوم: ROI Investigation

ما تو هرچیزی بخوایم سرمایه گذاری کنیم و برای پروژه هزینه اضافه کنیم، باید بدونیم که عایدی ما از اونکار قراره چی باشه و چه تاثیرهای مثبت و بازگشتی برای ما خواهد داشت. فرقی نمیکنه قراره دولوپر FrontEnd اضافه کنیم یا کارشناس QA. باید در هر صورت بدونیم این هزینه باعث سود پروژه در نهایت میشه.

توجه

لازمه اینو الان اضافه کنم که اگر تا به حال به هر دلیلی معتقد بودین که نیروی تست در شروع استارتاپ اختیاریه، لطفا این ذهنیت رو به طور کامل بزارید کنار و به عنوان کسی که بیشتر از یک دهه هست تو شرکت های بزرگ داخلی و خارجی در حوزه تست کار کرده و به صدها نفر و تیم مختلف مشاوره داده اینو قاطعانه لطفا از من بپذیرید که کارشناس تست از همون اول باید جزو ساختار تیم باشه و نبودنش قطعا باعث مشکلات جبران ناپذیر برای پروژه و حتی شکست اون میشه. (حداقل ۳-۴ مورد رو شاهد بودم بدون تست شروع کردن و پروژه شکست خورده)

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

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

1. محاسبه ROI تست:

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

• صدمه به کاربران و غرامت های سنگین / نمونه: کنسل شدن پروازهای هزاران مسافر هواپیمایی British Airways در سال 2017 به دلیل یک خطا در سیستم IT | نمونه های دیگر
• متوقف شدن فروش محصول و اشتراک نرم افزار
• نارضایتی مشتریان و کاهش کاربرها
• هزینه چندبرابر برای رفع خطا توسط دولوپرها
• سوخت شدن هزینه مارکتینگ
• و... اینها نمونه های هزینه های احتمالی هست که در ابتدا خواهیم داشت. شاید در ابتدا اینا رو حس نکنیم اما به مرور که اپلیکیشن ما بزرگ تر میشه کم کم خودشون رو نشون میدن و شروع تست در اون زمان خیلی سخت تر میشه. خوب حالا میتونیم حضور نفر QA رو با احتساب فلان قدر حقوق و هزینه هایی که برای شرکت داره رو داشته باشیم و در نهایت می بینیم این عدد در بلند مدت یک هزارم ضرر و زیان هایی که ممکنه در نتیجه نداشتن تست داشته باشیم نیست.

2. محاسبه ROI اتومیشن:

در رابطه با شروع تست اتومیشن و محاسبات پیچیده ROI ش در پست جداگانه ای در آینده، مفصل صحبت میکنم ولی به طور خلاصه بخوام بگم تست های Unit, Integration, Component و غیره که سمت کد هستن رو که از همون ابتدا باید داشته باشیم. حالا تست هایی مثل E2E, UI Functional, API Automation و... که معمولا نفر QA Automation انجام میده رو معمولا زمانی شروع میکنیم که اولا اپلیکیشن به یه نسخه Stable از نظر فیچرهای اولیه رسیده باشه و ثانیا ما یه تعدادی تست منوآل داریم که به عنوان تست رگرشن هر دفعه باید اجرا بشن و حالا میخوایم این زمان اجرا رو کم کنیم.

محاسبه ROI اتومیشن یعنی بیایم ببینیم چقدر تو هزینه و زمان تست ما صرفه جویی کرده. همچنین باید این موضوع رو برای بلند مدت در نظر بگیریم. یعنی نیایم در انتها بگیم یک Release چقدر هزینه برد. بلکه بیایم مثلا ۱۰ تا Release رو درنظر بگیریم.

گفتم که هدف اینه که تست های وقت گیر و تکراری رگرشن منوآل رو اتومیت کنیم تا تمرکز کارشناس تست بره رو موراد دیگه مثل تست های Exploratoty یا آپدیت /اضافه کردن تست های جدید.

این زمانی که با اتومیشن آزاد میکنیم میشه همون چیزی که فاکتور اصلی محاسبه ROI اتومیشنه. مثلا بیایم زمان اجرای ۵۰۰ تا تست رگرشن که به صورت منوآل ۴ روز از دو نفر تیم ما وقت میگیره رو بکنیم ۳ ساعت.

قدم سوم: آنالیز ریسک های تست نرم افزار

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

• نیازمندی های ناقص: وقتی که Requirement های نرم افزار و Acceptance Criteria به خوبی تعریف نشده باشه میتونه به این منجر بشه که تست های کامل که همه سناریوهای لازم رو پوشش بده نداشته باشیم.
• ریسک های فنی: مشکلات نرم افزاری و سخت افزاری سیستم، نبود ابزار و زیرساخت مناسب تست، مشکلات نتورک، از دسترس خارج شدن سرورها، دیتابیس و محیط های تست، حملات سایبری و هر نوع موضوعی که باعث اختلال و وقفه در کار روزانه تست بشه
• مشکلات تعاملی: هر نوع اختلاف و مشکل در ارتباط و تعامل بین دولوپرها، تسترها، مدیران و دیگر اعضا که باعث سوءتفاهم در درک نیازمندی ها و پیش برد تست بشه
• ریسک های بیزینسی : تغییرات ناگهانی در نیازمندی های تعریف شده و نیازهای کاربران، تغییر در Scope پروژه، تغییر در جایگاه محصول در مارکت و رقابت های پیچیده با رقبا که باعث خارج شدن پروژه از Mile stone ها بشه به احتمال زیاد باعث این میشه که پوشش دهی تست پایین تر بیاد و بخش های بررسی نشده زیاد بشن
• زمان بندی نامناسب: ریسک هایی که به زمان بندی های فلوی SDLC مرتبط میشوند وقتی که میخواهیم استیج تست رو هم اضافه کنیم. مثلا تخصیص زمان کوتاه برای توسعه و اجرای تست ها با برعکس ایجاد Bottleneck در انتشار نسخه با درنظرگفتن زمان بیش از حد نیاز برای تست
• منابع انسانی: نبود نیروی تست با تجربه در تیم، ضعف یا کمبود دانش تست مورد نیاز برای پروژه، نبود آموزش مناسب برای اعضای تیم، ضعف در هدایت و مدیریت توسط لیدها و مدیران
• ریسک وابستگی: وقتی که تست ما نیازمند و وابسته به سرویس دیگر یا بخشی از نرم افزار است که کنترلی روی آن نداریم یا هنوز توسعه داده نشده است
• و ...

قدم چهارم: ساختار (استراکچر) تیم تست

خوب خیلی مستقیم بریم سر اصل موضوع. ما سه مدل میتونیم تیم QA رو در ساختار سازمانی داشته باشیم.

1. متمرکز (Centralized)
2. غیرمتمرکز (Decentralized | Embedded | Distributed)
3. ترکیبی (Hybrid)

در ادامه نحوه پیاده سازی هرکدوم و مزایا و معایب شون رو بررسی می کنیم.

۱- مدل متمرکز (Centralized):

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

مزایا:

• بروز ماندن و آپ اسکیل تیم QA به دلیل اشتراک دانش و تجربه ها
• ثبات و حفظ استاندارد تست - به این دلیل که تمامی تیم QA صرف نظر از اینکه بر روی چه پروژه ای کار می کنن قواعد و استاندارد های تعریف شده توسط مدیران تست رو به کار می برن
• تخصیص بهتر منابع و نیروی انسانی - داشتن چنین تیمی امکان Flexible بودن ایجاد میکنه و در صورت نیاز مهندسین تست میتونن بین پروژه ها جابجا بشن یا موقتی به همدیگه کمک کنن

معایب:

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

ساختار: اگر تمام Role های تعریف شده برای QA را در یک تیم داشته باشیم چارت زیر ارتباط اونا رو به صورت سلسله مراتبی نشون میده. در رابطه بامدل های غیر متمرکز و هایبرید هم همین چارت صادقه با این تفاوت که نفر QA به عنوان نماینده تست در تیم های دیگه حضور داره.

2- مدل غیر متمرکز (Distributed):

تو این مدل که معمولا تو شرکت های با پروژه، Squad، Tribe های مختلف دیده میشه، هر تیم نفر QA خودش رو داره که مستقیما با دولوپرهای اون تیم کار میکنه.

مزایا:

• تعامل بیشتر با دولوپرها و دیگر اعضای تیم
• فیدبک سریعتر به تیم توسعه و حذف بروکراسی و پینگ-پنگ های اضافه ارتباطی بین QA و تیم توسعه
• شخص QA دانش بیشتری نسبت به اون دامین و بیزینس پروژه به دست میاره چون خیلی توش عمیق تر و متمرکز میشه

معایب:

• ناهماهنگی بین نحوه انجام QA در تیم های مختلف و احتمال خارج شدن از استانداردها
• احتمالا انجام کارهای چندباره در تیم های مختلف. مثلا ایجاد فریمورک اتومیشن مشابه که میتونست یکی باشه
• احساس انزوا و ایزوله شدن - افراد QA داخل اون تیم ممکنه این احساس رو پیدا کنن که از تیم اصلی QA سازمان جدا شدن.

3- مدل ترکیبی (Hybrid):

همونطور که از اسمش مشخصه این مدل ساختار یعنی ما بیایم دو مدل Centralized و Decentralized رو با هم داشته باشیم. به این معنی که یه تیم مرکزی QA رو داریم که استاندارد ها و قواعد رو تببین و تعریف رو میکنه و برای هر تیم هم به طور جداگانه فرد یا تیم تست داریم.

مزایا:

• استاندارد سازی به همراه تغییرات سریع در صورت نیازهای پروژه ها
• میزان تعامل QA با هم تیمی های خودش و دیگر QA جزو حلقه مرکزی بالانس میشه. یعنی نه به اون حد ایزوله داخل تیم به صورت Embedded و نه کاملا جدا مثل Centralized.
• بهبود تخصیص منابع

معایب:

• مدیریت پیچیده و سخت تر - اینکه همزمان هر دو مدل Centralized و Decentralized رو با هم داشته باشیم و تجربه کنیم مدیریتش سخت تر میشه و ممکنه چالش بیشتری داشته باشه
• امکان بروز تنش بین تیم هسته QA مرکزی و افراد تخصیص داده شده به تیم های دیگر

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

Centralized:

• وقتی تعداد ریسورس (نیروی تست) کمی داریم
• وقتی به تازگی QA رو راه اندازی کردیم
• وقتی Solo QA داشته باشیم که در این شرایط مجبوریم Centralized پیش بریم

Decentralized:

• وقتی ریسورس زیاد داریم.
• وقتی نیازه که نفر تست خیلی رو دامین و بیزینس اون پروژه یا Squad عمیق و مسلط بشه
• وقتی میخوایم تعامل بین دولوپرها و QA رو زیاد کنیم

Hybrid:

• وقتی پروژه خیلی پیچیده و بزرگ داریم
• وقتی ریسورس زیاد و کافی داریم

جالبه بدونین

شاید براتون سوال باشه شرکت های بزرگ معروف به FAANG مثل گوگل و آمازون چه مدلی رو دنبال می کنن؟ به طول کلی مدت زیادی هست که این شرکت ها تقریبا بخش عمده ای از تست ها رو به دلیل نیاز به دلیور و انتشار سریع و همینطور پیاده سازی هر چه بهتر Shift-Left به صورت اتومیشن انجام میدن و قسمت منوآل داستان بیشتر به تست های Exploratory یا Acceptance یا هرجا که نیاز باشه بر میگرده.

Google: دو مدل Role برای توسعه داره. SWE یا همون Software Engineer که همون دولوپرها هستن. TE یا Test Engineer که دقیقا همون SDET هست. و تست منوآل هم داخل تیم ها به هر نحوی که نیاز باشه توسط افراد تیم انجام میشه. در واقع همه برای Quality مسئول هستن. تو سال های اخیر هم گوگل نقش SDET رو داره کم کم با رول SWE ادغام میکنه ویعنی الان مهندسین نرم افزار باید در زمینه تست هم حرفه ای باشن و تمام مدل های تست هم باید خودشون انجام بدن. معرفی این دو Role توسط گوگل

Meta: غول شبکه های اجتماعی دنیا و صاحب اینستاگرام، فیسبوک و واتس اپ، همچنان Software Test Engineer یا به اختصار STE رو داره که همون شرح وظایف SDET و QA Automation Engineer رو با هم شامل میشه. لیست آگهی های شغلی STE در متا

Amazon: آمازون هم در حال حاضر همه نقش های تست رو که بالاتر بررسی کردیم یعنی QA Engineer, QA Manager,... رو غیر از QA Automation داره. و وظایف اتومیشن رو تو شرکت آمازون جایگاه SDET انجام میده. نمونه آگهی های شغلی SDET در آمازون

Community of Practice (CoP):

یکی از کارهای خیلی خوبی که میتونیم برای بهبود QA انجام بدیم داشتن جلسات منظمی هست که همه نفرات تست سازمان ما صرف نظر از اینکه با چه مدلی کار میکنیم دور هم جمع بشن و تجربیات شون رو با هم به اشتراک بزارن. این کار به خصوص تو مدل های Decentralized که کلا تعامل نیروهای تست با همدیگه کمتره خیلی میتونه به ما در همسو شدن و دنبال کردن Best Practice ها کمک بکنه.

قدم پنجم: نوشتن مستندات (Documentation)

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

استفاده از AI

خوب فکر کنم الان دیگه نیاز به گفتن نباشه که با وجود هوش مصنوعی و به خصوص LLM ها مثل ChatGPT بخش زیادی از این داکیومنت ها میتونه با کمک اونا ایجاد بشه که در این ارتباط اینجا و اینجا خیلی صحبت کردم.

Test Strategy

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

• فلوی کلی QA - مثلا ستون Ready for QA و QA Passed کجای Board ما اضافه میشه یا اینکه آنالیز نیازمندی ها و نوشتن تست-کیس ها تو کدوم مرحله انجام میشه
• چه افرادی رو توی تست داریم و وظیفه هر کدوم چیه؟
• چه متریک هایی رو برای ارزیابی فعالیت های تست داریم؟
• فرمت داکیومنت RTM
• نحوه آموزش تیم QA
• چه مدل تست هایی رو می تونیم با توجه به تکنولوژی سازمان داشته باشیم؟
• چه ابزار و فریمورک هایی رو میتونیم استفاده کنیم؟
• محیط های تست ما کدومان؟
• خروجی تست باید چیا باشه؟
• فرمت ریپورت نتایج اجرای تست ما یا گزارش باگ چه جوریه؟
• ریسک های تست چیه؟
• و...

Test Plan

وقتی که میخوام استراتژی تست رو تو دل پروژه پیاده سازی کنیم به این داکیومنت احتیاج پیدا میکنیم. در واقع Test Strategy داکیومنت جامع و کلی ماست و Test Plan مربوط به اون پروژه خاص یا Squad که توش هستیم که ممکنه پروژه به پروژه متفاوت بشه. اما استراتژی چیزیه که خط مشی تست تو کل شرکت و سازمان هست و همه جا باید رعایت و پیاده سازی بشه. تست پلن معمولا توسط لید تست و وقتی میخوایم تست رو برای پروژه شروع کنیم نوشته میشه. خوب شامل چیاس؟

• آپدیت DoD (Definition of Done) و DoD (Definition of Ready) تیکت های دولوپمنت به همراه تست
• چه مدل تست هایی رو قراره اجرا کنیم و با کدوم ابزار؟
• کیا تو تیم هستن و هرکدوم چه وظیفه ای دارن؟
• فیچر یا Epic هدف اصلی ما که قراره ریلیز بشه چیه؟ (مثلا اضافه شدن ثبت نام با شماره موبایل)
• ریسک هایی که تو این پروژه در زمینه تست داریم چیه و چجوری مدیریت شون می کنیم؟
• محیط های تست ما کجاس؟
• اسکوپ تست ما چیه؟ یعنی مثلا رو چه پلتفرم هایی باید تست بشه یا کدوم فیچرهاباید به صورت رگرشن در کنار فیچر اصلی تست بشن
• کدوم تست ها رو قراره برای فلان نسخه اجرا کنیم؟ (این مورد رو باید برای هر نسخه و جزوی از Release process بنویسیم.)
• نحوه تست لایو و پروداکشن به چه صورتیه؟
• تست دیتا هایی که لازم داریم رو چجوری تو دیتبایس ایجاد و حذف کنیم؟
• تخمین زمان/ریسورس لازم برای فعالیت های تست شامل آنالیز نیازمندی ها، ایجاد تست کیس ها، آماده سازی محیط تست، اجرای تست و ریپورت که به این بخش به طور کل Test Effort Estimation میگن
• چه مدت زمان (یا دقیق تر چند اسپرینت) طول میکشه فیچر یا Epic مد نظر تست بشه
• و...

Defect Management

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

به کل فرآیند پیدا شدن باگ تا زمان رفع آن Bug Life Cycle میگیم و باید به خوبی برای مدیریت اون داکیومنت های لازم رو شامل موارد زیر تعریف کرده باشیم:

• فرمت ثبت باگ
• ابزاری که باگ ها توش ثبت میشن - معمولا همون ابزار Issue management مون مثل Jira هست
• فلوهای رفع باگ در استیج های مختلف:
  • باگ هایی که در مرحله استتیک تست و روی Requirement و Design پیدا میشن
  • باگ هایی که در مرحله develop و قبل از انتشار پیدا میشن
  • باگ هایی که روی محیط Production-like مثل staging قبل از ریلیز پیدا میشن
  • باگ هایی که توسط خود ما توی پروداکشن پیدا میشن
  • باگ هایی که توسط کاربرای ما گزارش میشن - برای این مدل باگ ها اون تجربه ای که در اول این مقاله گفتم رو فراموش نکنین و یه کانال ارتباطی قوی بین پشتیبانی و توسعه به همراه روال مشخص برقرار کنین

Test Case Design

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

این کار باید تو ابزار مخصوص خودش مثل TestRail یا TestLink یا با استفاده از اکتنشن هایی مثل Xray در جیرا انجام بشه. تقریبا اکثر ابزارهای No-code/Low-code هم مثل Testimیا Qase این فیچر رو دارن. استفاده از هر نوع ابزار دیگه ای مثل Excel یا Notion یا حتی Confluence اشتباس حتی اگر Template مناسب برای اینکار داشته باشن. حتی Xray برای جیرا رو هم من توصیه نمیکنم چرا که زور زده فرمت تسک های جیرا رو تبدیل به تست-کیس کنه و کار رو پیچیده کرده. حالا چرا باید از ابزار مناسب این کار استفاده کنیم؟

• احتیاج داریم Test-plan ایجاد کنیم برای هر ریلیزمون
• احتیاج داریم Shared steps داشته باشیم و نیایم استپ های تکراری برای هر تست بنویسیم
• احتیاج داریم گزارش های مختلف تهیه کنیم
• احتیاج داریم با استفاده از API که اون ابزار داره فریمورک اتومیشن رو باهاش Integrate کنیم
• و...

نکته

یه مهندس تست باید تکنیک های نوشتن تست-کیس خوب رو به خوبی مسلط باشه مثل تسلط یه خطاط روی کار با قلم!

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

• فرمت استاندارد و قراردادی مون رو برای نوشتن تست کیس مشخص میکنیم.
• اپلیکیشن رو بر اساس فیچر/اپیک، سکشن های اصلی، صفحات، ماژول ها یا هر دسته بندی سطح بالایی که مناسب میبینیم جدا میکنیم. این دسته بندی سطح بالا به عنوان فولدربندی Test-case manager استفاده میشن.
• داکیومنت Requirement های اولیه رو آنالیز و Acceptance Criteria ها رو تبدیل به Test Scenario میکنیم. و بعد برای هر سناریو Test Suite می نویسیم که خودش شامل چند تا تست-کیس میشه.

از این بعد با اومدن فیچرهای جدید، تغییرات در اپلیکیشن، پیدا شدن باگ و... تست-کیس ها رو به مرور آپدیت میکنیم یا موارد جدید اضافه میکنیم.

نکات مهم

• آپدیت/اضافه کردن تست-کیس ها بخشی از DoD هست و تو ستون QA تو Board (که جلوتر میبینیم) باید براش وقت جداگانه درنظر گرفته بشه
• هیچ باگی نباید وجود داشته باشه که برای بار دوم دیده میشه ولی تست-کیسی که اون رو پوشش داده باشه نداشته باشیم. این یعنی باگ که پیدا میشه باید تست کیس ها رو بلافاصله آپدیت کنیم تا از این به بعد تو تست های رگرشن اونو پوشش بدیم
• بهتره از همون فیلدهایی تو ابزار تست مون اضافه کنیم تا بتونیم بهتر همه چیز رو مدیریت کنیم. این امکانات رو اکثر ابزارها مثل TestRailدارن ولی باید اونا رو اضافه و لینک کنیم معمولا. مواردی مثل:
  • ورژن اپلیکیشن که با این تست Compatible هست
  • Automation Status (Not feasible / Done/ Undone)
  • Test Version
  • Requirement / AC Link
  • Bugs related
  • ...

Qulification Matrix

هر سازمانی لازم داره که معیاری برای سنجش سطح تخصص و مهارت افراد داشته باشه. برای رسیدن به این هدف یه داکیومنت تخصصی لازمه که مشخص کنه که مثلا یه دولوپر جونیور FrontEnd باید چیا بلد باشه و مثلا همین شخص بخواد سنیور بشه باید تو چیا پیشرفت کرده باشه یا چه تخصص های جدیدی به دست آورده باشه. اسم این داکیومنت Qulification/Skill Matrix هست که از طریق اون میشه به اهداف زیر رسید:

• گریدبندی افراد تیم
• برای استخدام هر رول در سطوح مختلف شخص باید چه مهارت هایی بلد باشه و چه سوالایی ازش پرسیده بشه
• مسیر پیشرفت و Career Ladder که افراد بدونن مثلا با پیشرفت در فلان مهارت ها یا کسب فلان مهارت های جدید میتونن به درجه بالاتر ارتقا پیدا کنن
• ایجاد Roadmap و مسیر آموزش
• و ...

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

خبر خوش اینه که یکی از تخصص های من تو سازمان هایی که باهاشون کار کردم ایجاد این داکیومنت بوده و در حال حاضر هرچیزی که میدونستم و تو شرکت های بزرگ دیده بودم و تجربه کرده بودم رو گذاشتم کنار هم و این داکیومنت رو خیلی دقیق برای QA ایجاد و همواره هم با توجه به نیازها و استاندارد های فعلی مارکت آپدیتش میکنم که از اینجا میتونین مطالعه ش کنین و با خیال راحت تو سازمان خودتون به کار ببندینش چون حسابی چکش کاری و به صورت عملیاتی تو Scale های بزرگ اجرا شده. اسمش رو هم گذاشتم QA-Roadmap تا مشخص باشه که تمام این موارد رو پوشش میده.

Reporting

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

• ریپورت تست Regression
• ریپورت تست Smoke قبل از انتشار
• Requirements Traceability Matrix (RTM)
• Release Checklist
• Defect Density
• و ...

HowTos

از همون روز اولی که بچه های تست شروع به کار میکنن چه منوآل چه اتومیشن در حال پیاده سازی و سرو کله زدن با مسائل مختلف هستن که گاهی اوقات هم به مشکل میخورن و طول میکشه که سولوشنش رو پیدا کنن. اینا چیزایی هست که باید به خوبی با عنوان داکیومنت های How To نوشته بشه و هر شخص جدیدی میاد باید به عنوان بخشی از پروسه Onboarding مطالعه شون کنه. همچنین این داکیومنت ها به عنوان رفرنس برای همه اعضای تیم مورد استفاده قرار میگیره. این مهمه که آپدیت و بازنگری هم بشن. مسلماباید تو ابزار مناسب خودشون هم نوشته بشن مثل Confluence یا Notion. توصیه میشه که دانش های عمومی مورد استفاده و لازم برای تست هم در اینجا قرار بگیره مثل منابع یادگیری.

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

• نحوه دیپلوی نسخه های مختلف اپلیکیشن تو محیط های تست
• نحوه بیلد نسخه های مختلف اپلیکیشن به صورت لوکال و یا بر روی دیوایس های Android/iOS وقتی اپلیکیشن موبایل داریم.
• نحوه تغییر Feature flag های اپلیکیشن
• نحوه دسترسی به دیتابیس محیط های تست
• نحوه کار با بخش های مختلف DevTools مثل Network
• دستورات مهم ابتدایی Git
• نحوه کار با بخش های مهم کلاد یا کلاینت های Kubernetes وقتی معماری اپلیکیشن مون به صورت مایکروسرویسی هست یا رو کلاد قرار داره.
• ریسورس های خوب آموزشی برای ابزارهایی که باهاشون کار میکنیم
• و هرچیز دیگه ای که به درد بچه های QA میخوره و ما هر روز باهاشون سرو کار داریم.

در رابطه با اتومیشن هم متناظرا باید داکیومنت های این شکلی داشته باشیم که معمولا بخش عمده ای از اونا تو فایل README.md ریپوی اتومیشن قرار داره. مواردی مثل:

• نحوه ایجاد فریمورک از ابتدا که همزمان با اضافه کردن فیچرهای جدید توضیحات لازم به اینجا دوباره اضافه میشه. یعنی اگر یه شخص جدید بیاد باید بتونه با دنبال کردن این داکیومنت، فریمورک اتومیشن ما رو از اول ایجاد کنه. / نوشتن این داکیومنت کار زمان بری هست ولی خیلی زیاد اینو تجربه کردم که یکی از یه تیم رفته و بقیه نفهمدین طرف چیکار کرده و یا یه پروژه جدید میخواستن شروع بکنن و مجبور شدن از اول همه چیز رو بنویسن!
• Commit & Branch name rules
• Semantic Versioning / که متناظر با نسخه های اپلیکیشن هم باشه
• Framework Structure
• نحوه اجرای لوکال تست های اتومیشن
• و ...

قدم ششم: Shift-Left Testing

اول اومدم این مرحله رو تو قدم بعدی توضیح بدم اما دیدم خودش انقدر مهمه که به نظرم یه مرحله جدا و اساسی به حساب میاد. یکی از مفاهیم مهم در حوزه تست که در سالهای اخیر خیلی مطرح شده، Shift-Left Testing هست. خلاصش یعنی بیایم فعالیت های تست رو تا جایی که میتونیم به ابتدای فلوی توسعه انتقال بدیم. خوب حالا چرا؟ چون هر چقدر ایراد زودتر پیدا بشه هزینه رفع کردنش برای ما کمتره.

برای رسیدن به این هدف کارهای زیادی میتونیم انجام بدیم که هم مربوط به Development میشه هم تست منوآل هم اتومیشن. مثل:

• انجام تست های استتیک بر روی Requirement ها توسط مهندس تست
• پیاده سازی BDD
• داشتن Unit Test , Integration Test با کد کاوریج بالا - و بهتر از اون پیش رفتن به صورت TDD
• توسعه و اجرای API Automation / Contract Testing در زمان آماده شدن Backend و قبل از تحویل سرویس ها به Frontend
• و ...

اهمیت ‌BDD (Behaviour-Driven Development)

اگر بخوام یه چیز رو نام ببرم که کل فرآیند توسعه رو به شدت بهبود میبخشه و تو همه بخش ها به خصوص تست کمک مون کنه BDD هست که صرفا تعریف یه زبان مشترک داخل تیم به اسم Gherkin Syntax نیست بلکه یه فرهنگ درون تیمی هست که هرچیزی رو بهش فکر میکنم از تعریف فیچرها و باگ ها تا اتومیشن و علی الخصوص Shift-Left Testing رو میتونه بهبود بده. تو این ویدئو خیلی خوب این موضوع رو با مثال توضیح دادم.

خوب من امیدوارم که حتمابه Shift-Left Testing اهمیت بدین وتاجای ممکن کارهایی که برای محقق کردنش لازمه انجام بدین.

قدم هفتم: تعریف Workflow

ما برای اینکه تکلیف و چرخه یه تسک که قراره انجام بشه (باگ یا فیچر) رو بدونیم باید مشخص کنیم که از اون اول تا آخر چه فلویی رو طی میکنه، تست ش کی شروع میشه، اتومیشن چه زمانی انجام میشه و چرخه کجا به پایان میرسه. این flow باید وضعیت هایی که باعث block شدن هم میشه رو مشخص کنه.

با فرض اینکه اتومیشن ما out-sprint باشه و قراره تست های منوآل رو اتومیت کنیم میتونم فلوی زیر رو که خیلی خوب تو پروژه های بزرگ هم ازش جواب گرفتم توصیه کنم:

قدم هشتم: شروع کار و اقدام

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

• آماده سازی env های تست و هرچیزی که براشون لازم داریم مثل دیوایس های اندروید و iOS
• طراحی تست کیس های اولیه مون که از بخش های اصلی و حیاتی اپ مثل Signup و لاگین شروع و فانکشنالیتی های اصلی اپ و مهم برای بیزینس باید شروع کنیم. (مثل اضافه کردن به سبد خرید برای دیجیکالا)
• اجرای تست ها
• تهیه گزارش
• تحلیل نتایج و تهیه Action Item برای بهبود در صورت نیاز
• آپدیت و تکمیل داکیومنت ها
• آپدیت، اضافه کردن و اجرا کردن تست مرتبط با تسک های داخل board و بر اساس flow (که مرحله ششم توضیح داده شد)
• و ...

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

• اگر قراره تست های منوآل رو اتومیت کنیم: اولا باید یه تعدادی تست منوآل داشته باشیم که به صورت رگرشن برای ریلیز اجرا میشن. اینجا ما قراره با اتومیت کردن این تست ها وقت رو برای بچه های منوآل آزاد کنیم تا بیشتر و بهتر بتونن رو کارهای دیگه تست وقت بزارن و کار وقت گیر و تکراری تست رگرشن رو انجام ندن. بک لاگ اتومیشن در این حالت تست های منوآل هست که معمولا تو اسپرینت بعدی وقتی که اون فیچر ریلیز شد اتومیشن شون رو انجام میدیم. نوشتن این تایپ تست ها بیشترین وقت و هزینه رو از ما میگیرن و نگهداری ازشون هم سخت تر از هرمدل تست دیگه س. برای همین در بالای هرم معروف تست قرار میگیرن.
• اگر قراره برای فیچرهای در حال توسعه تو اسپرینت جاری تست اتومیشن بنویسیم: تو این حالت که بهش In-sprint automation میگن معمولا از نظر زمان و هزینه نمیتونیم تست های E2E کامل یعنی با کال کردن backend واقعی بنویسیم و اینکار یه bottleneck اساسی برای انتشار ایجاد میکنه. برای همین نیاز داریم که Mock server ایجاد کنیم و تمام backend رو ماک و اینترسپت کنیم. و صرفا بیایم رفتار frontend رو با اتومیشن بررسی کنیم. تو این استراتژی، ما معمولا به تست های منوآل دیگه کاری نداریم و به عنوان اتومیشن میایم متسقیما سناریوهایی مینویسم که اون فیچرها رو پوشش بده.

نکات مهم

• هرم تست میگه که تست های Unit/Integration ما باید بیشترین تعداد و در پایین و تست های E2E و فانکشنال ما باید کمترین تعداد باشن و در بالای هرم قرار دارن. پس بهتره که از همون اول دولوپرهای ما تست های whitebox رو مثل Unit/Integration/Component/Snapshot و ... رو کامل بنویسن و حتی TDD پیش برن.
• تست Service/Backend/Database چه منوآل چه اتومیشن باید زودتر از پیاده سازی Frontend شروع و انجام بشه. سرویس که آماده شد با Postman یا ابزارهای دیگه باید تست ش شروع بشه و زمانی که رفتیم سراغ تست Frotnend باید دیگه خیالمون از Backend اون فیچر راحت شده باشه. ضمن اینکه اگر داریم استراتژی دوم رو پیش میبریم بدونیم Mock ما باید چجوری باشه.

قدم نهم: KPIs / Metrics

خوب به عنوان مرحله آخر نیاز داریم که KPI های کیفیت نرم افزار رو بشناسیم و تعریف شون کنیم. البته این مرحله در واقع در آینده و بعد از اینکه یه مدت گذشت و چند تا ورژن به همراه تست کامل ریلیز کردیم باید شروع بشه. Key Perfomance Indicator یا همون شاخص های کلیدی عملکرد به ما کمک می کنن تا بتونیم کارایی و موثر بودن کل پروسه QA و به طور کلی مواردی که رو کیفیت محصول ما تاثیر میزاره رو اندازه گیری کنیم و به یه بالانس منطقی بین زمان و هزینه صرف شده (ریسورس) و کیفیت نرم افزار برسیم.

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

این نکته را بدونیم که لزوما همه KPI هایی که برای تست تعریف می شن به درد ما نمیخوره و یا در قالب پروژه و فلوی تست ما نمی گنجه و قابل اندازه گیری نیست و درگیر شدن باهاشون صرفا پیچیدگی و ابهام ایجاد می کنه. پس این مهمه که به عنوان کسی که میخواد این KPI هارو تعریف کنه (مدیر یا لید تست) اول کل فلوی STLC رو به طور دقیق تعریف و درک کرده باشیم سپس ببینیم کدوم یک از این متریک ها برای ما قابل اندازه گیری هست و در نهایت اون مواردی که درگیر شدن باهاشون بیشترین تاثیر رو روی بهبود پروژه ما میذارن انتخاب کنیم.

روش استفاده ازشون هم این شکلیه که باید برای هرکدوم یه حداقل یا حداکثر (یا اصطلاحا Threshold) تعریف کنیم. اگر از اون حد مجاز فراتر بریم با ریسک مواجه هستیم و باید مدیریت ش کنیم.

حالا بریم سراغ KPI یا همون متریک های متداول تست نرم افزار:

Covered Requirements

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

Passed Requirements

چه تعداد از نیازمندی ها تست شدن و میتونن ریلیز بشن؟ این مورد با مورد قبلی فرق داره. اون برای کاوریج نیازمندی ها توسط تست-کیس بود و این برای Pass شدن تست هاش. در واقع تست های تایپ Sanity رو برای این مورد در نظر میگیریم.

Passed Tests

چه تعداد از تست هایی که به طور کل تو این سایکل اجرا شدن Pass شدن؟ این مورد از قبلی کامل تره یعنی نه فقط تست های Sanity که برای نیازمندی های جدید هستن بلکه همه مدل تست ها مثل Regression و حتی Non-fucntional رو هم در نظر میگیریم.

Time Spent

مدت زمانی که برای هر استیج تست مثل بررسی نیازمندی ها، نوشتن تست کیس ها، اجرای اونا، اتومیت کردن اونا و تهیه گزارش و ثبت باگ ها طول کشیده

Active Defects

چه تعداد باگ حل نشده داریم؟

Automated Test Cases

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

Automated Requirements

مثل بالایی هست فقط برای مدل In-sprint automation که بک لاگش نیازمندی ها بود مستقیما. یه جورایی یه RTM مستقیم برای اتومیشن تو اسپرینت فعلی

Defects Fixed Per Day

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

Rejected Defects

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

Tests Executed (Velocity)

تعداد کل تست های منوآل و اتومیشن که تو این سایکل اجرا شدن

Defect Closure Rate

چه تعداد از باگ هایی که تو این سایکل ریپورت شدن حل شده؟ این متریک در واقع مجموع متریک Fixed Per Day هست که بالاتر توضیح دادم.

Retest Rate

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

Severe Defects

میزان باگ های Critical و مهم رو که در هر سایکل پیدا شده رو مشخص میکنه.

Code Coverage

این متریک برای اندازه گیری کاوریج تست های Unit و Integration به کار میره که متداول ترینشون اینه که چند درصد از خط های کد ما توسط تست ها Excercise شدن. این متریک توسط دولوپرها یا SDET ها اندازه گیری میشه

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

• وقتی که فلوی تست به خوبی پیاده سازی و اصطلاحا Mature شده و از مرحله چکش کاری درومده که شاید چند ماه یا حتی سال طول بکشه و این یعنی بعد از انتشار چند نسخه از اپلیکیشن به همراه کل پروسه تست
• وقتی یه تیم تست بزرگ و گسترده و یا ساختار Distributed داریم
• وقتی که میخوایم فلوی تست رو بازنگری و باز تعریف کنیم. داشتن KPI هایی که از تجربه های قبلی ما میان باعث میشه اهداف مشخص تری این دفعه تعریف کنیم.

چه زمانی داشتن KPI تست نرم افزار مفید نیست؟

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

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

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