بيئات الاختبار

لماذا يهم

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

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

ممّ تتكوّن بيئة الاختبار

تخيّلها طبقاتٍ حول البناء قيد الاختبار؛ وكل طبقة سؤال يجب أن تعرف إجابته حين تخطط للاختبارات أو تبلّغ عن عيب.

• البناء: الإصدار الدقيق لكل مكوّن قيد الاختبار، مثل web ⁦3.8.0⁩، البناء رقم ⁦214⁩.
• البنية التحتية: الخوادم أو الحاويات، ونظام التشغيل، وعدد النسخ العاملة من التطبيق (Instances)؛ وفي جهة العميل المتصفحات والأجهزة.
• الإعدادات (Configuration): ما يغيّر السلوك دون تغيير الشيفرة، مثل أعلام الميزات (Feature flags) والمنطقة الزمنية واللغة والحدود.
• الاعتماديات (Dependencies): قواعد البيانات وطوابير الرسائل (Queues) وخدمات الأطراف الخارجية مثل الدفع والرسائل القصيرة، وكلٌّ منها إما حقيقي، أو بيئة التجربة (Sandbox) لدى المزوّد، أي نسخة اختبارية من الخدمة يشغّلها المزوّد نفسه، أو بديل (Stub).
• البيانات وصلاحيات الوصول: خط الأساس لبيانات الاختبار والحسابات، إضافةً إلى السجلات التي تستطيع قراءتها.

التطوير والاختبار وStaging والإنتاج

تمرّر معظم الفرق التغيير عبر سلسلة من البيئات، كلٌّ منها أقرب إلى الإنتاج من سابقتها. والأسماء عرفٌ في الصناعة وليست مصطلحات ISTQB، وهي تختلف: فقد تُسمّى بيئة الاختبار QA أو SIT، وStaging ما قبل الإنتاج (Pre-production) أو UAT، والفرق الصغيرة كثيراً ما تكتفي ببيئة واحدة بين التطوير والإنتاج.

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

• التطوير: أجهزة المطوّرين، وأحياناً خادم تطوير مشترك أيضاً؛ اختبارات المكوّن (الوحدة) مع اعتماديات بالمحاكاة (Mocks)؛ أسرع تغذية راجعة وأبعد ما يكون عن الإنتاج.
• الاختبار (QA): يتشاركها المختبِرون لاختبار النظام والتكامل على بيانات اصطناعية يمكن إعادة ضبطها؛ وتصلها أبنية جديدة كثيراً.
• Staging: أقرب ما يمكن إلى الإنتاج في الإصدارات والبنية وحجم البيانات؛ لاختبار الإصدار والقبول ولتجربة النشر نفسه.
• الإنتاج: مستخدمون وبيانات وأموال حقيقية؛ ولا يُجرى فيه إلا فحوص مخطط لها وغير مدمّرة بعد النشر، بحسابات اختبار.
• وكثير من خطوط الأنابيب ينشئ أيضاً بيئة قصيرة العمر لكل طلب دمج (Pull request).

جرّبها: فاحص صحة API

الإعدادات والإصدارات والاعتماديات

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

كل سطر في هذا السجل يحدّ ما تثبته اختباراتك: فإذا كانت Staging ترسل الرسائل القصيرة إلى بديل، فقد أثبتّ أن التطبيق يطلب إرسال الرسالة، لا أن العميل يستلمها.

ويعامل منهج ISTQB بيئة الاختبار بوصفها عنصر تهيئة (Configuration item): فإدارة التهيئة (Configuration management) تسجّل أجزاءها والعلاقات بينها وإصداراتها. وحين تُعتمد البيئة للاختبار يصبح هذا السجل خط أساس (Baseline) لا يتغيّر إلا عبر ضبط التغيير (Change control)، فيمكن إعادة إنتاج النتائج السابقة.

• تُحفظ الإعدادات عادةً خارج البناء، في متغيرات البيئة أو في ملفات، ولهذا قد تنحرف بين البيئات دون أن يلاحظ أحد.
• اكتب الإصدارات كاملة: PostgreSQL 16 وPostgreSQL 16.4 سجلّان مختلفان.
• تحقّق من البناء المنشور قبل أن تختبر: كثير من التطبيقات تعرضه في صفحة «حول» (About) أو في نقطة نهاية للإصدار أو للصحة (Health endpoint).
• كثيراً ما تستجيب بيئات التجربة أسرع من الخدمة الحقيقية وبسلوك أسهل توقعاً.

جرّبها: مقارنة JSON جرّبها: مقارنة النصوص (Diff)

مشكلات تماثل البيئات

