استعمال اختبار القبول لضمان جودة المنتج

لا بدّ وأنّك سمعت بمشكلة واي تو كاي Y2K، أو مشكلة سنة 2000 ميلادي الّتي أرّقت التّقنيّين عند بدء الألفيّة الجديدة، والّتي بُذلت فيها ملايين الدّولارات ومئات ساعات العمل لإصلاح خطأ لم يكن مهندسو الماضي ليتوقّعوه.

أو ما حدث قبلها بسنتين، في 1998، عندما اكتُشف خطأ برمجي تسبب في انفجار مسبار ناسا المداريّ الّذي أرسلته لاستكشاف الغلاف الجويّ لكوكب المرّيخ The Mars Climate Orbiter، وذلك بسبب اقتراب المسبار من الكوكب أكثر ممّا يجب نتيجة استعمال ناسا الوحدات المئوية في حسابها لمسار المسبار؛ فيما اعتمد مصنّع المركبة لوكهيد مارتن Lockheed Martin على وحدات القياس الإمبرياليّة (الوحدات البريطانية).

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

لتوضيح الأمور أكثر، دعونا ننتقل الآن إلى الحديث عما تعنيه مراقبة الجودة في مجال تطوير البرامج الحديثة.

ما هي مراقبة الجودة؟

مراقبة الجودة حسب ISO 9000 هي عمليّة تحقيق شروط الجودة. ومنذ بدأت البشريّة في تصنيع المنتجات بأعداد كبيرة، ظهر السؤال: كيف يمكن ضمان رضا جميع العملاء عن المنتج الّذي يشترونه؟ لطالما ظهرت عيوب واختلافات بين المنتج المصنّع وبين التّصميم الأصليّ، ولذا اختُرعت عمليّات مختلفة للتحقّق من أنّ المنتج جيّد بما يكفي ليدخل السّوق.

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

تجاوبًا مع معايير الجودة المختلفة الّتي كان على المنظّمات المتعاقدة مع الحكومات الامتثال لها، نشرت المنظّمة الدّولية للتّوحيد القياسيّ the International Organization for Standardization واختصارها ISO، حيث نشرت متطلّباتِ جودةٍ معترف بها الآن عالميّا.

لقد سهّلت متطلّبات ISO 9000 على العملاء والمورّدين على حدّ سواء تحديد توقّعات الجودة، كما سمحت شهادة ISO 9000 لما يفوق مليون بائع عالميًّا بتأكيد جودة منتجاتهم. أمّا في مجال تطوير البرامج الحاسوبية، فإنّ مراقبة الجودة تتماشى طرديا مع مفهومين آخرين هما:

• ضمان الجودة Quality Assurance واختصارا QA.
• الاختبار Testing.

لنلقِ الآن نظرةً عليهما عن كثب.

مقارنة ضمان الجودة ومراقبة الجودة والاختبار

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

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

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

ولفهم اختبار القبول فهمًا أفضل، وكيفية تحديد الجودة في تطوير البرامج، سنغطّي في الآتي عمليّة مراقبة الجودة.

عملية مراقبة الجودة

مراقبة الجودة في جوهرها عبارة هي عن عمليّة التحقّق من أنّ المنتج النّهائي يوافق التوقّعات المسجّلة عند بداية تطوير البرنامج. وفيما يلي كيفيّة فعل ذلك.

تحديد متطلبات البرنامج ومعايير القبول

لقد غيّرَت منهجية أجايل Agile في تطوير البرامج كيفيّة فهمنا ومقاربتنا للجودة، فعندما طغت طريقة تدفّق المياه waterfall method كانت إدارة الجودة في مجال تطوير البرامج مشابهةً لها في مجال التّصنيع والبناء؛ فكان عندها التّركيز منصبًّا على إصلاح الأخطاء عند حدوثها، وتأجيل الاختبارات إلى ما بعد انتهاء العمل؛ أمّا في عصر أجايل، فقد صار الاختبار جزءًا من كلّ مرحلة تطوير، مع حلقة تغذية راجعة تتيح مراقبة الجودة على نطاق منتظم.

لكن ما هي إذًا الجودة في عصر فلسفة أجايل؟

تُعرَّفُ الجودةُ اليومَ بأنّها الالتزام بمفهومين:

1. المتطلبات الوظيفية: أو ما إذا كان في البرنامج مزايا طلبها المستعمل أو صاحب المصلحة.
2. المتطلبات غير الوظيفية: أو ما إذا كان البرنامج يؤدّي كما يجب.

يمكنك التّفكير في المتطلّبات الوظيفيّة وغير الوظيفيّة على أنّهما قوائم مهامّ يتبعها المطوّرون.

