الوحدة 4 · عملية الاختبار (STLC)

تقارير الاختبار

بقلم فريق ضمان الجودة في متقن سوفت · · 18 دقيقة · مبتدئ

تقارير الاختبار (Test Reporting) هي الطريقة التي يُبلغ بها الاختبار الآخرين أين يقف، وماذا وجد، وما المخاطر المتبقية، حتى يتخذ أصحاب القرار قرارهم على بيّنة. ويسمّي منهج ISTQB للمستوى التأسيسي (الإصدار ⁦4.0⁩) نوعين: تقرير تقدم الاختبار (Test progress report) الذي يصدر بانتظام أثناء سير الاختبار ليدعم التحكم في الاختبار، وتقرير إتمام الاختبار (Test completion report) الذي يصدر عند انتهاء مرحلة من الاختبار (مستوى اختبار أو دورة أو تكرار أو مشروع)، ويُفضَّل أن يكون ذلك بعد استيفاء معايير الخروج (Exit criteria).

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

لماذا يهم

المعلومة التي لا تصل إلى من يستطيع التصرف بناءً عليها معلومة ضائعة. عيب حرج (Critical) مدفون في جدول بيانات، أو بيئة اختبار معطّلة لم يُصعّد أحد مشكلتها، أو معدل نجاح ⁦90%⁩ يخفي منطقة لم تُختبر: كلها تنتهي بالنتيجة نفسها، إصدار يخرج بمخاطرة لم يقبلها أحد عن علم، أو موعد ينزلق دون إنذار.

وبالنسبة إلى المختبِر، التقارير تبني الثقة: فالحقائق المفصولة عن الرأي وطلبات القرار المحددة تقدّم الاختبار مصدراً للمعلومات، لا بوابة لا تقول إلا «غير جاهز».

تقرير تقدم الاختبار وتقرير إتمام الاختبار

ينتمي تقرير تقدم الاختبار إلى متابعة الاختبار والتحكم فيه (Test monitoring and control). ويصفه مسرد ISTQB بأنه تقرير دوري عن تقدم أنشطة الاختبار مقابل خط أساس، مثل خطة الاختبار، مع المخاطر والبدائل التي تتطلب قراراً. يصدر بإيقاع منتظم (يومياً أو أسبوعياً أو لكل سبرنت)، ويجب أن يقدّم معلومات كافية لتعديل الجدول الزمني أو الموارد أو خطة الاختبار حين ينحرف الاختبار عن الخطة أو تتغير الظروف. ويجيب عن: هل نسير وفق الخطة؟ ما الذي يعترض طريقنا؟ وما الذي يحتاج إلى قرار؟

أما تقرير إتمام الاختبار فيُعَدّ خلال إتمام الاختبار (Test completion)، عند انتهاء مستوى اختبار أو دورة أو تكرار أو مشروع. ويُبنى من تقارير التقدم ومن بيانات أخرى للمرحلة كلها، فيقيّم الاختبار وجودة المنتج مقابل أهداف الاختبار ومعايير الخروج، ويفيد الاختبار اللاحق. ويجيب عن: ماذا اختبرنا؟ ما مدى جودة المنتج؟ وما المخاطر المتبقية؟

ويقدّم المعيار ISO/IEC/IEEE ⁦29119-3⁩ قوالب للتقريرين ويسمّي تقرير التقدم تقرير حالة الاختبار (Test status report)؛ وتسمّي بعض الفرق، وبعض المناهج الأقدم، تقرير الإتمام تقرير ملخص الاختبار (Test summary report).

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

تقرير تقدم الاختبارأثناء الاختبار

يوجّه الاختبار أثناء سيره

متى:
بانتظام: يومياً أو أسبوعياً أو لكل سبرنت
السؤال الذي يجيب عنه:
هل نسير وفق الخطة؟ ما الذي يعترضنا؟ ما الذي يحتاج إلى قرار؟
مصدره:
بيانات المتابعة للفترة الحالية
يؤدي إلى:
التحكم في الاختبار: تعديل الجدول أو الموارد أو خطة الاختبار
الرسمية:
غالباً قصير وغير رسمي داخل الفريق
يُسمّى أيضاً:
تقرير حالة الاختبار (ISO/IEC/IEEE ⁦29119-3⁩)

