Agile للمختبِرين

لماذا يهم

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

وبالنسبة إلى المختبِر، تغيّر Agile متى وكيف يعمل أكثر مما تغيّر التقنيات التي يستخدمها: المهارات نفسها، لكن في وقت أبكر، وعلى أجزاء أصغر، وفي حوار دائم مع المطورين ومالك المنتج (Product Owner).

قيم Agile ومبادئها بعين المختبِر

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

والقيم الأربع تفضيلات: البند الأول يُقدَّر أكثر، لكن البند الثاني تبقى له قيمة. وكل قيمة تغيّر عادات المختبِر:

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

موقع الاختبار: مبكراً ومتكرراً وبمسؤولية مشتركة

ثلاث أفكار تصف موقع المختبِر في الفريق الرشيق، ويقارن المخطط الزمني أدناه قصة واحدة بالتدفق التتابعي.

• المشاركة المبكرة: يناقش المختبِر القصة قبل بنائها، عادةً في تنقيح قائمة المهام (Backlog refinement)؛ وتسمّي فرق كثيرة هذا اللقاء بين منظور الأعمال والتطوير والاختبار «الأصدقاء الثلاثة» (Three amigos). وسؤال مثل «ماذا لو انتهت صلاحية رمز الخصم؟» يصبح مثالاً، ثم معيار قبول، ثم اختباراً.
• حلقات التغذية الراجعة القصيرة (Feedback loops): تعمل الفحوص الآلية عند كل تغيير، ويستكشف المختبِر كل نسخة بمجرد قابليتها للنشر، ويُبلَّغ عن العيوب وتُصلَح ويُعاد اختبارها داخل الدورة، وغالباً خلال ساعات.
• الفريق الكامل: يصف ISTQB نهج الفريق الكامل (Whole-team approach)، وهو ممارسة مصدرها البرمجة القصوى (Extreme Programming)، ويكون فيه الجميع مسؤولين عن الجودة، ويستطيع فيه أي عضو يملك المعرفة والمهارات اللازمة أداء أي مهمة. فيساعد المختبِر ممثلي الأعمال، كمالك المنتج، على إعداد اختبارات قبول مناسبة، ويتفق مع المطورين على استراتيجية الاختبار ونهج الأتمتة. ويذكر ISTQB أن هذا النهج قد لا يناسب الحالات التي تتطلب استقلالية عالية للاختبار، كالأنظمة الحرجة للسلامة.

Sequential: testing waits for a phase of its own
  requirements -> design -> build -> test phase -> release
                                     ^ first feedback on the requirement, weeks later

Agile: one story inside a two-week iteration
  Before  refinement  tester asks for examples; they become acceptance criteria
  Day 1   planning    team agrees how the story will be tested and by whom
  Day 2   build       developer writes code and component tests; tester prepares data
  Day 3   test        automated checks run on each change; tester explores the build
  Day 3   fix         defect reported, fixed and retested the same day
  Day 4   done        acceptance tests pass and join the automated regression suite

أرباع الاختبار الرشيق

أرباع الاختبار الرشيق (Agile testing quadrants)، التي عرّفها بريان ماريك (Brian Marick) ووصفتها ليزا كريسبن وجانيت غريغوري في كتابهما Agile Testing ويتناولها منهج ISTQB للمستوى التأسيسي الإصدار ⁦4.0⁩، ترسم أنواع الاختبار التي يحتاج إليها الفريق. فالاختبارات الموجّهة للأعمال (Business-facing) تستخدم مصطلحات يفهمها خبير الأعمال، والموجّهة للتقنية (Technology-facing) تستخدم مصطلحات الكود. والاختبارات التي تدعم الفريق توجّه التطوير، أما التي تنقد المنتج فتقيس سلوكه مقابل التوقعات.

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

• Q1، موجّه للتقنية ويدعم الفريق: اختبارات المكوّن (الوحدة) واختبارات تكامل المكوّنات، يكتبها المطورون وتُؤتمت في التكامل المستمر (CI).
• Q2، موجّه للأعمال ويدعم الفريق: الاختبارات الوظيفية، والأمثلة، واختبارات قصص المستخدم، والنماذج الأولية لتجربة المستخدم، واختبارات الواجهة البرمجية (API)، والمحاكاة، التي تتحقق من معايير القبول؛ يدوية أو آلية.
• Q3، موجّه للأعمال وينقد المنتج: الاختبار الاستكشافي، واختبار قابلية الاستخدام، واختبار قبول المستخدم؛ موجّهة للمستخدم ويدوية غالباً.
• Q4، موجّه للتقنية وينقد المنتج: اختبارات الأداء والحمل والأمان وسائر الاختبارات غير الوظيفية عدا قابلية الاستخدام، إضافةً إلى اختبارات الدخان (Smoke tests) في قائمة ISTQB؛ آلية غالباً وبأدوات.

جرّبها: مولّد سيناريوهات الاختبار

مثال تطبيقي: قصة واحدة عبر دورة

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

• اليوم ⁦3⁩: يكشف الاستكشاف أن حذف منتج بعد تطبيق الرمز يُبقي الخصم القديم. فيُصلَح العيب ويُعاد اختباره في اليوم نفسه، وينضم السيناريو إلى فحوص Q2 الآلية التي تعمل عند كل تغيير.

Story: apply a discount code at checkout

Q1  developers     unit tests: 10% of 200.00 -> 20.00
                   15% of 99.99 -> 15.00 (the agreed rounding)
Q2  tester + devs  acceptance tests from the examples, automated:
                   SAVE10 on a 200.00 SAR basket -> total 180.00 SAR
                   expired code -> rejected with the expiry message
                   second code on the same order -> rejected
Q3  tester         30-minute exploratory session: remove items after applying
                   the code, back button, two browser tabs, Arabic layout
Q4  tester + devs  many wrong codes in a row -> rate-limited (own test env only)
                   response time of code checks under campaign load

جرّبها: مولّد معايير القبول جرّبها: قصة المستخدم ← سيناريوهات اختبار

أسئلة شائعة

المراجع

• Manifesto for Agile Software DevelopmentThe Agile Manifesto authors · 2001القيم الأربع لتطوير البرمجيات الرشيق (Agile)، مثل تقديم البرمجيات العاملة على التوثيق الشامل، والاستجابة للتغيير على اتباع الخطة.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)Addison-Wesley (Pearson) · 2009أرباع الاختبار الرشيق وكيف يعمل المختبرون داخل فريق التسليم — أساس «الاختبار في الطبقة الصحيحة».
• Principles behind the Agile ManifestoThe Agile Manifesto authors · 2001المبادئ الاثنا عشر وراء البيان، ومنها أن البرمجيات العاملة هي المقياس الأساسي للتقدم، وأن يعمل الفريق بوتيرة يمكنه الحفاظ عليها دون توقف.