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

تعامل کجای فرایند تست نرم‌افزار است؟

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

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

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

شرکت‌ها برای حل این مسائل، تلاش کرده اند که با راه حل‌های دیگری، کم‌تر آدم‌ها را درگیر چنین فرایند کنند مانند تست ماشینی (Automated Test) و یا جمع‌سپاری تست (Community Test) و یا برون‌سپاری تست (Outsourcing)، با این وجود نمی‌توان تست انسانی (Manual Test) را در فرایند توسعه بکلی نادیده گرفت و آن را جایگزین کرد (البته که هوش مصنوعی می‌تواند جایگزین خوبی برایش باشد!) چون در نهایت شرکت‌ها مغلوب تعاملات موثر انسانی شده‌اند.

بدترین راه حلی که برخی شرکت‌ها سراغ آن رفته‌اند، حذف فرایند تست بعنوان یکی از مراحل توسعه محصول است! بله درست خواندید! تیم‌هایی وجود دارند که به بهانه‌های مختلفی بجز مسائل مالی، تست محصول را نادیده می‌گیرند و این بدترین بلایی است که می‌تواند بر سر محصول و کاربر نهایی آن بیاید. (تجربه باسلام را اینجا بخوانید)

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

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

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

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

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

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

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

نویسنده تخصص روانشناسی ندارد و صرفا تجربیات و دانش خود در این زمینه را به رشته تحریر درآورده است.

بهتر است چه کسانی تست را انجام دهند؟

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

اما…

چرا تست محصول توسط خود تیم توسعه‌دهنده، ایده کاملی نیست؟

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

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

بر این اساس سطوح مختلفی از استقلال در تست بوجود می‌آید:

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

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

ذهنیت توسعه‌دهنده و تستر

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

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

بر اساس سوگیری تاییدی (Confirmation Bias) توسعه‌دهندگان دوست دارند که بیشترین تمجید از دسترنج‌شان را دریافت کنند اما تیم تست دقیقا برعکس این برخورد را بر اساس وظیفه‌شان انجام می‌دهند؛ اینجاست که یک مولفه مهم درگیر می‌شود: ارتباط موثر و سازنده.

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

تعارضات در هر مرحله‌ای رخ می‌دهد؛ چه در مرحله‌ای که کدی اجرا نمیشود و تیم روی پروتوتایپ‌ها یا کاربردپذیری (Usability) کار می‌کند (Static Test)، چه در مرحله‌ای که محصول در فضای واقعی‌تری با اجرای کدها تست می‌شود (Dynamic Test).

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

ارتباط موثر و سازنده: خروج تیم تست از لاک دفاعی

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

چه نوع افرادی برای تست نرم‌افزار مناسب هستند؟ (جای دیگری به این می‌پردازیم)

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

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

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

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

اما… عشق یکطرفه فرجام خوشی ندارد! (مانند مرحوم شهریار) توسعه‌دهندگان نیز یک طرف این رابطه هستند. آن‌ها نیز باید بار مسئولیت خود را به دوش بکشند و وظیفه‌ای را که به تیم تست محول شده، به درستی و با تمام جوانب آن بپذیرند. توسعه‌دهندگان بپذیرند که گزارش‌های تیم تست در راستای اهداف کلی محصول و بهتر شدن کیفیت آن است، گزارش‌های آن‌ها از جنس زیرآب زنی و یا تحقیر عملکرد و دانش تیم‌ها و افراد نیست، افراد آن دنبال دشمن تراشی نیستند و قصد تشویش اذهان عمومی و خصوصی را ندارند و نمی‌خواهند آب به آسیاب رقیب بریزند. تیم تست همانند آینه‌ایست که می‌خواهد ایرادهای محصولمان را قبل از اینکه دیگران به ما بگویند، به ما بگوید تا محصول را اصلاح کنیم. و در نهایت همه متعهد باشند به هم‌افزایی و مشارکت تلاش‌ها برای رسیدن به هدف مشترک (collaboration).

جمع بندی

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

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

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

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

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