قبل عام ونصف ، قمنا بتدمير فريق الاختبار: لقد تخلينا عن الانحدار ، ونقلنا الاختبارات التلقائية لـ E2E إلى السيلينيوم لدعم المطورين ، وانتشرنا بين الفرق التي رأت ميزات لمنع الأخطاء في مهدها. في الأحلام الوردية ، بدا لنا أنه سيكون أكثر فائدة: يعمل ضمان الجودة على الجودة ، ويبدأ الاختبار مبكرًا ، ويكتب المطورون الاختبارات التلقائية بأنفسهم ولا أحد يزعجهم.
لكن الأمر
ما هي عواقب الدرجة الأولى والثانية
راي داليو لديه مفهوم "عواقب الدرجة الثانية" في المبادئ. هذه عواقب غير واضحة لقراراتنا والتي غالبًا لا يمكننا التنبؤ بها. على سبيل المثال ، في الستينيات من القرن العشرين ، اندلعت حرب مع العصافير في الصين. أكلت العصافير الحبوب ، وحتى تتوقف عن أكلها ، بدأت الصين في البحث عن الطيور. أثناء الصيد ، قتل الصينيون ما يقرب من ملياري طائر بشكل جماعي.
نتيجة للإبادة الجماعية للعصافير ، زاد المحصول بعد عام. هذه عواقب من الدرجة الأولى. ولكن لم يكن هناك من يأكل الحشرات وتكاثر الجراد واليرقات ، الأمر الذي بدأ في تدمير المزيد من الحبوب ، مما أدى إلى مجاعة هائلة في الصين في السنوات التالية هذه عواقب من الدرجة الثانية.
العواقب من الدرجة الأولى هي عواقب مباشرة لقراراتنا وتبقى دائمًا على السطح. العواقب من الدرجة الثانية خفية وطويلة الأجل في كثير من الأحيان. لفهمهم ، عليك التفكير ومحاكاة الموقف. على سبيل المثال:
- إذا دفعت للمطورين مقابل عدد سطور التعليمات البرمجية ، فسيكون هناك المزيد من التعليمات البرمجية ، لكن الجودة ستكون أسوأ. بمرور الوقت ، سيبدأ الأشخاص في الغش وإنتاج المزيد والمزيد من التعليمات البرمجية السيئة من أجل الحصول على المزيد من المال. هذه عواقب من الدرجة الثانية.
- إذا بدأت في ممارسة الرياضة ، فستكون مؤلمة في البداية وستستغرق وقتًا طويلاً. ولكن بعد فترة (من أسبوع إلى أشهر) ، ستظهر عادة ، وستتحسن الصحة والمظهر. هذه عواقب من الدرجة الثانية.
- إذا كنت تسكر مثل الخنزير الصغير كل يوم جمعة ، فستكون ليلة الجمعة جيدة. لكن صباح السبت سيكون سيئًا - هذه عواقب من الدرجة الثانية. وإذا كنت تفعل هذا بانتظام ، لسنوات ، فمن المحتمل أن يتطور إلى إدمان الكحول وتليف الكبد. لكن هذه بالفعل عواقب من الدرجة الثالثة و "قصة مختلفة تمامًا".
كان لدينا فريق ضمان الجودة وقمنا "بتفريقه"
سأخبرك الآن كيف شعرنا بعواقب كل من الترتيب الأول والثاني. كان لدينا فريق مريح ومخصص من المختبرين من 7 أشخاص: 4 منهم كتبوا اختبارات تلقائية ، و 3 اختبروها يدويًا. في مرحلة ما ، قررنا الانقسام والتفرق في فرق. لماذا ا؟
لأن المطورين تلقوا ردود الفعل بعد فوات الأوان.
كانت الأخطاء في المرحلة عندما "انتهى" التطوير بالكامل ، وكان كل شيء "متكاملًا" وكان من الضروري التحقق من أن المنتج جاهز للإصدار. لم يكن هناك اختبار قبول ، تم إجراؤه من قبل محللي المنتجات الذين لم تكن لديهم مهارات الاختبار. بالإضافة إلى ذلك ، كان المختبرين والمطورين في عوالم مختلفة ولم يتفاعلوا كثيرًا.
الحل الواضح (إذن) هو تقسيم الفرق التي تعمل على ميزات (أجزاء) معينة من النظام من أجل منع الأخطاء في مهدها. لم نكن نريد التخلي عن وظيفتنا ، لذلك قررنا نقل وظائفنا إلى المطورين. لقد فكرنا في الاختبارات التلقائية - سنقوم بتسليمها إلى المطورين وسيختبرون أنفسهم دون مشاكل.
في البداية ، قرروا اختبار الفرضية على أنفسنا من خلال "تجربة": سنغطي سيناريوهات الانحدار الحرجة بالاختبارات التلقائية ونرفض الانحدار اليدوي. إذا لم يزد عدد الإصلاحات العاجلة وعمليات التراجع عن الإصدارات بشكل كبير ، نتيجة للتجربة ، فيمكن اعتبار التجربة ناجحة. وهكذا حدث - لم يكن هناك المزيد من الإصلاحات العاجلة. حل - غير موافق.
ملاحظة . الشركة لديها منتج يسمى مطعم. يشمل جميع الخدمات ومترابطنا. الهدف من المنتج هو أتمتة عمل جميع موظفي المطعم وتحسينه قدر الإمكان. الآن عملنا يركز بشكل أكبر على منع الأخطاء. الآن نحن ضمان الجودة في منتج "المطعم": نحن نطور الصفات في المنتج ، ونشارك في جميع مراحل تطوير المهام.
عواقب الدرجة الأولى والثانية
العواقب المباشرة . كما هو متوقع ، بدأنا في المشاركة في تطوير المهام منذ البداية ، للمشاركة في PBR والتخطيط وورش العمل ونقل خبرة الاختبار إليهم. أصبحنا أقرب إلى فرق التطوير ، أو بالأحرى جزء منها ، وكانت مشاكلنا أيضًا مشاكل الفريق. بدأت الخبرة في الاختبار وضمان الجودة والمعرفة الواسعة بالنظام في النمو في الفرق. بدأنا بدورنا في الانغماس في أعمال المطورين وفهم آلامهم.
الآن ، ما لم نخطط له هو العواقب من الدرجة الثانية .
لا أحد يقود جودة المنتج . هناك وجهان لهذه المشكلة:
- الجودة من حيث العمليات ؛
- جودة الاختبارات الآلية وخطوط الأنابيب.
في فريق ضمان الجودة لدينا ، قمنا بقيادة الجودة. كنا آخر من شاهد المنتج أمام المستخدمين وفهم كيف يرونه. ناقشنا التغييرات والتحسينات على الفريق بأثر رجعي ، وأتينا بمقترحات إلى فرق التطوير من أجل أن يقرروا معًا ما إذا كان ينبغي تقديمها أم لا. قمنا بمراقبة الاختبارات الآلية وعملنا على استقرارها.
بعد أن تفرقنا في فرق ، اختفى كل شيء في مكان ما. في فريق التطوير ، نحن جزء من الفريق ،
كانت جميع الأفكار تهدف فقط إلى تحسين حالة الفريق - لقد فعلنا كل شيء لإصدار ميزة الجودة ، وليس منتجًا عالي الجودة. نتيجة لذلك ، توقف ظهور الحلول القوية بشكل أساسي التي يمكن أن ترفع جودة المنتج إلى مستوى جديد.
اختفت كفاءة كتابة الاختبارات التلقائية - بدأت الاختبارات التلقائية في الانحناء وغالبًا ما تسقط دون تغيير الكود. بحلول الوقت الذي تم فيه حل الفريق ، كان المختبرون اليدويون قد بدأوا للتو في فهم أساسيات الأتمتة. اتضح أنه لا المختبرين ولا المطورين لديهم أي خبرة. بالإضافة إلى ذلك ، اختلط الأمر على ذرات الخبرة عندما ذهب الأشخاص الذين كتبوا هذه الاختبارات إلى التطوير وإدارة المنتج واستقال أحدهم.
لم نكن نعرف بشكل موثوق ما هي الاختبارات التلقائية التي لدينا ، وما الذي تغطيه ، ولم نكن نعرف كيف تتطور أو تتطور أو تضيف أو تزيل - فقد تُرك كل شيء لرحمة المطورين. نتيجة لذلك ، عندما كان من الضروري العثور على بعض المعلومات في الاختبارات التلقائية ، كانت نفس المهمة التي لا يمكنك اكتشافها بدون مطور.
عمل إضافي للمطورين . من الصعب أن تكون مطورًا. إذا اعتادوا في وقت سابق على كتابة رمز المنتج ، والذي تم التحقق منه "بطريقة سحرية" ويذهب إلى الإنتاج ، فإنهم الآن بحاجة إلى كتابة الاختبارات بأنفسهم وتحريرها وتحقيق الاستقرار. في PBR نحدد السيناريوهات التي يجب تغطيتها بالاختبارات ، ويختار المطورون مستوى الاختبارات التلقائية بأنفسهم.
مر المطورون بعدة مراحل لقبول
النفي... يتم طرح جميع إصدارات Dodo IS من قبل المطورين. ينظمون العملية ، ويتواصلون مع فريق اختبار الحمل ، وينظرون إلى السجلات والمراقبة أثناء الإصدار. لم يحاول المطورون الذين طرحوا الإصدار ، الذين واجهوا الاختبار الأحمر ، معرفة سبب ذلك ، لكنهم ببساطة أعادوا تشغيل خط الأنابيب حتى تحول إلى اللون الأخضر 5-7-10 مرات. هذا لأنه لم تكن هناك ثقة في الاختبارات التلقائية.
الحد الأقصى لعدد مرات إعادة التشغيل التي وجدتها هو 44 مرة !!! يبدو لي أن القاعدة التي اعتمدناها على أحد الرجعية "لا تطلق مع الاختبارات الحمراء. إذا كان الاختبار باللون الأحمر ، اكتشف المشكلة. إذا كانت المشكلة في الاختبارات ، فقم بإصلاحها أو وقّع عليها وصنع بطاقة لإلغاء قفل الاختبار وإضافته إلى الأعمال المتراكمة ".
الغضب : أقسم المطورون في اختباراتنا ، قالوا ذلك
لم يكن هناك مساومة أو اكتئاب ، جاء القبول على الفور : يمكن للمطورين الآن كتابة اختبارات E2E UI و API بأنفسهم ، وتحقيق الاستقرار فيها وتحسينها.
بدأ عدد الحشرات المعروضة للبيع في الزيادة . بدأت الحشرات غير الحرجة تتسرب إلى الإنتاج. هناك عدة أسباب لذلك:
- لا تغطي الاختبارات التلقائية الخاصة بنا جميع الوظائف ، بل الوظائف الهامة فقط. ولا يوجد المزيد من اختبار الانحدار اليدوي.
- لم يكن هناك ما يكفي من مهندسي ضمان الجودة لجميع الفرق. لم يكن لدى الفرق كفاءات اختبار ، لذلك لم ينتبهوا للاختبار
ونتيجة لذلك ، بدأنا في العثور عن طريق الخطأ على أخطاء في الإنتاج. إنهم ليسوا حرجين ، لكن كم منهم بشكل عام لم يكن متخيلًا.
كيف نحل هذه المشاكل
ربما كان بإمكان فريق آخر توقع كل العواقب غير الواضحة ، لكننا لم نتمكن من ذلك. اتخذنا قرارًا ، بعد شهور قليلة شهدنا العواقب ، وبدأنا في القضاء عليها.
إنشاء نقابة لضمان الجودة في مطعم أو مجتمع ممارسات ، والذي تضمن جميع ضمانات الجودة في المطاعم. هدف المجتمع هو رفع جودة المنتج بأكمله ، لنشر ممارسات الاختبار الجيدة لجميع فرق المنتج. هذا تعليم يجمع بين مزايا فريق ضمان الجودة المخصص ونستفيد أيضًا من كوننا ضمان الجودة في فريق التطوير.
نلتقي مرة واحدة في الأسبوع: نشارك النتائج والاكتشافات ونخطط للعمل معًا على الجودة. نخصص أيضًا عدة خانات زمنية في الأسبوع للعمل على مهام النقابة. على سبيل المثال ، نحن بصدد الانتهاء من مساعد البوت الخاص بنا من أجل التحرير.
مهمة... تغطي النقابة جزئيًا مشكلة نقص مالك الجودة والاختبارات الآلية. لكن النقابة ليس لديها كفاءات قوية في التطوير والأتمتة ، لذلك اتخذ كبير التكنولوجيا لدينا قرارًا قوي الإرادة ونظم مهمة على خط الأنابيب.
الآن يمكن للمطورين تحسين عملية خط الأنابيب بشكل منهجي: الاستقرار ، والعثور على المشاكل التي تؤخر الإصدارات وإصلاحها. يصبح أحد المطورين من فريق التطوير مالكًا لخط الأنابيب لمدة شهر ويقوم بتحسينه بشكل منهجي. لا يتم إطلاقه ، بل يتحسن - فهو يجعل عملية الإصدار ودعم الاختبارات سهلة وبدون مجهود. الآن وقد تحسنت مقاييس المنتج ، تخلصنا من هذا الشخص المناوب ، لكن يمكننا إعادته في أي وقت. (أثناء كتابة مقال، عدنا لأن الإشعار يبدأ في الاستقرار تتحلل)
دورات... نحن نغلق مشكلة نقص الكفاءات بدورات للمختبرين اليدوي والعمل المزدوج مع المطورين ذوي الخبرة في الأتمتة.
عمل إضافي للمطورين . لا يوجد شيء يمكنك القيام به حيال ذلك ، فقد وصل المطورون للتو إلى مرحلة قبول الاختبارات التلقائية. الآن يكتبون اختبارات E2E بأنفسهم ، إذا كانت الاختبارات ذات المستوى الأدنى لا يمكنها تغطية ميزة ما ، ويقومون بتثبيت خط الأنابيب. كما يقولون في الكتب الذكية ، من الممارسات الجيدة أن يتمكن الفريق بأكمله والمطورين والمختبرين من كتابة الاختبارات. كما أنه يؤثر على رحلتنا إلى جانب الخدمات المصغرة المشبعة من المنولث. هناك عدد أقل من الاختبارات في الكتلة المتراصة ، والمزيد والمزيد في مستودعات منفصلة ، يصبح خط الأنابيب أكثر استقرارًا.
نحن نحقق في المنتج... نحن نحل مشاكل الأخطاء في الإنتاج بالبدء في فحص المنتج بحثًا عن التناقضات مع السلوك المتوقع. لقد حددنا مواعيد جلسات اختبار استكشافية أسبوعية. ونقوم بإحضار الأخطاء إلى الأعمال المتأخرة إلى مالك المنتج.
ماذا سنفعل الآن؟
أدى الفشل في النظر في عواقب الدرجة الثانية والثالثة إلى قرارات سيئة. إنه أمر خطير بشكل خاص عندما يعزز الخيار الأول وليس الخيار الأفضل تحيزًا موجودًا بالفعل. لكن الآن ، مع كل الخبرة المكتسبة ، كنا سنتصرف بشكل مختلف.
على سبيل المثال ، يمكن حل فقدان الكفاءات من خلال مطالبتهم بمشاركة الكفاءة مع جميع مهندسي ضمان الجودة في أحد المنتجات أو المطورين من الفرق قبل بضعة أشهر من انتقال الأشخاص ذوي الكفاءة في الأتمتة. وأفضل للجميع مرة واحدة.
لا توجد وسيلة لتعويض مشكلة العمل الإضافي للمطورين ، ولكن يمكنك تقليل آلام كتابة الاختبارات من خلال عدم وضعها قبل الحقيقة ، ولكن:
- إظهار قيمة الاختبارات صراحة ؛
- تعليم المطورين كتابة هذه الاختبارات وتحسينها وصيانتها ؛
- ( ), .
عندما افترقنا ، لم نفكر حتى في هذه المشاكل. "بعد فوات الأوان" يبدو ، حسنًا ، كيف يمكن أن يكون التفكير فيه أمرًا أساسيًا. لكن بعد فوات الأوان ، نحن جميعًا أقوياء - حاول التنبؤ بالمستقبل.
قد تكون عواقب الدرجة الثانية أو الثالثة بالنسبة لي هي العواقب من الدرجة الأولى للأشخاص الأكثر خبرة الذين اتخذوا مثل هذه القرارات عدة مرات وشاهدوا نتائج مثل هذه القرارات.
الكثير من الشكوك والمتغيرات التي تؤثر على النتائج.
من المهم عدم التنبؤ بالعواقب ، ولكن على الأقل معرفة ما قد تكون عليه. قبل اتخاذ أي قرار ، من المهم التفكير في العواقب المحتملة ، وقراءة المعلومات حول الحالات في الشركات الأخرى من أجل الحصول على فكرة على الأقل عن حجم العواقب المحتملة غير الواضحة.
أي شخص يتعلم التنبؤ بنتائج الترتيب الثاني (وحتى الثالث) لأي قرارات سيكون قادرًا على إنقاذ البشرية أو تدميرها. أو كسب المزيد من المال من Scrooge McDuck - على الأقل من تقلبات أسعار الأسهم.
كيف سأحاول التنبؤ بالنتائج الآن
قرأت مقالات حول هذا الموضوع واستنتجت بنفسي العديد من القواعد التي ، وفقًا للمؤلفين ، ستساعد في التنبؤ بهذه العواقب. سأحاول استخدامها:
- قبل اتخاذ القرار - اسأل نفسك السؤال "ماذا سيحدث بعد ذلك؟" وإضافة جداول زمنية إلى السؤال. ماذا سيحدث بعد 10 دقائق أو 10 أشهر أو 10 سنوات؟
- درب تفكيرك تجاه مثل هذه العواقب من خلال التفكير في المواقف المختلفة. على سبيل المثال ، ماذا ستكون عواقب الترتيب الثاني أو حتى الثالث إذا تحول العالم كله إلى السيارات الكهربائية ، أو ، على سبيل المثال ، يقدم دخلًا أساسيًا غير مشروط. لا توجد إجابات صحيحة في هذا التمرين ، لكنه سيسمح لك بالتفكير على نطاق أوسع.
- تذكر أن الفكرة الأولى في رأسك هي الترتيب الأول. دائما.
إذا واجهت مشاكل أخرى عند تغيير تنظيم فريق الاختبار أو الفرق الأخرى ، فاكتب في التعليقات ، سيكون من المثير للاهتمام معرفة المشكلات التي واجهتها وكيفية حلها.
P.S. 2 QA- « » . . : , , SRE- mobile SRE . . , : (@EvgenSkt) HR (@alexpanev).
, , , : « » « » ( «» — ). QA, « ? ».
-, .