تقرير إتمام الاختبارعند انتهاء مرحلة

يختم مرحلة منتهية ويفيد الاختبار اللاحق

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

الحقائق نفسها لقرّاء مختلفين

ينبّه المنهج إلى أن كل جمهور يحتاج إلى معلومات مختلفة، وأن الجمهور يحدد أيضاً درجة الرسمية والتكرار: فالإبلاغ داخل الفريق غالباً متكرر وغير رسمي، أما تقرير الإتمام فيتبع قالباً محدداً ويُكتب مرة واحدة. وتمتد القنوات من الحديث في الاجتماع اليومي (Stand-up) ولوحة معلومات CI/CD ولوحة المهام ومخطط العمل المتبقي (Burn-down chart) الذي يرسم ما بقي من العمل يوماً بيوم، إلى الدردشة والبريد الإلكتروني وصفحة الويكي والتقرير الرسمي؛ والفرق الموزعة على مواقع أو مناطق زمنية مختلفة كثيراً ما تحتاج إلى إبلاغ أكثر رسمية ومكتوب.

كيّف العمق، لا الحقائق: يحصل كل قارئ على الأرقام نفسها بالتعريفات نفسها.

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

جرّبها: تحويل Markdown إلى PDF

ما الذي يحتويه التقرير الجيد

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

  • التعريف والنطاق: المنتج، والبناء (Build)، ومستوى الاختبار أو الدورة، والبيئة، والفترة، ووقت أخذ البيانات.
  • الخلاصة أولاً: الحالة العامة في سطر واحد مع سببها، وأي قرار مطلوب. وعرّف مرة واحدة كلمات الحالة مثل «وفق الخطة» و«في خطر» و«خارج الخطة».
  • أرقام مقابل الخطة: «⁦58⁩ من ⁦80⁩ اختباراً مخططاً» لا «نُفّذ ⁦58⁩». واعرض الناجح والفاشل والمحجوب وغير المشغَّل كلاً على حدة؛ فمعدل نجاح الاختبارات المنفذة لا يقول شيئاً عن الاختبارات التي لم تُشغَّل.
  • التقدم حسب الميزة أو المتطلب أو مستوى الخطر، حتى لا تختبئ منطقة عالية الخطر غير مختبَرة داخل مجموع جيد.
  • كل عيب حاجب (Blocker) أو حرج (Critical) مذكور برقمه وأثره والمسؤول عنه، والباقي أعداد حسب الخطورة.
  • العوائق والمخاطر مع مسؤول وموعد، أو «غير معروف» بصراحة، وأي حل بديل.
  • الحقائق أولاً، ثم تقييمك وتوصيتك منسوبين إليك، والاتجاه منذ التقرير السابق.

جرّبها: حاسبة النسبة المئوية جرّبها: المتطلبات ← حالات اختبار

مثال تطبيقي: إعادة كتابة تقرير تقدم ضعيف

تطبيق لحجز مواعيد العيادات، الإصدار ⁦2.4⁩، في دورة اختبار نظام مدتها عشرة أيام. في اليوم السادس كانت مسودة المختبِر الأولى إلى مالك المنتج: «نُفّذ ⁦58⁩ اختباراً، نجح منها ⁦52⁩، ومعدل النجاح ⁦90%⁩. ⁦9⁩ أخطاء مفتوحة. بعض الاختبارات محجوبة. الاختبار مستمر.» كل جملة صحيحة، لكن لا أحد يستطيع التصرف بناءً عليها: ⁦58⁩ من كم؟ أيّ الأخطاء مهم؟ ما المحجوب وإلى متى؟ وهل الموعد في خطر؟

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

تقرير تقدم في اليوم السادس لتطبيق حجز مواعيد العيادات، جزءاً جزءاً: التعريف، والفترة، وسطر الحالة، والمقاييس مقابل الخطة، والعيوب، والعائق، والمخاطرة الجديدة، والقرار المطلوب، والخطوات التالية.

تقرير التقدم بعد إعادة كتابته

