یک نرمافزار بعد از انتشار و ورود به محیط عملیاتی، دیگر یک محصول ثابت و بدون تغییر نیست. رفع خطاها، اضافه شدن قابلیتهای جدید، تغییرات محیط اجرا، مهاجرت به یک پلتفرم جدید و حتی پایان عمر یک سیستم، همگی میتوانند باعث تغییر در نرمافزار شوند.
اما هر تغییر در یک سیستم موجود میتواند پیامدهایی فراتر از همان بخش تغییریافته داشته باشد. ممکن است یک اصلاح کوچک باعث شود بخشی از قابلیتهایی که قبلاً بهدرستی کار میکردند، دچار مشکل شوند. به همین دلیل، تست نرمافزار فقط به مرحله توسعه اولیه محدود نمیشود و در طول عمر سیستم نیز ادامه پیدا میکند.
Maintenance Testing یا تست نگهداری به تستهایی گفته میشود که در ارتباط با تغییرات ایجادشده در یک سیستم عملیاتی انجام میشوند. هدف این تستها فقط بررسی موفقیت تغییر نیست؛ بلکه باید بررسی شود که تغییر ایجادشده باعث ایجاد Regression یا خرابی در بخشهای دیگر سیستم نشده باشد.
در این مقاله، Maintenance Testing را بر اساس مفاهیم ISTQB Foundation بررسی میکنیم و با مثالهای عملی، موقعیتهایی که نیازمند تست نگهداری هستند، نقش Impact Analysis، ارتباط Maintenance Testing با Regression Testing و عوامل مؤثر بر میزان تست موردنیاز را بررسی خواهیم کرد.
۱. Maintenance Testing چیست؟
Maintenance Testing یا تست نگهداری به تستهایی گفته میشود که برای ارزیابی تغییرات ایجادشده در یک سیستم نرمافزاری موجود و عملیاتی انجام میشوند.
وقتی یک نرمافزار وارد محیط Production میشود، توسعه و تغییر آن متوقف نمیشود. ممکن است برای رفع یک خطا، اضافه کردن قابلیت جدید، تغییر محیط اجرا یا مهاجرت به یک سیستم جدید، تغییراتی در آن ایجاد شود. هرکدام از این تغییرات میتوانند نیازمند Maintenance Testing باشند.
هدف Maintenance Testing را میتوان در دو بخش اصلی خلاصه کرد:
- بررسی موفقیت تغییر ایجادشده: مطمئن شویم تغییر موردنظر همانطور که انتظار میرود کار میکند.
- بررسی اثر تغییر بر بخشهای موجود سیستم: مطمئن شویم تغییر جدید باعث خراب شدن قابلیتهایی که قبلاً درست کار میکردند نشده است. این بخش معمولاً با Regression Testing ارتباط نزدیکی دارد.
برای مثال، فرض کنید در سیستم بانکی BlueBank نحوه محاسبه کارمزد انتقال وجه تغییر کرده است. تست این تغییر فقط به بررسی محاسبه جدید کارمزد محدود نمیشود. باید بررسی کنیم که تغییر ایجادشده روی فرآیند انتقال وجه، موجودی حساب، گزارش تراکنشها یا سایر قابلیتهای مرتبط تأثیر منفی نگذاشته باشد.
Maintenance Testing یعنی تست تغییرات در یک سیستم عملیاتی، همراه با بررسی اینکه این تغییرات باعث ایجاد مشکل در بخشهای موجود سیستم نشده باشند.
نکته مهم این است که Maintenance Testing یک Test Type مانند Functional Testing یا Performance Testing نیست؛ بلکه به شرایطی اشاره دارد که در آن، یک سیستم موجود و عملیاتی در حال تغییر یا نگهداری است. بسته به نوع تغییر، ممکن است در Maintenance Testing از Test Typeها و Test Techniqueهای مختلف استفاده شود.
۲. چه زمانی Maintenance Testing انجام میشود؟
Maintenance Testing زمانی انجام میشود که یک سیستم نرمافزاری موجود و عملیاتی تغییر کند یا شرایط محیطی که نرمافزار در آن اجرا میشود تغییر یابد.
بر اساس مفاهیم ISTQB، مهمترین موقعیتهایی که میتوانند نیاز به تست نگهداری ایجاد کنند، در سه گروه قرار میگیرند:
- Modifications: تغییرات، اصلاحات و Enhancementهای سیستم
- Upgrades / Migrations: ارتقا یا مهاجرت سیستم، محیط و دادهها
- Retirement: بازنشسته کردن سیستم و فعالیتهای مرتبط با آن
این سه گروه در ادامه با جزئیات بیشتری بررسی میشوند.
۲.۱ Modifications؛ تغییرات و اصلاحات
Modifications زمانی اتفاق میافتند که نرمافزار موجود تغییر میکند. این تغییر میتواند برای رفع یک مشکل، اضافه کردن یا بهبود یک قابلیت یا انجام یک اصلاح فوری باشد.
- Corrective Changes: اصلاح خطاها و مشکلات موجود
- Planned Enhancements: اضافه کردن یا بهبود قابلیتها در Releaseهای برنامهریزیشده
- Hot Fix: اصلاح فوری یک مشکل مهم در محیط Production
برای مثال، فرض کنید در BlueBank کاربران در شرایط خاصی نمیتوانند انتقال وجه انجام دهند. تیم توسعه مشکل را اصلاح میکند و نسخه جدید منتشر میشود.
در این شرایط QA باید حداقل دو موضوع را بررسی کند:
تغییر ایجاد شده
│
├── آیا مشکل اصلی برطرف شده؟
│ ↓
│ Retesting
│
└── آیا تغییر باعث مشکل جدید شده؟
↓
Regression Testing
بنابراین حتی یک تغییر نسبتاً کوچک نیز ممکن است نیازمند تست در بخشهای دیگری از سیستم باشد.
۲.۲ Upgrades و Migrations
در برخی موارد، تغییر اصلی مربوط به محیط عملیاتی، پلتفرم یا انتقال سیستم و دادهها است.
- انتقال نرمافزار به یک Operating System جدید
- تغییر Database
- انتقال نرمافزار به یک Platform جدید
- Migration دادهها از یک سیستم به سیستم دیگر
- تغییر Environment
- تبدیل یا انتقال دادهها (Data Conversion)
در این شرایط، Maintenance Testing ممکن است شامل تست خود نرمافزار در محیط جدید و همچنین بررسی صحت دادههای منتقلشده باشد.
برای مثال، اگر اطلاعات حسابهای BlueBank از یک Database قدیمی به Database جدید منتقل شود، QA باید بررسی کند که:
- دادهها بهدرستی منتقل شدهاند.
- اطلاعاتی از بین نرفته یا به شکل نادرست تغییر نکرده است.
- سیستم جدید میتواند دادههای منتقلشده را بهدرستی استفاده کند.
- قابلیتهای قبلی سیستم همچنان درست کار میکنند.
۲.۳ Retirement؛ بازنشستگی سیستم
Retirement یا بازنشسته کردن یک سیستم نیز میتواند به Maintenance Testing نیاز داشته باشد.
ممکن است یک نرمافزار پس از چند سال دیگر مورد استفاده قرار نگیرد و سازمان تصمیم بگیرد آن را از چرخه عملیاتی خارج کند. اما پایان کار سیستم به معنای پایان نیاز به تست نیست.
- Data Archiving: انتقال دادههای قدیمی به محل نگهداری
- Data Restore: بازیابی دادههای Archive شده
- Data Retrieval: امکان دسترسی مجدد به دادهها در صورت نیاز
برای مثال، اگر BlueBank سیستم قدیمی مدیریت وامهای خود را بازنشسته کند، ممکن است سازمان طبق الزامات قانونی مجبور باشد اطلاعات وامهای قدیمی را برای چند سال نگهداری کند. بنابراین باید مطمئن شود که دادهها بهدرستی Archive شدهاند و در صورت نیاز قابل بازیابی هستند.
| دسته | نمونهها |
|---|---|
| Modifications | Bug Fix، Enhancement، Hot Fix |
| Upgrade / Migration | تغییر Platform، Migration، Data Conversion |
| Retirement | Archiving، Restore و Retrieval دادهها |
نکته مهم این است که نوع تغییر تعیین میکند چه تستهایی لازم است. بنابراین Maintenance Testing یک مجموعه ثابت از Test Caseها نیست؛ بلکه بر اساس نوع تغییر، ریسک و شرایط سیستم، دامنه و نوع تست مشخص میشود.
۳. Maintenance Testing شامل چه تستهایی است؟
Maintenance Testing مجموعهای ثابت از تستها ندارد. نوع و دامنه تستها به نوع تغییر، میزان ریسک و بخشهایی که ممکن است تحت تأثیر تغییر قرار بگیرند بستگی دارد.
با این حال، دو فعالیت در بسیاری از سناریوهای تست نگهداری اهمیت ویژهای دارند: Retesting و Regression Testing.
۳.۱ Retesting؛ بررسی موفقیت تغییر
Retesting برای بررسی این موضوع انجام میشود که آیا مشکل یا شرایطی که باعث ایجاد تغییر شده، واقعاً برطرف شده است یا خیر.
مثلاً در BlueBank یک Bug باعث شده باشد که هنگام انتقال وجه، کارمزد اشتباه محاسبه شود.
پس از اصلاح کد، QA همان سناریویی را که قبلاً با شکست مواجه شده بود، دوباره اجرا میکند. اگر محاسبه اکنون درست باشد، میتوان گفت اصلاح موردنظر با موفقیت تست شده است.
۳.۲ Regression Testing؛ بررسی تأثیر تغییر بر بخشهای قبلی
رفع موفقیتآمیز یک Bug به این معنی نیست که کار تست تمام شده است. ممکن است تغییر ایجادشده روی بخش دیگری از سیستم تأثیر گذاشته باشد. بنابراین باید قسمتهای مرتبط سیستم نیز بررسی شوند.
مثلاً در BlueBank تغییر در منطق محاسبه کارمزد ممکن است روی این بخشها نیز تأثیر گذاشته باشد:
- نمایش مبلغ نهایی تراکنش
- موجودی حساب
- گزارش تراکنشها
- رسید انتقال وجه
- Notification مربوط به تراکنش
در نتیجه QA علاوه بر Retesting، تستهای مرتبط را نیز اجرا میکند تا مطمئن شود تغییر جدید باعث ایجاد Regression نشده است.
۳.۳ Functional و Non-functional Testing
بسته به نوع تغییر، ممکن است Functional Testing یا Non-functional Testing نیز در Maintenance Testing موردنیاز باشد.
برای مثال، اگر یک قابلیت جدید به سیستم اضافه شده باشد، ممکن است لازم باشد:
- رفتار صحیح قابلیت بررسی شود.
- Validationها تست شوند.
- Error Handling بررسی شود.
- Performance قابلیت جدید بررسی شود.
- Security آن مورد ارزیابی قرار گیرد.
بنابراین Maintenance Testing میتواند از Test Typeها و Test Techniqueهای مختلف استفاده کند.
Maintenance Testing
│
├── Retesting
│
├── Regression Testing
│
├── Functional Testing
│
└── Non-functional Testing
│
├── Performance
├── Security
└── Usability
البته این نمودار به این معنی نیست که همه این تستها در هر Maintenance Testing انجام میشوند؛ انتخاب تستها به تغییر و ریسک آن بستگی دارد.
۴. نقش Impact Analysis در تست نگهداری
قبل از ایجاد یک تغییر در سیستم، باید بررسی کنیم که این تغییر ممکن است چه بخشهایی از سیستم را تحت تأثیر قرار دهد. این فعالیت را Impact Analysis یا تحلیل اثر تغییر مینامیم.
هدف Impact Analysis این است که مشخص شود:
- چه قسمتهایی از سیستم مستقیماً تغییر میکنند؟
- چه بخشهایی ممکن است بهصورت غیرمستقیم تحت تأثیر قرار بگیرند؟
- چه Test Caseهایی باید دوباره اجرا شوند؟
- آیا تست Regression بیشتری لازم است؟
- ریسک ایجاد مشکل در سایر قسمتهای سیستم چقدر است؟
برای مثال، فرض کنید در BlueBank منطق محاسبه کارمزد انتقال وجه تغییر کرده است. در نگاه اول ممکن است فقط صفحه انتقال وجه را تست کنیم؛ اما Impact Analysis میتواند نشان دهد که این تغییر با بخشهای دیگری نیز ارتباط دارد:
تغییر محاسبه کارمزد
│
├── انتقال وجه
├── موجودی حساب
├── رسید تراکنش
├── گزارش تراکنشها
└── Notification
در نتیجه، دامنه تست فقط به همان قسمت تغییریافته محدود نمیشود.
Impact Analysis چه کمکی به QA میکند؟
فرض کنید یک سیستم ۲۰۰۰ Test Case دارد و فقط یک بخش کوچک آن تغییر کرده است. اجرای دوباره تمام Test Caseها ممکن است زمان و هزینه زیادی داشته باشد.
Impact Analysis به تیم تست کمک میکند تستها را بر اساس اثر احتمالی تغییر و ریسک، هدفمند انتخاب کند.
بهجای اینکه برای هر تغییر کل سیستم را دوباره تست کنیم، ابتدا اثر تغییر را تحلیل میکنیم و سپس بر اساس ریسک و محدوده تأثیر، دامنه مناسب تست را مشخص میکنیم.
نکته مهم این است که Impact Analysis خودش یک نوع تست نیست؛ بلکه فعالیتی است که به تعیین دامنه و اولویت تست پس از تغییر کمک میکند.
۵. عوامل مؤثر بر میزان تست نگهداری
همه تغییرات نرمافزاری به یک اندازه به تست نیاز ندارند. دامنه و میزان تست نگهداری (Maintenance Testing) باید متناسب با شرایط تغییر تعیین شود.
بر اساس ISTQB، سه عامل اصلی در تعیین میزان تست نگهداری عبارتاند از:
۵.۱ میزان ریسک تغییر
هرچه Risk یک تغییر بیشتر باشد، معمولاً به تست گستردهتری نیاز داریم.
برای مثال، تغییر متن یک پیام خطا معمولاً ریسک بسیار کمتری نسبت به تغییر منطق محاسبه موجودی حساب دارد.
بنابراین تغییر در یک بخش حساس مانند موارد زیر ممکن است نیازمند Regression Testing بیشتری باشد:
- پرداخت
- احراز هویت
- محاسبه موجودی
- کنترل دسترسی کاربران
۵.۲ اندازه سیستم موجود
هرچه سیستم بزرگتر و پیچیدهتر باشد، احتمال وجود وابستگی بین بخشهای مختلف آن بیشتر است. در نتیجه، حتی یک تغییر نسبتاً کوچک میتواند روی قسمتهای دیگری از سیستم اثر بگذارد.
برای مثال، تغییر در یک سرویس مرکزی در یک سیستم بانکی بزرگ ممکن است چندین ماژول و سرویس دیگر را تحت تأثیر قرار دهد.
۵.۳ اندازه تغییر
میزان و گستردگی تغییر نیز اهمیت دارد. یک تغییر کوچک در یک Validation ساده با تغییر گسترده در منطق کسبوکار یا معماری سیستم یکسان نیست.
هرچه Size of Change بیشتر باشد، معمولاً لازم است دامنه تست نیز گستردهتر شود.
یک مثال ساده
فرض کنید در BlueBank دو تغییر داریم:
تغییر A: اصلاح متن پیام «رمز عبور اشتباه است».
تغییر B: تغییر الگوریتم محاسبه سود حساب مشتریان.
- تغییر A: ریسک پایینتر، محدوده تغییر کوچک و احتمال تأثیر بر سایر قسمتها کم است.
- تغییر B: ریسک بالاتر، تغییر مهم در منطق کسبوکار و احتمال تأثیر بر گزارشها، موجودی و محاسبات مالی بیشتر است.
بنابراین منطقی است که برای تغییر B تست نگهداری گستردهتر و Regression Testing بیشتری در نظر گرفته شود.
در نتیجه، سه عامل اصلی را میتوان به خاطر سپرد:
Risk of Change + Size of Existing System + Size of Change
۶. تفاوت تست نگهداری و تست رگرسیون
این دو مفهوم به دلیل ارتباط نزدیکی که با یکدیگر دارند، گاهی با هم اشتباه گرفته میشوند. اما Maintenance Testing و Regression Testing یک مفهوم یکسان نیستند.
تست نگهداری چیست؟
Maintenance Testing به تستهایی مربوط میشود که در ارتباط با تغییرات یک سیستم موجود و عملیاتی انجام میشوند.
- رفع یک Bug
- اضافه کردن قابلیت جدید
- Hot Fix
- Migration
- Upgrade
- Retirement سیستم
تست رگرسیون چیست؟
Regression Testing با هدف بررسی این موضوع انجام میشود که یک تغییر باعث ایجاد مشکل در قسمتهایی از سیستم که قبلاً درست کار میکردند نشده باشد.
بنابراین Regression Testing میتواند یکی از اجزای Maintenance Testing باشد.
Maintenance Testing
│
├── بررسی خود تغییر
│ └── Retesting
│
├── بررسی اثر تغییر
│ └── Regression Testing
│
└── سایر تستهای موردنیاز
فرض کنید در BlueBank، نحوه محاسبه کارمزد انتقال وجه تغییر کرده است.
- آیا محاسبه جدید کارمزد درست است؟ این بخش میتواند با Retesting بررسی شود.
- آیا این تغییر روی موجودی حساب، رسید تراکنش، گزارشها یا سایر قابلیتها اثر منفی گذاشته است؟ اینجا Regression Testing اهمیت پیدا میکند.
Maintenance Testing زمینهای است که تست در آن به دلیل تغییر یا نگهداری یک سیستم موجود انجام میشود؛ در حالی که Regression Testing با هدف بررسی اثرات جانبی تغییر بر قابلیتهای قبلی انجام میشود.
بنابراین هر Maintenance Testing الزاماً فقط Regression Testing نیست و Regression Testing نیز الزاماً فقط در Maintenance Testing استفاده نمیشود.
۷. چه کسی تست نگهداری را انجام میدهد؟
تست نگهداری معمولاً یک فعالیت تیمی است و با توجه به نوع تغییر، افراد مختلفی میتوانند در آن نقش داشته باشند. با این حال، مسئولیت فعالیتهای تست معمولاً بر عهده تیم تست یا QA است.
نقش QA / Test Engineer
- بررسی و تست تغییر ایجادشده
- اجرا یا بهروزرسانی Test Caseهای مرتبط
- انجام Retesting
- انتخاب و اجرای Regression Testing مناسب
- مشخص کردن محدوده تست با توجه به Impact Analysis
- گزارش نتایج تست و Defectهای احتمالی
نقش Developer
Developer مسئول پیادهسازی تغییر است و معمولاً تستهای مربوط به کد، مانند Unit Testها، را نیز انجام میدهد.
برای مثال، پس از اصلاح یک Bug در محاسبه کارمزد، Developer میتواند ابتدا با Unit Test بررسی کند که منطق اصلاحشده درست کار میکند. سپس QA تغییر را از دید سیستم و کاربر بررسی میکند.
نقش Test Lead یا QA Lead
در تغییرات بزرگتر، Test Lead میتواند در تعیین Test Scope و میزان تست موردنیاز نقش داشته باشد. عواملی مانند Risk تغییر، Size of Change، Size of Existing System و Impact Analysis در این تصمیم مؤثر هستند.
نقش سایر تیمها
بسته به نوع تغییر، تیمهای دیگری نیز ممکن است در Maintenance Testing مشارکت داشته باشند:
- DevOps / Release Team: برای Deployment، Migration و تغییر Environment
- Business / Product: برای بررسی نیازمندی و Acceptance
- Database Team: در Migration و Data Conversion
- Operations: در تغییرات مربوط به سیستم عملیاتی
بنابراین دقیقتر است بگوییم تیم QA مسئول فعالیتهای تست است، اما Maintenance Testing بسته به نوع تغییر میتواند با مشارکت Developer، DevOps، Business و سایر تیمهای فنی انجام شود.
۸. مثال عملی تست نگهداری در پروژه BlueBank
برای درک بهتر Maintenance Testing، فرض کنیم در پروژه BlueBank تغییر مهمی در قابلیت انتقال وجه ایجاد شده است.
سناریو
در نسخه جدید BlueBank، نحوه محاسبه کارمزد انتقال وجه تغییر کرده است.
- قبل از تغییر: کارمزد انتقال = ۱٪ مبلغ انتقال
- بعد از تغییر: کارمزد بر اساس مبلغ انتقال و نوع حساب مشتری محاسبه میشود.
این تغییر مستقیماً منطق کسبوکار سیستم را تحت تأثیر قرار میدهد و بنابراین میتواند ریسک قابلتوجهی داشته باشد.
مرحله اول: بررسی خود تغییر
ابتدا QA بررسی میکند که منطق جدید درست پیادهسازی شده است.
| نوع حساب | مبلغ انتقال | کارمزد مورد انتظار |
|---|---|---|
| عادی | 1,000,000 | طبق Rule جدید |
| ویژه | 1,000,000 | طبق Rule جدید |
| عادی | 10,000,000 | طبق Rule جدید |
این بخش میتواند Retesting را نیز دربر بگیرد؛ بهخصوص اگر تغییر برای رفع یک Defect قبلی ایجاد شده باشد.
مرحله دوم: Impact Analysis
در مرحله بعد باید بررسی شود که تغییر محاسبه کارمزد ممکن است روی چه قسمتهایی اثر بگذارد.
تغییر محاسبه کارمزد
│
├── انتقال وجه
├── موجودی حساب
├── رسید تراکنش
├── تاریخچه تراکنشها
├── گزارش مالی
└── Notification
بنابراین فقط صفحه انتقال وجه مورد تست قرار نمیگیرد.
مرحله سوم: Regression Testing
حالا Test Caseهای مرتبط با قسمتهای تحت تأثیر اجرا میشوند.
- آیا مبلغ نهایی تراکنش درست است؟
- آیا موجودی حساب بهدرستی کاهش پیدا میکند؟
- آیا رسید تراکنش کارمزد صحیح را نمایش میدهد؟
- آیا گزارش تراکنش مقدار صحیح را ثبت میکند؟
- آیا Notification اطلاعات صحیحی دارد؟
هدف این مرحله پیدا کردن Regressionهای احتمالی است.
مرحله چهارم: بررسی تستهای تکمیلی
با توجه به ریسک تغییر، ممکن است تستهای دیگری نیز لازم باشند:
- Functional Testing
- Boundary Value Analysis
- Decision Table Testing
- Performance Testing
- Security Testing
برای مثال، اگر محاسبه کارمزد بر اساس چند Rule مختلف انجام شود، Decision Table Testing میتواند برای طراحی Test Caseها مناسب باشد.
نتیجه
در این مثال، Maintenance Testing فقط به معنای تست قابلیت جدید نیست.
Change ↓ Impact Analysis ↓ Retesting ↓ Regression Testing ↓ Additional Testing ↓ Release
این مثال نشان میدهد چرا در Maintenance Testing باید علاوه بر خود تغییر، اثرات آن بر سیستم موجود را نیز در نظر گرفت.
۹. نکات مهم ISTQB درباره تست نگهداری
۹.۱ تست نگهداری فقط برای رفع Bug نیست
Maintenance Testing میتواند در شرایط مختلفی انجام شود، از جمله:
- اصلاح خطاها
- Enhancement و تغییرات برنامهریزیشده
- Hot Fix
- Upgrade
- Migration
- Data Conversion
- Retirement سیستم
بنابراین نباید Maintenance Testing را فقط با Bug Fix یا Regression Testing یکی دانست.
۹.۲ سیستم عملیاتی نیز دائماً نیازمند تست است
تست نرمافزار با انتشار اولین نسخه به پایان نمیرسد. هر تغییری در یک سیستم عملیاتی میتواند نیازمند تست باشد. به همین دلیل، Maintenance Testing بخشی از چرخه عمر سیستم است.
۹.۳ Impact Analysis اهمیت زیادی دارد
قبل از ایجاد یک تغییر، Impact Analysis میتواند به تیم کمک کند تا پیامدهای احتمالی تغییر را شناسایی کند و مشخص شود چه قسمتهایی باید تست شوند.
۹.۴ Regression Testing معمولاً بخش مهمی از Maintenance Testing است
پس از تغییر، فقط نباید بررسی کنیم که قابلیت جدید یا اصلاحشده درست کار میکند. باید بررسی کنیم:
آیا این تغییر چیزی را که قبلاً درست کار میکرد، خراب کرده است؟
این همان نقشی است که Regression Testing در بسیاری از سناریوهای Maintenance Testing دارد.
۹.۵ میزان تست ثابت نیست
طبق مفاهیم ISTQB، میزان Maintenance Testing به عوامل مختلفی وابسته است، بهخصوص:
Risk of Change + Size of Existing System + Size of Change
بنابراین برای یک تغییر کوچک و کمریسک ممکن است تست محدودی کافی باشد، در حالی که یک تغییر پرریسک در سیستم بزرگی میتواند به Regression Testing گسترده نیاز داشته باشد.
جمعبندی
Maintenance Testing یا تست نگهداری بخشی از فعالیتهای تست در طول چرخه عمر یک سیستم نرمافزاری است و زمانی اهمیت پیدا میکند که یک سیستم عملیاتی دچار تغییر شود یا محیط و شرایط اجرای آن تغییر کند.
این تست میتواند در ارتباط با Modifications، Upgrades، Migrations و Retirement انجام شود و بسته به نوع تغییر، از فعالیتها و Test Typeهای مختلفی مانند Retesting، Regression Testing، Functional Testing و Non-functional Testing استفاده کند.
مهمترین نکته این است که تست نگهداری فقط به بررسی موفقیت تغییر محدود نمیشود. تیم تست باید با استفاده از Impact Analysis اثرات احتمالی تغییر را بررسی کند و بر اساس Risk، Size of Existing System و Size of Change دامنه مناسب تست را مشخص کند.
در یک جمله:
Maintenance Testing یعنی تست یک تغییر در سیستم عملیاتی و بررسی اینکه آن تغییر باعث ایجاد مشکل در بخشهای موجود سیستم نشده باشد.
