اختبار البرمجيات هو أن تجرّب تطبيقك عن قصد كما سيستخدمه عملاؤك، وتقارن ما يحدث فعلاً بما يجب أن يحدث، قبل أن يفعلوا هم ذلك. كل تجربة مكتوبة تسمّى حالة اختبار: خطوات واضحة ونتيجة متوقّعة. ما خالف المتوقّع يُسجَّل خللاً بدليله، ثم يُصلح ويُعاد اختباره. الهدف ليس إثبات أن التطبيق بلا أخطاء، فهذا مستحيل، بل أن تعرف حالته الحقيقية قبل الإطلاق وبعد كل تعديل.
ما هو الاختبار، وما الذي ليس اختباراً؟
تخيّل أنك تفتتح مطعماً. قبل يوم الافتتاح تدعو بعض الأصدقاء، وتطلب منهم أن يحجزوا ويطلبوا ويدفعوا، وتراقب أين يتعثّر كل شيء. هذا بالضبط هو الاختبار: تجربة مقصودة بعين ناقدة، غرضها أن تجد المشكلة أنت قبل أن يجدها ضيف حقيقي.
في البرمجيات، الاختبار يجيب عن سؤال واحد يتكرّر: هل يفعل التطبيق ما وعدنا به العميل؟ إذا ضغط «احجز»، هل يُسجَّل الحجز؟ إذا أدخل رقماً خاطئاً، هل تظهر رسالة مفهومة؟ إذا حجز شخصان الموعد نفسه، ماذا يحدث؟
- أن تفتح الصفحة الرئيسية وتقول «شكلها تمام».
- أن يجرّب المطوّر ما بناه بالطريقة التي يعرف أنها تعمل.
- أن تنتظر شكاوى العملاء لتعرف ما تعطّل.
- أن تجرّب مرة واحدة قبل الإطلاق ثم لا تعود.
- خطوات مكتوبة ونتيجة متوقّعة معروفة قبل أن تبدأ.
- تجربة الطريق الصحيح والطرق الخاطئة معاً.
- دليل على كل نتيجة: لقطة شاشة أو ردّ مسجَّل.
- إعادة التجارب نفسها بعد كل تعديل.
وهناك أمر يجب أن يُقال بصراحة: الاختبار لا يثبت أن تطبيقك خالٍ من الأخطاء. هو يثبت أن ما جرّبته يعمل، ويكشف ما لا يعمل ممّا جرّبته. لهذا قيمة الاختبار في اختيار ما تجرّبه، لا في عدد التجارب.
لماذا يكلّف الخلل أكثر كلما تأخّر اكتشافه؟
الخلل نفسه له ثمن مختلف بحسب من يجده ومتى. فكّر في خلل يسمح بحجز الطاولة نفسها مرتين:
- أثناء البناء: يُصلح في دقائق، ولا يعلم به أحد.
- قبل الإطلاق بيوم: يُصلح على عجل، وقد يتأخّر الإطلاق قليلاً.
- بعد الإطلاق، ووجده موظفك: إصلاح، واعتذار لضيف أو اثنين، وتصحيح يدوي للحجوزات.
- بعد الإطلاق، ووجده العملاء: ضيفان يقفان أمام طاولة واحدة، وتقييم سيّئ، وعملاء لن يخبروك بل لن يعودوا.
كلفة الكود لم تتغيّر كثيراً بين الحالات. الذي تضاعف هو ما حول الكود: وقت فريقك، وبيانات يجب تصحيحها، وثقة عميل يصعب استرجاعها. والعميل الذي يصادف خللاً في الدفع لا يكتب لك في الغالب، بل يغلق الصفحة.
اختبر أقرب ما يمكن إلى لحظة التغيير. كل تعديل، ولو صغيراً، هو فرصة لخلل جديد، واكتشافه في اليوم نفسه أرخص ما يكون.
أنواع الاختبار التي تهمّ صاحب المشروع
كتب الاختبار تعدّد عشرات الأنواع. أنت لا تحتاج إلى حفظها. هذه خمسة تغطّي معظم ما يهمّ مشروعاً صغيراً أو متوسطاً:
١. اختبار المسارات: هل يكمل العميل ما جاء لأجله؟
أهمّ نوع. تمشي في المسار كاملاً كما يمشيه العميل: يفتح الموقع، يختار، يملأ النموذج، يدفع، تصله رسالة التأكيد. ثم تجرّب الطرق الخاطئة: حقل فارغ، رقم جوال ناقص، ضغطتان متتاليتان على زرّ الدفع.
٢. الاختبار بعد كل تعديل: هل ما كان يعمل ما زال يعمل؟
تضيف كوبون خصم، فيتعطّل حساب الضريبة. هذا أكثر خلل شيوعاً في أي منتج يتطوّر: تعديل في مكان يكسر مكاناً آخر. الحل أن تحفظ حالات الاختبار وتعيدها كلها بعد كل تغيير. اسمه الشائع «اختبار الانحدار»، وشرحناه في صفحة الاختبار بعد كل تعديل.
٣. اختبار الـ API: هل يتفاهم نظامك مع الأنظمة الأخرى؟
إن كان تطبيق الجوال، أو شريك التوصيل، أو نظام المحاسبة يتصل بنظامك، فهو يتصل عبر الـ API لا عبر الشاشات. هنا تتحقّق من أن كل طلب يعيد البيانات الصحيحة، ويرفض من لا يملك الصلاحية، ويعيد رسالة خطأ مفهومة. التفاصيل في صفحة اختبار الـ API.
٤. مقاس الجوال: هل يعمل كل شيء على شاشة صغيرة؟
معظم عملائك يفتحون موقعك من الجوال. زرّ يختفي تحت لوحة المفاتيح، أو جدول يخرج عن الشاشة، أو نص عربي ينقلب اتجاهه: هذه أخطاء لا تظهر على شاشة الحاسوب. جرّب المسارات المهمة بعرض شاشة الجوال، لا الصفحة الرئيسية فقط.
٥. اختبار القبول: هل هذا ما طلبتُه فعلاً؟
هذا اختبارك أنت. قد يعمل كل شيء تقنياً ولا يطابق طريقة عملك: النظام يسمح بالإلغاء حتى آخر دقيقة وأنت تريد إيقافه قبل الموعد بساعتين. لا أحد يعرف قواعد عملك غيرك، فخصّص وقتاً لتجرّب بنفسك قبل أن توافق.
اختبار التحمّل (آلاف الزوّار في لحظة واحدة)، والفحص الأمني واختبار الاختراق، وتجربة تطبيقات الجوال على أجهزة حقيقية مختلفة: هذه تخصّصات قائمة بذاتها، لها أدواتها وخبراؤها. لا تفترض أن اختبار المسارات يغطّيها، واسأل أي جهة تختبر لك ماذا يشمل عملها وماذا لا يشمل.
الاختبار اليدوي والآلي: ما الفرق، ومتى يكفي كلٌّ منهما؟
اليدوي أن يمشي إنسان في الخطوات بنفسه. الآلي أن تُكتب الخطوات مرة، ثم ينفّذها برنامج في متصفح حقيقي كلما طلبت. لا أحد منهما «أفضل»؛ لكلٍّ مكانه:
| الاختبار اليدوي | الاختبار الآلي | |
|---|---|---|
| يبرع في | ملاحظة ما يبدو غريباً أو مربكاً، وتجربة ما لم يخطر على بال أحد | إعادة الخطوات نفسها بالدقة نفسها في كل مرة |
| نقطة ضعفه | يملّ الإنسان، فيتخطّى خطوات في المرة العاشرة | لا يلاحظ إلا ما طُلب منه أن يتحقّق منه |
| الكلفة | قليلة في البداية، وتتكرّر كاملة مع كل جولة | جهد في كتابة الحالات أولاً، ثم إعادة شبه مجانية |
| يناسب | منتجاً جديداً يتغيّر شكله كل يوم، واختبار القبول | المسارات الأساسية التي يجب أن تعمل بعد كل تعديل |
متى يكفي اليدوي؟ حين يكون المنتج صغيراً، والتعديلات قليلة، وعندك قائمة مكتوبة تمرّ عليها. ابدأ من قائمة فحص الموقع قبل الإطلاق.
متى لا يكفي؟ حين تعدّل كل أسبوع، أو حين صارت قائمة التجارب أطول من أن يكملها أحد بتركيز، أو حين يمرّ عبر التطبيق مال أو مواعيد. عندها يصبح تخطّي الاختبار «هذه المرة فقط» هو العادة، وهنا تأتي الأخطاء.
ما هي حالة الاختبار، وكيف تُكتب؟
حالة الاختبار هي أصغر وحدة في الاختبار: تجربة واحدة مكتوبة بحيث ينفّذها أي شخص ويصل إلى الحكم نفسه. إن احتاج منفّذها أن يسألك «وماذا أقصد بالضبط؟» فهي ناقصة. مكوّناتها خمسة:
- العنوان: ما الذي نتحقّق منه، في سطر.
- المتطلبات المسبقة: ما يجب أن يكون جاهزاً قبل البدء (حساب تجريبي، موعد متاح).
- الخطوات: أفعال محدّدة بالترتيب، فعل واحد في كل خطوة.
- النتيجة المتوقّعة: ما يجب أن يراه العميل أو يُسجَّل في النظام.
- الأولوية: ما مدى سوء الأمر إن فشلت هذه الحالة؟
- العنوان
- لا يمكن حجز موعد محجوز مسبقاً عند الطبيب نفسه
- المتطلبات المسبقة
- حسابا مريضين تجريبيان، وموعد متاح غداً الساعة 10:00 صباحاً
- الخطوات
- ١) ادخل بحساب المريض الأول واحجز موعد 10:00. ٢) اخرج وادخل بحساب المريض الثاني. ٣) افتح صفحة الحجز للطبيب نفسه واليوم نفسه. ٤) حاول اختيار 10:00.
- النتيجة المتوقّعة
- موعد 10:00 يظهر غير متاح للمريض الثاني، ولا يُنشأ حجز ثانٍ
- الأولوية
- عالية: مريضان في موعد واحد مشكلة يراها العميل مباشرة
لاحظ أن الحالة لا تقول «تأكّد من أن الحجز يعمل». هذه أمنية وليست حالة اختبار. الحالة الجيدة تحدّد الموقف، والفعل، وما يجب أن يحدث بعده. وحين تفشل، تتحوّل خطواتها مباشرة إلى تقرير خلل جاهز.
ماذا تعني نتائج الاختبار؟
جولة الاختبار لا تنتهي بـ«نجح» أو «فشل» فقط. التقرير الصادق يفرّق بين خلل في تطبيقك ومشكلة في الاختبار نفسه أو في ظروفه:
| النتيجة | معناها | ماذا تفعل |
|---|---|---|
| نجحت | حدث ما كان متوقّعاً بالضبط | لا شيء. أعِدها بعد التعديل القادم |
| فشلت | التطبيق فعل شيئاً غير المتوقّع | سجّل خللاً بدليله، ثم أصلح وأعد الاختبار |
| محجوبة | لم تبدأ أصلاً لأن خطوة قبلها تعطّلت، كتسجيل الدخول | عالج السبب الأول؛ ليست خللاً جديداً بحدّ ذاتها |
| غير حاسمة | تعذّر الحكم: انقطع الاتصال، أو تغيّرت الصفحة فلم تعد الخطوات تطابقها | حدّث الحالة أو أعد المحاولة قبل أن تستنتج شيئاً |
| متذبذبة | فشلت مرة ونجحت عند الإعادة دون أي تغيير | لا تتجاهلها: قد يكون خللاً يظهر تحت ظرف معيّن |
رسم توضيحي: حكم «جاهز / غير جاهز» في نهاية جولة اختبار. الأرقام أمثلة.
عشرون حالة ناجحة لا تقول شيئاً عن الحالة الحادية والعشرين التي لم تُكتب. التقرير الجيد يذكر حدوده صراحة: ما الذي غطّاه، وما الذي بقي خارجه.
كم اختباراً يحتاج مشروع صغير؟
ليس كل شيء يستحق الجهد نفسه. خطأ إملائي في صفحة «من نحن» مزعج، وخلل في الدفع يوقف دخلك. رتّب بحسب الخطر، لا بحسب ترتيب الصفحات. ابدأ بهذه الأسئلة الأربعة:
- 1أين يمرّ المال؟
الدفع، والاسترجاع، والخصومات، والضريبة، والفاتورة. أي خلل هنا خسارة مباشرة أو نزاع مع عميل.
- 2من يدخل، وماذا يرى؟
التسجيل، والدخول، واستعادة كلمة المرور، والصلاحيات: هل يرى الموظف ما لا يخصّه؟ هل يرى عميل بيانات عميل آخر؟
- 3أين يمكن أن تضيع بيانات أو تتكرّر؟
حجز لا يُحفظ، أو طلب يُسجَّل مرتين، أو تعديل يمحو ما قبله. هذه أخطاء صامتة لا تظهر إلا بعد أن تتراكم.
- 4ما المسار الذي يسلكه أكثر عملائك؟
المسار الواحد الذي يمرّ به تسعة من كل عشرة زوّار يستحق اختباراً أدقّ من عشر صفحات لا يفتحها أحد.
اكتب من خمس إلى عشر حالات اختبار تغطّي إجابات هذه الأسئلة، بطريقها الصحيح وأشهر طرقها الخاطئة. هذه «مجموعتك الأساسية»: تعيدها قبل كل إطلاق وبعد كل تعديل. ثم تضيف إليها حالة جديدة كلما ظهر خلل، حتى لا يعود الخلل نفسه مرتين.
- المسار الأساسي يكتمل من أوله إلى آخره على الجوال.
- النماذج ترفض الإدخال الخاطئ برسالة مفهومة.
- الدفع ينجح، وفشله لا يُنشئ طلباً معلّقاً.
- كل دور يرى ما يخصّه فقط.
- الضغط المتكرّر أو الطلب المتزامن لا يكرّر الحجز أو الطلب.
- رسائل التأكيد تصل، بالعربية الصحيحة.
أين يقع مهندس الجودة بالذكاء الاصطناعي، وما حدوده؟
الاختبار الآلي كان يحتاج تقليدياً إلى من يكتب الحالات ويصونها، وهذا ما أبعده عن المشاريع الصغيرة. مهندس الجودة بالذكاء الاصطناعي يسدّ هذه الفجوة: تصف له ما تريد التأكّد منه بكلامك، فيقترح حالات الاختبار، وينفّذها، ويوثّق ما وجد.
في فنّان، مهندس الجودة يعمل بهذه الطريقة: يستكشف تطبيقك، ويعرض عليك خطة اختبار تراجعها قبل التنفيذ، ثم ينفّذها في متصفح حقيقي، ويتحقّق من الـ API إن وُجد. كل خلل يصلك بلقطة شاشة وخطوات تعيده والمتوقّع مقابل الفعلي، ولا يُعدّ مُصلَحاً إلا بعد أن تنجح إعادة الاختبار. وفي النهاية حكم واضح: جاهز، أو غير جاهز، أو غير حاسم، مع ذكر ما لم يُغطَّ. يعمل على التطبيقات المبنيّة بفنّان، وعلى المواقع الخارجية بمجرّد إضافة رابطها.
رسم توضيحي: تقرير خلل موثّق بلقطة شاشة وخطوات إعادته. البيانات أمثلة.
مهندس الجودة يرى تطبيقك كما يراه الزائر. لا يستطيع تخمين قاعدة عمل لم تذكرها: إن كان الإلغاء ممنوعاً قبل الموعد بساعتين فقل له ذلك. وجولة ناجحة ليست دليلاً على تطبيق بلا أخطاء؛ هي دليل على أن ما اختُبر يعمل. ويبقى اختبار القبول عليك أنت.
أخطاء شائعة في الاختبار
- اختبار الطريق الصحيح فقط. العملاء يخطئون ويستعجلون ويضغطون مرتين. جرّب ما سيفعلونه، لا ما تتمنّى أن يفعلوه.
- الاختبار على الحاسوب والعملاء على الجوال. اختبر حيث يكون عملاؤك.
- الاختبار ببيانات مثالية. اسم طويل جداً، رقم يبدأ بصفر، نص عربي وإنجليزي في الحقل نفسه: الواقع أقلّ ترتيباً من بياناتك التجريبية.
- اعتبار الخلل مُصلَحاً لأن أحداً قال ذلك. الخلل يُغلق حين تنجح الحالة التي كشفته، لا قبل.
- تجربة التعديل الجديد فقط. ما انكسر غالباً ليس ما عدّلته، بل ما يجاوره. أعد المجموعة الأساسية كاملة.
- الاختبار على بيانات العملاء الحقيقية بلا حذر. استخدم حسابات تجريبية، وحدّد ما لا يجوز تغييره قبل أن تبدأ.
- تأجيل الاختبار إلى ليلة الإطلاق. لن يبقى وقت للإصلاح، فتطلق وأنت تعرف أن هناك خللاً.
السؤال ليس «هل في تطبيقي أخطاء؟» فالجواب دائماً نعم. السؤال: «هل أعرفها أنا قبل عملائي؟»
الخلاصة
- الاختبار تجربة مقصودة بخطوات مكتوبة ونتيجة متوقّعة، لا نظرة سريعة على الصفحة الرئيسية.
- الخلل نفسه يكلّف أكثر كلما تأخّر اكتشافه، وأغلى ما يكون حين يجده العميل.
- رتّب بحسب الخطر: المال، والدخول والصلاحيات، وضياع البيانات، والمسار الأكثر استخداماً.
- احفظ حالات الاختبار وأعدها بعد كل تعديل؛ معظم الأخطاء تأتي من تعديل كسر شيئاً مجاوراً.
- الخلل لا يُعدّ مُصلَحاً إلا بعد إعادة اختبار ناجحة.
- جولة ناجحة تثبت أن ما اختُبر يعمل، لا أن التطبيق بلا أخطاء. اسأل دائماً عمّا لم يُختبر.