اختبار قبول المستخدم UAT

اختبار قبول المستخدم هو اختبار يقوم به المشتري بنفسه للنظام الجديد قبل أن يوقّع على استلامه. ليس اختبار الشركة التي بنته، بل اختبارك أنت. تجلس أمام البرنامج وتتأكد أنه يؤدي العمل الذي دفعت من أجله.

أفضل طريقة هي أن تكتب عددًا قليلًا من أيام العمل العادية ثم تمر عليها خطوة بخطوة. زبون يشتري ثلاثة أصناف ويدفع نصف المبلغ نقدًا والنصف الآخر بالبطاقة. مريض يحجز موعدًا ثم يتصل ليؤجله. ولي أمر يطلب إيصال رسوم عن الفصل الماضي. كل حالة من هذه سيناريو. اكتبها قبل أن ترى البرنامج، حتى تأتي القائمة من عملك أنت لا من الشاشات التي بناها غيرك.

جرّبها على الأجهزة الحقيقية. الهواتف التي يحملها موظفوك فعلًا، وطابعة الإيصالات خلف الطاولة، وماكينة البطاقات، والحاسوب القديم في المكتب الخلفي. الاختبار على جهاز سريع عند المبرمج لا يثبت شيئًا يُذكر. وعندما تسلّم لينكي سوفت لنظم المعلومات نظام عيادة، نطلب من موظفة الاستقبال أن تمر على صباح ثلاثاء عادي من مكتبها هي وبطابعتها هي. نصف ما يتعطل في الأسبوع الأول سببه طابعة أو اتصال بطيء أو شاشة أصغر مما توقع الجميع.

حدّد مسبقًا من الذي يوقّع. شخص واحد باسمه من جهتك، وغالبًا هو من سيُلام إذا ساءت الأمور. احجز له وقتًا حقيقيًا في جدوله، نصف يوم لا عشرين دقيقة بين اجتماعين. ثم اتفقوا على ما يحدث للمشكلات التي تظهر بعد التوقيع. هذا هو الجزء الذي يتجاهله الناس. اطلب فترة ضمان مكتوبة، ثلاثين يومًا أو تسعين، يُصلَّح فيها بلا مقابل كل ما يخالف السيناريوهات المتفق عليها.

الخطأ الأكثر شيوعًا هو تجربة الطريق السهل فقط. كل شيء يعمل حين يدفع الزبون كامل المبلغ ولا يُرجع شيئًا. جرّب الاسترجاع، والحجز الملغى، والسعر الخاطئ، والموظف الذي ترك العمل الشهر الماضي. في لينكي سوفت نكتب قائمة السيناريوهات مع العميل قبل أن يبدأ مشروع تطبيق الويب، ونستخدم القائمة نفسها للجانب الهاتفي عند بناء تطبيق الهاتف. هكذا يُحسم الخلاف على معنى كلمة انتهى مبكرًا، لا في النهاية حيث يكلّف مالًا.