سازگاری افزونه یک جمله کلی نیست؛ ترکیبی از نسخه Jira، نوع artifact، مرورگر، context صفحه، نوع فیلد و افزونههای مکمل است. هرچه UI پویاتر و integrationها بیشتر باشند، آزمون واقعی اهمیت بیشتری پیدا میکند.
نسخه build با نسخه runtime یکی نیست
مخزن عمومی فعلی نسخه افزونه را 11.4.61 ثبت کرده و در pom، Jira 9.12.0 و Java 11 بهعنوان target build آمده است. descriptor نیز Data Center compatibility را اعلام میکند. این اطلاعات نشان میدهد artifact برای یک محدوده مشخص ساخته شده، اما بهتنهایی پشتیبانی runtimeهای دیگر را اثبات نمیکند.
برای Jiraهای جدیدتر، نسخه Java، APIهای تغییرکرده، namespaceهای javax/jakarta و رفتار UI باید با نصب واقعی بررسی شوند. نتیجه آزمون را بهصورت مستند و نسخهمحور نگه دارید.
matrix آزمون پیشنهادی
بهجای یک تست کلی، ردیفهای matrix را بر اساس context بسازید. یک افزونه ممکن است در صفحه create issue درست کار کند اما در inline edit، JSM portal یا iframe JXL نیاز به آزمون جدا داشته باشد.
- Jira version × نوع استقرار
- Browser × زبان و timezone
- Date field × DateTime field
- Create/Edit × Inline Edit × Search
- Jira Core × JSM × Roadmaps × JXL × Audit Log
افزونههای مکمل و UI پویا
کد افزونه adapterهایی برای contextهای متنوع دارد و برای محتوای پویا از listener و observer استفاده میکند. این رویکرد پوشش بیشتری میدهد، اما selectorهای UI محصولات مکمل ممکن است با یک update تغییر کنند. هنگام ارتقا، smoke test سناریوهای تاریخ را در pipeline نگهداری یا checklist release قرار دهید.
معیار قبولی
معیار قبولی را از قبل تعریف کنید: popup بدون تداخل باز شود، تاریخ انتخابشده درست save شود، refresh مقدار درست را نشان دهد، جستوجو و گزارش قابل فهم باشد و failure license یا endpoint رفتار مشخصی داشته باشد. «تقویم باز شد» معیار کافی برای go-live نیست.
پیشنهاد Desktopcenter
در پروژههای سازمانی، ابتدا inventory و compatibility assessment انجام میدهیم، سپس pilot را با داده و integrationهای واقعی اجرا میکنیم. اگر نسخه هدف در محدوده build مستند نباشد، نتیجه را بهصورت «نیازمند آزمون» اعلام میکنیم و از وعده قطعی بدون evidence پرهیز میشود.