چگونه یک سند استراتژی تست برای تست نرم افزار بنویسیم

استراتژی آزمون بخش کلیدی فرآیند آزمون است که بر اساس الزامات تجاری هدایت می شود. این جزئیات فرآیندهای آزمایشی است که باید برای اطمینان از توسعه محصول با کیفیت انجام شود. این کمک می کند تا هم پوشش تست و هم محدوده آزمایش را تعریف کنیم و اطمینان حاصل کنیم که تیم محدوده پروژه را درک می کند. باید تمام جنبه های فرآیند تست، از تست دستی و اتوماسیون گرفته تا الزامات غیرعملکردی (NFR) مانند تست عملکرد و امنیت را پوشش دهد.

تفاوت بین استراتژی تست و طرح تست چیست؟

ساده ترین راه برای تمایز بین آنها این است که یک استراتژی آزمایشی رویکرد کلی را که یک تیم باید اتخاذ کند، توضیح می دهد، در حالی که یک طرح آزمایشی جزئیات اجرای استراتژی، توسط چه کسی و چه زمانی را شرح می دهد.

چه کسی باید استراتژی آزمون را ایجاد کند؟

به طور معمول سند استراتژی آزمون توسط مدیر پروژه یا مدیر آزمایش ایجاد می شود، زیرا آنها بیشترین دانش و قرار گرفتن در معرض طرح گسترده تر پروژه را دارند. با این حال، از آنجایی که ما ساختارهای تیمی مدرن و مسطح تری را می بینیم، در تیم های چابک تر کوچک تر که عمدتاً از اعضای ارشد تشکیل شده اند، می تواند بر عهده مهندس ارشد آزمون باشد که استراتژی آزمایش را بنویسد، و کسب تأیید از پروژه منجر به اطمینان از کیفیت می شود. استانداردهای پروژه رعایت می شود.

آیا می توانم از یک الگوی استراتژی تست استفاده کنم؟

هر پروژه نیازها و الزامات متفاوتی از جمله ریسک های متفاوت دارد. این بدان معنا نیست که نمی توانید با یک الگوی پایه برای تسریع فرآیند شروع کنید، اما این باید بیشتر در مورد اطمینان از وجود بخش های مختلف باشد، نه کپی کردن محتوا در آن بخش ها. فرآیند نوشتن یک استراتژی تست بیشتر در مورد فکر کردن در مورد عوامل خطر در پروژه و برنامه ریزی برای کاهش این خطرات است، نه علامت زدن کادرها برای نشان دادن اینکه همه انواع تست ها گنجانده شده اند.

چه چیزی باید در سند استراتژی آزمون گنجانده شود؟

اجزای اصلی یک سند استراتژی آزمون خوب به شرح زیر است:

• اهداف آزمون و دامنه آنها
• الزامات کیفیت کلیدی مبتنی بر کسب و کار
• عوامل خطر احتمالی
• موارد تحویلی آزمایشی
• ابزار تست
• مسئولیت ها
• پیگیری و گزارش مشکلات
• پیکربندی و مدیریت تغییر
• الزامات محیط آزمایشی

مهم است که به یاد داشته باشید که این یک لیست قطعی نیست، اگر چیز دیگری پیدا کردید که برای پروژه شما مهم است، آن را درج کنید.

هنگام پر کردن بخش های زیر ، که دوباره یک توصیه پایه هستند ، نیازهای فوق را در ذهن داشته باشید و باید به جای اینکه دیکته کنید ، نحوه ایجاد استراتژی آزمون خود را راهنمایی کنید.

1. تاریخچه نسخه و علامت گذاری

هر سند پروژه ارزشمند باید دارای یک جدول تاریخچه نسخه و جدول ثبت نام اسناد در بالای سند باشد تا از کیفیت سند در طول زمان اطمینان حاصل شود.

تاریخچه نسخه

در این جدول هر تغییر اساسی که در سند استراتژی آزمون ایجاد شده است. معمولاً ، یک پیش نویس و سپس یک نسخه منتشر شده که امضا شده است وجود دارد. سپس هرگونه تغییر بیشتر در این سند شماره انتشار را افزایش می دهد و دوباره نیاز به امضاء دارد.

ثبت نام خاموش

پس از اتمام استراتژی آزمون و انتشار ، باید توسط ذینفعان پروژه اصلی امضا شود زیرا این قرارداد با کیفیت تبدیل می شود. برای اطمینان از رعایت استانداردهای با کیفیت بالا ، هرگونه تغییر بیشتر پس از آن نیز باید امضا شود.

2. اهداف

اهداف استراتژی آزمون را ذکر کنید ، و جزئیات آنچه را که می خواهید در نتیجه دنبال کردن آن به دست آورید ، شرح دهید.

• تعیین کنید که کدام نوع آزمایش مورد نیاز است
• پوشش آزمون را به حداکثر برسانید و تکثیر تلاش را به حداقل برسانید
• از استقرار مداوم پشتیبانی کنید
• برای دستیابی به استانداردهای مورد انتظار از نیازهای غیر کاربردی
• برای رعایت استانداردهای صنعت

