تجربه ایجاد تیم تست: باسلام چطور تیم تست‌دار شد؟

میانه‌های سال ۱۴۰۰، اوضاع محصول باسلام در نسخه‌های موبایلی و کامپیوتری، به حد بسیار آزاردهنده‌ای رسیده بود. هم برای تیم باسلام هم برای کاربران محصول باسلام (شامل غرفه‌داران و مشتریان). درصد قابل توجهی از تماسهای ورودی به عملیات پشتیبانی، ریشه در باگهای نرم‌افزاری داشتند. طبق آماری که کافه بازار در گفتگویی ارائه دادند، میزان انتشار (release) نسخه موبایلی باسلام، ۳ برابر اپلیکیشن‌های مشابه بوده است. تیم‌های توسعه بیشترین فشار را بابت اصلاح خطاها و باگ‌ها تحمل می‌کردند و همه سازمان در تب و تاب اصلاح ناهماهنگی‌ها و عجله‌ها بود. با وجود اینکه هر کسی خروجی کار خود را تست می‌کرد، اما اغلب انتشارها بسیار کم کیفیت و حتی خراب بودند. بازخوردهای منفی از هر طرف به سمت تیم باسلام می‌آمد.

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

ریشه دیدگاه مذکور اما ذهنیت مدیران توسعه‌دهنده محصول باسلام بود: دقت نکردن به نیاز واقعی مشتری و تمرکز صرف بر نوآوری و رشد سریع و توجه نداشتن به اعتماد کاربر (trust). ( تجربیات داود با موضوع بلیتز اسکیلینگ جالب هستند - BlitzScaling -) به بیان دیگر، به بهانه این که "ما در حال رشد سریع هستیم نمی‌توانیم وقت را تلف کنیم! هر وقت کاربری به مشکل خورد آن را برطرف می‌کنیم" هر چند رویکرد درستی بود اما خروجی‌های بی‌کیفیت و پر اشکالی منتشر می‌شد که باعث کم شدن اعتماد کاربران به محصول شد. اولویت شدید کمیت بر کیفیت! (درباره کیفیتِ کمیت خواهم نوشت…)

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

این نوشته برای چه کسانی خوب است؟

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

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

قیف هست، قیر نیست! قیر هست، مامور رفته به مرخصی!! و کلا همه چیز هست اما انگار نیست…

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

تصمیم سخت رهبران و مدیران

تغییر شیوه تفکر به فرآیند توسعه محصول، جام زهری بود که رهبران باید سر می‌کشیدند! نظم نداشتن، هماهنگی کم، ارائه سریع نسخه‌ها (fast releases)، تحلیل کم عمق و در یک کلام «چارچوب درست نداشتن»، رفتارهایی بودند که همه ما به آن عادت کرده بودیم و تغییر چنین عادت‌هایی بسیار سخت و انرژی‌بر است. هم‌راستا کردن افرادی که متفاوت فکر می‌کردند و ناهماهنگ عمل، کاری بس سخت بود.

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

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

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

مرحله دوم، اقناع مدیران و سایر افراد مجموعه برای پذیرش مسیر جدید و قاعده‌مندتر شدن بود. مدیران و سرتیم‌هایی که به همان رفتارهای پیش‌گفته عادت کرده بودند و افراد تیم را به آن ترغیب می‌کردند، حالا باید ۱۸۰ درجه تغییر مسیر بدهند. بسیار پیش آمده افرادی که در بخشی مشغول کار هستند، توجهی به تصویر کلی ندارند و بعضا تاثیرات مثبت و منفی عملکرد خود را در مقیاس بزرگ، نادرست ارزیابی می‌کنند. ترکیب این نگرش با خطاهای ذهنی مانند انواع سوگیری‌ها، باعث ایجاد اینرسی حرکتی بالایی برای ادامه مسیر قبلی می‌شود که تغییر آن انرژی زیادی می‌طلبد. (چقدر فیزیک!!!) این عوامل سبب می‌شود که عوض کردن تفکرات افراد به ذهنیت جدید، فوق‌العاده سخت باشد.

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

بالاخره پس از جلسات سخت و گفتگوهای بسیار، فرآیند جدید تصویب شد؛ و چه خوب که شد!

ساختن تیم تضمین کیفیت (Quality Assurance - QA)

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

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

چرا QA بله و QC نه؟ تفاوتشان در چیست؟

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

این شکل جداسازی خوبی انجام داده:

اما در باسلام ملغمه‌ای را پیاده کردیم! درست است که وظایف QC را انجام می‌دهیم اما به اسم QA هستیم به یک دلیل: میخواهیم Proactive باشیم.

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

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

تعریف وظایف و شاخص عملکرد

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

• تست جامع محصول و تهیه گزارش پیش از هر انتشار
• جمع‌آوری و پالایش گزارشهای باگ از همه کانالها
• پردازش و ارسال گزارشها به تیم مربوطه در کانال درست
• ارائه گزارشهای دوره‌ای از وضعیت عملکردی تیمها و باگهای آنها

بر این اساس شاخصی برای تیم تضمین کیفیت تعریف شد: ۱۰۰% باگها از مسیر این تیم گزارش بشود؛ تا این تیم به دنبال اصلاح فرآیند گزارش باگها باشد و آن را از مسیر بهینه پیش ببرد. از دلایل تعیین شاخص فوق، ارتباط زیاد اشخاص مختلف در داخل و خارج تیم با افراد توسعه دهنده محصول (شامل مدیران و همکاران) بود که باعث عدم تمرکز آدم‌ها و بهم خوردن اولویت‌ها در مسیر توسعه بود و بارها از مسیرهای مختلف یک باگ تکراری گزارش می‌شد؛ بعلاوه اینکه باگها به افراد غیر مرتبط گزارش می‌شد که بعضا این گزارشها در گفتگوها محکوم به فراموشی بودند.

