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

كما هو الحال مع العديد من مختبري البرمجيات، هنالك صعوبة عند العمل لأول مرة ضمن فريق scrum. كيف يتم كتابة الاختبارات بدون مواصفات (specifications)؟ كيف نعرف متى ننتهي من اختبار البرمجيات في غياب خطة اختبار (test plan)؟ في أنشطة جَمْع المتطلبات لإنشاء الميزات (features) وقصص المستخدم (user stories)، يُمكِن أن يُقدّم مختبرو البرمجيات مساهمات مهمّة وسنستعرض هذه المساهمات في الأقسام التالية.

منهجيّة أجايل ليست عمليةً صارِمة بل هي مجموعة من القِيَم والمبادئ التي تهدف إلى مساعدة المطورين على تطوير البرمجيات بسرعة أكبر وبجودة أفضل. إذا ركّزنا على الأفراد وكيفيّة تعاونهم أكثر من الأدوات والإجراءات (tools and processes)، فسنتمكّن من إيجاد طريقة لإنجاز العمل على نحوٍ أفضل. وإذا أعطينا الأولوية للبرمجيات العاملة بدلًا من التركيز المُفرَط على التوثيق (documentation)، فسيكون لدينا فرصة أكبر لتقديم برمجيات فعّالة. وإذا عملنا مع العميل بدلًا من وضع عَقْد جامد (rigid contract)، فسيكون البرنامج أقرب إلى ما يمكن للعميل استخدامه والاستفادة منه. كذلك إذا فضّلنا إجراء التغييرات الصحيحة على اتباع خطّة محدّدة، فسيكون لدينا فرصة أفضل لتجاوز ما أغفلته الخطة. وهناك أيضًا 12 مبدأً أساسيًا تدعم هذه القِيَم. وحتى مع هذه القِيَم ومع هذه المبادئ المحدّدة نوعًا ما، فإنها تترك المجال مفتوحًا على مصراعيه أمام كيفيّة تطبيق الفريق لمنهجيّة أجايل.

Scrum هي منهجيّة لتطوير البرمجيات تعتمد على قِيَم ومبادئ Agile مع مجموعة من الإرشادات العمليّة المسانِدة. المقولة صعبةٌ في البداية، لكنها سهلةٌ في النهاية هي جوهر scrum. تعتمد scrum على فِرَق صغيرة تُنجِز مشاريع صغيرة بسرعة وكفاءة ويضيف فيها مختبِرو البرمجيات مجموعةً مميّزةً من المهارات إلى الفريق.

عند انضمامك كمختبِر برمجيات إلى فريق scrum، ستساهم في نجاح الفريق من خلال مهاراتك. هناك ثلاثة أمور يمكنك القيام بها لمساعدة الفريق، اثنان منها مألوفان لديك:

• يمكنك المساعدة في ضمان تطوير المنتَج الصحيح (the right product is getting created)
• والتأكّد من إنشائه بالشكل الصحيح (the product is being made right)
• كما يمكنك التحلّي بالمرونة لتعظيم مساهمتك داخل الفريق

قبل تنفيذ الـ User Story

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

حدّدْ مخاطر المُنتَج ومخاطر النظام قبل أن تتحوّل إلى مشاكل. قد يتطلّب ذلك التخطيط لاختبارات خاصة. على سبيل المثال، إذا كان الخادم (server) يدعم موازنة الأحمال (load balancing)، فقد تحتاج إلى اختبار العديد من الميزات في بيئة متوازنة الأحمال (load balanced environment). الاستعانة بفريق الاختبار للتحقق من النظام (system testing) أمر ممكن لكن إصلاح الأخطاء التي سيتم العثور عليها في تلك المرحلة سيكون مُكْلِفًا للغاية.

تأكّدْ من أن الميزة تدعم أتمتة الاختبارات. إذا تطلّب الأمر تطوير دعْم لأتمتة الاختبارات (test automation)، فيجب تضمين ذلك في التقدير والتصميم (estimate and design).

يتطلّب هذا حضورك كمختبِر برمجيات منذ البداية. لا تفوّتْ الاجتماعات الأوليّة لتصميم الميزات (features) وتقديرها (designing and estimating). إذا لم تتم دعوتك، فبادر بطلب الانضمام أو احرص على أن تكون ضمن هذه الاجتماعات. حينها يمكنك تقديم ملاحظاتك الأولية لضمان تطوير المُنتَج الأمثل.