• متطلّب وظيفيّ: ينبغي أن يتمكّن المستخدم من تغيير لغة الواجهة.
• متطلّب غير وظيفيّ: يجب أن يؤدّي النّظام الحسابات باستعمال الوحدات المتريّة فقط.

وكما تلاحظ، فإنّ هذه العبارات خالية من أيّ سياق أو عاطفة؛ أمّا عن سؤال ما هي أهميّتها لجودة البرنامج؟ وما القيمة الّتي تضيفها؟ فإنّ تمكين المطوّرين من العمل على قيمٍ بدل المزايا، سيتحقّق باستخدام ما يسمى "قصص المستخدمين". وقصّة المستخدم هي هدف نهائيّ يُعبَّرُ عنه من وجهة نظر المستخدم، مثل:

• "كوني مستخدمًا، فإنّني أريد تشغيل البرنامج باللّغة الّتي أفهمها".
• "كوني مستخدمًا، فإنّني أريد أن يُجري النّظام الحسابات بالوحدات الّتي أنا معتاد عليها".

إنّ كتابة هذه القصص بهذا الأسلوب ينقل التّركيز إلى المستخدم، ويمكّن من الخروج بحلول أكثر إبداعًا. ولكنّ هذه القصص لا تفيد كثيرًا في قياس الجودة. فكيف إذًا نتحقّق من توصيل الفائدة؟ هنا يأتي دور ما يسمى "معايير القبول".

تصف معايير القبول سيناريوهات أو قواعد محدّدة لكيفيّة عمل المزايا، وهي تُكتب غالبًا وفق تنسيق: "إذا كان/عندما/فإنّ"، ومثال ذلك توضيحيًا هو كما يلي:

• إذا كان المستخدم، اتّجه إلى صفحة إعدادات الحساب.
• عندما يختار المستخدم إعدادات اللّغة.
• فإنّ قائمة اللّغات المتاحة ستظهر.
• إذا كان المستخدم اختار لغته.
• عندما يوافق على التّغييرات.
• فإنّ لغة الواجهة ستتغيّر.

العلاقة بين المتطلّبات وقصص المستخدمين ومعايير القبول

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

تحديد أنواع اختبار القبول

الغاية من وراء اختبار القبول Acceptance Testing واختصارا AT، هي التحقّق من أنّ المنتج ملتزم باحتياجات العمل من حيث الأهداف، والقبول لدى المستخدم، والقواعد، والشّروط، والعمليّات، إلى غير ذلك. والمشاكل المكتشفة خلال اختبار القبول، تعني أنّ المنتج غير جاهز للسّوق، ويجب تعديله في الحال.

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

اختبار قبول المستخدم

اختبار قبول المستخدم User Acceptance Testing أو اختصارًا UAT ويسمّى أيضًا "اختبار المستخدم النّهائيّ" هو اختبار يُجرى بتبنّي منظور المستخدم النّهائي، أو بتوظيف مستخدم نهائي فعليّ لإجراء الاختبار.

يتحقّق هذا الاختبار من المتطلّبات الوظيفيّة فقط، في بيئة حرّة غير متحكَّمٍ فيها، بمعنى أنّ القيود على كيفية استخدام المنتج خلال هذا الاختبار قليلة جدًّا؛ كما لا ينحصر إجراء هذا الاختبار على المراحل النّهائيّة من التّطوير، بل خلال مرحلة تصميم البرنامج، أو تصميم تجربة المستخدم؛ وحتّى أبكر من ذلك بمجرّد جاهزيّة عرض البرنامج The product demo.

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

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

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

اختبار قبول العقود

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

يحتوي العَقد عادةً على شروط مفصّلة حول وقت وكيفيّة الاختبار، وحول الشّروط الّتي تجعل المنتج مقبولًا أو غير مقبول.

اختبار قبول اللوائح

ويسمّى أيضًا "اختبار قبول الامتثال"، وهو اختبار يفحص ما إذا كان المنتج يمتثل لقواعد ولوائح البلدان الّتي سيُسوّقُ فيها. وحتّى لو نجح في الاختبارات جميعها وفشل في هذا، فإنّه لن يُسمحَ بتسويقه.

اختبار قبول التشغيل

ويسمّى كذلك "باختبار جاهزية التشغيل"، وهو يفحص المتطلّبات غير الوظيفيّة مثل قابليّة التوسّع، وإمكانيّة الصّيانة، والتّوافق، والثّبات، وغير ذلك.

كتابة حالات اختبار من معايير القبول

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

تبدو معيار القبول كما يلي:

