چقدر باگ بگیرم خوبه؟!

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

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

آبان ۲۴, ۱۴۰۰

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

آبان ۱۲, ۱۴۰۰

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

آبان ۱۰, ۱۴۰۰

دو سه شب پیش از شدت خستگی و سر رفتن حوصله، تصمیم گرفتم به جای خوابیدن، یک فیلم ببینم. شانسی، فیلمی با نام فارسی “بازی پول”(Moneyball) را انتخاب کردم. کلا نمی‌دانستم فیلم، چه داستانی را روایت می‌کند. ولی گویا فیلم خوبی بود، چون با حدود ۳۵۰۰۰۰ رای در IMDb، رتبه بالای ۷ داشت، و این یعنی با فیلم جذابی طرف بودم.

اما در ادامه ترجیح می‌دهم مقداری با حال و هوای این فیلم همراه شوید، تا در زمان ورود به مباحث تست، با تحلیل‌های آماری غریبه نباشید. برای تشریح فیلم ترجیح دادم بخشی از متن ویکیپدیای فارسی را ارائه دهم، که البته مقداری هم مطلب به شرح مذبور اضافه کرده‌ام که داخل “[ ]” قرار دارد:

“مانیبال یک روایت واقعی از بیلی بین(با بازی برد پیت) مدیر ناموفق یک تیم بیسبال است. بیلی بین مدیر تیم بیسبال اوکلند اتلتیک است و تیمش نتایج بسیار ضعیفی را کسب کرده ‌است و دو تن از بهترین بازیکنان خود را به خاطر همین مشکلات از دست می‌دهد. به خاطر همین موضوع تیم اوکلند اتلتیک در آستانه فروپاشی قرار گرفته ‌است. اما بیلی بین که در سن جوانی با یک اشتباه ورزش بیسبال رو انتخاب کرده‌ است راه بازگشتی را نمی‌بیند و تصمیم می‌گیرد نهایت سعی و تلاش خود را به کار گیرد تا بتواند تیمش را از بحران نجات دهد! او با کمک فردی به نام پیتر براند[که درس خوانده رشته اقتصاد از داشنگاه ییل(Yale) آمریکاست و بیلی بین او را به عنوان آنالیزور تیم استخدام می‌کند،] دست به اقدام عجیبی می‌زند و براساس یک سری معادله‌های ریاضی برخی از بازیکنان را به خدمت می‌گیرد تا اینکه به خاطر همین تصمیم رفته رفته تیم نتایج بهتری می‌گیرد و موفقیتی تاریخی را رقم می‌زند[این موفقیت تاریخی یعنی ۲۰ برد پیاپی که گویا در تاریخ بیسبال آمریکا سایقه نداشته است. درنهایت کار به جایی می‌رسد، که تیم دیگری برای استخدام بیلی بین مبلغ ۱۲٫۵۰۰٫۰۰۰ دلار را به وی پیشنهاد می‌دهد، اما او به دلایلی که خودش می‌داند، باز هم ترجیح می‌دهد، در اوکلند اتلتیک مربیگری کند].”

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

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

اما آن بخش از فیلم که مرا به نوشتن این مقاله تحریک کرد، این بود که:

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

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

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

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

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

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

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

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

اما این سوال “چقدر باگ بگیرم خوبه؟”، طبیعی‌ترین و درست ترین سوالیست که یک تستر می‌تواند بپرسد. چرا که می‌خواهد معیار قابل لمسی از درستی عملکرد خود داشته باشد.

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

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

طبق جدول بالا بعد از ۸ ریلز به این آمار رسیده‌ایم:

این یعنی ما طی ۸ ریلیز با ۴۰۰ باگ مواجه شده‌ایم. که نتیجه آن یعنی۵۰ باگ به طور میانگین در هر ریلیز.

نتیجه منطقی این است که اگر ما بتوانیم با توجه به تجربه ریلزهای خود تا اینجا، از ریلیز ۹ به بعد، در هر ریلیز ۵۰ باگ استخراج کنیم، قطعا آهنگ ارجاع باگ از سمت مشتری با احتمال زیاد بعد از تعدادی ریلیز، به صفر میل خواهد کرد. بنابراین می‌توانیم علاوه بر Test Exit Criteriaهای دیگر، یک مورد جدید با عنوان “استخراج ۵۰ باگ در هر ریلیز” را نیز داشته باشیم.

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

مثلا آهنگ تعداد باگ‌ها.

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

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

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

اما در بحث نیرو!

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

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