چرا یک هکاتون برای آزمایش کنندگان برگزار کردیم؟

این مقاله مورد توجه کسانی خواهد بود که مانند ما با مشکل انتخاب متخصص مناسب در زمینه تست مواجه هستند.

به اندازه کافی عجیب، با افزایش تعداد شرکت های فناوری اطلاعات در جمهوری ما، تنها تعداد برنامه نویسان شایسته افزایش می یابد، اما نه آزمایش کنندگان. بسیاری از مردم مشتاق ورود به این حرفه هستند، اما بسیاری معنای آن را درک نمی کنند.

من نمی توانم به جای همه شرکت های فناوری اطلاعات صحبت کنم، اما ما نقش QA/QC را به متخصصان کیفیت خود واگذار کرده ایم. آنها بخشی از تیم توسعه هستند و در تمام مراحل توسعه، از تحقیق تا انتشار نسخه جدید، شرکت می کنند.

یک آزمایش‌کننده در یک تیم، حتی در مرحله برنامه‌ریزی، باید تمام الزامات عملکردی و غیرعملکردی را برای پذیرش یک داستان کاربر بررسی کند. او باید ویژگی های عملیاتی محصول و همچنین برنامه نویسان و حتی بهتر را درک کند و به تیم کمک کند حتی در مرحله برنامه ریزی تصمیمات اشتباه نگیرند. تستر باید درک روشنی از نحوه عملکرد عملکرد پیاده سازی شده و چه مشکلاتی داشته باشد. آزمایش‌کنندگان ما خودشان برنامه‌های آزمایشی و موارد آزمایشی را ایجاد می‌کنند و همچنین تمام نیمکت‌های آزمایشی لازم را آماده می‌کنند. تست بر اساس مشخصات آماده مانند کلیکر میمون گزینه ما نیست. با کار در تیم، او باید به انتشار یک محصول ارزشمند کمک کند و اگر مشکلی پیش آمد زنگ هشدار را به موقع به صدا درآورد.

چیزی که هنگام جستجوی آزمایش کننده ها با آن مواجه شدیم

در مرحله مطالعه بسیاری از رزومه ها، به نظر می رسید که متخصصانی با تجربه مناسب برای ما وجود دارند و هیچ مشکلی برای انتخاب تستر برای تیم ما وجود نخواهد داشت. اما، در طول جلسات شخصی، به طور فزاینده ای با نامزدهایی مواجه می شدیم که در واقع از دنیای فناوری اطلاعات بسیار دور بودند (به عنوان مثال، آنها نمی توانستند اصول تعامل بین مرورگر و وب سرور، اصول اولیه امنیت، رابطه ای و غیر را بگویند. پایگاه‌های اطلاعاتی رابطه‌ای، آنها هیچ ایده‌ای در مورد مجازی‌سازی و کانتینری‌سازی نداشتند)، اما در همان زمان خود را در سطح QA ارشد ارزیابی کردند. پس از انجام ده ها مصاحبه به این نتیجه رسیدیم که تعداد متخصصان مناسب برای ما در منطقه ناچیز است.

در ادامه به شما می گویم که برای یافتن آن جنگنده های مورد انتظار برای کیفیت، چه قدم هایی برداشتیم و چه اشتباهاتی را انجام دادیم.

چگونه سعی کردیم وضعیت را درست کنیم

پس از اتمام منابع متخصصان آماده، شروع به هدف قرار دادن مناطق مجاور کردیم:

1. ما سعی کردیم از روش‌های ارزیابی استفاده کنیم تا در میان بسیاری از افراد «ترک کردن»، افرادی را که می‌توانیم از آنها متخصصان قوی توسعه دهیم، شناسایی کنیم.

   ما از گروهی از نامزدهای احتمالی با سطح دانش تقریباً یکسان خواستیم تا وظایف را تکمیل کنند. با مشاهده روند فکری آنها، سعی کردیم امیدوارکننده ترین نامزد را شناسایی کنیم.

   به طور خاص، ما به وظایفی رسیدیم تا توجه، درک قابلیت‌های فناوری و ویژگی‌های چندفرهنگی را آزمایش کنیم:

   
   

