لا تحذف بيانات الاختبار—افصلها عن الإيراد الحقيقي

لا تختفِ المشكلة عندما تحذف بيانات الاختبار؛ بل تختفي الأدلة التي تساعدك على فهمها. وفي المقابل، إذا احتسبت كل عملية اختبار ضمن الإيراد والعملاء ومعدل التحويل، فستبدو لوحة SaaS أفضل مما هي عليه فعلاً. الحل العملي هو الاحتفاظ ببيانات الاختبار مع فصلها بوضوح عن البيانات الحقيقية.

خطآن شائعان يفسدان الصورة

الخطأ الأول هو حذف عمليات الاختبار من قاعدة البيانات. هذا يجعل التحقيق في الأخطاء، ومراجعة مسار الدفع، ومقارنة سلوك البيئات أكثر صعوبة.

الخطأ الثاني هو إبقاء البيانات من دون تمييزها، ثم السماح لها بالدخول في مؤشرات الأداء. عندها قد تُحسب دفعة اختبارية كإيراد، أو حساب تجريبي كعميل، أو رحلة اختبارية كتحويل حقيقي.

اجعل وضع البيانات جزءاً من المصدر

أضف حقلاً صريحاً مثل data_mode إلى الحدث أو العملية منذ لحظة إنشائها. يمكن أن تكون قيمته real أو test، وإذا تعذر تحديده مؤقتاً فليكن unknown بدلاً من التخمين.

هذا المبدأ ينسجم مع طريقة Stripe في فصل بيئات الاختبار عن الوضع الحي عبر sandboxes وبيانات اختبار مستقلة. المصدر الرسمي: https://docs.stripe.com/testing

طبقات الفصل الثلاث

1. طبقة التخزين

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

2. طبقة التحليلات

اجعل الاستعلامات التي تحسب الإيراد والعملاء والتحويلات تستخدم real فقط. وفي المقابل، أنشئ لوحات منفصلة لمراقبة test وunknown حتى تكتشف الأعطال أو التسرب بين البيئات.

3. طبقة الواجهة

اعرض البيانات الثلاث بوضوح. استخدم شارة TEST أو لوناً مختلفاً للسجلات التجريبية، ولفت الانتباه إلى unknown لأنه يعني أن سلسلة القياس لم تثبت نوع البيانات بعد.

القاعدة التي يجب أن يحميها الكود

القاعدة الأساسية بسيطة:

• real يظهر في المؤشرات التجارية.
• test يبقى مرئياً للتصحيح، لكنه لا يدخل في الإيراد أو عدد العملاء أو معدل التحويل.
• unknown لا يُحسب تلقائياً كحقيقي؛ بل يدخل قائمة مراجعة حتى يُحسم مصدره.

ولا يكفي اختبار المسار الإيجابي فقط. أضف اختبارات سلبية تثبت أن بيانات test وunknown لا تستطيع الدخول إلى مؤشرات real حتى بعد تعديل الكود أو ترحيل البيانات.

ماذا نفعل بالبيانات القديمة؟

لا تفترض أن كل سجل قديم حقيقي. نفّذ backfill اعتماداً على أدلة قابلة للتحقق، مثل وضع بوابة الدفع، البيئة، مفاتيح API، معرّفات الاختبار أو حسابات معروفة. أي سجل بلا دليل كافٍ يبقى unknown حتى تتم مراجعته.

إجابات قصيرة

هل يجب حذف بيانات الاختبار من الإنتاج؟

لا. احتفظ بها إذا كانت مفيدة للتدقيق والتصحيح، لكن افصلها بعلامة واضحة واستبعدها من مؤشرات الأعمال.

هل يكفي إخفاء بيانات الاختبار في الواجهة؟

لا. يجب تطبيق الفصل في مصدر البيانات والاستعلامات والحسابات، لا في العرض فقط.

لماذا نحتاج حالة unknown؟

لأن التخمين بأن السجل حقيقي قد يلوث الإيراد، والتخمين بأنه اختبار قد يخفي عميلاً حقيقياً. unknown يجعل عدم اليقين مرئياً وقابلاً للمراجعة.

الخلاصة

البيانات الجيدة ليست البيانات النظيفة شكلياً؛ بل البيانات التي تحتفظ بالحقيقة وتوضح حدودها. عندما تفصل real وtest وunknown في التخزين والتحليل والواجهة، تستطيع تصحيح النظام من دون أن تفسد مؤشرات القرار.