الجزء 1:TEST PROGRESS REPORT · Clinic Booking 2.4 · System test, cycle 1
الجزء 2:Period: day 6 of 10 · data as of 28 Sep, 17:00 · build rc3 on staging
الجزء 3:Status: AT RISK. A Critical defect and a blocked SMS sandbox threaten
        sign-off on 4 Oct. Decision needed by 30 Sep (see below).

الجزء 4:Area                 Plan  Run  Pass  Fail  Blocked  Not run
Booking & payment      32   30    29     1        0        2
Rescheduling           18   12     8     4        2        4
SMS reminders          14    0     0     0        6        8
Profile & settings     16   16    15     1        0        0
Total                  80   58    52     6        8       14

الجزء 5:Open defects: Blocker 0 · Critical 1 · Major 3 · Minor 5
  CB-412 Critical: rescheduling keeps the old slot booked;
  blocks 2 tests; owner: backend team; fix expected 30 Sep
الجزء 6:Impediment: SMS provider sandbox down since 24 Sep; blocks 6 tests;
  owner: DevOps; no restore date yet; workaround needs a decision (below)
الجزء 7:New risk: if the CB-412 fix arrives after 30 Sep, regression cannot
  finish before sign-off

الجزء 8:Decision needed by 30 Sep: test SMS reminders with the live provider
  and staff phone numbers, or move sign-off to 6 Oct
الجزء 9:Next: retest CB-412, finish rescheduling, full regression on day 9
  1. 1التعريفنوع التقرير والمنتج والإصدار ومستوى الاختبار والدورة، حتى لا يختلط بتقرير آخر.ممارسة الفرق
  2. 2فترة الاختبار والبياناتاليوم ⁦6⁩ من ⁦10⁩، ووقت أخذ البيانات، والبناء والبيئة اللذان تنطبق عليهما.
  3. 3الحالة: التقدم والانحرافكلمة حالة واحدة، وسببها، والموعد المهدَّد، وإشارة إلى القرار.
  4. 4مقاييس الاختبار مقابل الخطةالمخطط والمنفذ والناجح والفاشل والمحجوب وغير المشغَّل حسب المنطقة: معدل النجاح ⁦90%⁩ ما زال ظاهراً، وكذلك منطقة الرسائل النصية غير المختبَرة.run 58/80 · passed 52/58 = 90%
  5. 5العيوبمقاييس العيوب معدودةً حسب الخطورة؛ والعيب الحرج الوحيد مذكور بأثره والاختبارات التي يحجبها والمسؤول عنه وموعد إصلاحه.
  6. 6العائق والحل البديلما المحجوب ومنذ متى ومن المسؤول عنه، مع إقرار صريح بأنه لا موعد للاستعادة بعد، والحل البديل الذي يحتاج إلى قرار.
  7. 7المخاطر الجديدة والمتغيرةما قد يسوء بعد، مذكوراً قبل أن يحدث.
  8. 8القرار المطلوبموعد نهائي وخياران محددان يختار بينهما مالك المنتج: البدائل التي تتطلب قراراً.مسرد ISTQB
  9. 9الاختبار المخطط للفترة التاليةما سيحدث بعد ذلك، حتى يعرف القارئ ما سيغطيه التقرير التالي.

الأجزاء ⁦2–7⁩ و⁦9⁩ هي محتويات تقرير تقدم الاختبار كما يذكرها منهج CTFL ⁦4.0⁩ (والجزآن ⁦4⁩ و⁦5⁩ مقاييس الاختبار فيه)؛ والجزء ⁦8⁩ من تعريف مسرد ISTQB؛ والجزء ⁦1⁩ ممارسة شائعة في الفرق.

  • ما زالت نسبة ⁦90%⁩ موجودة (⁦52⁩ من ⁦58⁩ منفذاً)، لكن الجدول يكشف ما أخفته: لم يُشغَّل أي اختبار لتذكيرات الرسائل النصية (SMS)، وإعادة الجدولة متأخرة.
  • العيب الوحيد الذي يهدد الإصدار هو المذكور برقمه والمسؤول عنه؛ والعيوب الثمانية الأخرى أعداد.
  • للعائق مسؤول وإقرار صريح بأنه لا موعد للاستعادة بعد؛ وحلّه البديل الوحيد يحتاج إلى موافقة، فصار هو القرار المطلوب، بموعد نهائي وخيارين.
