در دنیای توسعه نرم‌افزار، باگ‌ها کاملا طبیعی و بخشی از زندگی روزمره ما هستند. تمام تیم‌های مهندسی تلاش می‌کنند تا حد ممکن خطاهای کمتری داشته باشند؛ زیرا تاثیر منفی روی کاربران می‌گذارد و رفع آنها برای شرکت زمان و هزینه‌های (گاها) زیادی دارد.
جلوگیری از باگ‌ها کار پیچیده‌ای است، اما ما می‌توانیم با پیروی از بهترین روش‌های موجود مانند نوشتن سرویس طبق مستنداتی با توضیحات بسیار دقیق که همه موارد استفاده ممکن را پوشش می‌دهد، استفاده از کد تمیز هنگام توسعه سرویس‌ها و نوشتن تست‌های قوی، تعداد خطاهای کد خود را کاهش دهیم.
مسئولیت اطمینان از عدم وجود باگ در یک سرویس بر عهده چه کسی است؟
اگر بگوییم این مسئولیت صرفا بر عهده مهندسان QA (تضمین کیفیت) است (در صورت وجود)، اما علاوه بر نادرست بودن، ناعادلانه است؛ زیرا ما تمام مسئولیت را به آنها محول می‌کنیم.
در برخی از تیم‌ها، تصور می‌شود مهندس QA به عنوان نقشی وجود دارد و فعالیت می‌کند که تضمین کند هیچ سرویس دارای باگی وارد چرخه تولید نمی‌شود. من از توسعه‌دهندگان شنیده‌ام که می‌گویند، «من کد را می‌نویسم و سپس QA آن را آزمایش می‌کند.» این نباید اینطور باشد.
کیفیت کد یک مسئولیت مشترک بین کل تیم است.
چه زمانی باید در مورد مشکلاتی که ممکن است کد ایجاد کند فکر کنیم؟
بیشتر باگ‌ها در مرحله توسعه معرفی می‌شوند و این به دلایل مختلفی اتفاق می‌افتد:
اگر توسعه‌دهنده شروع به کار بر روی یک سرویس با شرح وظایف نادرست کرده باشد، چه؟
اگر معیارهای پذیرش مبهم باشد یا حتی تعریف نشده باشد چه؟
ما باید از همان لحظه‌ای که یک کار را ایجاد و اصلاح می‌کنیم، در مورد اشکالات فکر کنیم. فکر کردن به آنها در طول توسعه خیلی دیر است.
فرض کنید چرخه عمر توسعه نرم‌افزار زیر را داریم:
- Requirements
- Design
- Implementation
- Review and QA
- Deploy to production
اگر دقت کرده باشید، QA در آخرین مرحله قبل از رسیدن به تولید است؛ یعنی بازخورد QA بسیار دیر ارائه می‌شود و توسعه‌دهنده این بازخورد را در آخرین مرحله قبل از استقرار در محیط Production در دریافت می‌کند و می‌تواند مورد نظر قرار دهد.
این می‌تواند منجر به گفتگویی بی‌پایان بین توسعه‌دهنده و QA در هنگام بررسی عملکرد شود و ممکن است کار چندین رفت و برگشت (مانند یک مسابقه پینگ‌پنگ) داشته باشد؛ فقط به این دلیل که QA حتی قبل از شروع توسعه درگیر چرایی پیاده‌سازی این سرویس نبوده است.
رفع باگ هزینه‌های را به همراه دارد که با پیشرفت در مراحل توسعه به طور قابل توجهی افزایش پیدا می‌کند.
رفع باگ یک سرویس در مراحل اولیه توسعه بسیار ساده‌تر و ارزان‌تر از زمانی است که این سرویس در مراحل انتهایی استقرار در محیط Production قرار دارد.
بنابراین، استفاده نکردن از shift left testing چندین پیامد دارد:
- با عدم تمرکز روی تست از مرحله اول، زمان اجرا افزایش پیدا می‌کند
- با افزایش زمان اجرا، بازخورد در مورد کار بسیار دیر انجام می‌شود
- اگر بازخورد دیر برسد، تلاش و هزینه تغییر کد بیشتر است
Shift Left Testing چیست؟
Shift Left Testing به معنای تمرکز روی تست نرم افزار از همان زمانی است که شروع به فکر کردن درباره نحوه نزدیک شدن به یک کار می‌کنیم. ما باید همه موارد استفاده بالقوه، از جمله سناریوهای مثبت و منفی را در نظر بگیریم تا اطمینان حاصل کنیم که معیارهای پذیرش کار تا حد امکان دقیق و جامع هستند.
مزایای Shift Left Testing
- تشخیص زودهنگام باگ: با شروع فعالیت‌های تست زودتر در فرآیند توسعه، می‌توان باگ‌ها و مشکلات را زودتر شناسایی و برطرف کرد و هزینه و تلاش لازم برای رفع آنها را در مراحل بعدی چرخه توسعه کم کرد.
- بهبود کیفیت محصول: با تست‌هایی که زودتر در چرخه توسعه نرم‌افزار انجام می‌شوند، کیفیت نرم‌افزار با شناسایی و حل باگ‌ها در مراحل اولیه بهبود پیدا می‌کند.
- حلقه بازخورد سریع‌تر: توسعه‌دهندگان بازخورد سریع‌تری در مورد کد خود دریافت می‌کنند که به آنها اجازه می‌دهد تا به سرعت تنظیمات لازم را انجام دهند که منجر به چرخه‌های تکرار و توسعه سریع‌تر می‌شود.
- کاهش هزینه و ورود سریع‌تر به بازار: شناسایی و رفع مشکلات زودتر در فرآیند توسعه، هزینه کلی توسعه نرم‌افزار را با اجتناب از دوباره کاری پرهزینه و رفع اشکال در مراحل آخر کاهش می‌دهد.
- افزایش همکاری: Shift Left Testing، همکاری بین توسعه‌دهندگان، آزمایش‌کنندگان و سایر ذینفعان را از ابتدای پروژه تشویق می‌کند و فرهنگ مسئولیت مشترک و همکاری را تقویت می‌کند.
- رضایت مشتری: با ارائه نرم‌افزار با کیفیت بالاتر با نقص کمتر، Shift Left Testing در نهایت منجر به افزایش رضایت مشتری می‌شود.
چگونه Shift Left Testing را پیاده‌سازی کنیم؟
تسترها را در اولین مرحله ممکن قرار دهید
گنجاندن تسترها در مرحله جمع‌آوری نیازمندی‌ها برای اجرای موفقیت‌آمیز Shift Left Testing بسیار مهم است؛ زیرا آنها چشم‌انداز دقیقی را در مورد چگونگی آزمایش سرویس‌ها حتی قبل از اینکه توسعه‌دهندگان شروع به نوشتن کد کنند، ارائه می‌دهند.
اگر توسعه‌دهندگان معیارهای پذیرش بسیار دقیقی داشته باشند و دقیقاً بدانند که کد باید چگونه رفتار کنند و چه چیزی مورد آزمایش قرار می‌گیرد، تعداد اشکالات و دوباره کاری‌ها به شدت کم می‌شود.
نقش آزمایشگران از تمرکز صرف بر شناسایی اشکالات پس از مرحله توسعه به مسئولیت گسترده‌تر تضمین کیفیت (QA) تکامل یافته است. این به معنای جلوگیری از اشکالات در کل چرخه عمر توسعه نرم‌افزار (SDLC) است. با این حال، این انتقال می‌تواند دشوار باشد و تستر ممکن است برای انطباق با این مسئولیت‌های جدید در روال روزمره خود، به مربی نیاز داشته باشد.
معیارهای پذیرش بسیار دقیق را به وظایف خود اضافه کنید
معیارهای پذیرش قراردادی است که اگر قبلا در مورد مشکل تحقیق کرده باشیم، نباید در طول توسعه تغییر کند.
ایجاد تغییرات در معیارهای پذیرش پس از توسعه بسیار پرهزینه است، زیرا برنامه نویس را مجبور می‌کند تا کدهای از قبل تکمیل شده را به دلیل الزامات نادرست بازنویسی کند.
مطمئن شوید که همه تیم معیارهای پذیرش را درک کرده‌اند.
توسعه دهندگان باید کد خود را قبل از ارسال به مرحله بررسی آزمایش کنند.
با آزمایش صحیح کد می توان از چندین اشکال و مکالمه بین توسعه‌دهندگان و QA جلوگیری کرد. تست واحد یک ابزار بسیار قدرتمند است که می تواند برای کاهش زمان بررسی و تعداد باگ های کد مورد استفاده قرار گیرد. تست دستی گران است و باید از آن اجتناب کرد.
بازخورد مستمر
توسعه‌دهندگان باید در مرحله اجرا با QA و مدیر محصول (در صورت وجود) کار کنند تا بتوانند در اسرع وقت بازخورد خود را به توسعه‌دهنده ارائه دهند. به این ترتیب، مقدار دوباره کاری و تعداد باگ‌های اواخر مرحله را کاهش می‌دهیم.
همانطور که می‌بینید، برنامه‌نویسی با استفاده از Shift Left Testing به زمان بیشتری نیاز ندارد؛ زیرا زمان توسعه حفظ می‌شود، زمان بازبینی بسیار کاهش پیدا می‌کند، بنابراین در زمان کمتر و همچنین بدون اضافه کردن باگ‌های بیشتر، کارهای بیشتری انجام می‌دهیم.
سخن پایانی
در مقاله فوق، مفهوم Shift Left Testing و اهمیت آن در فرآیند توسعه نرم‌افزار بررسی شد که به معنای انجام تست‌ها و ارائه بازخورد از ابتدای فرآیند توسعه است. این رویکرد منجر به شناسایی زودهنگام مشکلات و باگ‌ها و رفع آنها در مراحل اولیه می‌شود. همچنین، Shift Left Testing منجر به بهبود کیفیت محصول، حلقه بازخورد سریع‌تر، کاهش هزینه و ورود سریع‌تر به بازار، افزایش همکاری تیم و رضایت مشتری می‌شود. بنابراین، پیاده‌سازی این رویکرد می‌تواند به بهبود کارایی و کیفیت فرآیند توسعه نرم‌افزار کمک کند و باعث افزایش رقابت‌پذیری شرکت در بازار می‌شود.
دیدگاهتان را بنویسید