مصفوفة تتبع المتطلبات
مصفوفة تتبع المتطلبات
مصفوفة تتبع المتطلبات (RTM) هي جدول يربط كل متطلب في وثيقة المتطلبات SRS بحالات الاختبار التي تتحقق منه، ثم يمتد إلى نتائج الاختبار التي تُثبت أنه اختُبر فعلًا. إذا لم يكن للمتطلب صف في مصفوفة RTM، فقد لا يُختبر أبدًا. وإذا لم تحمل حالة الاختبار عمودًا للمتطلب، فلن يعرف أحد القاعدة الأعمالية التي تحميها. المصفوفة تُغلق هاتين الفجوتين معًا.
يسير التتبع في اتجاهين:
- التتبع الأمامي — من المتطلبات نزولًا إلى حالات الاختبار والنتائج. يجيب على: "هل كتبنا اختبارات لكل ما طُلب منا بناؤه؟"
- التتبع العكسي — من حالات الاختبار صعودًا إلى المتطلبات. يجيب على: "هل كل اختبار كتبناه يرتبط بشيء طلبه أصحاب المصلحة فعلًا؟ هل نختبر خارج النطاق المتفق عليه؟"
تشريح مصفوفة RTM
تحتوي المصفوفة في حدودها الدنيا على هذه الأعمدة:
- معرف المتطلب — المعرّف الفريد من وثيقة SRS (مثل
FR-012). - وصف المتطلب — عبارة مختصرة تصف ما يقوله المتطلب.
- معرفات حالات الاختبار — معرّف (أو أكثر) لحالات الاختبار التي تغطي هذا المتطلب.
- نتيجة الاختبار — ناجح أو فاشل أو لم يُنفَّذ بعد (تُحدَّث بعد كل دورة اختبار).
تضيف المصفوفات الأكثر نضجًا أعمدة لأثر التصميم الذي يُجسّد المتطلب (مثل اسم الفئة أو نقطة نهاية API)، والأولوية، والإصدار أو السبرنت المجدوَل فيه. احتفظ بالجدول بقدر ما يحتاجه مشروعك — الهدف الأساسي هو رؤية التغطية، لا البيروقراطية.
المخطط الأول: هيكل مصفوفة RTM لنظام حجز عيادة طبية
تخيّل نظام حجز مواعيد في عيادة طبية. تحتوي وثيقة SRS على ستة متطلبات وظيفية. تُظهر المصفوفة أدناه كيف يرتبط كل منها بحالات الاختبار ونتائجها بعد دورة الاختبار الأولى.
قراءة المصفوفة
ثلاثة إشارات تلفت النظر في المصفوفة أعلاه فور تصفّحها:
- الصفوف الخضراء (PASS) — المتطلب مُغطى بحالة اختبار واحدة على الأقل وجميعها اجتازت الاختبار. الميزة تعمل كما هو محدد.
- الصف الأحمر (FAIL) — للمتطلب
FR-003حالات اختبار لكنها فشلت. هذه ليست مشكلة تغطية؛ إنها عيب. يجب على المحلل فتح تذكرة عيب وتتبّعها حتى الحل قبل اجتياز بوابة الجودة. - الصفوف العنبرية (NOT RUN) — للمتطلب
FR-005حالات اختبار لكن دورة الاختبار لم تصل إليها بعد. أماFR-006فأسوأ: لا توجد له حالات اختبار على الإطلاق. هذه فجوة تغطية — متطلب قد يصل إلى الإنتاج دون أي دليل على عمله.
FR-006 إلى الإنتاج بلا تغطية اختبارية، فإن أي عيب في استرجاع سجل المواعيد سيكتشفه المستخدمون الحقيقيون لا المختبِرون. كلما ظهر صف يحمل "none defined" في عمود حالة الاختبار، يجب على المحلل معالجته كعائق أمام دورة الاختبار التالية.
المخطط الثاني: سلسلة التتبع — من المتطلب إلى الدليل
مصفوفة RTM ليست مجرد جدول ثابت. إنها تمثّل سلسلة أدلة. كل متطلب في وثيقة SRS يتدفق نزولًا عبر التصميم إلى حالات الاختبار، ثم إلى سجلات تنفيذ الاختبار. يُظهر المخطط أدناه هذه السلسلة لميزة تتبع الطرود في شركة لوجستية.
بناء مصفوفة RTM عمليًا
يبني المحللون عادةً المصفوفة ويصونون تحديثها في جدول بيانات (Excel أو Google Sheets) أو داخل أداة إدارة المتطلبات المتخصصة (مثل Jira أو Confluence أو Helix ALM). تسير العملية عبر هذه الخطوات:
- زرع الصفوف. صدِّر كل معرّف متطلب ووصفه من وثيقة SRS. كل منها يحصل على صف. في هذه المرحلة تكون أعمدة حالة الاختبار والنتيجة فارغة.
- تعيين حالات الاختبار. بينما يكتب فريق الاختبار حالاته، يُوسم كل منها بمعرّف المتطلب الذي يغطيه. تُحدَّث المصفوفة بهذه المعرّفات. متطلب واحد قد تكون له حالات اختبار متعددة؛ وحالة اختبار واحدة قد تغطي متطلبات متعددة (رغم أن تغطية الكثير في حالة واحدة علامة على ضرورة تقسيمها).
- فحص الفجوات. بعد الجولة الأولى، أي صف بلا معرّف حالة اختبار هو فجوة تغطية. يرفع المحلل الأمر إلى مسؤول الاختبار — إما يُكتب اختبار أو يُتخذ قرار رسمي بقبول الخطر (موثّق كتابيًا).
- التحديث بعد كل دورة اختبار. حين تنتهي جولة الاختبار، تُسجَّل النتائج (ناجح/فاشل/محجوب) في عمود النتيجة. الصفوف الفاشلة تُولّد تذاكر عيوب ترتبط بمعرّف المتطلب.
- استخدامها عند بوابات الجودة. قبل الإصدار لقبول المستخدم أو الإنتاج، تُراجَع المصفوفة. يجب استيفاء العتبة المتفق عليها (مثلًا: 100% من المتطلبات لها حالات اختبار، و95% منها ناجحة). أي متطلب فاشل إما يُصحَّح أو يُؤجَّل رسميًا.
أنماط فاشلة في تطبيق مصفوفة RTM
المصفوفة مفيدة فقط إذا ظلّت دقيقة. تجنّب هذه الأخطاء الشائعة في المشاريع الحقيقية:
- حالة الاختبار اليتيمة. حالة اختبار لا ترتبط بأي متطلب إما تختبر شيئًا لم يطلبه أحد (تمدد النطاق) أو المتطلب حُذف ولم تُنظَّف الاختبارات تبعًا لذلك. كلاهما يُهدر وقت المختبِرين.
- معدل النجاح الوهمي. وضع علامة "ناجح" على اختبار نُفِّذ جزئيًا فقط. هذا يُضخّم نسبة التغطية ويُضلّل أصحاب المصلحة عند بوابات الجودة.
- حالة اختبار واحدة لكل متطلب. حالة اختبار واحدة نادرًا ما تغطي جميع حالات الحدود في متطلب. المتطلب
FR-003("بريد التأكيد خلال دقيقتين") يحتاج على الأقل ثلاث حالات: المسار الطبيعي، والنظام تحت ضغط عالٍ، وعدم توفر خدمة البريد. الاكتفاء بحالة واحدة يُخلّف مخاطر خفية. - المصفوفة المكتوبة بأثر رجعي. حين يملأ المحللون المصفوفة بعد الاختبار لا قبله، يربطون اللاوعي حالات الاختبار بمتطلبات تبدو مطابقة — عوضًا عن تحديد التغطية المفقودة استباقيًا قبل فوات الأوان لكتابة اختبارات جديدة.
في الدرس التالي نتناول إدارة العيوب — كيف تُرفع العيوب المكتشفة من خلال اختبار مدفوع بمصفوفة RTM وتُصنَّف وتُرتَّب أولوياتها وتُحلّ ضمن سير عمل المشروع.