چگونه به درخواست‌های Retest پاسخ دهیم

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

اتوماسیون تست بیش از حد

آبان ۲۴, ۱۴۰۰

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

آبان ۱۲, ۱۴۰۰

چگونه تعامل صحیح کسب و کاری می تواند به تحول “همیشه شاد” یا Happy Ever After منجر شود؟

آبان ۱۰, ۱۴۰۰

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

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

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

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

منطقی ترین سوالی که هیچ پاسخی برای آن وجود نداشت این بود، که: “خانم یا آقای کدنویس محترم، چطور بدون تست کردن متوجه شدید، Failure رویت شده در حین اجرا را دیباگ کرده و مشکل را برطرف نمودید؟”

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

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

مثلا فرض کنید ماژولی داریم که قرار است دو عدد را با هم جمع کند. تستر انتظار دارد وقتی دو و سه را به آن می‌دهد، عدد ۵ حاصل شود. در حقیقت ۵ همان Expected Test Result ماست. اما نتیجه خروجی یا Actual Test Result برابر با ۶ است. از اینجا به بعد کار کدنویس است که علت این Failure که یک باگ است را کشف کند، که به این فرآیند دیباگ می‌گویند. پس از بررسی مشخص می‌شود، به جای علامت + در کد، از علامت * استفاده شده است.

نتیجه منطقی این بحث این است که Bug عامل ایجاد Failure است. اگر Failureای وجود دارد، حتما باگی پشت سر آن خودنمایی می‌کند. هیچکس نمی‌تواند مدعی رفع Bug باشد، مگر آنکه بررسی کند، آیا اثر باگ که همان Failure باشد رفع شده است یا خیر. پس هیچ کدنویسی تا زمانیکه حداقلِ تست را بر اساس Bug Report(یعنی همان سناریوی Bug Report با همان داده‌ها را) اجرا نکرده است، نمی‌تواند مدعی دیباگ کردن کار باشد. اما ممکن است این سوال پیش آید: “پس کار تستر چیست؟”. تستر موظف است تا تست‌های دیگری با داده‌های دیگر در همان نقطه انجام دهد، و ایضا باید نقاط دیگر را نیز برای بروز احتمالی باگ‌های جدید به دلیل تغییر کد، بررسی نماید.

2. ساقط شدن وظیفه اجرای تست از کدنویس در شرایط خاص

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

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

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

باید در نظر داشته باشیم که طبعا هیچ کس دوست ندارد کار زائد انجام دهد. ولو اینکه منطقا باید کاری توسط تستر انجام شود، ابتدا باید سودمند بودن این کار را برای تستر برجسته کنیم.

مثلا ما یک بار باگی پیدا کردیم و آن را گزارش کردیم. یکی دو هفته گذشت و به نظر نمی‌رسید اتفاقی افتاده باشد. وقتی پیگیر شدیم، این پاسخ را دریافت کردیم: “لطفا آخرین نسخه کد را مجددا تست کنید و بررسی کنید که آیا باگ هنوز وجود دارد یا خیر؟”

چرا باید دوباره اجرا شود؟ ما مشکل را یک بار دیدیم! چه چیزی تغییر کرده است؟ و سپس جواب نهایی را گرفتیم: “ما کد را تغییر دادیم”.

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

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

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

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

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

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

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

برنامه‌نویسان فروم به دنبال ارائه توضیحی منطقی بودند و تأکید بر این داشتند که درخواست‌های مکرر تست مجدد به دلیل بی احترامی یا تنبلی نیست.

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

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

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

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

4. تسترها امکان اجرای تست توسط کدنویس را برای وی فراهم کنند

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