طريق إلى اختبار رشاقة أفضل

يُظهر تقرير الجودة العالمي السنوي الذي أنشأته Capgemini أن 42٪ من المشاركين في الاستطلاع يسردون "نقص خبرة الاختبار الاحترافي" باعتباره تحديًا في تطبيق الاختبار على تطوير Agile. في حين أن ظهور Agile قد أدى إلى زيادة سرعة التكرارات لتطوير البرامج ، فقد جاء ذلك في بعض الحالات على حساب الجودة.

تضغط المنافسة الشرسة على الفرق لتقديم تحديثات المنتجات الجديدة باستمرار ، ولكن هذا يأتي أحيانًا بتكلفته الخاصة ، بما في ذلك الاهتمام المنخفض بالاختبار. يذهب البعض ، مثل Rob Mason ، إلى أبعد من ذلك ويجادلون بأن Agile تقضي على اختبار البرامج. في الآونة الأخيرة ، قام Facebook بتغيير شعاره من "التحرك بسرعة وكسر الأشياء" إلى "التحرك بسرعة مع بنية تحتية مستقرة" في محاولة لحل الإغراءات للتضحية بالجودة.

لذا ، كيف يمكن دمج الاختبار بشكل أفضل في العالم الجديد لتطوير البرمجيات الرشيقة؟ اختبار رشيق.

الاختبارات التقليدية مرهقة للغاية وتعتمد على الكثير من الوثائق. اختبار Agile هو نهج لعملية الاختبار التي تحاكي مبادئ تطوير البرمجيات Agile حيث:

• يتم إجراء الاختبار في كثير من الأحيان ،
• يعتمد الاختبار بدرجة أقل على الوثائق وأكثر على تعاون أعضاء الفريق ، و
• يتم إجراء بعض أنشطة الاختبار ليس فقط بواسطة المختبرين ولكن أيضًا بواسطة المطورين.

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

إضفاء الطابع الرسمي على عملية دورة اختبار الإطلاق

تتمثل إحدى مشكلات الاختبار في عدم وجود دورة اختبار الإصدار ، أو عدم وجود جدول زمني للإصدار ، أو طلبات اختبار غير منتظمة. تجعل طلبات الاختبار عند الطلب عملية ضمان الجودة صعبة ، خاصة إذا كان المختبرين يتعاملون مع مشاريع متعددة.

تقوم العديد من الفرق ببناء واحد فقط بعد كل سباق ، وهو ليس مثاليًا لمشاريع Agile. قد يكون الانتقال إلى الإصدارات مرة في الأسبوع مفيدًا ، والانتقال تدريجيًا إلى إصدارات متعددة أسبوعيًا. من الناحية المثالية ، يجب إجراء عمليات إنشاء واختبار التطوير يوميًا ، مما يعني أن المطورين يدفعون التعليمات البرمجية إلى المستودع كل يوم ويتم جدولة الإنشاءات في وقت محدد. لاتخاذ هذه الخطوة إلى الأمام ، سيكون المطورون قادرين على نشر كود جديد عند الطلب. لتنفيذ ذلك ، يمكن للفرق استخدام عملية تكامل مستمر ونشر مستمر (CI / CD). يحد CI / CD من إمكانية فشل البناء في يوم الإصدار الرئيسي.

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

قم بتمكين المختبرين باستخدام أدوات النشر

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

على سبيل المثال ، في أحد فريقي ، استخدمنا Git للتحكم في الإصدار و Slack للتواصل. أنشأ المطورون Slackbot الذي لديه حق الوصول إلى Git ونصوص النشر وجهاز افتراضي واحد. تمكن المختبرين من اختبار اتصال الروبوت باستخدام اسم فرع تم الحصول عليه من GitHub أو Jira ونشره في بيئة مرحلية.

وفر هذا الإعداد الكثير من الوقت للمطورين مع تقليل إهدار الاتصالات والانقطاعات المستمرة عندما كان على المختبرين أن يطلبوا من المطورين نشر فرع للاختبار.

جرب مع TDD و ATDD

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

يتبع التطوير القائم على اختبار القبول (ATDD) منطقًا مشابهًا لـ TDD ولكن ، كما يوحي الاسم ، يركز على اختبارات القبول. في هذه الحالة ، يتم إنشاء اختبارات القبول قبل التطوير بالتعاون مع المطورين والمختبرين والطالب (العميل ، مالك المنتج ، محلل الأعمال ، إلخ). تساعد هذه الاختبارات كل فرد في الفريق على فهم متطلبات العميل قبل كتابة أي رمز.

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

اكتشف أوجه القصور عن طريق تتبع حركة بطاقة المهام

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

في بعض الأحيان ، يسرع المطورون في عملهم في محاولة لإخراج الميزات في أسرع وقت ممكن و "الاستعانة بمصادر خارجية" للجودة للمختبرين. مثل هذا الإعداد ينقل فقط عنق الزجاجة إلى أسفل العدو. ضمان الجودة (QA) هو أهم شبكة أمان يمتلكها الفريق ، ولكن هذا قد يعني أن وجود ضمان الجودة يمنح المطورين القدرة على التخلي عن اعتبارات الجودة.

تمتلك العديد من أدوات إدارة المشاريع الحديثة القدرة على تتبع حركة بطاقات المهام على لوحة Scrum أو Kanban. في حالتنا ، استخدمنا Jira لتحليل ما حدث مع مهام المطور المعني وأجرينا مقارنات مع مطورين آخرين في الفريق. اكتشفنا أن:

• قضت مهامه ضعف الوقت تقريبًا في عمود الاختبار بمجلسنا ؛
• غالبًا ما يتم إرجاع مهامه من ضمان الجودة للجولة الثانية أو الثالثة من الإصلاح.

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

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

أضف Test Automation إلى QA Team Skillset

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

أتمتة الاختبار هي حل شائع لهذه المشكلة. تسهل الاختبارات الآلية اختبار الميزات الجديدة والصغيرة ، حيث يمكن تشغيل كود الاختبار في الخلفية بينما يركز المطورون والمختبرين على المهام الأخرى. علاوة على ذلك ، نظرًا لتشغيل الاختبارات تلقائيًا ، يمكن أن تكون تغطية الاختبار أكبر بكثير مقارنة بجهود الاختبار اليدوي.

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

إدارة أولويات الاختبار

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

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

دعم العميل

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

ادارة المنتج

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

أتمتة الاختبار

كما ناقشنا سابقًا ، غالبًا ما يكون الاختبار اليدوي أدنى من الأتمتة. في هذا السياق ، يمكن أن يقترن الضغط من أجل الأتمتة بوجود مختبِر يكرس اهتمامه الكامل للفريق ويستفيد من وقت فراغه في تعلم العمل باستخدام أدوات أتمتة الاختبار مثل السيلينيوم.

ملخص: اختبار الجودة السريع

إن جعل الاختبار أكثر مرونة هو أمر حتمي يواجهه الكثير من فرق تطوير البرامج الآن. ومع ذلك ، لا ينبغي المساس بالجودة من خلال اعتماد عقلية "الاختبار بأسرع ما يمكن". من الضروري أن يتضمن انتقال Agile تحولًا إلى اختبار Agile ، وهناك عدة طرق لتحقيق ذلك:

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

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