نحوه نوشتن یک سند استراتژی تست برای آزمایش نرم افزار

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تاریخچه نسخه

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

ثبت نام خاموش

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

2. اهداف

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

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

3. مزایا

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

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

4. دامنه

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

در دامنه

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

خارج از دامنه

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

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

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

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

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

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

تست های دستی و اکتشافی

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

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

استراتژی

الزامات خاص

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

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

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

6. محیط های تست

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

7. داده های تست

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

8. ابزار تست

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

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

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

10. ردیابی نقص

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

همچنین، نحوه تریاژ کردن باگ ها را در صورت لزوم شرح دهید.

11. خطرات

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

نتیجه

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