لماذا عقدنا هاكاثون للمختبرين؟

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

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

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

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

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

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

بعد ذلك، سأخبرك بالخطوات التي اتخذناها والأخطاء التي ارتكبناها من أجل العثور على هؤلاء المقاتلين الذين طال انتظارهم من أجل الجودة.

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

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

1. لقد حاولنا تطبيق ممارسات التقييم لتحديد من بين العديد من الأشخاص الذين "يتركون الأمر"، وهم نفس الأشخاص الذين يمكننا تطوير متخصصين أقوياء منهم.

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

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

   
   

2. لقد عقدنا لقاءات للمختبرين لتوسيع حدود فهم المهنة بين المجموعة الموجودة.

   سأخبرك قليلاً عن كل واحد منهم.

   Ufa Software QA and Testing Meetup #1 هي محاولتنا الأولى لجمع أولئك الذين يهتمون بالمهنة وفي نفس الوقت فهم ما إذا كان الجمهور سيكون مهتمًا بما نريد أن ننقله إليهم. في الأساس، كانت تقاريرنا تدور حول المكان الذي من الأفضل أن تبدأ فيه إذا قررت أن تصبح مختبرًا. ساعد المبتدئين على فتح أعينهم والنظر إلى الاختبار مثل البالغين. تحدثنا عن الخطوات التي يجب على المختبرين المبتدئين اتخاذها للانضمام إلى المهنة. حول ما هي الجودة وكيفية تحقيقها في الظروف الحقيقية. وأيضًا ما هو الاختبار التلقائي وأين يكون استخدامه أكثر ملاءمة.

   
   
   ثم، مع فاصل زمني قدره شهر أو شهرين، عقدنا لقاءين آخرين. كان هناك بالفعل ضعف عدد المشاركين. في "Ufa Software QA and Testing Meetup #1" تعمقنا في مجال الموضوع. تحدثوا عن أنظمة تتبع الأخطاء، واختبار UI/UX، وتطرقوا إلى Docker وAnsible، وتحدثوا أيضًا عن الصراعات المحتملة بين المطور والمختبر وطرق حلها.

   اجتماعنا الثالث، "Ufa Software QA and Testing Meetup #3"، يرتبط بشكل غير مباشر بعمل المختبرين، ولكنه كان مفيدًا في تذكير المبرمجين في الوقت المناسب بواجباتهم الفنية والتنظيمية: اختبار التحميل، واختبار e2e، والسيلينيوم في الاختبار التلقائي، ونقاط الضعف في تطبيقات الويب. .

   طوال هذا الوقت كنا نتعلم كيفية إنشاء ضوء وصوت عاديين في عمليات البث من أحداثنا:

   → الخطوات الأولى في الاختبار – Ufa Software QA ولقاء الاختبار رقم 1
   → اختبار واجهة المستخدم/تجربة المستخدم – لقاء ضمان الجودة واختبار البرامج في Ufa رقم 2
   → اختبار الأمان واختبار التحميل والاختبار التلقائي – Ufa QA ولقاء الاختبار رقم 3

3. وفي النهاية قررنا أن نحاول عقد هاكاثون للمختبرين

كيف قمنا بإعداد وإجراء هاكاثون للمختبرين

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

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

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

وهنا ما حصلنا عليه: الأعمال المتراكمة للهاكاثون.

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

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

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

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

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

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

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

ماذا حققت؟

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

المصدر: www.habr.com