النسخة النصية
TEST PROGRESS REPORT · Clinic Booking 2.4 · System test, cycle 1
Period: day 6 of 10 · data as of 28 Sep, 17:00 · build rc3 on staging
Status: AT RISK. A Critical defect and a blocked SMS sandbox threaten
        sign-off on 4 Oct. Decision needed by 30 Sep (see below).

Area                 Plan  Run  Pass  Fail  Blocked  Not run
Booking & payment      32   30    29     1        0        2
Rescheduling           18   12     8     4        2        4
SMS reminders          14    0     0     0        6        8
Profile & settings     16   16    15     1        0        0
Total                  80   58    52     6        8       14

Open defects: Blocker 0 · Critical 1 · Major 3 · Minor 5
  CB-412 Critical: rescheduling keeps the old slot booked;
  blocks 2 tests; owner: backend team; fix expected 30 Sep
Impediment: SMS provider sandbox down since 24 Sep; blocks 6 tests;
  owner: DevOps; no restore date yet; workaround needs a decision (below)
New risk: if the CB-412 fix arrives after 30 Sep, regression cannot
  finish before sign-off

Decision needed by 30 Sep: test SMS reminders with the live provider
  and staff phone numbers, or move sign-off to 6 Oct
Next: retest CB-412, finish rescheduling, full regression on day 9

جرّبها: منسّق Markdown

أخطاء شائعة

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

من منظور ضمان الجودة

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

قبل الإرسال، اقرأ التقرير كما سيقرؤه متلقيه: هل يعرف خلال عشر ثوانٍ إن كان عليه أن يقلق، وهل يمكنه تتبّع كل رقم إلى أداة إدارة الاختبار أو متتبّع العيوب في وقت محدد، وهل يستطيع الإجابة عن القرار كما صيغ؟ ثم سجّل الإجابات، مع من قرر ومتى: فتقرير الإتمام سيحتاج إليها بوصفها مخاطر مقبولة.

تمرين عملي

اكتب تقرير تقدم من بيانات اختبار خام

المطلوب

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

ثم اذكر ما سيحتاج إليه تقرير إتمام الاختبار ولا تحتويه هذه البيانات بعد.

المادة
Feature: Returns & refunds, web shop 5.1 · system test, day 4 of 5
Data as of 15 Oct, 16:00 · build 5.1.0-rc2 on staging
Cycle ends 18 Oct · release planned 19 Oct

Planned: 60   Executed: 41   Passed: 37   Failed: 4
Blocked: 5    (refund to card: payment sandbox rejects test cards)
Not run: 14   (9 partial-refund tests, 5 return-label tests)

Open defects
  RF-88  Critical  Refund is issued twice when the user double-clicks
  RF-91  Major     Return label shows the wrong warehouse address
  RF-95  Minor     Typo on the confirmation page
  RF-97  Minor     Date picker accepts a return date in the past

Payment sandbox: vendor ticket open, no restore date given
الخطوات
  1. احسب التقدم مقابل الخطة ومعدل النجاح، مع إبقاء المحجوب وغير المشغَّل ظاهرين.
  2. حدّد الحالة العامة واكتب سطر خلاصة يذكرها مع سببها.
  3. سمِّ العيب الذي يهدد الإصدار، والعائق والمسؤول عنه، والقرار الذي تحتاج إليه.
  4. أعد كتابة الحقائق للمطورين، ثم اذكر بنود تقرير الإتمام.
إظهار الإجابة النموذجية
الإجابة النموذجية

الأرقام: نُفّذ ⁦41⁩ من ⁦60⁩ اختباراً مخططاً (⁦68%⁩)؛ نجح ⁦37⁩ وفشل ⁦4⁩، أي معدل نجاح ⁦90%⁩. لكن ⁦19⁩ اختباراً (⁦32%⁩) لم تُشغَّل: ⁦5⁩ محجوبة و⁦14⁩ لم تُشغَّل بعد، منها اختبارات الاسترداد الجزئي التسعة كلها. الحالة: في خطر، ولم يبقَ إلا يوم واحد.