2. ما جلساتی را برای آزمایش کنندگان برگزار کردیم تا مرزهای درک این حرفه را در میان گروه موجود گسترش دهیم.

   من کمی در مورد هر یک از آنها به شما خواهم گفت.

   Ufa Software QA and Testing Meetup #1 اولین تلاش ما برای جمع آوری کسانی است که به این حرفه اهمیت می دهند و در عین حال درک می کنیم که آیا عموم به آنچه ما می خواهیم به آنها منتقل کنیم علاقه مند هستند یا خیر. اساساً گزارش های ما در مورد این بود که اگر تصمیم گرفته اید یک آزمایشگر شوید، بهتر است از کجا شروع کنید. به مبتدیان کمک کنید چشمان خود را باز کنند و مانند بزرگسالان به تست نگاه کنند. ما در مورد مراحلی که آزمایش کنندگان تازه کار باید برای پیوستن به این حرفه انجام دهند صحبت کردیم. در مورد اینکه کیفیت چیست و چگونه می توان به آن در شرایط واقعی دست یافت. و همچنین اینکه تست خودکار چیست و کجا استفاده از آن مناسب تر است.

   
   
   سپس با فاصله 1-2 ماهه دو جلسه دیگر برگزار کردیم. در حال حاضر دو برابر تعداد شرکت کنندگان وجود داشت. در "Ufa Software QA and Testing Meetup #2" ما عمیق‌تر در حوزه موضوع فرو رفتیم. آنها در مورد سیستم های ردیابی باگ، تست UI/UX صحبت کردند، Docker، Ansible را لمس کردند و همچنین در مورد درگیری های احتمالی بین توسعه دهنده و تستر و راه های حل آنها صحبت کردند.

   سومین جلسه ما، "Ufa Software QA and Testing Meetup #3" به طور غیرمستقیم با کار آزمایشگران مرتبط بود، اما برای یادآوری به موقع وظایف فنی و سازمانی برنامه نویسان مفید بود: تست بار، تست e2e، سلنیوم در تست خودکار، آسیب پذیری های برنامه های وب. .

   در تمام این مدت ما یاد می‌گیریم که چگونه نور و صدای معمولی را در پخش رویدادهایمان ایجاد کنیم:

   → اولین گام در تست - Ufa Software QA و Testing Meetup #1
   → تست UI/UX – Ufa Software QA and Testing Meetup #2
   → تست امنیتی، تست بار و تست خودکار – Ufa QA و Testing Meetup #3

3. و در پایان تصمیم گرفتیم که سعی کنیم یک هکاتون برای آزمایش کنندگان برگزار کنیم

چگونه یک هکاتون را برای آزمایش کنندگان آماده و اجرا کردیم

برای شروع، ما سعی کردیم بفهمیم که این چه نوع "جانور" است و معمولاً چگونه انجام می شود. همانطور که مشخص شد، رویدادهایی از این دست بارها در فدراسیون روسیه برگزار نشده است و جایی برای وام گرفتن ایده وجود ندارد. ثانیاً، من نمی خواستم بلافاصله منابع زیادی را برای رویدادی سرمایه گذاری کنم که در نگاه اول مشکوک به نظر می رسید. بنابراین، تصمیم گرفتیم که مینی هکاتون های کوتاه را نه برای کل چرخه کاری QA، بلکه برای مراحل جداگانه انجام دهیم.

سردرد اصلی ما عدم تمرین در بین آزمایش کنندگان محلی در ایجاد نقشه های آزمایشی واضح است. آن‌ها وقت خود را صرف تحقیق درباره داستان‌های کاربر قبل از پیاده‌سازی و ایجاد معیارهای پذیرشی نمی‌کنند که برای توسعه‌دهندگان برای الزامات کاربردی و غیرعملکردی، UI/UX، امنیت، بارهای کاری و بارهای اوج روشن باشد. بنابراین، ما تصمیم گرفتیم برای اولین بار، جالب ترین و خلاقانه ترین بخش کار آنها - تجزیه و تحلیل و شکل گیری الزامات در طول تحقیقات قبل از پروژه را مرور کنیم.

