أضافت SaveLink إلى SaveTest سجلّ متطلبات ومقارنة بين الفروع وتخطيط التشغيلات

أصدرت شركة SaveLink تحديثًا لمنصة إدارة الاختبارات SaveTest. نُشر الإعلان في 8 أكتوبر 2026، وهو يذكر ثلاث وظائف رئيسية: سجلّ متطلبات مع مصفوفة تتبّع، ومقارنة بين الفروع، وتخطيط تشغيلات الاختبار. لا يتضمن الجزء المتاح من المادة أي مقاييس أداء أو عدد العملاء أو الأسعار، لذا لا يمكن تقييم الإصدار إلا من خلال مجموعة إمكاناته والمهام التي يغطيها لفرق QA.

ما الذي تضمنه الإصدار

التغيير الأبرز هو الربط بين المتطلبات والاختبارات. في السابق كانت أنظمة كهذه تحتفظ في الغالب بحالات الاختبار ونتائج التشغيل فقط، بينما تبقى المتطلبات في نظام تتبّع المهام أو في المستندات. أما الآن فيوجد سجلّ المتطلبات داخل SaveTest، وتُظهر المصفوفة المتطلبات التي تغطيها الاختبارات وتلك التي بقيت دون فحص.

مكوّنات التحديث بحسب الوصف المعلن:

• سجلّ متطلبات داخل المنصة؛
• مصفوفة تتبّع: الربط بين المتطلب وحالة الاختبار والنتيجة؛
• مقارنة الفروع؛
• تخطيط تشغيلات الاختبار؛
• تاريخ الإعلان: 8 أكتوبر 2026، والمصدر هو CNews.

لماذا نحتاج إلى التتبّع

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

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

الفروع والتخطيط

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

أما تخطيط التشغيلات فهو وظيفة أكثر واقعية، لكنها هي التي تحدد العمل اليومي. فجدولة عمليات التشغيل، وتوزيع الاختبارات على المنفّذين وعلى البنى (builds)، ورؤية الحِمل على الفريق، كلها أمور تعيش عادةً في الجداول وغرف الدردشة. ونقلها إلى المنصة يقلل احتمال نسيان تشغيل الانحدار (regression) أو إطلاقه على بنية خاطئة.

السوق والسياق

يدخل SaveTest سوقًا مزدحمة. فإلى جانبه تعمل TestRail وQase وAllure TestOps وTest IT، ولدى كل منها نسختها الخاصة من التتبّع والتخطيط. لذلك سيكون التمايز بعمق التكاملات وسهولة العمل مع الفروع. وفي ظل التوسع الواسع في اعتماد الذكاء الاصطناعي في الاختبار، ومنه توليد حالات الاختبار انطلاقًا من المتطلبات، يلفت النظر أمر آخر: لا يذكر الجزء المتاح من الإعلان أي وظائف ذكاء اصطناعي. فالإصدار موجّه إلى العملية والانضباط، لا إلى التوليد الآلي.

ما الذي يجب التحقق منه قبل الاعتماد

ينبغي للفرق التي تدرس التحديث أن تستوضح من المورّد عدة نقاط:

• كيف تدخل المتطلبات إلى السجلّ: استيراد من نظام تتبّع المهام، أم عبر API، أم إدخال يدوي؛
• هل يمكن مزامنة حالات المتطلبات مع المهام في Jira أو ما يماثله؛
• ما الذي يُقارَن بالتحديد عند مطابقة الفروع، وكيف تُحَلّ التعارضات؛
• هل تتوفر تقارير تغطية تصلح للتدقيق؛
• ما خيارات النشر المتاحة: السحابة أم بيئة خاصة.

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