لمالك المنتج: «المرتجعات والمبالغ المستردة ⁦5.1⁩، اليوم ⁦4⁩ من ⁦5⁩ (⁦15⁩ أكتوبر ⁦16:00⁩، البناء rc2 على Staging). في خطر: الاسترداد إلى البطاقة غير مختبَر، وعيب حرج في الاسترداد مفتوح؛ القرار مطلوب قبل ⁦12:00⁩ يوم ⁦18⁩ أكتوبر. نُفّذ ⁦41⁩ من ⁦60⁩: نجح ⁦37⁩ وفشل ⁦4⁩؛ محجوب ⁦5⁩ ولم يُشغَّل ⁦14⁩. العيوب: حرج ⁦1⁩، رئيسي (Major) ⁦1⁩، ثانوي (Minor) ⁦2⁩. RF-88: النقر المزدوج يصدر الاسترداد مرتين، فيُفقد المال في كل مرة؛ والمسؤول عنه وموعد إصلاحه لم يُؤكَّدا بعد. العائق: بيئة التجربة (Sandbox) لدى مزود الدفع ترفض بطاقات الاختبار؛ تذكرة مفتوحة لدى المزود ولا موعد. القرار: تمديد الدورة وتأجيل الإصدار، أو الإطلاق والاسترداد إلى البطاقة غير مختبَر. توصيتي: لا إطلاق وRF-88 مفتوح في الحالتين. التالي: الاسترداد الجزئي والملصقات وإعادة اختبار RF-88.»

للمطورين: «اليوم ⁦4⁩: نُفّذ ⁦41/60⁩، و⁦4⁩ اختبارات فاشلة. RF-88 (استرداد مزدوج عند النقر المزدوج) هو خطر الإصدار، أرجو البدء به؛ وRF-91 يعرض عنوان مستودع خاطئاً. ⁦5⁩ اختبارات استرداد إلى البطاقة محجوبة بسبب بيئة التجربة لدى مزود الدفع. أخبروني حين يصل RF-88 إلى Staging.»

ما زال ينقص تقرير الإتمام: معايير الخروج وهل استُوفي كل منها؛ والانحرافات عن الخطة؛ والمقاييس النهائية للدورة كلها؛ والعوائق وحلولها البديلة؛ والعيوب التي لم تُصلَح والمخاطر غير المعالجة مع من قبلها؛ والدروس المستفادة، مثل التحقق من بيئات التجربة لدى الأطراف الخارجية قبل بدء الدورة.

أسئلة شائعة

هل تقرير الاختبار هو نفسه تقرير الخطأ؟

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

كم مرة أرسل تقرير تقدم الاختبار؟

بالقدر الذي يحتاج إليه القرّاء لاتخاذ قراراتهم؛ ويذكر المنهج اليومي والأسبوعي مثالين. داخل الفريق يكون غالباً يومياً وغير رسمي، ولأصحاب المصلحة الآخرين أسبوعياً أو لكل سبرنت. ولا تنتظر موعد التقرير حين يظهر عائق أو عيب حرج: ارفعه في اليوم نفسه.

من يكتب تقرير إتمام الاختبار، ومن يقرؤه؟

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

هل يجب أن يقول تقرير الاختبار هل نُطلق أم لا؟

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

المراجع

الأدوات

تدرّب بأدوات متقن

حاسبة النسبة المئوية

حساب النسب المئوية ونسبة التغيّر والزيادة/النقصان وكم تمثّل X من Y بالنسبة المئوية.

أدوات مساعدة

منسّق Markdown

توحيد تنسيق Markdown (العناوين والقوائم والجداول والتأكيد) ومعاينة النتيجة المعروضة.

التنسيق

تحويل Markdown إلى PDF

حوّل ملفات Markdown (md.) إلى PDF في متصفحك: العناوين والقوائم والجداول وكتل الشيفرة والاقتباسات والروابط والصور منسّقة بخطوط مضمّنة.

تحويل PDF

المتطلبات ← حالات اختبار

حوّل قائمة متطلبات مرقّمة إلى حالات اختبار قابلة للتتبّع مع مصفوفة تربط المتطلبات بالاختبارات.

تصميم الاختبارات

للتعمّق أكثر

تقدّمك في هذا الموضوع

جزء من مسار تعلم ضمان الجودة