تعداد بالقوه شرکت‌کنندگان را تخمین زدیم و تصمیم گرفتیم که حداقل به 5 بک لاگ برای انتشار MVP، 5 محصول و 5 نفر نیاز داریم که به‌عنوان مالک محصول عمل کنند، نیازهای تجاری را رمزگشایی کنند و در مورد محدودیت‌ها تصمیم بگیرند.

این چیزی است که ما به دست آوردیم: عقب ماندگی ها برای هکاتون.

ایده اصلی این بود که به موضوعاتی بپردازیم که تا حد امکان از کارهای روزانه شرکت کنندگان دور باشد و به آنها فضایی برای پرواز خلاقانه بدهد.

چه اشتباهاتی مرتکب شدیم و چه کاری می توانستیم بهتر انجام دهیم؟

استفاده از شیوه های ارزیابی که در زمینه استخدام فروشندگان و مدیران سطوح پایین بسیار محبوب بود، تلاش زیادی را به خود اختصاص داد، اما به ما اجازه نمی داد به هر یک از شرکت کنندگان توجه کافی داشته باشیم و توانایی های او را ارزیابی کنیم. به طور کلی، این گزینه انتخاب یک تصویر منفی از شرکت ایجاد می کند، زیرا افراد زیادی بازخورد ناکافی دریافت می کنند و متعاقباً اثر ظلم کارفرما را در خود و دیگران ایجاد می کنند (ارتباطات در جوامع فناوری اطلاعات بسیار توسعه یافته است). در نتیجه، ما به معنای واقعی کلمه با دو نامزد بالقوه با آینده بسیار دور باقی می‌مانیم.

ملاقات چیز خوبی است. مبنای گسترده ای برای تفصیل ایجاد می شود و سطح عمومی شرکت کنندگان افزایش می یابد. این شرکت روز به روز بیشتر در بازار شناخته می شود. اما شدت کار چنین تعهداتی کم نیست. شما باید به وضوح درک کنید که برگزاری جلسات تقریباً 700-800 ساعت کار در سال طول می کشد.

در مورد هکاتون آزمایشی. این نوع رویدادها هنوز خسته کننده نشده اند، زیرا برخلاف هکاتون ها برای توسعه دهندگان، کمتر برگزار می شوند. مزیت این ایده این است که می توانید مقدار زیادی از دانش عملی را به صورت آرام مبادله کنید و سطح هر شرکت کننده را کاملاً دقیق تعیین کنید.

پس از تجزیه و تحلیل نتایج این رویداد، متوجه شدیم که اشتباهات زیادی مرتکب شدیم:

1. نابخشودنی ترین اشتباه این بود که باور کنیم 4-5 ساعت برای ما کافی است. در نتیجه فقط معرفی و آشنایی با مطالب عقب افتاده تقریباً 2 ساعت طول کشید.
   کار با صاحبان محصول در مرحله اولیه و زمان فرو رفتن در منطقه موضوعی به همان میزان زمان نیاز داشت. بنابراین زمان باقی مانده به وضوح برای توسعه همه جانبه نقشه های آزمایشی کافی نبود.
2. زمان و انرژی کافی برای بازخورد دقیق در مورد هر نقشه وجود نداشت، زیرا از قبل شب بود. بنابراین، ما به وضوح در این بخش شکست خوردیم، اما در ابتدا قرار بود با ارزش ترین در هکاتون باشیم.
3. ما تصمیم گرفتیم کیفیت توسعه را با رای ساده همه شرکت کنندگان ارزیابی کنیم و برای هر تیم 3 رای اختصاص دهیم که آنها می توانند برای کار با بالاترین کیفیت ارائه دهند. شاید بهتر باشد که یک هیئت منصفه تشکیل دهیم.

چه چیزی به دست آورده اید؟

ما تا حدودی مشکل خود را حل کرده ایم و اکنون 4 مرد شجاع و خوش تیپ برای ما کار می کنند که پشت 4 تیم توسعه را پوشش می دهند. مجموعه قابل توجهی از نامزدهای قوی بالقوه و تغییرات ملموس در سطح جامعه QA شهر هنوز مورد توجه قرار نگرفته است. اما پیشرفت هایی وجود دارد و این نمی تواند باعث خوشحالی شود.

منبع: www.habr.com