3. مزایا

مزایایی را که می خواهید به دست آورید ، لیست کنید.

• شناسایی قبلی الزامات آزمایش
• ارتقاء ارتباط بین اعضای تیم
• کاهش خطر
• درک بهتر از کارهای آزمون
• زمینه های مسئولیت را تشخیص دهید

4. دامنه

مواردی را که در محدوده این سند قرار می گیرند ، لیست کنید. شما همچنین می توانید مواردی را که صریحاً نیز انجام نمی دهند ، لیست کنید.

در دامنه

• تست های واحد
• تست های ادغام / E2E / UI
• تست های پذیرش
• تست های API
• تست های امنیتی
• تست های عملکردی
• تست های مرورگر
• تست های دسترسی
• اتوماسیون تست ها
• حوزه مسئولیت توسعه دهندگان و آزمایش کنندگان را شناسایی و توافق کنید
• منبع مورد نیاز: NFRS

خارج از دامنه

• مقیاس های زمانی
• تلاش
• هزینه

5. انواع آزمایشات

این یک بخش دقیق تر است و برای هر نوع آزمایش که قرار است انجام شود ، دارای زیر است. همچنین ، در صورت تمایل ، در یک هرم تست پرتاب کنید.

فهمیدم که بهتر است هر نوع آزمایش و جزئیات را در زیر تجزیه کنید:

• چالش ها / مزایا
• استراتژی
• الزامات خاص

در اینجا نمونه ای از یکی از بخش هایی که می توانید در آن قرار دهید آورده شده است:

آزمایشات دستی و اکتشافی

چالش ها / مزایا

• شناسایی اولیه اشکالات
• قادر به آزمایش مناطقی که جزئی از مسیر شاد نیستند
• از سیستم به روش های غیر منتظره ای استفاده کنید تا اطمینان حاصل شود که هنوز هم همانطور که انتظار می رود عمل کند
• گران برای اجرای

استراتژی

الزامات خاص

• تست های دستی در برابر داستان ها / کارها وارد شده اند
• اشکالات وارد شده در نرم افزار ردیابی
• آزمون رگرسیون اشکالات ثابت که باید انجام شود
• (پیوند به NFR های خاص)

و در اینجا لیستی از بخش هایی وجود دارد که ممکن است بخواهید در آن قرار بگیرید:

• آزمایشات دستی و اکتشافی
• تست اتوماسیون UI
• تست های API
• تست های ادغام
• تست پذیرش کاربر
• تست های عملکردی
• تست های امنیتی
• تست سازگاری مرورگر
• تست های دسترسی

6. محیط های آزمایش

محیط های آزمایشی مختلف مورد نیاز را لیست کنید.

7. داده های آزمون

الزامات داده هایی را که برای برآورده کردن مراحل مختلف آزمایش مورد نیاز است ، لیست کنید.

8. ابزارهای تست

ابزارهای مختلف تست را که برای انجام آزمایش نیاز دارید ، لیست کنید. همچنین توجه داشته باشید که آیا هنوز ابزارهایی تصمیم گرفته نشده است تا سنبله های تحقیق در اسرع وقت اتفاق بیفتند.

9. نتایج آزمون

هرگونه گزارش آزمایشی را که خروجی و جزئیات هرگونه سیاست نگهداری است ، لیست کنید. همچنین ، هرگونه ابزار / افزونه گزارش دهی را که استفاده خواهید کرد ، لیست کنید. مانند افزونه Zephyr برای JIRA که یک روش محبوب برای مستندسازی تست های دستی یا گزارش پورتال است که یک راه حل گزارش آزمایش منبع باز است.

10. ردیابی نقص

نحوه ورود و ردیابی اشکالات ، مانند GitLab را مشخص کنید.

همچنین ، جزئیات چگونگی تثبیت اشکالات در صورت لزوم را نشان می دهد.

11. خطرات

سعی کنید خطراتی را که ممکن است در این پروژه رخ دهد ، شناسایی و لیست کنید ، و هرگونه اقدامی را که می تواند این خطرات را کاهش دهد ، شرح دهید. در صورت تبدیل شدن به خطرات ، می توانید هر برنامه احتمالی را نیز توضیح دهید.

نتیجه

لطفاً به یاد داشته باشید که این یک راهنما است ، نه یک لیست قطعی از آنچه در یک سند استراتژی آزمایش می رود. هر پروژه متفاوت است و هر تیم نیازهای متفاوتی خواهد داشت. همچنین به یاد داشته باشید که می توانید سند استراتژی آزمون را به عنوان و در صورت لزوم ، با تأیید البته ، به روز کنید ، زیرا همه ما می دانیم که نیازهای پروژه می تواند تغییر کند.< SPAN> سعی کنید خطرات موجود در این پروژه را شناسایی و لیست کنید ، و هرگونه اقدامی را که می تواند این خطرات را کاهش دهد ، شرح دهد. در صورت تبدیل شدن به خطرات ، می توانید هر برنامه احتمالی را نیز توضیح دهید.