تسترِ دارای ۱۰ مدرک که نمیتوانست یک باگ پیدا کند
شما تمام گواهینامهها را دارید. ISTQB، ScrumMaster، Cloud و Security. رزومهی شما دیواری از مخففهاست.
اما نمیتوانید حتی یک تست بنویسید که یک باگ واقعی را پیدا کند.
سه ماه پیش با کاندیدایی مصاحبه کردم. او فقط از تئوری حرف میزد. از V-model و shift-left صحبت میکرد. وقتی از او خواستم یکی از تستهایی را که نوشته و باعث پیدا شدن یک باگ شده نشان دهد، سکوت کرد.
او هرگز تستی ننوشته بود که چیزی را از کار بیندازد. او فقط تستهایی مینوشت که با موفقیت پاس میشدند.
گواهینامهها حافظهی شما را میسنجند. باگها طرز فکر شما را.
گواهینامهها واژگان و ساختار را در اختیار شما قرار میدهند. آنها به شما کمک میکنند تا از فیلتر استخدامکنندگان عبور کنید، اما به شما یاد نمیدهند که چگونه نقصها را پیدا کنید.
سوالات آزمون از یک سرفصل پیروی میکنند، اما اپلیکیشنهای واقعی اینطور نیستند. یک فرم ورود (login form) سرفصل ندارد؛ بلکه موارد خاص و عجیب (edge cases) دارد، مثل اختلاف چهار دقیقهای ساعت سرور یا مشکلات زمانی خاص.
تسترِ دارای مدرک، یک چکلیست را دنبال میکند. او تستها را بر اساس نیازمندیها مینویسد و آنها را به عنوان پاس یا فیل علامتگذاری میکند.
اما شکارچی باگ (bug hunter)، تست کردن را مثل یک تحقیق و تفحص میبیند. او با یک فرضیه شروع میکند و سعی میکند ثابت کند که اپلیکیشن اشتباه میکند.
به تفاوت در طرز فکر نگاه کنید.
یک تست استاندارد، مسیر خوشبینانه (happy path) را بررسی میکند:
- رفتن به بخش محصولات.
- افزودن به سبد خرید.
- وارد کردن جزئیات معتبر کارت.
- انتظار تایید سفارش.
این تست ثابت میکند که قابلیت مورد نظر زمانی که همه چیز عالی است، کار میکند. این تست هرگز یک باگ پیدا نخواهد کرد.
تستِ یک شکارچی باگ، مشکوک است:
- وارد کردن شماره کارت با یک غلط تایپی.
- انتظار پیام خطا.
- بررسی اینکه تایید سفارش با این حال نمایش داده نشود.
تست دوم فرض را بر این میگذارد که اپلیکیشن با شکست مواجه خواهد شد. این تست میپرسد: «اینجا کجا خراب میشود؟»
بسیاری از تسترها شکافی در تجربه دارند، نه شکافی در رزومهشان. شما دیدهاید که تستها به دلیل دادههای اشتباه یا از دسترس خارج شدن محیطها با شکست مواجه شوند، اما تستهایی را ندیدهاید که به دلیل پیدا کردن یک نقص در منطق (logic)، با شکست مواجه شوند.
مطالعه برای آزمونهای جدید را متوقف کنید. با نوشتن تستهایی که برای شکست خوردن طراحی شدهاند، این شکاف را پر کنید.
این تمرین را امتحان کنید: یک قابلیت را انتخاب کنید. یک ساعت وقت بگذارید و سعی کنید آن را از کار بیندازید.
برای یک قابلیت جستجو:
- تست کردن پرسوجوهای (queries) نامفهوم.
- تست کردن کاراکترهای SQL injection.
- تست کردن رشتههای خالی.
برای آپلود فایل:
- تست کردن فایلهای بدون پسوند.
- تست کردن فایلهایی با حجم بسیار زیاد.
- تست کردن نامهای فایل مخرب.
من زمانی روی یک سیستم پرداخت با ۹۵٪ پوشش تست (coverage) کار میکردم. تمام تستها با موفقیت پاس میشدند. سپس، سیستم در محیط عملیاتی (production) به دلیل یک خطای گرد کردن، پول از دست داد. تستهای ما مسیرهای اصلی (happy path) را پوشش میدادند، اما هیچکس به فکر تست کردن منطق ریاضی نبود.
حالا، من هر تست را با یک سوال شروع میکنم: «چه چیزی باید برقرار باشد تا این قابلیت بهصورت بیصدا (silently) با شکست مواجه شود؟»
سایت پورتفولیو نسازید. پروفایل لینکدین خود را بهروزرسانی نکنید.
یک تست بنویسید که هدفش شکست خوردن باشد. اگر پاس شد، یک تضمین ایمنی دارید. اگر شکست خورد، یک باگ پیدا کردهاید.
بنویسید چه چیزی را تست کردید، چگونه آن را تست کردید و چه چیزی پیدا کردید. این تنها مدرک واقعی است که نشان میدهد شما توانایی تفکر دارید.
این هفته چه تستی خواهید نوشت تا ثابت کنید میتوانید باگها را پیدا کنید؟
انجمن یادگیری اختیاری: https://t.me/GyaanSetuAi