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