در کنار این شاخص برای تیم QA، برای همه تیمهای محصول یک KR مهم تعریف شد: " Bug free بودن حوزه مسئولیت" تا به این ترتیب تیمها به همکاری با تیم جدید نیازمند و متعهد باشند و در نتیجه هم‌افزایی بیشتری برای بهبود کیفیت محصول انجام دهند.

چون سه اصل سختگیرانه برای تیم‌ها تعریف شد:

1. هیچ چیز تست نشده‌ای نداشته باشیم.
2. پیش از هر انتشاری (Release)، حتما تایید QA برای UAT را بگیرد.
3. مسئول باگهای هر تیم، همان تیم است؛ حتی اگر تایید QA را گرفته باشد.

مورد سوم البته ابهامی ایجاد کرد: عدم تناسب مسئولیت و اختیار. جواب:

دو اصل مهم در تست نرم‌افزار وجود دارد:

. Testing shows the presence of defects, not their absence

. Absence-of-errors is a fallacy

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

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

( اصول هفتگانه تست نرم افزار در ISTQB را بدانید)

خوشبختانه همه به این اصول متعهد شدند.

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

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

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

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

شاید در نگاه اول برنامه‌نویسان مناسب‌ترین نفرات برای تست باشند و ممکن است مالک محصول (Product Owner) یا طراحان را برای این مساله دقیقتر بدانید. اما انتخاب ما باید کسانی می‌بودند که هم ریزبینی بالایی داشته باشد و هم وسواس مشتری!

خصوصیات اعضای تیم را اینطور تعریف کردیم:

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

برای یافتن جمع آدمهایی با چنین ویژگی‌هایی از تجربه آدمها (یا PX یا همان منابع انسانی سابق، بزودی نوشته‌اش را می‌خوانید) یک راست رفتیم پیش همکاران عزیز عملیات پشتیبانی!

دوستانی که در این قسمتِ سخت فعالیت می‌کنند، مهمترین مهارتهای نرم (Soft skills) مدنظر را داشتند ولی قسمت دیگر را چه می‌کردیم؟

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

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

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

قبل از اینکه ادامه دهیم، سوالی مطرح می‌شود: چرا automated test را اجرا نکردید؟

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

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

چیزهایی که آموزش داده شد

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

روانشناسی تست (Psychology of Testing)

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

مفصل بخوانید: روانشناسی تست نرم‌افزار

فازهای انتشار (Release states)

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

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

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

بقچه سناریوها (Senario pool)

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

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

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

گزارش‌دهی (Reporting)

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

شرح دقیق و شفاف بودن باگ بسیار مهم است و چون ممکن است باعث سوءتفاهم شود و حتی به اشتباه برداشتی دیگر بشود.

گزارشها دو دسته هستند:

1. گزارش تست: مجموعه تستهای مربوط به یک انتشار که معمولا یک فرآیند در محصول هستند.
2. گزارش باگ: ایرادها و اشکالهایی که در زمانهای مختلفی در محصول کشف یا گزارش می‌شوند و نیاز به اصلاح دارند.

اما مواردی که در هر گزارش باید ذکر شود اینهاست:

1. بستر و آدرس دقیق جایی که خطا رخ داده: مثلا در اپلیکیشن اندروید "غرفه من"
2. نسخه‌ای که با آن کار شده: 3.55.34 RC
3. نوع دستگاه، سیستم عامل و مشخصات صفحه نمایش در صورت لزوم: گوشی nova 5t, Android 10, 6.26", 1080x2340
4. نحوه بازتولید خطا (چطور می‌توان آن را دوباره دید): برنامه غرفه من > سفارشات > انتخاب سفارش > گزینه پرینت لیبل مرسوله > گزینه پرینت > دریافت pdf
5. زمان انجام تست یا مشاهده باگ: چون ممکن است در آن زمان خاص، اشکال زیرساختی وجود داشته باشد.
6. شرح کامل خطای رخ داده و پیامهای سیستم. فیلم ضبط شده از صفحه و تصویری از آن بسیار کمک کننده است. نحوه اتصال به اینترنت نیز بعضی جاها مهم است.
7. اولویت: بر اساس حساسیت، تعداد گزارش، نسبت کاربران آن بستر به همه و …
8. شیوه مطلع شدن از خطا و تعداد: بیان این که چطور متوجه شدیم و در تست بودیم.
9. تیم مسئول

اين موارد توسط تیم تست مشخص می‌شوند و بعد از گزارش توپ در زمین تیم مسئول است و آنجا وضعیت برطرف کردن باگ مشخص می‌شود.

بستر گزارش باگ هر جایی می‌تواند باشد، اما باید این خصوصیات را دارا باشد:

1. در دسترس همه افراد تیم باشد.
2. وضعیت در آن مشخص شود.
3. قابلیت گزارش‌گیری داشته باشد.
4. چیزی از آن پاک نشود.

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

فرآیند تست: چطور تیم تست سر جای خود نشست؟

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

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

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

پس از استقرار تیم و فرآیندهای آن، نوبت به پایش (monitoring) آن رسید.

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

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

جمع‌بندی

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

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

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

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

تشکر

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