هندسة الجودة

لماذا يهم

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

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

ضمان الجودة التقليدي وهندسة الجودة

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

• التوقيت: بعد «انتهاء» التطوير (ضمان الجودة التقليدي)، مقابل من جلسة التنقيح حتى الإنتاج (هندسة الجودة).
• من يشارك: فريق اختبار منفصل، مقابل الفريق كله، مع مهندسي جودة يمكّنون الآخرين ويوجّهونهم.
• الناتج الرئيسي: تقارير الأخطاء وتقارير تنفيذ الاختبار، مقابل فحوص مؤتمتة في خط الأنابيب وتصميمات قابلة للاختبار وإشارات من الإنتاج، إضافةً إلى تقارير الأخطاء.
• التغذية الراجعة: بعد أيام أو أسابيع من كتابة الشيفرة، مقابل دقائق بعد كل تغيير ثم مرة أخرى من الإنتاج.
• السؤال الموجِّه: «هل وجدنا العيوب؟» مقابل «كيف نجعل إدخال العيوب صعباً واكتشافها سريعاً؟».

بناء الجودة في المنتج: قابلية الاختبار والأتمتة وقابلية الرصد

ثلاث خصائص هندسية تحمل معظم العمل؛ وهندسة الجودة تخطط للثلاث معاً، لكل ميزة، قبل كتابة الشيفرة.

• قابلية الاختبار (Testability): يضع معيار ISO/IEC ⁦25010⁩ قابلية الاختبار ضمن قابلية الصيانة: مدى فاعلية وكفاءة وضع معايير الاختبار وإجراء الاختبارات للتحقق منها. واسأل عن كل ميزة: هل تستطيع التحكم فيها (الوصول إلى جلسة منتهية عبر واجهة برمجية، وضبط الساعة)، ورؤيتها (استجابات واضحة، وأحداث في السجل، ومعرّفات اختبار ثابتة أو test ids)، وعزلها (استبدال مزوّد الدفع ببديل اختبار أو test double).
• الأتمتة: الفحوص التي يجب أن تنجح مع كل تغيير تعمل في خط الأنابيب (pipeline) على أدنى مستوى يستطيع كشف العيب، فيظهر الانحدار بعد دقائق من التغيير الذي سببه. وشيفرة الاختبار برمجيات: من دون مراجعة وسياسة للاختبارات المتذبذبة (flaky) لا يثق بها أحد.
• قابلية الرصد (Observability): فهم ما يفعله النظام أثناء عمله من الإشارات التي يصدرها، وهي عادةً السجلات (logs) والمقاييس (metrics) والتتبعات (traces). وفي المراقبة تابع الإشارات الذهبية الأربع التي عرفتها في درس الإزاحة لليسار والإزاحة لليمين: زمن الاستجابة (latency)، وحجم الحركة (traffic)، والأخطاء (errors)، والتشبّع (saturation). والإشارات الجيدة تحوّل «فشلت عملية الشراء» إلى «انتهت مهلة استدعاء خدمة الدفع لهذا الطلب».

جرّبها: مولّد استجابات API وهمية جرّبها: فاحص صحة API

مثال تطبيقي: مواعيد التوصيل مع بناء الجودة من البداية

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

• قابلية الاختبار: تقرأ الخدمة الوقت من ساعة يستطيع الاختبار ضبطها؛ ونقطة نهاية متاحة للاختبار فقط تملأ موعداً بـ⁦19⁩ حجزاً؛ ويحصل منتقي المواعيد على معرّفات اختبار ثابتة.
• الأتمتة: اختبارات وحدة لوقت الإغلاق عند ⁦3:00:01⁩ و⁦3:00:00⁩ و⁦2:59:59⁩ قبل البداية (المتفق عليه: مغلق عند ⁦3:00:00⁩ تماماً)؛ واختبارات واجهة برمجية للحجز رقم ⁦20⁩ (مقبول) ورقم ⁦21⁩ (مرفوض مع SLOT_FULL)؛ واختبار واحد لواجهة المستخدم للمسار السعيد.
• قابلية الرصد: كل حجز مرفوض يسجّل حدثاً منظّماً مع سببه؛ ولوحة متابعة تعرض حالات الرفض بحسب السبب؛ وتنبيه يُطلق إذا هبطت الحجوزات إلى الصفر خلال ساعات العمل.
• ما يبقى يدوياً: استكشاف حالة عميلين يحجزان آخر مكان في اللحظة نفسها، وأوقات المواعيد بالعربية.
• بعد الإصدار تُظهر اللوحة حالات رفض SLOT_FULL لمواعيد ما زالت تعرض أماكن شاغرة. ويحمل حدث السجل أدناه معرّف الموعد ومعرّف الطلب، فيعيد المختبِر إنتاج الحالة خلال ساعة: الطلبات الملغاة كانت ما زالت تُحتسب.

{
  "time": "2026-10-01T18:42:07Z",
  "level": "warn",
  "event": "slot_booking_rejected",
  "reason": "SLOT_FULL",
  "slot_id": "SLOT-7781",
  "booked_count": 20,
  "capacity": 20,
  "order_id": "ORD-58213",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736"
}

جرّبها: مولّد معايير القبول

ماذا يفعل مهندس الجودة

تتنوع المسميات، مثل مهندس الجودة ومهندس QA وSDET، لكن مهندس الجودة مختبِر أولاً: يبقى تحليل المخاطر وتصميم الاختبار والاختبار الاستكشافي في صميم عمله. ويصف منهج ISTQB للمستوى التأسيسي نهج الفريق الكامل (Whole-team approach)، الذي يستطيع فيه أي شخص يملك المعرفة والمهارات اللازمة أداء أي مهمة، ويكون الجميع مسؤولين عن الجودة؛ ومهندس الجودة يجعل ذلك عملياً.

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

• طرح أسئلة قابلية الاختبار والمخاطر و«كيف سنعرف؟» في جلسات التنقيح.
• التخطيط لأي الفحوص تعمل على مستوى الوحدة والواجهة البرمجية وواجهة المستخدم، وما يُترك للاستكشاف.
• كتابة الاختبارات المؤتمتة ومراجعتها، ومساعدة المطورين على كتابة اختبارات أفضل.
• إبقاء خط الأنابيب جديراً بالثقة: بوابات جودة ذات معنى، ولا اختبارات متذبذبة مُهمَلة.
• الاتفاق مع المطورين وفريق العمليات على الإشارات التي تُتابع بعد الإصدار.
• الاختبار الاستكشافي، وتقارير العيوب المدعومة بالأدلة، والتعلّم من العيوب المفلتة.

جرّبها: مولّد الاختبار المبني على المخاطر جرّبها: مولّد سيناريوهات الانحدار

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023نموذج جودة المنتج: الملاءمة الوظيفية وكفاءة الأداء والتوافق وقابلية التفاعل والموثوقية والأمان وقابلية الصيانة والمرونة.
• Monitoring Distributed Systems — Site Reliability Engineering (Rob Ewaschuk)Google / O'Reilly Media · 2016إرشادات SRE من Google في المراقبة: المراقبة من الخارج (black-box) مقابل المراقبة من الداخل (white-box)، والإشارات الذهبية الأربع — زمن الاستجابة والحركة والأخطاء والتشبّع.