• إذا كان المستخدم، اتّجه إلى صفحة إعدادات الحساب.
• عندما يختار المستخدم إعدادات اللّغة.
• فإنّ قائمة اللّغات المتاحة ستظهر.
• إذا كان المستخدم اختار لغته.
• عندما يوافق على التّغييرات.
• فإنّ لغة الواجهة ستتغيّر.

ويمكن تحويله إلى نمط حالة اختبار اعتياديّة بالشّكل التّالي:

تبسّط هذه العلاقة بين حالات الاختبار وبين معيار الاختبار عمليّة التّنقيح، إذ متى لاحظنا خلال الاختبار أنّ السّيناريو لم يمضِ كما كان متوقَّعًا، أعدنا ببساطة كتابة قصص المستخدم ومعايير القبول.

إجراء اختبارات قبول مؤتمتة

رغم أنّ اختبارات القبول تراجع عادةً المتطلّبات الّتي تواجه الجانب التّجاريّ بدل التّفاصيل التّقنية، إلاّ أنّه يمكن أتمتتها. بل إنّ أتمتتها في نظام أجايل نفسه تُعَد ضرورةً حتميّة. والكثير من أدوات أتمتة اختبارات القبول تفهم صيغة "إذا كان/عندما/فإنّ'، ويمكنها تنفيذ المزايا دون الحاجة إلى تدخّل كبير من مُجري الاختبار.

في الصّورة التّالية نموذج عن كيفيّة كتابة اختبار مؤتمت باستخدام الأداة المعروفة Cucumber:

المصدر: Semaphore

من بين الأدوات المفيدة في إنشاء اختبارات القبول المؤتمتة نذكر على سبيل المثال لا الحصر:

• JBehave
• Behat
• SpecFlow

تبنّي تطوير مدفوع باختبارات القبول

طرائق الاختبار المشهورة في نظام أجايل ثلاثة هي:

• التطوير المدفوع بالاختبار Test-Driven Development واختصارًا TDD.
• التّطوير المدفوع بالسّلوك Behavior-Driven Development واختصارًا BDD.
• التطوّير المدفوع باختبارات القبول Acceptance Test-Driven Development واختصارًا ATDD.

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

الفروق بين TDD وBDD وATDD

عندما تبدأ في التّطوير المدفوع بالاختبار TDD بكتابة حالات الاختبار، فإنّك على الجانب المقابل، في حال بدأت التّطوير المدفوع بالسّلوك BDD، ستبدأ بتحديد قصص المستخدم؛ أمّا في التّطوير المدفوع باختبارات القبول ATDD فإنّك ستحتاج للبدء بكتابة اختبارات القبول أوّلًا. وقد يكون الفرق بين أوّل اثنين غامضًا، أمّا الثّالث ATDD فيهدف إلى هدفين فريدين اثنين:

• يركّز التّطوير المدفوع باختبارات القبول ATDD على تعريف المتطلّبات تعريفًا صحيحًا بدل التحقٌّ من موافقتها لسلوك النّظام. وهو بذلك يضمن أنّ جودة المنتج هي الاعتبار الأوّل سواءً من الجانب التّجاريّ أو جانب المستخدم.
• يحرص التّطوير المدفوع باختبارات القبول ATDD على أن يشمل جميع أصحاب المصلحة بدءًا بالمطوّرين والمختبرين، مرورًا بأصحاب الجانب التّجاري، ووصولًا إلى خبراء الميدان ليشترك الجميع في فهم شامل لأهداف المشروع، ويساهموا في كتابة اختبارات القبول.

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

من يراقب الجودة؟

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

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

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

أمّا اختبارات القبول ذاتها، فيُجريها أصحاب المصلحة من عملاء، ومستخدمين نهائيّين، ومُختبرين محترفين يُوظّفون لهذا الغرض.

الجودة أولا وقبل كل شيء

رضا العملاء في نموذج أجايل مرادف للجودة، فقد جاء في أوّل مبدأ من بيان أجايل:

اقتباس

"أولويّتنا القصوى هي إرضاء العميل عبر التقديم المبكّر والمتواصل لبرامج قيّمة".

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

ولعلّ التّطوير المدفوع باختبارات القبول ATDD قادر على مساعدتك في تحقيق ذلك المستوى من الجودة.

ترجمة -وبتصرّف- للمقال Quality Control: Using Acceptance Testing to Guarantee Product Quality.

اقرأ أيضًا

• ما هي إدارة المنتجات؟
• ما هي إدارة المشاريع؟
• دليل المبتدئين لمنهجية أجايل Agile
• المراسم الأربعة لمنهجية أجايل Agile ceremonies
• مفهوم الجودة المدركة للمنتجات Perceived Quality