تیستن جامعه مهندسین تست نرم‌افزار ایران
نوشته های مرتبط
چکیده: داده های تست یکی از تنگناهای مهم در فرآیندهای تست هستند. با ساده سازی داده های تست، می توانیم این تنگنا را بوسیله مقابله با چهار چالش عمده حل کنیم. در بسیاری از سازمان‌ها، هنگام تست، داده های تست را به عنوان یکی از تنگناهای اصلی در پیاده سازی Test Automation، Agile و CI/CD می بینیم.
زمان زیادی برای یافتن کیس های مناسب برای داده های تست هدر می شود، چندین تیم روی پایگاه های داده یکسانی کار می کنند(با عواقب احتمالی)، زمان زیادی برای ساختن کپی ها در اندازه کامل هدر می شود و همه اینها تلاش تست(Test Effort یا میزان کاری که برای تست باید انجام شود) را کند می کند. به ناراحتی ها و ناامیدهای ناشی از این کار اشاره نمی کنیم .اگر می خواهید بدانید چگونه می توانید تنگنای داده های تست را حل کنید، ادامه مطلب را بخوانید.
بازگشت به اصول اولیه
در اوج رقابت های فضایی در دهه ۱۹۶۰، دانشمندان ناسا متوجه شدند که خودکارها نمی توانند در فضا کار کنند. آنها باید راهی دیگر برای فضانوردان به منظور نوشتن پیدا کنند. بنابراین، آنها سالها و میلیونها دلار از مالیات دهندگان را صرف ساخت یک خودکار کردند، که بتواند جوهر را بدون وجود گرانش روی کاغذ بیاورد. اما پس از این داستان، همتایان حیله گر روس(شوروی سابق)، به سادگی مدادهای فضانوردان خود را به آنها تحویل دادند.
اگر از این منظر به داده های تست نگاه کنیم، چه می شود؟ به اصول اولیه برگردید و برای ساده سازی تلاش کنید! ما باید یک راه حل ساده در دنیای پیچیده داده های تست ایجاد کنیم. چگونه می توان داده های تست را به آسانی در دسترس قرار داد؟ چگونه می توان آن را به راحتی به روز رسانی کرد؟ چگونه می توانید آن را در هر زمان و هر کجا که می خواهید یا به آن نیاز دارید در دسترس قرار دهید؟ تصور کنید اگر ما برای این سوالات پاسخ داشته باشیم، دنیای تست شما چه قدر بهترخواهد بود.
بیایید با دلایلی که چرا داده های تست به آسانی در دسترس هستند و در دسترس نیستند شروع کنیم. اگر برای لحظه ای تمرکز کنیم، اساسا چهار چالش عمده را مشاهده می کنیم که باعث ایجاد تنگنا می شود.
- زمان
- افراد
- اندازه
- پول
۱- زمان
اگر نگاه دقیق تری به این موضوع بیندازید که چرا بروز رسانی اطلاعات داده ها اینقدر زمان بر است، متوجه می شوید که این امر تا حدی فنی و تا حدی رویه ای است. تحقیقات به ما نشان می دهد که دریافت داده های تست مناسب می تواند تا پنج روز کاری طول بکشد. ما با سازمان هایی روبه رو شده ایم که این کار برایشان هفته ها طول می کشد! پیدا کردن دلایل این مدت طولانی انتظار، جالب است.
در سطح فنی، موضوع تهیه نسخه پشتیبان و بازگرداندن آن به QA یا سایر محیط های غیر بهره برداری(non-production) زمان بر است. این موضوع از دقیقه، تا ساعت، تا روز متفاوت است، بدیهی است که چنین امری به اندازه پایگاه داده بستگی دارد و هر چه پایگاه داده بزرگتر باشد، زمان بیشتری طول خواهد کشید. اما بعد فنی این رویه ها، شامل پشتیبان گیری و بازیابی بعید است بیش از دو روز طول بکشد. چرا ؟ زیرا وقت معمول برای انجام این کار، آخر هفته است.
بنابراین حداقل ۶۰ درصد از زمان ما، قبل از(یا گاهی بعد از) اجرای فنی بر روی رویه ها هدر می رود. یکی از مسائل مهم در این رویه ها این واقعیت است که تیم های تست نرم افزار در هیچ جائی برای نزدیک شدن به عملکردهای کپی/پشتیبان گیری و بازیابی مجاز نیستند. این منحصرا در حوزه عملکرد DBA (Data Base Administrator) است. بنابراین، تیم های کیفیت نرم افزار به طور مستقیم به سایرتیم های سازمان وابسته هستند.
مسئولیت یک درخواست
فرایندی که باید به عنوان یک مهندس طی کنید احتمالا شبیه موارد زیر است:
- شما از مدیر آزمون یا مدیر پروژه خود برخی از داده های تست را به صورت حضوری( در دوران پیش از کرونا) یا از طریق ایمیل درخواست می کنید، که امیدوارید بدون تاخیر بیش تر به توافق برسید.
- در صورت چالش، احتمالا از شما سوالاتی در مورد نیاز به داده های آزمون می پرسند: آیا محیط شماره ۱ ، ۲ یا ۳ در دسترس نیست و متناسب با نیازهای شما نیست؟ دلیل اینکه آنها این سوالات را می پرسند این است که این اولین سوالاتیست که توسط تیم DBA از خود آنها پرسیده می شود.
کمک به تیم های تست با داده های تست، یا به عبارت دیگر کپی کردن داده ها از Production(بهره برداری) به QA بخش اصلی کار DBA نیست. وی علاوه بر مدیریت در دسترس بودن و عملکرد محیط های بهره برداری و عملیاتی، مسئولیت برنامه ریزی ظرفیت(Capacity Planning)، نصب، پیکربندی، طراحی پایگاه داده، مهاجرت(Migration)، نظارت بر Performance، امنیت، عیب یابی و غیره را نیز بر عهده دارد. DBA ها دائما موارد عقب افتاده خود را اولویت بندی و بررسی می کنند و ایجاد یا به روز رسانی پایگاه داده QA جدید احتمالا اولین اولویت کاری آنها نیست. در نتیجه ممکن است مدتی طول بکشد تا پایگاه داده تستی خود را دریافت کنید.
مختل کردن کار DBA
آیا از درخواست پایگاه داده تستی می ترسیم؟ اگر این چنین است، چرا؟ زیرا می دانیم که داریم DBA خود را با وظیفه ای که مانع از انجام آنچه او باید انجام دهد، مختل می کنیم. آنها با رضایت از جایگاه خود خارج نمی شوند زیرا تیم تست، درخواست یک کپی از Production را داشته است. از سوی دیگر، DBA می خواهد این فرایند را کنترل کند. آنها به شما اجازه نمی دهند خودتان این کار را انجام دهید، چرا که آنها مسئول این کار هستند. اما چطور ممکن است که کار DBA را مختل نکنیم؟
حذف یا خودکارسازی این فرآیندها باعث صرفه جویی در مقدار زیادی از زمان انتظار می‌شود. پایگاه داده ها را می توان با راه اندازی سیستمی که DB را به طور خودکار در محیط(های) پایین تر(پایین دستی) پر می کند، به راحتی به روزرسانی کرد. این فرآیند را می توان با گفتگو و توسعه راهکار با تیم DBA به دست آورد. اگر این رویه ها را حذف کنید بسیاری از مشکلات حل می شوند. می توانید تست های اتوماتیک خود را شروع کنید یا با داده های به روزرسانی شده تست Manual را آغاز نمایید.
۲- افراد
اکنون شما پایگاه داده تستی خود را دارید و برخی از تست ها را اجرا می کنید. اما مجبور می شوید با یک تیم تست دیگر تماس بگیرید و این موضوع را بپرسید که:” بچه ها شما با #*$$@ چکار دارید؟! فقط همه Test Caseهای من رو خراب کردین!” این بخش دیگری از تنگنای داده های تست است؛ یعنی افراد. البته خود افراد(در بیشتر موارد) مشکل نیستند، اما وفق دادن و جای دادن چندین تیم یا فرد در پایگاه داده های تستی یکسان مشکل است. آنها ممکن است داده های مورد نیاز یکدیگر را تخریب کنند.
۳- اندازه
البته این چالش بیشتر ناشی از اندازه ذخیره اطلاعات است. صادق باشیم؛ پایگاه داده ها اغلب به طور منظم پشتیبان گیری می شوند. این یک ضرورت در پشتیبانی از تداوم کسب و کار است. چالش اندازه، دو برابر است. اول از همه تعداد بایت‌هاییست که باید از Backup به این DB در محیط پایین دستی منتقل شود که البته این موضوع در تلاقی با سرعت و پهنای باند I/O زیرسیستمیست که این کار را انجام می‌دهد. دومین موضوع که از نظر اندازه وجود دارد، فضاست. فضای ذخیره سازی مورد نیاز برای نگهداری معمولا، برای سه تا پنج کپی از فضای Production(در اندازه کامل) است. برای کسب فضا، بودجه درخواست کنید.
کپی‌های Production
زمان یک دارایی ارزشمند در توسعه نرم افزار است. بسیاری از سازمان ها سعی می کنند محیطی ایجاد کنند که در آن به روزرسانی برنامه های نرم افزاری هر روز و گاهی چندین بار در طول روز ارائه شود. به همین دلیل ما سعی می کنیم Agile، CI/CD و Test Automation را پیاده سازی کنیم. ما نه تنها در تلاش هستیم تا در وقت خود صرفه جویی کنیم بلکه می‌خواهیم در پیشرفت هایی که ارائه می دهیم به سطح بالاتری از کیفیت و ارزش افزوده برای کسب وکار دست پیدا کنیم.
به دلیل مسائل مربوط به اندازه وزمان، مهندسین تست این سوال را می پرسند که “آیا واقعا به یک نسخه(کپی) کامل از Production نیاز داریم؟” در برخی موارد، پاسخ این سوال ” خیر! ” است. آنچه ما معمولا می بینیم این است که آنها خودشان شروع به تولید داده های تست می کنند. چرا؟ زیرا با این داده های تولید شده آنها درک می کنند که می توانند سریعتر شروع کنند. این یک موضوع قابل درک، اما کمی ساده لوحانه است.
تولید داده های تست مصنوعی از ابتدا یک ریسک است زیرا واقعا حاکی از محیط Production نیست. دسترسی به داده‌های تست که واقعا مبین داده های Production باشد، برای پروژه ها بسیار ارزشمند است. ما باید نا هماهنگی های داده موجود در Production و همچنین در Test Caseها را نیز در نظر بگیریم.
پوشش داده های تست
روش ها و تکنیک های متعددی در استقرار داده های تست وجود دارد:
- یک کپی از Production ( قبلا در مورد آن بحث شده اما به منظور ذکر همه روش ها ، اجازه دهید آن را بیان کنیم)
- داده های ماسک شده: داده‌های ماسک شده همان داده‌هایی هستند، که به منظور حفظ محرمانگی اطلاعات، محتوای آنها تغییر کرده است، اما فرمت آنها ثابت مانده. مثلا اگر رقم یک سپرده بانکی را برابر با ۱٫۰۰۰٫۰۰۰٫۰۰۰ ریال در نظر بگیرید، می‌تواند پس از ماسک به رقم ۲٫۵۰۰٫۰۰۰ ریال تغییر کند. این داده فرمت خود را حفظ کرده است، اما محتوای آن تغییر کرده.
- داده های زیر مجموعه(Subsetted Test data که به معنی استخراج یک زیر مجموعه از داده‌ها از یک DB و انتقال آن به DB دیگر است) و ماسک شده.
- داده های مصنوعی تولید شده: داده‌های ایجاد شده به صورت دستی
- داده های تولید شده توسط هوش مصنوعی
در این تکنیک‌ها اگر نگاهی به این موضوع بیندازید که چه پوششی روی Test Dataها می‌تواند ایجاد شود، به یک مدل بالغ مانند این می رسید.
همانطور که می بینیم همه داده های تست به غیر از داده های Production کمی پوشش تست را از دست می دهند. شما می توانید داده های ماسک شده داشته باشید اما اندکی از نمایش داده ها را از دست می دهید. بدیهیست که داده های مصنوعی و داده های هوش مصنوعی بدترین مجموعه داده های تست هستند. این داده ها طبق آنچه که ما تا به حال دیده ایم در یک پروژه واقعی بی فایده هستند. شما در این مورد که این داده‌ها حاوی چه اطلاعاتی شوند، هیچ ایده ای ندارید. بنابراین چگونه تست خود را انجام می دهید؟
از منظر ریسک در کسب و کار، کار با معمولترین داده های تست، مترادف با ارزشمندترین روش است. بنابراین کار با داده‌های Production یا زیر مجموعه داده های Production، چه ماسک شده و چه ماسک نشده، احتمالا بهترین کاریست که می توانید انجام دهید. بنابراین برای حل این قسمت از تنگنا، شروع به ایجاد زیرمجموعه های پایگاه داده(Data Base Subset) می کنیم. این باعث استقرار سریعتر، صرفه جویی قابل توجه در زمان و رسیدگی به مسائل مربوط به اندازه و فضا می شود.
۴- پول
با کاهش حجم داده های تست، ما به طور خودکار شروع به حل آخرین قسمت تنگنای داده های تست می کنیم: پول. این دو پیوند ناگسستنی با یکدیگر دارند. تهیه نسخه های کپی از پایگاه داده صرف نظر از اینکه در فضای پیش فرض یا در فضای ابری مستقر شده ایم، به ازای هر مگابایت/گیگابایت هزینه دارد. مجددا نکته ای را که قبلا بیان شد به خاطر بسپارید که ما اغلب سه تا پنج نسخه کپی از پایگاه داده های Production را در محیط های پائینتر می بینیم. دستورالعمل اصلی این است که در چهارچوب بودجه کارکنیم و رویکرد هوشمندانه، حداکثر استفاده از منابع بودجه ای می‌باشد که به ما ارائه شده است.
نتیجه
با مقابله با چهار چالش(زمان، افراد، اندازه و پول)، ما تنگنای داده های تست را حل می کنیم. بله، ما می توانیم نسخه هایی ازپایگاه داده را برای هرتیم داشته باشیم؛ البته آنها کوچکتر هستند. ما می توانیم به سمت استقرار این پایگاه های داده به صورت خودکار حرکت کرده و کارتراشی برای DBA را از بین ببریم. ما می توانیم زمان هدر رفته مربوط به بروز رسانی محیط را کاهش دهیم. ما فشار بروز رسانی را در تیم ها کاهش می دهیم. ما می توانیم از بودجه خود حداکثر استفاده را ببریم.
