فناوری اطلاعات همچنان میتواند بدون دسترسی به کد منبع اصلی آزمایش کند. از تست پذیرش چابک استفاده کنید، به منطق تجاری بپردازید، و پلتفرمهای آزمایشی را با یادگیری ماشینی بپذیرید.
مهندسین اتوماسیون تضمین کیفیت، برنامههای توسعهیافته داخلی را آزمایش میکنند، از یکپارچههای قدیمی گرفته تا برنامههای بومی ابری که از میکروسرویسها استفاده میکنند. یک برنامه کاربردی معمولی برای ماموریت حیاتی نیاز به ترکیبی از تست واحد در سطح کد، بررسی کد، تستهای API، تست تجربه کاربر خودکار، تست امنیتی و تست عملکرد دارد. بهترین روش توسعه این است که اجرای این آزمایشها را خودکار کنید و سپس یک زیرمجموعه بهینه برای تست مداوم در خطوط لوله CI/CD (ادغام پیوسته و تحویل مداوم) انتخاب کنید.
اما در مورد برنامهها، گردشهای کاری، ادغامها، تجسم دادهها و تجربیات کاربر که با استفاده از پلتفرمهای SaaS (نرمافزار بهعنوان سرویس)، ابزارهای توسعهی کمکد یا پلتفرمهای بدون کد پیکربندی شدهاند، چه میشود؟ که توسعه دهندگان شهروندی را توانمند می کند؟ صرفاً به دلیل اینکه کدنویسی کمتر یا اصلاً مورد استفاده قرار نمیگیرد، آیا این به طور خودکار به این معنی است که گردشهای کاری طبق نیاز عمل میکنند، پردازش دادهها الزامات تجاری را برآورده میکند، پیکربندیهای امنیتی با خطمشیهای شرکت مطابقت دارد، و عملکرد مطابق انتظارات کاربر است؟
این سوال مرا به یاد چیزی می اندازد که معلم حساب دیفرانسیل و انتگرال دبیرستانم به ما یاد داده است. او میگفت: «اگر فرض میکنی، پس از من و تو یک الاغ درست میکنی». در موارد SaaS، کمکد و بدون کد، با فرض اینکه برنامه بدون برنامه آزمایشی طبق نیاز عمل کند، میتواند منجر به مشکلات زیادی شود:
- ذینفعان آزرده از نتایج غیرمنتظره ناامید شده اند
- حفرههای امنیتی که دادهها را در معرض دید عموم یا کارمندانی قرار میدهد که نباید دسترسی داشته باشند
- مشکلات دادهای که ممکن است به سایر گردشهای کاری یکپارچه و تجربیات مشتری منتشر شود
- مشکلات عملکرد زمانی که برنامه به تعداد زیادی از کاربران و مجموعههای داده بزرگتر میرسد
- تیمهای فناوری اطلاعات ناامید برای بازسازی برنامهها یا توسعه راه حلهای کاری فراخوانده شدند
بنابراین، چه چیزی باید آزمایش شود؟ چگونه می توان این برنامه ها را بدون دسترسی به کد منبع اصلی آزمایش کرد؟ IT کجا باید تست را در اولویت قرار دهد، به ویژه با توجه به اینکه بسیاری از سازمانهای devops در مهندسین QA کم کار هستند؟
من با چندین متخصص صحبت کردم تا به من کمک کنند تا برخی از پاسخ ها را پیدا کنم.
با تعریف و اجرای تست پذیرش چابک شروع کنید
جان کودومال، مدیر ارشد فناوری و یکی از بنیانگذاران LaunchDarkly، در IT به ما یادآوری می کند که آزمون پذیرش باید برای همه برنامه های کاربردی پشتیبانی شده اعمال شود. IT، نه فقط آنهایی که نیاز به توسعه نرم افزار دارند. او میگوید: «در یک مدل سنتی SaaS، تیم توسعهدهنده آزمایش پذیرش را به عنوان بخشی از روند آزمایش انتشار عادی انجام میدهد.»
تعریف تستهای پذیرش کسبوکار و کاربر محل مهمی برای شروع است زیرا اکثر برنامههای SaaS، کمکد و بدون کد نیاز به پیکربندی دارند و پیادهسازی میتواند از scrum یا روشهای چابک دیگری پیروی کند. رشتههای چابک شامل شرایط نوشتن بهعنوان داستانهای کاربر با معیارهای پذیرش قبولی یا عدم موفقیت است. یک تیم چابک باید داستان یک کاربر چابک را مانند یک قرارداد عملکردی کوچک از تجارت و الزامات غیر کاربردی مدیریت کند.
تعریف معیارهای پذیرش اولین قدم مهم است و باید حتی برای برنامههای SaaS که نیازی به کدنویسی یا پیکربندی محدودی ندارند، دنبال شود.
اما فرض کنید IT مسئولیت تعریف معیارهای پذیرش و خودکارسازی این آزمون ها را بر عهده نمی گیرد. در این موارد، عدم انجام آزمایش خطراتی را ایجاد می کند یا تیم های تجاری وظیفه آزمایش را بر عهده می گیرند. هیچ کدام از اینها بهینه نیست. فناوری اطلاعات باید بخش مسئول رهبری پیادهسازی، از جمله عملکردهای آزمایشی باشد.
کد کم و بدون کد نیاز به آزمایش منطق تجاری دارند
پلتفرمهای کمکد و بدون کد یک لایه انتزاعی ارائه می دهد و توسعه، پشتیبانی و بهبود برنامه ها را ساده می کند. اما هنگام استفاده از این پلتفرمها، همچنان در حال کدنویسی منطق کسبوکار، پیکربندی یک گردش کار، تعریف قوانین پردازش دادهها و انتخاب نقشهای دسترسی هستید. پلتفرم سادهسازی را انجام میدهد، اما همچنان این خطر وجود دارد که توسعهدهنده منطق را به درستی پیادهسازی کند یا به طور کامل نمیداند که چگونه الزامات پلتفرم کمکد یا بدون کد را به طور دقیق انجام دهد.
Kodumal اضافه می کند که آزمایش دو مسئولیت اضافی اضافه می کند. آزمایش یک راهحل کمکد بر آزمایش دو چیز متفاوت متمرکز است: آزمایش منطق تجاری که کاربر کمکد بیان میکند و آزمایش اینکه ساختاری که از راهحل کمکد پشتیبانی میکند به درستی کار میکند. این دو نوع تست اطمینان حاصل میکنند که برنامه بهگونهای کار میکند که کاربران نهایی انتظار دارند کار کند.”
میتوانید منطق کسبوکار را با ابزارهایی آزمایش کنید که تعاملات کاربر را از طریق مرورگر ثبت میکنند و آزمایش این جریانها را خودکار میکنند. آزمایش ساختار زیربنایی ممکن است نیاز به بررسی مدلهای داده، مجوزها، فرمها، گزارشها و اتوماسیونها داشته باشد تا اطمینان حاصل شود که استانداردها را برآورده میکنند و خطرات را ایجاد نمیکنند.
اندرو کلارک، مدیر ارشد فناوری Monitaur، پیشنهاد می کند که تست اتوماسیون باید بر روی گردش کار و نحوه پشتیبانی برنامه تمرکز کند. یک فرآیند تجاری او میگوید: «یک راه خوب برای آزمایش SaaS و برنامههای کمکد، انجام اعتبارسنجی اولیه ورودی و خروجی است. شما باید ماتریسی از رویدادها/عملکردهای کلیدی ایجاد کنید که انتظار داریم سیستم انجام دهد و موارد آزمایشی را تنظیم کنید تا تأیید کنید که سیستم مطابق انتظار عمل می کند.”
روزاریا سیلیپو، رئیس تبشیر علم داده در KNIME این را یک قدم جلوتر میبرد و پیشنهاد میکند که بدون کد و برنامه های کم کد باید از استانداردهای آزمایشی مشابه پیروی کنند. او میگوید: «یک برنامه کمکد باید مجموعه آزمایشی خود را داشته باشد، که باید دقیقاً همان دستورالعملهای برنامههای مبتنی بر کد را دنبال کند: واحدهای آزمایشی، جداول طلایی، خروجی زیبا و غیره. ساختن یک وب سرویس بدون کد خرابی در پاسخ یا یک برنامه وب بدون خروجی دلپذیر در صورت بروز خطا، دقیقاً مانند یک برنامه مبتنی بر کد، غیرحرفه ای است.”
از پلتفرمهای تست کمکد و یادگیری ماشین استفاده کنید
اگرچه توسعه با کد کم و بدون کد اغلب فرآیند توسعه را تسریع میکند و پیشرفتهای آسانتری را امکانپذیر میکند، تیمهای devops همچنان باید آزمایش و بررسی پیکربندی را انجام دهند.
خبر خوب این است که مهندسان QA میتوانند آزمایشهایی را با پلتفرمهای تست با کد پایین توسعه دهند. Ram Shanmugam، مدیر عامل AutonomIQ، یک شرکت Sauce Labs، میگوید: «با تستهای کمکد، شما از پیشرفتهترین آزمایشها استفاده میکنید. تکنیک های هوش مصنوعی و ML، بنابراین فرآیند نوشتن و نگهداری اسکریپت های تست از طریق ماشین ها انجام می شود. این می تواند به طور قابل توجهی زمان و هزینه های مربوطه را کاهش دهد، در حالی که اتکای شما به مهندسین اتوماسیون تست را نیز کاهش می دهد، زیرا کدگذارهای معمولی و حتی غیر کدنویس ها اکنون می توانند اسکریپت های اتوماسیون تست را تولید کنند. در نهایت، آزمایشکنندگان اکنون میتوانند روی نیازهای تجاری نرمافزار تمرکز کنند و اطمینان حاصل کنند که قصد کاربر حفظ میشود.»
چگونه پلتفرمهای کمکد و SaaS تست را خودکار میکنند
اگر تجربه کاربر، منطق تجاری، پردازش دادهها و پیکربندی برنامه SaaS یا کمکد خود را آزمایش میکنید، آیا این یک اعتبارسنجی کافی برای کیفیت، قابلیت اطمینان و امنیت است؟
کیفیت کلی همچنین به این بستگی دارد که پلت فرم کمکد یا فروشنده SaaS چگونه فناوری خود را آزمایش میکند و خدمات و زیرساخت ابری زیربنایی را مدیریت میکند. اکثر فروشندگان پلتفرم گواهینامه های امنیتی، سطوح خدمات و اعتبارنامه های انطباق مانند ISO، SOC، GDPR، PCI و FedRamp را به اشتراک می گذارند. فروشندگان برتر همچنین برنامههای انتشار، یادداشتهای انتشار، نقصهای شناختهشده، سوابق سطح سرویس و دسترسی به صفحات وب را برای بررسی وضعیت آپتایم به اشتراک میگذارند. اما بسیاری از فروشندگان جزئیاتی در مورد معماری، استانداردهای توسعه و شیوه های آزمایش ارائه نمی دهند.
من با مارتین لاپورت، معاون ارشد تحقیق و توسعه در Coveo صحبت کردم تا در مورد رویکرد آنها برای آزمایش صحبت کنم. و استقرارها او میگوید: «در دنیایی که اجزای پلتفرمهای SaaS چندین بار در روز بهروزرسانی میشوند، مشاهدهپذیری برای تشخیص هرگونه تغییر در رفتار، مانند افزایش نرخ خطا یا تغییرات در زمان پاسخ، کلیدی است. هر زمان که یک ناهنجاری تشخیص داده شود، انتشار باید با بازگشت خودکار در نسخه قبلی قطع شود.”
این یک نوار بالا برای روشهای آزمایش و فرکانس استقرار و آنچه شما امیدوارید که سایر پلتفرمهای SaaS و کمکد هدف قرار دهند، است. این سطح از آزمایش، که با تلاشهای اتوماسیون تست تیم توسعه تکمیل میشود، به کاهش خطرات استقرار، بهویژه برای برنامههایی که به قابلیت اطمینان بالایی نیاز دارند، کمک میکند.
خط آخر: اگر برنامهای با کد پایین یا SaaS را آزمایش نمیکنید، خوب، ممکن است فرضیات زیادی داشته باشید.
پست های مرتبط
نحوه خودکار کردن تست QA SaaS و برنامه های کم کد
نحوه خودکار کردن تست QA SaaS و برنامه های کم کد
نحوه خودکار کردن تست QA SaaS و برنامه های کم کد