تماثل البيئات (Environment parity) يعني أن تختلف البيئات عن الإنتاج بأقل قدر ممكن، وفي جوانب تعرفها فقط. ويوصي مقال Martin Fowler عن التكامل المستمر بالاختبار في نسخة مطابقة لبيئة الإنتاج، وتسمي منهجية Twelve-Factor App هذا الهدف تماثل التطوير والإنتاج (Dev/prod parity)، وتذكر ثلاث فجوات ينبغي تقليصها: الوقت والأشخاص والأدوات.

وتسبب الفجوات نتائج خاطئة في الاتجاهين: نجاح كاذب، أي سلبية كاذبة (False negative)، حين تُخفي البيئة عيباً، وفشل كاذب، أي إيجابية كاذبة (False positive)، حين يُبلَّغ عن بناء قديم أو بيئة تجربة متوقفة على أنهما عيب في المنتج. والتماثل الكامل نادراً ما يكون ممكناً، فاسعَ إلى اختلافات معروفة: كل فجوة قد تؤثر في التغيير إما تُغلق، أو تُختبر بطريقة أخرى، أو تُسجَّل خطراً.

• المنطقة الزمنية: موعد إغلاق عند الساعة ⁦20:00⁩ يُختبر على الساعة الخطأ.
• نسخة واحدة في الاختبار وعدة نسخ في الإنتاج: الملفات أو الجلسات المحفوظة على خادم واحد تختفي.
• بيانات قليلة: تقرير يظهر فوراً على ⁦5,000⁩ صف يتجاوز المهلة على مليون صف.

جرّبها: محوّل المناطق الزمنية

مثال تطبيقي: رفع إيصال نجح في Staging

يتيح الإصدار ⁦3.8.0⁩ للعملاء إرفاق إيصال حتى ⁦5⁩ ميغابايت بطلب الاسترداد. ونجحت حالات الاختبار كلها، وعددها ⁦18⁩، في Staging. وقبل الاعتماد يقارن المختبِر سجلّي البيئتين.

البناء متطابق، فما اختُبر هو ما سيُنشر. وتهمّ هذا التغيير ثلاثة فروق:

• حدّ ⁦2⁩ ميغابايت: في الإنتاج وكيل عكسي (Reverse proxy)، أي خادم يقف أمام التطبيق، يرفض الطلبات الأكبر. الإيصالات التي يزيد حجمها على ⁦2⁩ ميغابايت نجحت في Staging، لكن الإنتاج سيرفضها، عادةً برمز حالة HTTP ⁦413⁩ (Content Too Large)، قبل أن يتمكن التطبيق من عرض رسالته. ارفع الأمر إلى فريق DevOps الآن.
• نسخة واحدة تحفظ الملفات على قرصها المحلي، مقابل ثلاث نسخ تتشارك تخزين الكائنات (Object storage) خلف موازن أحمال (Load balancer) يوزّع الطلبات عليها: لم يُجرَّب التخزين الذي يستخدمه الإنتاج قط، ولأن رفع الإيصال وعرضه قد يصلان إلى خادمين مختلفين، فإن أي شيء ما زال يُحفظ على قرص خادم واحد سيختفي. اطلب تشغيلاً في Staging بنسختين وتخزين مشترك، أو افحص بعد النشر مباشرةً.
• العلم معطّل في الإنتاج: تفعيله تغيير في الإعدادات له مخاطره. اختبر والعلم معطّل أيضاً، واتفق على من يفعّله.
• الدفع والرسائل القصيرة وحجم البيانات تختلف كذلك، لكن رفع الإيصال لا يعتمد عليها: سجّلها اختلافاتٍ معروفة.

Item              staging                  production
----------------  -----------------------  ---------------------------
Build             web 3.8.0+214            web 3.8.0+214
App instances     1                        3, behind a load balancer
Reverse proxy     none                     request body limit 2 MB
File storage      local disk               shared object storage
Database          PostgreSQL 16.4          PostgreSQL 16.4
Time zone         Asia/Riyadh              Asia/Riyadh
refund_receipts   flag on                  flag off until release day
Payment           provider sandbox         live provider
SMS               stub, records messages   live provider
Orders in DB      5,000 synthetic          1.2 million real

جرّبها: مقارنة استجابات API

أسئلة شائعة

المراجع

• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• Continuous Integration (Martin Fowler)martinfowler.com · 2024الوصف الأكثر استشهاداً للتكامل المستمر: ادمج كثيراً، واجعل البناء يختبر نفسه وسريعاً، وأصلح البناء المكسور فوراً.
• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021نماذج ومحتوى وثائق الاختبار — سياسة الاختبار واستراتيجيته وخطته وتقارير الحالة والإنجاز وتقارير الحوادث.