لماذا أجرينا hackathon للاختبار

سيكون هذا المقال ذا أهمية بالنسبة لأولئك الذين ، مثلما نواجه مشكلة اختيار متخصص مناسب في مجال الاختبار.

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

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

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

ما واجهناه عند البحث عن اختبار

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

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

كيف حاولنا إصلاح الوضع

بعد أن عانينا من البحث عن متخصصين جاهزين ، بدأنا في إطلاق النار على المناطق القريبة:

1. لقد حاولنا تطبيق ممارسة التقييم لتحديد عدد كبير من "الابتعاد عن الأشخاص" ، أولئك الذين يمكننا أن ننمي متخصصين أقوياء منهم.
   
   مجموعة من المرشحين المحتملين ، مع ما يقرب من نفس المستوى من المعرفة ، وقد عرض علينا لإكمال المهام. مراقبة عملية التفكير الخاصة بهم ، حاولوا تفرد المرشح الواعد.
   
   على وجه الخصوص ، توصلنا إلى مهام للتحقق من الانتباه وفهم قدرات التقنيات وخصائص التعددية الثقافية:
   
   
   
   
   
   
2. عقدت اجتماعات لفاحصي الاختبار لتوسيع حدود فهم المهنة للوحدة القائمة.
   
   سوف أخبركم قليلاً عن كل منهم.
   
   تعد Ufa Software QA و Testing Meetup # أول محاولة لنا لجمع أولئك الذين لا يهتمون بالمهنة وفي نفس الوقت لفهم ما إذا كان الجمهور سوف يهتم بما نريد إيصاله إليهم. في الأساس ، كانت تقاريرنا على وشك البدء ، إذا قررت أن تصبح اختبارًا. ساعد المبتدئين على فتح أعينهم وإلقاء نظرة على اختبار البالغين. تحدثنا عن الخطوات التي يتعين على المختبرين المبتدئين اتخاذها من أجل الانضمام إلى المهنة. حول ماهية الجودة وكيفية تحقيقها في ظروف حقيقية. وأيضًا ما هو الاختبار التلقائي وما هو أكثر ملاءمة لتطبيقه.
   
   
   
   علاوة على ذلك ، مع فاصل 1-2 أشهر ، عقدنا اثنين من عمليات التخفيف الأخرى. كان هناك بالفعل مرتين أكثر من المشاركين. في Ufa Software QA و Testing Meetup # 2 ، تعمقنا في الموضوع. تحدثنا عن أنظمة تتبع الأخطاء ، واختبار UI / UX ، وتطرق إلى Docker ، Ansible ، وتحدثنا أيضًا عن التعارضات المحتملة بين المطور والاختبار وكيفية حلها.
   
   لقد تم التركيز بشكل غير مباشر على عمل المختبرين الثالث "Ufa Software QA و Testing Meetup # 3" ، ولكنه كان مفيدًا لتذكير المبرمجين في الوقت المناسب بواجبهم الفني والتنظيمي: اختبار التحميل ، اختبار e2e ، السلينيوم في الاختبار الذاتي ، ونقاط ضعف تطبيق الويب.
   
   تعلمنا طوال هذا الوقت أن نجعل الضوء والصوت العاديين في البث من أحداثنا:
   
   → الخطوات الأولى في الاختبار - Ufa Software QA و Testing Meetup # 1
   ← UI / UX Test - Ufa Software QA and Test Meetup # 2
   → اختبار الأمان ، اختبار الحمل ، واختبار السيارات - Ufa QA و Meetup # 3
3. وفي النهاية قررنا تجربة hackathon للمختبرين

كيف تم إعداد hackathon ونفذت لاختبار

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

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

قدّروا العدد المحتمل للمشاركين وقرروا أننا نحتاج إلى 5 تراكم على الأقل لإصدارات MVP و 5 منتجات و 5 أشخاص سيعملون كمالكين للمنتج وفك تشفير احتياجات العمل واتخاذ القرارات بشأن القيود.

إليك ما حصلنا عليه: تراكم العمل على hackathon .

كانت الفكرة الرئيسية هي الخروج بموضوعات بعيدة كل البعد عن العمل اليومي للمشاركين ومنحهم مجالًا للخيال الإبداعي.

ما هي الأخطاء التي ارتكبناها وما الذي يمكن فعله بشكل أفضل

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

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

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

بعد تحليل نتائج الحدث ، أدركنا أن الأكوام ارتكبت أخطاء:

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

ماذا حققت

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