درخواست کاربر چهارشنبه، نیم ساعت مانده به پایان روز کاری ثبت میشود. تعهد پاسخ دو ساعت کاری است، اما سامانه مهلت را همان شب نشان میدهد. تیم پشتیبانی به افزونه تقویم شمسی مشکوک میشود؛ در حالی که ممکن است نمایش تاریخ کاملاً درست باشد و درخواست، تقویم کاری شعبه دیگری را دریافت کرده باشد.
تقویم کاری سرویس دسک فقط یک انتخابگر تاریخ نیست. برای محاسبه درست مهلتها باید ساعات ارائه خدمت، تعطیلات، منطقه زمانی و سیاست توافق سطح خدمت با هم سازگار باشند. این مقاله یک طرح آزمون پذیرش برای ServiceDesk Plus ارائه میکند تا پیش از تحویل سامانه یا پس از ارتقا، تفاوت میان خطای نمایش و خطای محاسبه روشن شود. مثالها آموزشی هستند و نتیجه نهایی باید در نسخه و تنظیمات واقعی سازمان آزمون شود.
چهار لایهای که نباید یکی فرض شوند
تقویم نمایشی، شکل خواندن تاریخ را تعیین میکند؛ منطقه زمانی، ساعت محلی یک لحظه را مشخص میکند؛ تقویم کاری، بازههای ارائه خدمت را تعریف میکند و سیاست سطح خدمت میگوید مهلت یک درخواست چگونه تعیین شود. درست بودن یکی از این لایهها، سه لایه دیگر را تضمین نمیکند.
| لایه | پرسش درست | نمونه خطا |
|---|---|---|
| نمایش تاریخ | کاربر همان تاریخ مورد نظر را میبیند؟ | تبدیل دوباره تاریخ در نمایشگر |
| منطقه زمانی | ساعت نمایشدادهشده متعلق به کدام منطقه است؟ | تفاوت ساعت در مرورگر و گزارش |
| ساعات و تعطیلات | کدام بازهها برای این خدمت کاری هستند؟ | اعمال تعطیلات دفتر مرکزی به شعبه |
| سیاست مهلت | برای این نوع درخواست چه توافقی اعمال شده است؟ | استفاده از تعهد شبانهروزی برای پشتیبانی اداری |
به همین دلیل، نصب تقویم شمسی را معادل وارد شدن خودکار تعطیلات سازمان یا اصلاح همه توافقهای زمانی در نظر نگیرید. هر کدام باید مسئول تنظیم و معیار پذیرش جداگانه داشته باشند.
ابتدا نسخه و دامنه تنظیمات را مشخص کنید
معرفی رسمی امکانات میز خدمت، تنظیمات پیشفرض یا وابسته به سایت برای ساعات کاری، تعطیلات، منطقه زمانی و توافقهای سطح خدمت را توضیح میدهد. همچنین در راهنمای پشتیبانی چندمکانی، ارتباط گروهها و کارشناسان با محل ارائه خدمت مطرح شده است. پیش از آزمون، مشخص کنید درخواست متعلق به کدام سایت و گروه است و تنظیم مؤثر آن از کجا میآید.
مسیر منو و جزئیات اولویت تنظیمات را از راهنمای همان محصول بخوانید. نسخه ابری، داخلی و نسخه ارائهدهندگان خدمات را یکسان فرض نکنید. در صورت وجود چند محل، تنها آزمودن دفتر مرکزی برای پذیرش کل سازمان کافی نیست.
نکته مخصوص نسخه ابری
در یادداشتهای رسمی نسخه ابری، ساعات کاری مبتنی بر گروه، ساعات ویژه و گروههای تعطیلات مستند شدهاند. این مستند توضیح میدهد که نبود ارتباط اختصاصی برای سایت یا گروه میتواند موجب استفاده از تنظیم پیشفرض شود. بنابراین یک فیلد خالی الزاماً به معنی «بدون تقویم» نیست؛ باید نتیجه واقعی آن را کنترل کرد. این توضیح را بدون بررسی به همه نسخههای داخلی تعمیم ندهید.
یک مثال ساده برای محاسبه دستی مهلت
فرض آموزشی ما این است: سازمان از شنبه تا چهارشنبه، ساعت ۸ تا ۱۶ کار میکند؛ پنجشنبه و جمعه غیرکاری هستند؛ وقفه میانروزی وجود ندارد؛ مهلت از زمان ثبت درخواست آغاز میشود و هیچ توقف یا تغییر سیاستی رخ نمیدهد. درخواست چهارشنبه ساعت ۱۵:۳۰ ثبت شده و دو ساعت کاری فرصت دارد.
در چهارشنبه فقط نیم ساعت مصرف میشود. یک ساعت و نیم باقیمانده از ساعت ۸ نخستین روز کاری بعد ادامه پیدا میکند. پس بدون تعطیلی اضافی، مهلت شنبه ساعت ۹:۳۰ است. اگر شنبه هم در تقویم مؤثر تعطیل باشد، با همان فرضها مهلت یکشنبه ساعت ۹:۳۰ خواهد بود.
| حالت آزمایشی | زمان قابل محاسبه | نتیجه مورد انتظار در مثال |
|---|---|---|
| تقویم اداری بدون تعطیلی اضافی | نیم ساعت چهارشنبه و یک ساعت و نیم شنبه | شنبه ۹:۳۰ |
| شنبه تعطیل در تقویم مؤثر | نیم ساعت چهارشنبه و یک ساعت و نیم یکشنبه | یکشنبه ۹:۳۰ |
| تعهد دو ساعت پیوسته شبانهروزی | دو ساعت پس از ثبت | چهارشنبه ۱۷:۳۰ |
این جدول خروجی تضمینشده همه پیکربندیها نیست؛ یک پاسخ مرجع برای آزمونی با فرضهای روشن است. اگر زمان سامانه متفاوت شد، ابتدا توافق اعمالشده، شروع شمارش، تقویم مؤثر و تغییرات تاریخچه را بررسی کنید، نه اینکه فوراً ساعت سرور را دستکاری کنید.
طرح آزمون را با مرزهای زمانی بسازید
ابتدا و انتهای روز کاری
درخواستهایی با زمان معلوم در ابتدای روز، نزدیک پایان روز و خارج از ساعات کاری ایجاد کنید. برای هر کدام پاسخ مرجع را پیشاپیش بنویسید. مرز دقیق پایان روز را نیز با دقت زمانی قابل پشتیبانی سامانه آزمایش کنید تا اختلاف گرد کردن دقیقه یا ثانیه با خطای واقعی اشتباه نشود.
تعطیلات و روزهای استثنایی
یک تعطیلی آزمایشی را فقط در دامنه مجاز تعریف کنید و نتیجه را با یک روز عادی مقایسه کنید. تعطیلات متحرک یا برنامههای موقت سازمان را بدون کنترل تاریخ به تکرار سالانه تبدیل نکنید. وجود تاریخ در فهرست، کافی نیست؛ ارتباط آن با سایت یا گروه هدف نیز باید درست باشد.
شیفت عبوری از نیمهشب
برای تیم شبکار، روز تقویمی و شیفت عملیاتی ممکن است یکسان نباشند. در آزمون مشخص کنید شیفت از چه ساعتی شروع میشود و به کدام روز بعد میرسد. درخواست پیش و پس از نیمهشب را مقایسه کنید. قابلیت تنظیم چنین شیفتی و رفتار تعطیلات در آن باید از نسخه واقعی استخراج شود.
تقویم شمسی را با آزمون رفتوبرگشت بسنجید
در صفحه افزونه فارسیساز و تقویم شمسی مدانت، هدف بومیسازی نمایش و ورود تاریخ معرفی شده است. برای پذیرش در یک سازمان، یک تاریخ معلوم را از فرم وارد کنید، ذخیره کنید و دوباره همان رکورد را باز کنید. سپس آن را در فهرست، جزئیات، اعلان و خروجی مرتبط مقایسه کنید.
در این آزمون، ثابت ماندن لحظه و تاریخ مورد نظر مهم است، نه یکسان بودن ظاهر رشته در همه خروجیها. یک خروجی ممکن است طبق قرارداد رابط برنامهنویسی تاریخ را با قالب دیگری ارائه کند. قالب ذخیرهسازی یا نوع داده را حدس نزنید؛ قرارداد همان رابط و نتیجه خواندن دوباره رکورد را مبنا قرار دهید. ورود ارقام فارسی و انگلیسی نیز باید بدون تغییر معنای تاریخ آزمون شود.
تغییر زبان رابط نباید دلیل پنهان کردن اختلاف زمان باشد. وقتی تقویم نمایشی عوض میشود، بررسی کنید مهلت همان درخواست و بازه گزارش همچنان به همان دوره اشاره کنند.
تغییر گروه یا سایت را در آزمون فراموش نکنید
ممکن است درخواست ابتدا در صف عمومی ثبت و بعد به شعبه یا تیم شبانهروزی منتقل شود. رفتار مهلت پس از این انتقال باید روشن باشد: آیا سیاست دوباره انتخاب میشود، زمان قبلی حفظ میشود یا قاعده دیگری اعمال میگردد؟ پاسخ را از اجرای واقعی و تاریخچه درخواست به دست آورید؛ از روی نام گروه نتیجهگیری نکنید.
برای هشدارهای نزدیک مهلت، راهنمای طراحی ارجاع و هشدار زمانی مکمل این موضوع است. هشدار درست، روی مهلت اشتباه، فقط خطا را سریعتر به مدیر منتقل میکند.
چه مدارکی باید هنگام تحویل باقی بماند؟
برای هر آزمون، شناسه درخواست، زمان شروع، سایت، گروه، توافق اعمالشده، پاسخ مرجع و خروجی واقعی را ثبت کنید. شماره نسخه نرمافزار و افزونه نیز بخشی از این مدرک است. تصویری که فقط یک تاریخ سبز را نشان میدهد، برای تشخیص تفاوت پیکربندی دو محیط کافی نیست.
پس از ارتقای محصول، تغییر افزونه، اصلاح منطقه زمانی یا جابهجایی سیاستهای گروهی، همین مجموعه آزمون را تکرار کنید. این تکرار، آزمون بازگشتی نام دارد و برای جلوگیری از بازگشت خطاهای قبلی مفید است. روش اجرا و تفسیر نتیجه را در پایگاه دانش معتبر سرویس دسک نگه دارید تا وابسته به حافظه یک کارشناس نباشد.
نکات کلیدی
- نمایش شمسی، منطقه زمانی، تقویم کاری و سیاست مهلت را جداگانه بررسی کنید.
- محاسبه دستی با فرضهای روشن، مرجع مناسبی برای آزمون است.
- تعطیلات باید به دامنه درست متصل باشند؛ ثبت آنها بهتنهایی کافی نیست.
- پس از ارتقا، آزمون فرم، گزارش، اعلان و تغییر گروه را تکرار کنید.
سخن پایانی
تقویم کاری درست، فقط تاریخ خوانا تولید نمیکند؛ تعهد زمانی سازمان را به رفتاری قابل پیشبینی تبدیل میکند. وقتی هر مهلت با یک آزمون روشن قابل توضیح باشد، اختلاف میان کاربر، کارشناس و مدیر نیز بر اساس شواهد بررسی میشود، نه برداشت متفاوت از ساعت و تعطیلی.
برای بومیسازی، بررسی سازگاری نسخه و طراحی آزمون پذیرش سرویس دسک پلاس، از افزونهها و خدمات تخصصی مدانت استفاده کنید. دامنه پیادهسازی، آموزش و پشتیبانی را میتوان در جلسه فنی مدانت با تقویم واقعی سازمان تطبیق داد.
منابع
- امکانات رسمی میز خدمت و تنظیمات سایت
- پشتیبانی چندمکانی
- یادداشتهای نسخه ابری
- معرفی افزونه تقویم شمسی مدانت
