چرا برنامه شغلی توسعه شما باید شامل تست نرم افزار خودکار باشد؟
افزایش محبوبیت تست خودکار به این معنی است که تضمین کیفیت نرم افزار (QA) باید نقش فزاینده ای در برنامه شغلی توسعه شما ایفا کند.
اکثر توسعه دهندگان مدرن تست نرم افزار را بخشی از شرح وظایف خود نمی دانند، چه رسد به اینکه بخشی از برنامه شغلی توسعه خود باشند. به طور سنتی، توسعه دهندگان فقط مسئول نوشتن کد بودند. شخص دیگری تست و QA را انجام داده است. اما این در حال تغییر است. افزایش محبوبیت تست خودکار به این معنی است که به طور فزاینده ای از توسعه دهندگان خواسته می شود تا در تضمین کیفیت نرم افزار (QA) نقش ایفا کنند – یا در برخی موارد مسئولیت آن را به طور کامل به عهده بگیرند.
در اینجا نگاهی می اندازیم به چرایی این اتفاق، و معنای آن برای توسعه دهندگان مدرن.
تست خودکار چیست؟
تست خودکار چیزی است که به نظر می رسد: استفاده از اسکریپت های خودکار برای ارزیابی نحوه عملکرد یک برنامه (یا بخشی از یک برنامه). این برخلاف آزمایش نرم افزار با تعامل دستی با آن به منظور فعال کردن عملکردها یا ویژگی های خاص و ارزیابی عملکرد آنها است. با آزمایش خودکار، کدی نوشته میشود تا این رفتار را به طور خودکار ایجاد کند و نتایج نیز به صورت خودکار جمعآوری میشوند.
انواع مختلفی از تست نرم افزار وجود دارد – تست یکپارچه سازی، تست قابلیت استفاده، تست عملکرد و تست بار رایج ترین دسته ها هستند – و بنابراین انواع مختلفی از ابزارهای تست خودکار در دسترس هستند. (برای اطلاع از اینکه کدام ابزارها از کدام نوع تست پشتیبانی می کنند، راهنمای خرید اتوماسیون تست نرم افزار ما را بررسی کنید.) اما مهم نیست که کدام نوع آزمایش را انجام می دهید، اگر از یک اسکریپت برای خودکارسازی فرآیند استفاده می کنید، در این صورت در حال انجام تست خودکار هستید.
شایان ذکر است که برخی افراد بین تست خودکار و اتوماسیون تست تمایز قائل می شوند. از نظر آنها، اصطلاح قبلی به استفاده از اسکریپت های خودکار برای ارزیابی یک برنامه کاربردی اشاره دارد. پس از شروع، آن اسکریپت ها به طور خودکار اجرا می شوند، و از این نظر، خودکار هستند، حتی اگر به صورت دستی فعال شوند. در مقابل، اتوماسیون تست به اتوماسیون فرآیند گستردهتر شروع تستها و جمعآوری نتایج اشاره دارد. برای اهداف این مقاله، تفاوت بین این دو اصطلاح واقعاً مهم نیست، زیرا ظهور چارچوبهای تست خودکار است که نحوه تعامل توسعهدهندگان با QA را تغییر داده است. اما هنوز هم یک تمایز مهم برای درک است.
افزایش محبوبیت تست اتوماسیون
آزمایش خودکار برای چندین دهه به یک شکل یا آن شکل وجود داشته است. با این حال، در سالهای اخیر، چند عامل همگرا شدهاند تا آزمایش خودکار را به روشی بسیار رایجتر برای ارزیابی برنامهها قبل از استفاده از آنها در تولید تبدیل کند:
چارچوبهای آزمایش خودکار متنباز، مانند سلنیوم و اپیوم، به بلوغ رسیدهاند و ایجاد و اجرای تستهای خودکار را بدون تکیه بر ابزارهای اختصاصی آسانتر میکنند.
در دسترس بودن محیطهای آزمایشی مبتنی بر ابر، اجرای همزمان بسیاری از آزمایشها را برای تیمها آسان کرده است، بدون اینکه در دسترس بودن محیطهای آزمایشی در محل محدود شوند. تست خودکار برای به دست آوردن حداکثر عملکرد از محیط های آزمایشی مبتنی بر ابر بسیار مهم است زیرا زمان بیکار ماندن ابرهای آزمایشی را به حداقل می رساند و منتظر اجرای مجموعه آزمایش های بعدی هستند.
از منظر فرهنگی، ظهور خطوط لوله CI/CD و به طور کلی جنبش DevOps، اتوماسیون هر جنبه ای از فرآیند تحویل نرم افزار را تشویق کرده است.
برای اطمینان، تست دستی هنوز یک چیز است. من هنوز در مورد سازمانی نشنیده ام که تمام تست های خود را کاملاً خودکار کرده باشد، و انجام انواع خاصی از تست ها (مانند تست قابلیت استفاده) همیشه به روشی کاملاً دستی دشوار خواهد بود. (گاهی اوقات، شما باید بنشینید و تماشا کنید که کاربران واقعی چگونه با نرم افزار شما تعامل دارند تا بینش های مهم قابلیت استفاده را به دست آورید.)
با این حال، به طور کلی، تست خودکار برای اکثر عملیات تحویل نرم افزار به یک قانون تبدیل شده است، نه استثنا. بر اساس صحبتهایم با تیمهای تحویل نرمافزار، تخمین میزنم که سازمانهای معمولی اکنون بین ۶۰ تا ۸۰ درصد تستهای خود را خودکار میکنند.
بیشتر بخوانید: تحلیل نیازمندیهای نرمافزار
چگونه تست خودکار بر توسعه دهندگان تأثیر می گذارد
میپرسید همه موارد فوق چه ربطی به توسعهدهندگان و برنامههای شغلی توسعه آنها دارد؟ پاسخ بسیار ساده است: وقتی تست خودکار مبنایی برای عملیات QA نرم افزار می شود، آزمایش به کد کاهش می یابد. و هیچ کس کد را به خوبی توسعه دهندگان نمی داند.
اگر میخواهید تستهای نرمافزاری را خودکار کنید، باید کدی بنویسید که به ابزار تست خودکار شما اجازه میدهد جنبههای یک برنامه کاربردی را که در حال آزمایش هستید ارزیابی کند. بنابراین، به جای اینکه به صورت دستی روی یک دکمه در یک برنامه کلیک کنید تا رفتار خاصی را نشان دهد و نتیجه را ارزیابی کند، برای مثال، کدی را می نویسید که این کار را برای شما انجام می دهد.
برای مهندسان QA، این گاهی اوقات یک چالش است. افراد QA برای ارزیابی قابلیت استفاده، عملکرد و غیره به صورت دستی آموزش دیده اند. آنها به طور سنتی برای کدنویسی آموزش ندیده اند.
این بدان معنا نیست که هیچ مهندس QA نمی تواند کد بنویسد. بسیاری یاد گرفتهاند که اسکریپتها را با استفاده از چارچوبهای محبوبی مانند Selenium و Appium بنویسند. اما دیگران این کار را نکرده اند. و حتی زمانی که افراد QA تست های خودکار را می نویسند، ممکن است به خوبی توسعه دهندگان در انجام این کار خوب نباشند. این درست است نه تنها به این دلیل که توسعهدهندگان تمام روز را صرف نوشتن کد میکنند و بنابراین بهتر از هرکس دیگری در آن کار میکنند، بلکه به این دلیل که درک کد درون یک برنامه اغلب برای نوشتن یک اسکریپت تست خودکار که آن برنامه را آزمایش میکند، مهم است.
بنابراین، در دنیایی که تست نرم افزار تا حد زیادی خودکار شده است، توسعه دهندگان برای کمک به متخصصان QA در نوشتن و بهینه سازی تست های خودکار اهمیت فزاینده ای پیدا کرده اند. امروزه برای بسیاری از توسعه دهندگان، دانستن نحوه کدنویسی در جاوا یا سی پلاس پلاس کافی نیست. همچنین انتظار می رود که آنها بتوانند اسکریپت هایی را با استفاده از تست خودکار محبوب بنویسند.
پیشنهاد ما: تست نفوذ شبکه
تست خودکار و برنامه های شغلی توسعه
اگرچه حداقل یک بار شرکتی را می شناسم (که نمی توانم نامش را ببرم، اما یک سازمان خدمات مالی بزرگ است) که تیم QA خود را به طور کامل با توسعه دهندگان جایگزین کرده است، من شک دارم که مهندسان QA به زودی به طور کامل از اکثر سازمان ها ناپدید شوند. QA هنوز یک رشته مهم است و معمولاً نمی توان از توسعه دهندگان انتظار داشت که هر کاری را که یک مهندس QA انجام می دهد انجام دهند.
با این حال، واقعیت این است که کمک به انجام عملیات تست خودکار به یکی از مهارت های مهم برای توسعه دهندگان در عصر DevOps تبدیل شده است. اگر توسعهدهندهای هستید که به دنبال راهی برای ارزشمندتر کردن خود برای سازمانهای آیندهنگر هستید، آموزش سلنیوم (یا چارچوب مشابه) یکی از راههای انجام آن است.
دیدگاهتان را بنویسید