چطور با توجه به جزئیات، شرلوک هولمز باگ‌یابی شویم

اگر بخواهید چیزی را پیدا کنید، در قدم اول باید بدانید که آن چیز دقیقاً چیست. درست مثل کارآگاه‌ها، متخصصان Testing هم وقتی دنبال باگ می‌گردند، یک سری تحقیق و تفحصات انجام می‌دهند. هر نوع باگی ویژگی‌های منحصر به فرد خودش را دارد. در تیم‌های توسعه نرم‌افزار، یک Software Tester باید همه این ویژگی‌های خاص باگ‌ها را بداند تا بتواند «مجرم» را شناسایی کند!

بیایید با چند نوع از باگ‌ها شروع کنیم که معمولاً شناسایی کردنشان سخت است اما رواج بسیار زیادی دارند:

باگ کارکردی (Functional Bug)

این باگ را وقتی می‌توانیم پیدا کنیم که همه کارکردهای سیستم را بررسی کرده، و مطمئن شویم که هرکدام همان کاری را می‌کنند که باید بکنند. اگر یک Function کار عجیب و غریبی بکند که در لیست کارهای مورد نیاز نبوده، این یک باگ محسوب می‌شود. مثال بزنم؛ فرض کنید دکمه‌ای در اپلیکیشن هست که قرار بوده پنجره A را باز کند؛ اما در عوض، این دکمه یا پنجره B را باز می‌کند یا اینکه کلا هیچ چیزی را باز نمی‌کند. این یک باگ کارکردی است.

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

باگ رابط کاربری (User Interface Bug)

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

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

اگر هیچگونه مستندسازی (Documentation) برای دیزاین انجام نشده، نگران نباشید. فقط با بررسی نرم‌افزار هم می‌شود بیشتر باگ‌های UI را پیدا کرد. دنبال خرابی Layout، بلوک‌ها (Blocks) یا المان‌های (Elements) روی هم افتاده، متن خارج از بلوک، و هر عنصر دیگری باشید که سر جایش نیست یا کلا ناپدید شده است. در حین پروسه باگ‌یابی، به زودی متوجه خواهید شد که اغلب باگ‌های UI وقت گشتن به دنبال باگ‌های کارکردی خودشان را نشان می‌دهند.

باگ‌های محلی‌سازی (Localization Bug)

پیدا کردن باگ‌های محلی‌سازی فقط وقتی لازم می‌شود که نرم‌افزارتان چند زبان مختلف را پشتیبانی کند، و/یا زمانی که قرار باشد افرادی از منطقه‌های زمانی (time zone) مختلف از آن استفاده کنند.

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

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

باگ کاربردپذیری (Usability Bug)

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

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

در ادامه لیست، می‌خواهیم با باگ‌هایی آشنا شویم که شاید در اینترنت یا کتاب‌ها توضیح درست و حسابی در مورد آنها پیدا نشود؛ اما این به این معنی نیست که وجود ندارند:

باگ ادغامی (Integration Bug)

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

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

مثلا یک وبسایت را تصور کنید که در آن صفحه A، اطلاعات B را دارد که قرار بوده به صفحه C منقل شوند. اگر اطلاعات B با اطلاعات موجود در صفحه C یکی نباشد، این یک باگ ادغامی است.

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

باگ آپدیت سیستم (System Update Bug)

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

باگ صوتی (Audio Bug)

هر اپلیکیشنی صدا ندارد، اما آن اپلیکیشن‌هایی که نوتیفیکیشن می‌دهند یا صدا یکی از Functionهای اصلی‌شان است باید کاملاً از نظر صوتی چک شوند.

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

باگ‌های Texture و Objectهای سه بعدی

این باگ در بازی‌های سه بعدی مثل MMORPG خیلی شایع است. بعضی وقت‌ها این نوع باگ‌ها را به سختی می‌شود پیدا کرد، زیرا ممکن است از نظر بصری قابل تشخیص نباشند. برای شکار آنها باید اول تفاوت بین باگ Texture و باگ Objectهای سه بعدی را بدانیم.

بیایید اول از باگ‌های سه بعدی شروع کنیم. مثلاً ممکن است شخصیت بازی بعد از انجام یک کار بخصوص یا رفتن به یک مکان خاص، ناگهان ناپدید شود. این اتفاق در نتیجه ناپایداری‌ها و Aliasهای ضعیف Objectها در این وضعیت/مکان بخصوص اتفاق می‌افتد. وجود textureهای روی هم ممکن است باعث شود که از این باگ غافل شوید. یک مثال دیگر برای این باگ، حالتی است که شخصیت بازی در یک جایی گیر افتاده، و Object‌هایی که سد راهش شده‌اند نمی‌گذارند از آنجا خارج شود.

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

باگ محتوا (Content Bug)

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

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

هایزن‌باگ (Heisenbug)

اسم این باگ از هایزن‌برگ (Heisenberg) می‌آید؛ یعنی‌کاشف اصل عدم قطعیت در مکانیک کوانتوم. هایزن‌باگ به آن خطاهایی اشاره دارد که مثلا وقت اجرا شدن نرم‌افزار در IDE دیده می‌شوند، اما وقتی برنامه با Debugger اجرا شود اثری از آنها نیست.

تصویر از: simonb.com

بورباگ (Bohrbug)

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

مندل‌باگ (Mandelbug)

این باگ به نام بنوا مندلبرو (Benoit Mandelbrot) نام‌گذاری شده است که پیشرفت‌های عظیمی در حیطه مطالعه فراکتال‌ها ایجاد کرد. مندل‌باگ خطایی است با دلیلی عمیقاً پیچیده و مبهم، آنقدر که این دلیل به نظر غیر منطقی و غیر قابل توضیح می‌رسد (دقیقاً «به نظر می‌رسد»). این باگ ممکن است به خاطر واکنش کند سیستم اتفاق بیفتد. یک نمونه از مندل‌باگ، خطایی هست که رخ داده، اما شما خیلی بعدتر از رخ دادنش از آن باخبر می‌شوید و برای همین پیدا کردن دلیل مشکل برایتان خیلی سخت می‌شود.

شرودین‌باگ (Schrödinbug)

اسم این باگ از آزمایش معروف گربه شرودینگر (Schrödinger) گرفته شده است. تصور کنید که برنامه‌ای دارید و این برنامه به خوبی دارد کار می‌کند. شما تصمیم می‌گیرید نگاهی به کد برنامه بیندازید. وقتی این کار را می‌کنید می‌بینید کد برنامه طوری است که قاعدتاً اصلاً نباید کار می‌کرده. از همان لحظه‌ای که این را می‌فهمید، برنامه از کار می‌افتد! در نهایت وقتی بلاخره کد را اصلاح کردید، برنامه دوباره شروع به کار می‌کند. به نظر غیرممکن می‌رسد، اما واقعیت این است که در عالم واقع چنین باگ‌هایی خیلی زیاد پیش می‌آیند.

ترجمه‌ای از:

How to Become the Sherlock Holmes of Bug Searching: Concentration on the Details By Andrew Smith @ DZone

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

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

گردآوری توسط ایده طلایی

دیدگاهتان را بنویسید