انتقل إلى المحتوى
مصطفى محمود

كل الأعمال

مساحة عمل واحدة لفريق الجودة

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

الدور
مالك المنتج ومنفّذه.
الفترة
2026 – حتى الآن
الحالة
نسخة أولية (MVP)
الأدوات
Next.js 15، Supabase، Jira REST API، TestRail API، scheduled sync
  • 15 minالفاصل بين كل مزامنة
  • ~1,860حالة اختبار متزامنة
  • ~640تذكرة متزامنة

البنية

خطوات النظام بالترتيب

  1. المصادر
    1. Jira API (مدخل). يغذّي: مجدول كل 15 دقيقة
    2. TestRail API (مدخل). يغذّي: مجدول كل 15 دقيقة
  2. المزامنة
    1. مجدول كل 15 دقيقة (منطق)
    2. استيعاب وتصنيف (منطق)
    3. التذاكر والحالات والتشغيلات والنتائج والتعليقات (بيانات). يغذّي: الملخص اليومي
  3. التطبيق
    1. الملخص اليومي (مخرج)
    2. مصفوفة التغطية (مخرج)
    3. إعادة الاختبار الذكية (مخرج)
    4. تعليق على Jira (مخرج)
  4. القادم (مخطط له)
    1. مساعد AI حسب الدور (ذكاء اصطناعي)
    2. توليد حالات اختبار إلى TestRail (ذكاء اصطناعي)
    3. كشف البلاغات المكررة (ذكاء اصطناعي)

المشكلة

يضيّع مهندسو الجودة وقتهم في التنقل بين Jira وTestRail والمحادثات للإجابة عن أسئلة بسيطة: ما الذي تغيّر، وما الذي فشل، وما الذي يحتاج إعادة اختبار.

ما بنيته

مزامنة تحدّث بيانات Jira وTestRail كل 15 دقيقة داخل Supabase، وتطبيق فوقها فيه: ملخص يومي، وتسلسل التذاكر مع مصدر كل خلل، ومصفوفة تغطية بين القصص ومجموعات الاختبار، واختيار ذكي لما يُعاد اختباره، وتصنيف للتعليقات، ونشر تعليقات على Jira مع الإشارة للأشخاص.

قرارات أساسية

  1. الربط لا الاستبدال. يبقى Jira وTestRail هما مصدر البيانات الأساسي.
  2. حداثة واضحة. تعرض الواجهة متى تمت آخر مزامنة لكل مصدر.
  3. تكلفة كل مستخدم قيد في التصميم لطبقة الذكاء الاصطناعي، فيُختار النموذج حسب كل مهمة.

النتائج

نسخة أولية قيد الاستخدام التجريبي مع فريق جودة في شركة تقنية تعليمية. الأرقام أعلاه من بيانات التجربة.

كل الأعمال

دراسة الحالة التاليةوكلاء جودة يكتبون حالات الاختبار