تیستن جامعه مهندسین تست نرم‌افزار ایران
نوشته های مرتبط
خلاصه: تست مداوم یا همان Continuous Testing حلقه‌های بازخورد را از طریق تست خودکار که در طول چرخه عمر توسعه رخ می‌دهند کوتاه می‌کند. تست و QA به عهده همه افرادیست که روی این نرم افزار کار می‌کنند، نه فقط تسترهای سیستم، که عرفا به آنها تستر گفته می‌شود. بیایید به برخی از اقدامات اثبات شده سازمان‌هایی که برای پی بردن به مزایای محسوس از تست مداوم استفاده کرده‌اند، نگاهی بیندازیم.
حدود پنج سال پیش، در حوزه QA برای یکی از شرکت‌های بزرگ خرده فروشی یا اصطلاحا Retail، مشغول به کار بودم(البته با پست مشاوری که باید ۱۰۰ ساعت در ماه حضور می‌داشت)، و یک تیم کوچک را هدایت می‌کردم. برنامه‌ای که ما روی آن کار می‌کردیم در وب و تلفن همراه در دسترس بود و ویژگی‌های جدید دائماً به آن اضافه می‌شدند. با وجود پوشش خوب QA، باگ‌هایی در تولید پیدا شد، که در این راستا تیم‌های امور مشتریان با شکایات مربوط به تحویل محصولات اشتباه، مشکلات حمل و نقل و ایضا چالش‌هایی در رابطه با دسترس پذیر بودن محصول، که به بخش فنی مهندسی، به ویژه QA منتقل شد، مواجه شدند.
Continuous Integration یا CI یا همان یکپارچه‌سازی مداوم در آن زمان تازه در اروپا و آمریکا محبوب شده بود و تیم مهندسی ما فرآیندی را برای توسعه دهندگان ایجاد کرد تا به طور مکرر کار خود را Integrate کنند. ایضا فرآیندهایی را برای همکاری نزدیک با توسعه دهندگان و نمایندگان کسب و کار، نوشتن تست‌های رفتار محور(Behavior-Driven) برای از بین بردن ابهام در User Storyها و در نظر گرفتن جنبه‌های تست Non-Functional اپلیکیشن مانند Performance و Security در اوایل پروژه، پیاده‌سازی کردیم.
Pipeline(اصطلاحی که در CI که به معنی مسیر حرکت برای تکمیل یک عملیات به صورت اتوماتیک و مکانیزه است. می‌توان برای تقریب ذهنی از عنوان فرآیند اتوماتیک برای آن استفاده نمود) ویژه استقرار(Deployment) ایجاد شد که مجموعه‌ای از تست‌های اولیه برای Validate یا تأیید اعتبار Build در آن اجرا می‌شد و اگر تست‌های Build Verification نیز پاس می‌شد، تست‌های پذیرش خودکار بیشتری برای بررسی عملکرد اصلی کسب و کار بر روی نسخه RC(یا Release Candidate یک نسخه از بین نسخه‌های مختلف است که از همه آنها Stableتر بوده، و مستعد استقرار است) انجام می‌شد. این تست‌های پذیرشِ خودکار، مبتنی بر رفتار بوده، و برای همکاری نزدیک با نیازهای کسب و کاری طراحی می‌شدند. و براساس سفر کاربر(یا User Journey، تجربیاتیست که کاربر در زمان کار و تعامل با محصول، آنرا کسب کرده است)، طراحی می‌گردید.
آزمون های پذیرش خودکار به عنوان یک مجموعه کوچک آغاز شد و حدود ۱۰ تست End To End در ماژول‌هایی مانند مدیریت کالا، انبار و حمل و نقل وجود داشت. این تست‌ها به نوعی کتاب مقدس مهندسین ما بود، زیرا روی هر نسخه RC اجرا می‌شد و بازخورد سریعی در مورد نحوه عملکرد اصلی کسب و کار ارائه می‌داد. با ادامه پیشرفت امکانات سیستم، اندازه مجموعه تست‌ها نیز افزایش می‌یافت و همچنین زمان اجرای مجموعۀ تستِ خودکارِ پذیرش نیز بیشتر می‌شد. تصمیم گرفتیم مجموعه را به دو قسمت تقسیم کنیم.
ما در مورد User Storyها برای قابلیت‌های جدید با نمایندگان کسب و کاری گفتگو کردیم، و به این ترتیب تست‌های مربوط به قابلیت‌های جدید به موازات توسعه، به صورت خودکار انجام شد. این داستان‌ها(User Storyها) به مجموعه تست خودکار پذیرش اضافه شدند و تست‌های قبلی که در آن مجموعه بودند به مجموعه تست رگرسیون Smoke ما منتقل شدند که اغلب با به روزرسانی برنامه اجرا می‌شدند.
اصطلاح “تست مداوم” در آن روزها معمول نبود، اما تیم‌ها اصرار داشتند که تمام امورات هر چه بیشتر خودکار شوند، و این تاکتیک به یکی از روش‌های توصیه شده تست مداوم تبدیل شد. من بعد از تعیین تکلیف خرده‌فروشی که به دنبال دیسیپلین و انضباط در تحویل مداوم بودم، روی بسیاری از پروژه‌ها کار کردم و تیم‌هایی را دیدم که تست‌های مداوم را به طور جدی انجام می‌دادند. من توانستم نقاطی را به برنامه خرده فروشی متصل کنم که مرا بیشتر درگیر این روند می‌کرد. اگرچه نمی‌توانم ادعا کنم که تمام جنبه‌های تست مداوم را به طور کامل در اختیار داشتم، اما روی تمام اصول کلیدی و اصلی تست مداوم که طی سال‌ها بنیان شده بود متمرکز بودم.
در این مقاله با توجه به تجربه کار در پروژه‌هایی با اندازه‌های مختلف از آن زمان، برخی از روش‌های اثبات شده را از سازمان‌هایی که برای درک مزایای محسوس از تست مداوم استفاده کرده‌اند را ذکر می‌کنم.
یک استراتژی تست مداوم ایجاد کنید
داشتن اهدافی که می‌خواهید از رویکرد تست مداوم خود به دست آورید، مهم است و این یک استراتژی تست را می‌طلبد.
من معتقدم برای ایجاد یک استراتژی تست در حوزه تست مداوم، چهار سوال اساسی را باید در نظر گرفته و پاسخ داد:
- آیا می‌توان تست‌های کافی را به صورت زودهنگام برای کاهش ریسک کسب و کاری ایجاد کرد؟
- آیا می‌توان تست را برای نمایش رفتار واقعی کاربر طراحی کرد؟
- آیا تسترها می‌توانند برای اطمینان از درک کامل نیازمندی‌ها(Requirement)، با کلیه ذینفعان در فرآیند تولید نرم‌افزار همکاری خوبی داشته باشند؟
- آیا اجزای دیگری برای اطمینان از تاثیر تست مداوم وجود دارد؟
دریافت پاسخ به این سوالات می‌تواند نقطه شروع خوبی برای تنظیم تست‌های مداوم باشد.
از تست‌های پذیرش خودکار استفاده کنید
تست‌های پذیرش خودکار یکی از مولفه‌های اساسی تست مداوم است. اینها تست‌هایی هستند که به تیم‌های مهندسی کمک می‌کنند رفتار کسب و کاری سیستم را درک نمایند. اجرای این تست‌های زودهنگام که غالباً برای شناسایی ریسک کسب و کاری انجام می‌شوند، هسته اصلی تست مداوم هستند. این تست‌ها برای بررسی هر خط کد طراحی نمی‌شوند، بلکه بیشتر بر رفتار کلی برنامه تحت تست تمرکز دارند.
به طور کلی، منابع Practical در مورد تست مداوم توصیه می‌کنند که توسعه دهندگان هنگام نوشتن تست یونیت، بر مبنای اصول “توسعه تست محور”(TDD) به پیش روند، و آنها را با تست‌های پذیرش خودکار تکمیل نمایند. لطفاً توجه داشته باشید که آنها برای نوشتن و مدیریت تست‌های پذیرش خودکار توصیه نمی‌کنند از تیم اختصاصی QA استفاده شود.
با این حال، بیشتر سازمان‌ها نمی‌توانند از این رویکرد پیروی کنند. به عنوان مثال، همان مدتی که من در آن مجموعه بودم، هم دارای نیروی توسعه و هم نیروی تست و QA بودیم، اما همه ما بر این اصل استوار بودیم که هرگز با آنها متفاوت رفتار نکنیم. همه ما “مهندس” بودیم. انتظار این بود که هر یک از اعضای تیم مهندسی باید به طور گسترده کارهایی را که هر شخص دیگری انجام می‌دهد درک کند و در صورت لزوم، باید بتواند به جزئیات آن بپردازد. این همان مفهوم Cross Functional در تیم‌های Agile است که بعدها منجر به بروز مفهومی به نام Full Stack شد(که البته در مورد آن تفسیرهای گوناگونی وجود دارد). در این رویکرد توسعه دهندگان، تسترها و تحلیلگران کسب و کار با هم همکاری می‌کنند تا در مورد Storyها بحث کرده و سپس آنها را تولید و تست کنند.
از طرف دیگر، من بخشی از پروژه‌هایی نیز بوده‌ام که اتوماسیون تست در آن انجام می‌شد، اما تست آنها مداوم نبود. مهندسان اتوماسیون با استفاده از ابزارهایی مانند سلنیوم، تست های اتوماتیک UI را می‌سازند، اما این تست‌ها رفتار محور نیستند. نارسایی‌هایی که کاربران در هنگام تولید پیدا می‌کردند، به سختی در این تست‌های UI خودکار یافت می‌شد، و اکثرا هم اصلا یافت نمی‌شد. تست‌های UI خودکار مزایای خود را دارند، و این مزایا قابل انکار نیست، اما این تست‌ها ویژه پذیرش(Acceptance) نیستند که بتوان از آنها برای بازخورد سریع روی ریسک‌های کسب و کاری بهره گرفت.
باید درک کنید که تست مداوم در انزوا عمل نمی‌کند
Pipeline استقرار یکی از عناصر اصلی تحویل مداوم(Continuous Deliver) است. به طور مشابه، یکپارچه‌سازی مداوم(Continuous Integration)، مدیریت پیکربندی(Configuration Management) و استقرار(Deployment) خودکار نیز از عناصر اصلی هستند. تست مداوم بدون آنها بی معنی خواهد بود.
من سازمان‌هایی را دیده‌ام که هیچ ستاپی برای یکپارچه‌سازی مداوم یا همان Continuous Integration نداشتند، اما ادعا می‌کردند که تست مداوم انجام می‌دهند. این تست هر چه که باشد، مداوم نیست.
همکاری را در اولویت قرار دهید
سرانجام، مطلبی کوتاه در مورد همکاری. به طور کلی در پروژه‌های Continuous Delivery، تحویل مداوم بیش از نوشتن کد، فعال بودن زیرساخت‌ها یا کیفیت خوب، متکی به همکاریست. Continuous Integration تماما در مورد تشویق همکاری بین توسعه دهندگان است، و DevOps تماما در مورد همکاری بین توسعه و بهره‌برداریست.
تحویل مداوم به بهترین وجه، زمانی تحقق می‌یابد که همه تیم‌ها در یک محیط جمعی و مشارکتی، با اطلاعات لازم از تیم‌های پایین دست و بالادست و با همکاری با کارشناسان مربوطه فعالیت کنند.
