المحطّة ٧: خطة الاختبار وضمان الجودة
أثبِت أنّ منتجك يعمل: خطة اختبارٍ تغطّي الوظائف والحدود والأمن. ⏱ نحو 22 دقيقة.
- تصمّم خطة اختبارٍ تغطّي الوظائف والحدود والأمن وسهولة الاستخدام.
- تكتب حالات اختبارٍ قابلةً للتكرار بناتجٍ متوقَّعٍ مسبق.
- تتتبّع العيوب وتمنع عودتها.
- تربط الاختبار اليدويّ بالأتمتة التي تعلّمتها في 245.
١«يعمل عندي» ليست شهادة جودة
تعلّمت في مقرّر 245 أنّ البرنامج لا يُسلَّم لأنه «اشتغل مرّةً عندك»، بل بعد أن يصمد أمام حالاتٍ مقصودة صمّمتها لتكسره. الاختبار هنا ليس محطّةً أخيرة بل طريقة تفكير: لكل قصّة مستخدمٍ، ما الذي يثبت أنها تعمل؟ وما الذي قد يكسرها؟
المشروع الطلّابيّ الذي يُسلَّم بخطة اختبارٍ مكتوبة يتفوّق على من يسلّم كودًا أكثر بلا دليلٍ على أنه يعمل. الخطة دليلُك أمام المقيّم.
٢أنواع الاختبار التي تهمّ مشروعنا
| النوع | يسأل | مثالٌ من المشروع |
|---|---|---|
| وظيفيّ | هل تؤدّي الميزة غرضها؟ | إضافة مهمّةٍ تظهر في القائمة. |
حدّيّ (Boundary) | ماذا عند الأطراف؟ | عنوانٌ فارغ، عنوانٌ طويلٌ جدًّا، قائمةٌ فارغة. |
| أمنيّ | هل يصمد أمام العبث؟ | حقن ' OR '1'='1، ومحاولة حذف مهمّة مستخدمٍ آخر. |
| سهولة الاستخدام | هل يفهمه مستخدمٌ جديد؟ | هل رسائل الخطأ واضحة؟ هل الأزرار مفهومة؟ |
٣حالة الاختبار: وصفةٌ قابلةٌ للتكرار
كل حالة اختبارٍ صفٌّ يصف: ماذا تفعل، وبأيّ مدخل، وما الناتج المتوقَّع، وما النتيجة الفعليّة. مثالٌ من مشروعنا:
| # | الحالة | المدخل | المتوقَّع | نجح؟ |
|---|---|---|---|---|
| 1 | دخولٌ صحيح | sarah / sarah123 | يدخل ويرى مهامّه | ☐ |
| 2 | دخولٌ خاطئ | sarah / خطأ | رسالة «بيانات غير صحيحة» | ☐ |
| 3 | إضافةٌ فارغة | عنوانٌ فارغ | رفضٌ ولا تُضاف | ☐ |
| 4 | عزل البيانات | ali يفتح مهامّه | لا يرى مهامّ sarah | ☐ |
| 5 | منع حذف الغير | ali يحذف مهمّة sarah | يفشل، تبقى المهمّة | ☐ |
| 6 | هروب XSS | عنوان فيه <script> | يُعرَض نصًّا لا يُنفَّذ | ☐ |
٤تتبّع العيوب
حين تفشل حالة، لا تصلحها بصمتٍ فحسب؛ سجّلها: ما العيب، وخطوات إعادته، وشدّته، وحالته (مفتوح/أُصلح). هذا سجلٌّ يثبت جودة عملك ويمنع عودة العيب نفسه.
توقّع وتحقّق
ما الاختبار الذي يجرّب العنوان الفارغ والطويل جدًّا؟
متى نكتب «الناتج المتوقَّع»؟
«ali يحاول حذف مهمّة sarah» حالةُ اختبارٍ من نوع:
بعد إصلاح عيبٍ، ما الأفضل؟
الخلاصة
- «يعمل عندي» ليست جودة؛ صمّم حالاتٍ لتكسر منتجك عمدًا.
- أنواع تهمّك: وظيفيّ، حدّيّ، أمنيّ، سهولة استخدام.
- حالة الاختبار: الحالة + المدخل + المتوقَّع (قبل التشغيل) + الفعليّ.
- سجّل كل عيبٍ بخطوات إعادته وشدّته وحالته.
- حوّل أهمّ الحالات إلى اختباراتٍ آليّةٍ تضمن ألّا تنكسر لاحقًا.
تحدٍّ تصميمي: خطة اختبار «مفكّرة مهامّي»
تصميمياكتب خطة اختبارٍ لمشروعك: حالاتٌ تغطّي كل قصّة مستخدم، مع حالاتٍ حدّيّةٍ وأمنيّة. نفّذها يدويًّا وسجّل النتائج، ثم حدّد أهمّ الحالات لأتمتتها.
- جدول حالات اختبارٍ (الحالة، المدخل، المتوقَّع، النتيجة).
- تغطية كل قصّة مستخدمٍ بحالةٍ واحدةٍ على الأقلّ.
- حالاتٌ حدّيّةٌ وأمنيّة (فارغ، عزل البيانات، حقن، XSS).
- سجلّ عيوبٍ لما فشل.