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

لماذا يهم

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

والوثائق المناسبة تجعل عمل المختبِر قابلاً للمراجعة وسهل التسليم وقابلاً للدفاع عنه، لأن تقليص النطاق والمخاطر المقبولة مسجّلة باسم من قرّرها وتاريخ القرار.

ماذا تكتب: القارئ والعمر والمالك والإلزام

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

إذا لم يقرأها أحد ليقرر أو يعمل، فلا تكتبها. والوثيقة المفروضة تتبع القالب المتفق عليه، والوثيقة الحية تحتاج إلى مالك وإلى حدث يستدعي تحديثها، والملاحظة قصيرة العمر تكفيها قائمة تحقق. وبحسب الغرض، تكتب الفرق عادةً ما يلي:

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

المعيار ISO/IEC/IEEE ⁦29119-3⁩: أنواع الوثائق في لمحة

يقدّم المعيار ISO/IEC/IEEE ⁦29119-3:2021⁩ قوالب وأمثلة للوثائق التي تُنتجها عمليات الاختبار في المعيار ISO/IEC/IEEE ⁦29119-2⁩، ويجمعها في الطبقات الثلاث المبيّنة أدناه. وقد حلّت الطبعة الأولى من هذا الجزء، الصادرة عام ⁦2013⁩، محل IEEE ⁦829-2008⁩.

وفيه ثلاث عبارات هي الأهم. يجوز أن تكون الوثائق ورقية أو إلكترونية، كالسجلات في أداة اختبار أو في جدول بيانات. ويجوز تغيير أسماء الوثائق أو دمجها أو تقسيمها، ويختار الفريق المجموعة التي يحتاج إليها؛ والمطابقة المكيّفة (Tailored conformance) تعني تسجيل تلك المجموعة وتسويغ ما استُبعد منها. ويمكن اعتماده في أي دورة حياة، بما فيها الرشيقة وDevOps. فتعامل معه بوصفه قائمة تحقق بالمعلومات، لا أمراً بإنتاج كل قالب وثيقةً مستقلة.

• الطبقة المؤسسية: سياسة الاختبار (Test policy)، وتبيّن لماذا تختبر المؤسسة، وأهداف الاختبار، والتدريب، والأخلاقيات، وكيف تُقاس قيمة الاختبار؛ وممارسات الاختبار المؤسسية (Organizational test practices)، وتبيّن كيف يُجرى الاختبار عبر المشاريع، وكانت الطبعة الأولى تسمّيها استراتيجية الاختبار المؤسسية.
• طبقة إدارة الاختبار: خطة الاختبار (السياق والنطاق، وأصحاب المصلحة، وسجل المخاطر، واستراتيجية اختبار المشروع، والأنشطة وتقديراتها، والموارد البشرية، والجدول الزمني)؛ وتقرير حالة الاختبار (Test status report)، وهو تقرير تقدم الاختبار عند ISTQB؛ وتقرير إتمام الاختبار، ويُسمّى أيضاً تقرير ملخص الاختبار (Test summary report).
• طبقة الاختبار الديناميكي: مواصفة نموذج الاختبار (Test model specification)، أي ما تُشتق منه الاختبارات، مثل عبارات المتطلبات أو أقسام التكافؤ أو جدول القرار (وفي طبعة ⁦2021⁩ حلّت نماذج الاختبار محل مفهوم شروط الاختبار، ويمكن أن يتضمن النموذج شروط اختبار)؛ ومواصفات حالات الاختبار وإجراءاته؛ ومتطلبات بيانات الاختبار وبيئته وتقارير جاهزيتها؛ والنتائج الفعلية ونتائج الاختبار؛ وسجل تنفيذ الاختبار؛ وتقرير الحادثة (Incident report)، المعروف أيضاً بتقرير العيب أو تقرير الخطأ.

التوثيق المقتصد: ما يكفي، في الوقت المناسب

يقدّم بيان تطوير البرمجيات الرشيق (Manifesto for Agile Software Development) «البرمجيات العاملة على التوثيق الشامل»، مع إقراره بأن للتوثيق قيمة. والتوثيق المقتصد يطبّق هذا التوازن على الاختبار: اكتب ما يحتاج إليه القارئ، حين يحتاج إليه، بأخف شكل يؤدي الغرض، ولا تكتب أبداً ما يحمله مصدر أفضل.

والاقتصاد في التوثيق لا يعني ألا يُكتب شيء: فالعقود والجهات التنظيمية والتدقيق والفرق الموزعة والمنتجات طويلة العمر تبرر قدراً أكبر من الرسمية. سجّل المستوى الذي اخترته في استراتيجية الاختبار.

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

مثال تطبيقي: تقليص مجموعة الوثائق

تنضم قائدة ضمان جودة جديدة إلى FleetTrack، وهو منتج خيالي لتتبع التوصيل يعمل عليه ستة مطورين ومختبِران. فترث خطة اختبار رئيسية من ⁦45⁩ صفحة آخر تحديث لها قبل ثمانية أشهر، و⁦1,200⁩ حالة اختبار في جدول بيانات كثير منها لشاشات محذوفة، وتقرير حالة يستهلك نصف يوم كل أسبوع، ولا دليل لبيانات الاختبار. وهناك قيد ثابت واحد: عقد العميل يشترط تقرير إتمام موقّعاً لكل إصدار يبيّن المتطلبات التي اختُبرت.

تربط القرّاء واحتياجاتهم بعناصر المعيار ⁦29119-3⁩، وتتفق على الخريطة أدناه مع مالك المنتج وقائد التطوير:

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

FleetTrack documentation map (fictional), agreed in sprint 31

Item (29119-3 name)        Form and place                 Owner    Update trigger
Org. test practices        wiki page, about 4 pages       QA lead  quarterly review
Test plan (with strategy)  1 page per release, wiki       QA lead  scope, dates, risks
Test models, test cases    regression set in test tool;   testers  feature changes
                           charters for new features
Test data and environment  how-to page: accounts, seed    testers  environment changes
  requirements             scripts, reset steps
Execution log, results     test tool runs, CI report      tool     every run
Incident reports           defect tracker                 finder   until closed
Test status report         dashboard + 5-line note        QA lead  weekly
Test completion report     2 pages, signed PDF            QA lead  each release

Not written: a separate test policy (a purpose statement opens the practices page),
separate test procedure specifications and readiness reports,
and a traceability matrix kept by hand

جرّبها: المتطلبات ← حالات اختبار جرّبها: منسّق Markdown جرّبها: تحويل Markdown إلى PDF

أسئلة شائعة

المراجع

• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021نماذج ومحتوى وثائق الاختبار — سياسة الاختبار واستراتيجيته وخطته وتقارير الحالة والإنجاز وتقارير الحوادث.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• Manifesto for Agile Software DevelopmentThe Agile Manifesto authors · 2001القيم الأربع لتطوير البرمجيات الرشيق (Agile)، مثل تقديم البرمجيات العاملة على التوثيق الشامل، والاستجابة للتغيير على اتباع الخطة.