أثناء التنفيذ (During Implementation)

ثانيًا، يمكنك المساعدة من خلال التأكّد من كتابة الاختبارات منذ البداية وأفضل طريقة لتحقيق ذلك هي الاجتماع مع المطوّر وكاتب الـ user story قبل البَدْء بأي عمل. وكما ذكَرَت جانيت غريغوري في كتابها الذي شاركت في تأليفه مع ليزا كريسبين بعنوان Agile Testing: A Practical Guide to for Testers and Agile Teams: لقد حققنا نجاحًا كبيرًا باستخدام the Power of Three.

عندما يجتمع المختبر والمطوّر والعميل (أو مُمَثّل العميل) لمناقشة الميزة منذ البداية وفي كل مرّة يطلبون فيها توضيحًا يُقدّم المختبر ملاحظاته حول ما سيتم اختباره. إذا كان فريقك يتبع منهجيّة تطوير البرمجيات القائمة على السلوك (Behavior Driven Development – BDD)، فاكتب السيناريوهات أو على الأقل قُم بتوجيههم للتأكّد من أنها لا تفتقر إلى التحقق الكافي.

إذا لم تقم بكتابة السيناريوهات، فراجعها. يجب أن توضّح السيناريوهات الهدف من الميزة بوضوح. ينبغي أن تكون قادرًا على تحديد حالة النظام في البداية ومعايير الاختبار (test criteria). احرص على أن تكون الاختبارات متوازنة وأن تتجنّب السيناريوهات المتكرّرة مع توفير تفاصيل كافية لمعرفة قواعد العمل التي يتم اختبارها (business rules). بالطبع، يجب التحقق من جميع معايير القبول (acceptance criteria).

قبل الانتهاء (Before Completion)

قد يبدو هذا غريبًا لأي فريق يتبع منهجيّة تطوير البرمجيات القائمة على السلوك (BDD)، لكن لن تحصل على جودة كافية إذا لم تُجرِ اختبارات استكشافية (exploratory testing) أثناء أو بعد اكتمال الميزة. دوّنْ ملاحظات حول كيفية اختبار الميزة بما في ذلك المتغيّرات (parameters) والإعدادات الرئيسية. يمكنك إيجاد بعض الأدوات لتسجيل نشاط الويب (record web activity) مما يُسهّل تتبّع الخطوات عند ظهور أي مشكلة.

طوال الوقت (All the Time)

كما ذكرنا، فِرَق scrum صغيرة الحجم وغالبًا ما تضم ​​نسبة عالية من المطوّرين إلى المختبرين. ورغم أن هذا قد يستحوذ على معظم وقت الاختبار، إلا أن الفرق الناجحة تتميّز بأعضاء مرنين. يمكنك المساهمة في ذلك من خلال استعدادك للخروج من دائرة راحتك ومساعدة الفريق عن طريق إعداد الخوادم والأدوات وحل مشكلات الـ build وغيرها.

يُعزّز التعاون بين أعضاء الفريق في مرحلتي التطوير والاختبار من قدراتهم. فعندما يتشارك الأفراد في تخصّصات مختلفة، يتحسّن فهمهم للمُنتَج وللكود البرمجي ولما يعتبره أصحاب المصلحة الآخرون (other stakeholders) مهمًا.

هناك الكثير مما يجب فعله!

كما هو الحال في أي عملية تدقيق ناجحة (audit)، هناك الكثير من العمل. من المذهل أن تُنجَز قصص المستخدم وأن تُستكمَل الميزات وأن نجد طريقة للحفاظ على وتيرة عمل مُستدامة. وللحفاظ على الهدوء، نحاول أن نتذكّر أن التمهّل هو الأفضل. يمكننا الحفاظ على وتيرة عمل أفضل بعدم التسرّع المُفرَط.

يتحمّل فريق scrum بأكمله المسؤولية ولا تُعتبر المهمة مكتملة إلا بعد استيفاء جميع متطلّبات الإنجاز. أيضًا يوجد سِجِل مهام (backlog) وإذا تعذّر إجراء اختبارٍ مّا بسبب متطلّبات معيّنة مثل اكتساب مهارة معينة، فيُجدْوَل لاحقًا. المهم التأكّد من عدم نسيانه.

* المصدر: https://www.scrumexpert.com/knowledge/being-a-software-tester-in-scrum
** الصورة من موقع: https://www.systemsvalley.com/becoming-the-scrum-master-your-team-needs