تیستن جامعه مهندسین تست نرم‌افزار ایران
نوشته های مرتبط
این مقاله ترجمه‌ای از مقاله A Context-Driven Approach to Automation in Testing نوشته جیمز باخ(James Bach) و مایکل بولتون(Michael Bolton) است که دو تن از بزرگان و مشهورترین افراد در حوزه تست نرم‌افزار دنیا هستند. این مقاله در فوریه ۲۰۱۶ به رشته تحریر در آمده است.
مقاله پیش رو نسبتا طولانیست که احتمالا طی ۷ تا ۱۰ پست منتشر خواهد شد.
ترجمه این مقاله توسط سرکار خانم مهندس اعظم موسویان آماده شده است.
خلاصه: راه‌های شگفت انگیز بسیاری وجود دارند که می‌توان از ابزارها برای کمک به تست نرم‌افزار استفاده کرد. در حال حاضر از ابزارها استفاده مناسبی نمی‌شود که این موضوع سردرگمی و مشکلات بسیاری را به آنچه در حال حاضر یک مشکل سخت است، اضافه می‌کند. چرا اینطور است؟ چه کاری می‌توان انجام داد؟ ما فکر می‌کنیم که مشکل اساسی، نگرش سطحی به استفاده از ابزار است. و این مشکل با یک باور همه گیر و غلط درباره تست، که تست را یک فرآیند تکراری و مکانیکی می‌داند تشدید شده است. یک تست خوب مانند برنامه‌نویسی، یک فرآیند فکری و چالشی است. بنابراین تست کردن باید به دست افرادی سپرده شود که پیچیدگی‌های ابزارها و تست‌ها را متوجه می‌شوند. این موضوع در مورد توسعه نرم‌افزار و برنامه‌نویسی و در واقع برای هر شغل و مهارتی از نجاری تا داروسازی صدق می کند.
فهرست عناوین:
ربات‌ها! کمک!
مشکل ما در مواجه با خودکارسازی(Automation)
اول: آنها را ابزار بنامید[نه خودکارسازی تست (Test Automation)]
دوم: به تست بسیار بیشتر از چک کردن خروجی(Output Checking) فکر کنید
- تفاوت بین تست کردن و چک کردن
- چک کردن مهم است
سوم: روش‌های بسیاری برای استفاده از ابزارها کشف کنید!
- اجازه دهید متن شما، ابزارتان را هدایت کند
- به طور مشخص چطور متن، ابزار را هدایت می‌کند؟
- روی ابزارهایی سرمایه‌گذاری کنید که آزادی‌های بیشتری در موقعیت‌های مختلف به شما بدهند
- روی تست‌پذیر بودن سرمایه‌گذاری کنید
اجازه دهید در عمل با ابزارهای پشتیبانی کننده تست آشنا شویم!
- مورد اول: ابزار بدون چک کردن استفاده می‌شود
- مورد دوم: استفاده از ابزار پشتیبانی همراه با تولید داده‌های الگو، برای یک Oracle[پیشبینی کننده نتیجه تست] قدرتمند و پوشش بهتر
- مورد سوم: چک کردن خودکار
- چرا خودکارسازی فعالیت‌هایی که از طریق واسط گرافیکی کاربر(GUI) انجام می‌شود بسیار سخت است؟
خودکارسازی فعالیت‌ها یک تاکتیک است و نباید یک کار تکراری و روزمره باشد
مشکل ما در مواجه با خودکارسازی (Automation)
مشکل با “خودکارسازی تست” با خود کلمات آن شروع می‌شود. تست کردن بخشی از یک کار خلاقانه و انتقادی است که در هنگام طراحی اتفاق می‌افتد اما کلمه “خودکارسازی” باعث می‌شود تا ذهن مردم به سمت کارهای مکانیکی خط مونتاژ کارخانه‌ها هدایت شود.
بعلاوه عبارت “خودکارسازی تست” مبهم نیز هست. حتما تا به حال جمله‌ای شبیه به “تست خودکارسازی شده را اجرا کنید” را شنیده‌اید. که به طور خاص به ابزارها مربوط می‌شود. جمله‌ای مانند “خودکارسازی تست ارزش انجام دادن را دارد”، نه تنها به ابزارها بلکه به مجموع فعالیت‌های تولید، نگهداشت(Maintenance)، تست و بهره‌برداری(Operation) آن ابزارها نیز مربوط می‌شود. در برداشت اول، خودکارسازی تست فعالیتیست که به هیچ وجه توسط انسان انجام نمی‌شود و از آنجایی که شما هیچ مبلغی به کامپیوتر پرداخت نمی‌کنید، فوق العاده سریع و ارزان به نظر می‌آید. در برداشت دوم، خودکارسازی تست، یک فعالیت ماهرانه است و توسط کسانی انجام می‌شود که ساعت‌ها، روزها و هفته‌ها برای توسعه نرم‌افزارها وقت صرف می‌کنند و به این افراد بابت وقتی که می‌گذارند باید حقوق پرداخت شود.
ما می‌بینیم که به طور معمول، تکنیک انجام “خودکارسازی تست”، همان اسکریپت‌نویسی عادی است. به این صورت که فعالیت‌های یک کاربرِ محصول را تکرار می‌کنید و از دستگاه‌ها برای فشردن کلیدها با سرعت خیره کننده کمک می‌گیرید و سپس چک می‌کنید که آیا ورودی‌ها و فعالیت‌های انجام شده باعث تولید خروجی‌های مورد انتظار شده اند یا خیر؟ این تعریف، یک گام کوچک برای شروع تفکر درباره عبارت “خودکارسازی تست” به عنوان یک تستر می‌باشد. اما حتی تسترهای غیر ماهر که بیش از حد به صورت کورکورانه به اقدامات تجویزی پایبند هستند، چیزی بیش از خروجی چند Function مشاهده می‌کنند. انسان‌ها زندگی، برنامه‌ها، استعدادها، ایده‌ها و مشکلات پیچیده‌ای دارند. اگر چه بعضی از فعالیت‌های کاربر و تستر امکان شبیه‌سازی دارند، اما نمی‌توان خود کاربران و تسترها را در نرم‌افزارها تکرار کرد. عدم درک این حقیقت ساده، تست را دچار مشکل می‌کند و باعث می‌شود که بسیاری از خطاها از دید ما پنهان بمانند.
چگونه می توانیم در مورد همه این موارد واضح‌تر فکر کنیم؟
قدم اول: آنها را ابزار بنامید(نه “خودکارسازی تست“)
ما ابزار را به عنوان یک اختراع انسانی تعریف می‌کنیم که به تکمیل شدن اهداف انسانی کمک می‌کند. همچنین یک ابزار تست می‌تواند یک سخت‌افزار، نرم‌افزار، نقشه، سند یا یک محصول مصنوعی باشد که به پیشبرد اهداف تست کمک می‌کند. ما در این مقاله در درجه اول، ابزارهای تست نرم‌افزار را بررسی می‌کنیم.
اصطلاح “ابزار تست” این درک روزمره و عادی را به ما یادآوری می‌کند که این اختراعات بدون هدایت انسان قادر به کارکردن نیستند. این ابزارها توانایی‌های انسان‌های ماهر را گسترش می‌دهند و می‌توانند باعث سبک‌تر شدن مسیولیت و افزایش قدرت تسترها شوند.
همچنین عبارت “خودکارسازی تست” می‌تواند یک تهدید برای بیکار شدن تسترها باشد. برای اینکه دلیل آن را بدانید در ابتدا باید درک کنید که تست کردن چیست؟ تست کردن به معنی پیدا کردن وضعیت واقعی محصول است، که در محصولات پیچیده از دید کاربر پنهان است. تسترها تست می‌کنند تا مشکلات را پیدا کنند. یک تستر با منابع محدود کار می‌کند و باید مشکلات را قبل از اینکه دیر شود کشف کند. این امر نیازمند توجه دقیق به سرنخ‌های ظریف در رفتار محصول است که در فرآیند یادگیری سریع و مداوم به دست می‌آید. تسترها درگیر کارهایی مثل معنی کردن، تفکر انتقادی و آزمایش محصول می‌شوند، کارهایی که هیچ کدام به وسیله ابزارهای مکانیکی قابل انجام نیست. با این حال، در تجربه طولانی مدتی که ما در بازدید از صدها شرکت و تیم به دست آورده‌ایم، مدیران و متحصصانی را دیده‌ایم که از تست روتین و روزانه‌ای که این فرآیندهای فکری را نادیده می‌گیرد، صحبت می‌کنند. ما سعی کردیم به آنها یادآوری کنیم که این موارد حیاتی را نمی‌توان داخل تست نرم‌افزار یا Test Case کدگذاری کرد و آنها شاید بگویند: “بله، ما هم با شما موافقیم”، اما سریع به صحبت‌های قبلی خودشان بر می‌گردند و تاکید می‌کنند که “خودکارسازی تست”، اساس و ذات تست کردن است. و ما در نهایت پس از سال‌ها بحث و مجادله متوجه شدیم که این عبارت نوعی افیون و مخدر است.
نرم‌افزار کامپیوتر به طور دقیق از الگوهای کدگذاری شده صریح تشکیل شده است و هیچ الگوی مهم و ارزشمند رفتاری اتفاق نمی‌افتد مگر اینکه در کد گنجانده شده باشد. این مطلب واضح است، اما چیزی که واضح نیست این است که مقدار زیادی از دانش یک تستر، دانش ضمنی است.(توجه داشته باشید که دانش صریح، دانشی است که می‌تواند توسط کامپیوتر کدگذاری شود و دانش ضمنی، دانشیست که قابل نمایش و کدگذاری نیست.)
هنگامی که یک تستر با یک محصول شروع به کار می‌کند، به طور خود به خود به وقایع عجیب و نادرست واکنش نشان می‌دهد بدون اینکه در مورد آنها آگاه باشد. به عنوان مثال اگر یک پنجره برای یک لحظه بنفش شود و تغییر رنگ بدهد یا یک خط اضافی ظاهر شود یا یک فرآیند برای تکمیل مقداری بیشتر از ۱۰ واحد زمانی به خود اختصتص دهد، تستر در این مواقع تقریبا بدون هیچ تلاشی متوجه می‌شود و واکنش نشان می‌دهد. اما هنگامی که این تستر بخواهد این موارد را شرح دهد و آنها را با نوشتن مراحل و نتایج مورد انتظار مکتوب کند، تنها بخش کوچکی از همه انتظارات واقعی بیان می‌شوند. هیچ تستری فعالیت‌های غیر منتظره را کدگذاری نمی‌کند. اگر نتوان تستی که یک شخص انجام می‌دهد را مکتوب کرد پس نمی‌توان آن را کدگذاری کرد و اگر نتوان تست را کدگذاری کرد پس نمی‌توان آن را خودکار کرد. بنابراین ما نباید از عبارتی استفاده کنیم که این معنی را برساند.
همه می‌دانند که برنامه‌نویسی قابل خودکارسازی نیست. اگرچه بسیاری از زبان‌های برنامه نویسی قدیم “Autocodes” نامگذاری شده بودند و همچنین بسیاری از کامپایلرهای قدیمی “Autocoders” نامیده می‌شدند. این روش نامگذاری تقریبا در سال ۱۹۶۵ در اوج بود. اما بعدها واژه کامپایلر محبوبتر شد. به عبارت دیگر زمانی که کدنویسی در نرم‌افزار شروه شد، آنها نام این عمل را به کامپایل کردن، اسمبل کردن یا تفسیر کردن(Interpreting)، تغییر دادند. بنابراین برنامه‌نویس همیشه بوجود آورنده تمام تکنولوژی‌هاست و هیچ مدیری هیچگاه این جمله را نمی گوید که “چه زمانی ما می‌توانیم برنامه‌نویسی را خودکار کنیم؟”
برای تولید محصولات و خدمات با کیفیت بالا، ما به افراد ماهری نیاز داریم که از ابزارهای مناسب برای پیشبرد اهداف تست استفاده می‌کنند. استفاده از عبارات “تسترهای دستی(Manual Testers)” یا “تسترهای خودکار(Automated Testers)” برای تفاوت قایل شدن بین تسترها گمراه کننده است، چون همه تسترهای خوب و ماهر از ابزار استفاده می‌کنند. برنامه‌نویس‌ها و محقق‌ها هم از ابزار استفاده می‌کنند اما هیچکس از عبارات “برنامه‌نویسی خودکار” یا “تحقیق خودکار” استفاده نمی‌کند. مدیری که خواستار خودکارسازی تست است هیچ وقت دوست ندارد مدیریت خودش را هم خودکار کند. تنها دلیلی که باعث می‌شود تا افراد به خودکارسازی تست فکر کنند این است که آنها باور دارند تست به هیچ مهارت و قضاوتی احتیاج ندارد.
از آنجایی که همه تسترها از ابزار استفاده می‌کنند ما یک تمایز جالبتر را مطرح می‌کنیم و آن این است که بعضی از تسترها ابزار تولید می‌کنند(کد می‌نویسند و ابزارهایی که به تست کمک می‌کند را تولید می‌کنند). پیشنهاد ما این است که اینگونه تسترهای فنی را “Toolsmiths” بنامیم. اگرچه Toolsmithsها و ابزارهایشان باعث گسترده کردن و سرعت دادن به بعضی فعالیت‌ها در حین تست می‌شوند، اما آنها خودشان خودکارسازی تست را انجام نمی‌دهند. بنابراین از این نقطه به بعد ما سعی می‌کنیم از عبارت “خودکارسازی تست” استفاده نکنیم.
