تحية! اسمي Alyona Isakova ، أنا رائد اختبار في Avito ، وأود أن أخبركم عن تجربتي في تقديم اختبار Agile للفريق. عندما قرأت مقالات عن اختبار Agile و ATDD باللغة الروسية ، حصلت على انطباع بأنني "لست من المألوف" ، "وليس عن Agile". يبدو أن هذا كان نوعًا من البنية المعقدة التي تتطلب إدراج المطورين ، وقبل تطبيقه ، كان لا يزال يتعين علي "المحراث والحرث".

لفترة من الوقت عشت مع هذه الفكرة ، كتبت قائمة مراجعة للمهام أثناء التعيين في المهام ، واجتماعات تم جمعها من "فريق الميزات" ، والتي تمت دعوتها PM و QA و Frontend و Backend لمناقشة الفروق الدقيقة للمهمة قبل التنفيذ.

أولئك الذين يفهمون ما الذي يتحدثون عنه قد لاحظوا بالفعل المصيد ، أليس كذلك؟

إذا كنت جوجل ما هو "اختبار رشيق" ، يمكنك الخروج باقتراحات لأخذ الدورات ، واثنين من المقالات مع وجهات النظر حول النهج والتعريف على ويكيبيديا:

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

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

كيف تم ترتيب تدفق مهمتنا

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

1. بيان من العميل (افترض PM)

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

2. مراجعة بيان المشكلة من قبل المختبر

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

3. مناقشة المهمة من قبل جميع المهتمين أو "فريق الميزة"

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

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

4. المهمة المتبعة في الأعمال المتراكمة ، تم التخطيط لها وتنفيذها وتنفيذها وجلبت المنفعة والسعادة

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

ما تم القيام به لتحسين

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

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

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

ماذا تقرأ عن هذا الموضوع

"اختبار رشيقة. دورة تدريبية للفريق بأكمله ، "جانيت جريجوري وليزا كريسبين. تم نشر الكتاب مؤخرًا في الترجمة الروسية وهو متاح على الأوزون.

ما الذي تغير بالضبط

1. في اجتماعاتنا لتوضيح الأعمال المتراكمة (PBR) ، أصبحت مثل تلميذ ممتاز مزعج يسأل كل شيء وكل شيء: "ماذا سيحدث إذا سقطت خدمة الطرف الثالث؟" ، "ماذا سيحدث إذا عدنا لاغية ، وليس 0؟" ، "A لماذا نسمي هذا ، وليس هناك؟ "،" وماذا لو لم نحصل على جميع البيانات؟ "،" ماذا لو تم التقاط الكوكب بواسطة الديناصورات المتمردة؟ " مجرد مزاح ، فقط الأسئلة المهمة ، لا "لاغية" و "0".
   مع مرور الوقت ، أدرك الرجال أنه في مثل هذا النقاش ، يولد العديد من الحالات التي لم يتم تحديد مصيرها مقدمًا بحيث يمكنهم الآن التنبؤ بها. سابقا ، أسئلة مثل "ماذا يحدث إذا كان كل شيء ينهار؟" تساءلت في مرحلة الاختبار ، والآن في مرحلة الإعداد.
2. بدلاً من عنصر "الاختبارات" في المهام ، نكتب "معايير القبول" بالتفصيل والوعي ، ونحدد أيضًا عدد ومستويات الاختبارات الذاتية المستقبلية.
   للأمانة ، تجدر الإشارة إلى أننا لا نعرف 100٪ من الحالات في حالات الاختبار الذاتي مقدماً. هناك أوقات لا يمكننا فيها القيام بذلك تقنيًا أو يستغرق الأمر وقتًا أطول مما لدينا في الاجتماع. في الممارسة العملية ، غالبًا ما يكون من غير الممكن التصرف بشكل مثير. وهذا مسموح به - سيأتي شيء مع مرور الوقت.
3. البنود "مراجعة بيان المشكلة بواسطة المختبر" و "فريق الميزات" الذي لا نجريه حاليًا. نحل جميع المشكلات في اجتماعات PBR ، حيث أن جميع الأشخاص الضروريين موجودون بالفعل هنا ، وتناقش معايير القبول في هذه العملية.
4. يضاف المختبر إلى رمز مراجعة اختبار الوحدة للتأكد من وجود عمليات فحص كافية.
5. بدلاً من الاختبار المعتاد للوظائف ، في نهاية عملية التطوير ، يتم تشغيل الاختبارات التلقائية (على جميع المستويات) ويتم إجراء اختبار بحثي فقط.
   من الناحية المثالية ، بالطبع ، لا ينبغي أن يكون الاختبار موجودًا على الإطلاق ، ولكن في ممارستنا ، وجدنا أنه عند إجراء تغييرات على منتج تم تطويره بواسطة العديد من الفرق ، يكون من الأسهل والأكثر صحة إضافة اختبار البحث.

ما الصعوبات التي واجهتك؟

1. ما هو اختبار وحدة

إننا نواجه حقيقة أننا ، QA ، لا نفهم اختبارات الوحدة التي نقوم باختبارها وبالتالي لا نثق بها ، وتكريمًا ليقظتنا ، نكتب اختبارات على مستوى أعلى وبكعب قوي "لأتمتة ، لا يمكنك أن ترحم".

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

سهم واحد محدد - رحلة واحدة - تحقق واحد في اختبار الوحدة

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

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

2. في التطبيق الحالي ، لا يمكن حذف جميع الاختبارات دون تعديلات

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

النتائج

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

  
  

• الشيء الرئيسي في منهجية ATDD هو أنه قبل القيام بشيء ما ، يجب عليك التوصل إلى معيار للعمل المنجز ومعيار للعمل الذي يتعين القيام به بشكل صحيح. بمعنى تقريبي ، يحدد النهج الفترة الزمنية التي تتفق فيها مع الفريق. يذهب الباقي مع المسرحية.

  
  

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

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

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

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