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