تیستن جامعه مهندسین تست نرم‌افزار ایران
نوشته های مرتبط
خلاصه: تست تکامل می‌یابد و واضح است که بعضی از مفاهیمی که ما عادت به انجامشان داریم، امروزه دیگر قابل اجرا نیستند. این امر بسیار مهم است که به صورت دوره‌ای روش‌های تست را بررسی کنیم و آنهایی که دیگر بی‌معنی هستند و یا حتی کاملا زیان بار هستند را جمع‌آوری کنیم. در اینجا سه روش متداول تست که بسیار تمایل به متوقف شدن آنها را داریم آمده است.
صنعت نرم‌افزار در میان بسیاری از نوآوری‌ها و تحولات نفوذ کرده و مدل‌های چندگانه، جرخه‌ها، چارچوب‌هایی مانند مدل V ،Agile و تعدادی از تغییراتش و غیره، وجود داشته است. هر چند که تلاش‌هایی برای استاندار کردن تست وجود داشته است، اما توسط جامعه تستت مورد اعتراض قرار گرفته‌اند. تسترها معتقدند فقدان وجود استاندارد، خوب است. آنها اَشکال مختلف زیادی از تست را شامل تست در Production، مدیریرت تست Session-Based(مبتنی برجلسه)، تست اکتشافی(Exploratory Testing)، توسعه رفتار محور(Behavior Driven Development-BDD)، توسعه تست محور(Test Driven Development-TDD) را به کار می‌برند.
با وجود روش‌های گوناگون، تست تکامل می‌یابد و واضح است که بعضی از مفاهیمی که ما عادت به انجامشان داریم، امروزه دیگر قابل اجرا نیستند. ادامۀ انجام یک کار صرفا به دلیل اینکه ما همیشه آن کار و روش را انجام داده‌ایم خطرناک است و به همین دلیل بسیار اهمیت دارد که به صورت دوره‌ای روش‌های تست را بررسی کنیم و آنهایی که دیگر بی‌معنی هستند و یا حتی کاملا زیان‌بار هستند را جمع‌آوری کنیم. در اینجا سه روش متداول تست که بسیار تمایل به متوقف شدن آنها را داریم آمده است.
۱- ارزیابی Performance(کارایی) مبتنی بر تعداد باگ‌ها
اگر تسترها توسط باگ‌های ثبت شده و برطرف شده مورد قضاوت قرار گیرند، دیگر تمرکز به روی بهبود کیفیت محصول نخواهد بود. افراد یک شرکت امروز بیشتر نگران هستند که چند باگ پیدا شده و اینکه آیا جابجایی در هدف عملیاتی آنها، کارایی آنها را تحت‌الشعاع قرار می‌دهد یا خیر.
تسترها ثبت باگ‌هایی که ساده پیدا می‌شوند را سرلوحه کار خود می‌کنند، و یا گزارش‌های متنوعی از باگ‌های یافت شده برای هر پلتفرم تولید می‌کنند. به این ترتیب برنامه‌نویسان هم Reject کردن باگ‌هایی که تکرار کردنشان سخت است را سرلوحه عملیاتی خود می‌کنند، و یا می‌گویند این موراد اصلا باگ نیستند. تستری که جهت طراحی یک تست خوب برای یک باگ Critical، زمان قابل توجهی را صرف کرده است، طبق این قاعده به دنبال باگ‌هاییست که راحتر پیدا می‌شوند. برنامه‌نویسی که یک راهکار طولانی مدت را طراحی می‌کرد تا بتواند یک محصول قوی بوجود آورد، حالا صرفا فیکس‌های کوتاه مدت برای با گ‌های خفیف از او خواسته می‌شود.
تعداد باگ‌ها هیچگاه به تنهایی تمام ماجرا را بازگو نمی‌کنند. واژۀ باگ را با واژۀ “ایده” جا به جا کنید و آنوقت خواهید دید که مفهوم واضحتر است. شخصی ۵ ایده و دیگری ۲ ایده دارد. آیا این به این معنا است کسی که ۵ ایده دارد تستر و یا برنامه‌نویس بهتریست؟
بدون چیستی و ماهیت یک باگ یا پیچیدگی پیدا کردن و برطرف کردن آنها، ما نمی‌توانیم به یک نتیجه خوب در این مورد برسیم. حال چگونه باید کارایی تسترها را ارزیابی کنیم؟
اول ایده که ایده خوبی هم هست این است که با تستر صحبت کرده و یک Plan برای توانایی‌هایی که هم به خود او و هم شرکت کمک می‌کند، ایجاد کنیم. اگر تستر هیچوقت یک اپلیکیشن موبایل را تست نکرده و علاوه بر آن ممکن است تیم شما در ماه‌های آینده به یک تستر اپلیکیشن موبایل نیاز پیدا کند، چنین چیزی می‌تواند یک شانس خوب برای هر کسی باشد. برای مثال تستر باید بواسطه به کارگیری ابزارهایی مانند X، Y و Z قادر به پیداکردن باگ‌هایی در سطوح UI ، پایگاه داده و سرور باشد و همچنین فعالیت‌های جاری را نیز اجرا کند.
این نوع از اهداف به جای تمرکز محدودتر به یک ویژگی خاص، بروی آموزش و توانایی‌های تستر تمرکز می‌کند. ممکن است این موضوع از تمرکزِ صرف بروی تعداد باگ‌ها زمانبرتر باشد، اما بسیار ارزشمندتر است، چرا که هم باعث پیشرفت و بهبود فرد و هم شرکت می‌شود.
۲- درصد Pass و Fail شدن Test Suite
هر تستری که تعداد کمی باگ پیدا کرده باشد، می‌داند که بیشتر باگ‌ها در زمان انحراف از اسناد پیدا می‌شوند. هنوز هم تیم‌ها مدت زمان زیادی را برای مستندسازی صحیحِ Test Caseها قبل از تعامل با محصول سپری می‌کنند. یک Unit Test می‌تواند در یک Condition(شرط)، Pass شده و در شروط مستند نشده دیگر Fail شود. حتی ممکن است، شما نرخ و درصد قبولی ۹۵ داشته باشید ولی هنوز ۱۰۰ باگ برای برطرف شدن وجود داشته باشد.
لیست کردن تمام Test Scenarioها و داشتن یک Test Case برای هر باگ ایده خیلی خوبی نیست. سنجش و اندازه‌گیری جالبتر زمانی رخ می‌دهد که تصمیمات تنها بر اساس درصد Pass یا Fail شدن باگ‌ها باشد. تیم‌ها به این درصد استناد می‌کنند، اما باید گفت که این نگرش غلط است.
اگر ما از درصد Pass یا Fail شدن تست‌ها چشمپوشی کنیم و روی اطمینانی که تیم‌ها می‌دهند تمرکز کنیم، بهتر عمل خواهیم کرد. ما می‌توانیم از گزارش‌های ساده و ارزیابی ذهنی در مورد اصطلاحات Coverage(مسدود شده، معقول، عمیق) و اطمینان(کم، متوسط، خوب) استفاده کنیم. سپس بر اساس ترکیب آنها اطلاعات کسب کنیم. ما باید از سوال کردن دربارۀ اینکه چند تست Pass و چند تست Fail شدند خودداری کنیم و به جای آن این سوال را بپرسیم: ” آیا مشکلی در این قسمت وجود دارد؟”
من کار خود را با با به اشتراک گذاشتن یک دشبورد با لیستی از امکانات و نیز مشکلات موجود در این امکانات آغاز کردم. این موضوع به ما اجازه داد تا بفهمیم که چه چیزی ما را در Release کردن یک امکان متوقف می‌کند و اینکه آیا ما Use Caseهای بحرانی را برطرف کرده‌ایم یا خیر؟
۳- اتمام کار به وسیله گروه تست
این موضوع کاملا شناخته شده است که کیفیت، مسئولیت فردی افراد است. تسترها می‌توانند آن قسمت از کیفیت که مربوط به آنهاست را تایید کنند، ولی نمی‌توانند کیفیت کل محصول را تضمین کنند. همیشه تیم پروژه از تیم تست انتظار دارد که بعد از چرخه تست یک گزارش اتمام کار بدهند.
روش های گوناگونی برای تضمین کیفیت محصول وجود دارد، اما تضمین کیفیت صرفا در تست خلاصه نمی‌شود، و الزاما یک دستاورد تیمیست. بنابراین:
- همه افراد باید بر روی یک تعریف عمومی از کیفیت قابل پذیرش اتفاق نظر کرده، و Checkpointهای قابل اندازه‌گیری برای تضمین آن داشته باشند.
- هر تیمی باید به اندازه سهم خود در کیفیت پاسخگو باشد و اقداماتی را برای تضمین اینکه محصول ارائه شده مطابق با استاندارهای کیفیت است، انجام دهد.
- موانع میان نقش‌ها باید شکسته شود و متخصصان به عنوان یک تیم با یکدیگر کار کنند و علاوه بر آن به یکدیگر نیز کمک کنند.
- توانایی‌های منحصر بفرد هر شخص باید برای خلق فرهنگ بُردِ گروهی استفاده شده و هر کسی صاحب آن کیفیت باشد.
زمانیکه یک نماینده از هر تیم در تصمیمگیری دخیل باشد،و ما بتوانیم نتایج تست‌ها را مشاهده کنیم، آنگاه به جای خلق یک بازی اشتباه قادر به تعامل خواهیم بود. تمامی ایده‌های تست باید توسط توسعه‌دهندگان و تحلیلگران کسب و کار مرور شوند. Unit Testing باید توسط تیم توسعه انجام شده، و تست User Acceptance نیز باید توسط تحلیلگران کسب و کار انجام شود. این تضمین می‌کند که در آخر کار هر کسی از کیفیت محصول آگاه است، و در نتیجه تصمیم برای Release نیز یک تصمیم مشترک خواهد بود.
هم تیم تست و هم تیم توسعه به مالک محصول(Product Owner) و تحلیلگر کسب و کار(Business Analyst) یک ورودی می‌دهند، و تصمیم نهایی توسط مالک محصول انجام خواهد شد. در نتیجه این تیم تست نیست که پایان دهنده کار است.
این‌ها صرفا نظراتی بود، که من از آنها نتایج مثبتی گرفته بودم، و ترجیح دادم آنها را با شما در میان بگذارم.
