باگلنی: BUgHunting. چگونه 200 باگ در روز پیدا کنیم؟

سلام به همه! نام من یولیا است و من یک آزمایشگر هستم. پارسال بهت گفتم bagodelnya - رویدادی در شرکت ما برای پاکسازی مشکلات عقب افتاده برگزار شد. این یک گزینه کاملاً مناسب برای کاهش قابل توجه آن (تیم های مختلف از 10 تا 50٪) تنها در یک روز است.

امروز می خواهم در مورد قالب بهاری Bagodelny - BUgHunting (BUH) به شما بگویم. این بار ما باگ های قدیمی را رفع نکردیم، بلکه به دنبال موارد جدید و ایده های پیشنهادی برای ویژگی ها بودیم. در زیر برش جزئیات زیادی در مورد سازماندهی چنین رویدادهایی، نتایج ما و بازخوردهای شرکت کنندگان وجود دارد.

باگلنی: BUgHunting. چگونه 200 باگ در روز پیدا کنیم؟

با فکر کردن و نوشتن مقررات، ما دعوت نامه ای را برای تمام کانال های شرکت Slack ارسال کردیم که حاوی هیچ محدودیتی نبود:

باگلنی: BUgHunting. چگونه 200 باگ در روز پیدا کنیم؟

در نتیجه، حدود 30 نفر ثبت نام کردند - هم توسعه دهندگان و هم متخصصان غیر فنی. ما یک روز کاری کامل را برای این رویداد اختصاص دادیم، یک اتاق جلسه بزرگ رزرو کردیم و ناهار را در غذاخوری دفتر ترتیب دادیم.

چرا؟

به نظر می رسد که هر تیم عملکرد خود را آزمایش می کند. کاربران اشکالات را به ما گزارش می دهند. چرا حتی چنین رویدادی برگزار می شود؟

ما چندین هدف داشتیم.

  1. بچه ها را به پروژه ها/محصولات مرتبط تر معرفی کنید.
    اکنون در شرکت ما همه در تیم های جداگانه - واحدها کار می کنند. اینها تیم های پروژه ای هستند که بر روی قسمت خود از عملکرد کار می کنند و همیشه از آنچه در پروژه های دیگر اتفاق می افتد کاملاً آگاه نیستند.
  2. فقط همکاران خود را به یکدیگر معرفی کنید.
    ما تقریباً 800 کارمند در دفتر مسکو داریم؛ همه همکاران یکدیگر را از روی دید نمی شناسند.
  3. توانایی توسعه دهندگان برای یافتن اشکالات در محصولات خود را بهبود بخشید.
    ما اکنون در حال تبلیغ Agile Testing و آموزش افراد در این راستا هستیم.
  4. بیش از متخصصان فنی را در آزمایش دخالت دهید.
    علاوه بر بخش فنی، ما همکاران بسیاری از سایر تخصص‌ها داریم که می‌خواستند بیشتر در مورد آزمایش صحبت کنند، در مورد نحوه گزارش صحیح یک اشکال به طوری که پیام‌های کمتری مانند "آههه ... هیچ کار نمی‌کند" دریافت کنیم.
  5. و البته، باگ‌های پیچیده و نامشخص را پیدا کنید.
    من می‌خواستم به تیم‌ها کمک کنم تا ویژگی‌های جدید را آزمایش کنند و به آنها این فرصت را بدهم که عملکردهای پیاده‌سازی شده را از زاویه‌ای متفاوت ببینند.

اجرا

روز ما شامل چندین بلوک بود:

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

(ما همچنین استراحت بین جلسات و ناهار را فراموش نکردیم).

قوانین بنیادی

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

باگلنی: BUgHunting. چگونه 200 باگ در روز پیدا کنیم؟

جزئیات دیگر

  • در ابتدا، من می خواستم یک رویداد آزمایشی "پیشرفته" انجام دهم، اما ... افراد زیادی از تیم های غیرمحصولی ثبت نام کردند (SMM، وکلا، روابط عمومی)، ما مجبور شدیم محتوا را تا حد زیادی ساده کنیم و موارد پیچیده/پروفایل را حذف کنیم.
  • با توجه به کار واحدها در جیرا در پروژه های مختلف، با توجه به جریان خود، به طور خاص یک پروژه جداگانه ایجاد کردیم که در آن یک قالب برای معرفی باگ ها راه اندازی کردیم.
  • برای محاسبه امتیازات، آنها قصد داشتند از تابلوی امتیازات استفاده کنند که از طریق وب هوک به روز می شد، اما مشکلی پیش آمد و در پایان محاسبه باید به صورت دستی انجام می شد.

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

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

ما وقت نداشتیم که عملکرد را ارائه کنیم، مجبور شدیم بلوک ها را عوض کنیم.
برای جلوگیری از دور ریختن کل بلوک، بهتر است یک طرح پشتیبان داشته باشید.

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

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

نکات مفید سازمانی:

  • از قبل یک جلسه رزرو کنید؛
  • میزها را مرتب کنید، سیم های داخلی و محافظ برق را فراموش نکنید (شارژ کردن لپ تاپ / تلفن ممکن است برای کل روز کافی نباشد).
  • خودکار کردن فرآیند امتیازدهی؛
  • تهیه جداول رتبه بندی؛
  • تهیه جزوات کاغذی با ورود و رمز عبور کاربران آزمایشی، دستورالعمل های کار با Jira، اسکریپت ها.
  • فراموش نکنید که یک هفته قبل از رویداد یادآوری ارسال کنید و همچنین آنچه را که باید با خود ببرید (لپ تاپ/دستگاه) را مشخص کنید.
  • به همکاران خود در مورد این رویداد در یک دمو، در ناهار، با یک فنجان قهوه بگویید.
  • با devop موافقت کنید که در این روز چیزی را به‌روزرسانی یا عرضه نکنند.
  • آماده کردن سخنرانان؛
  • با صاحبان ویژگی مذاکره کنید و سناریوهای بیشتری برای آزمایش بنویسید.
  • سفارش خوراکی ها (کوکی ها/آب نبات) برای میان وعده؛
  • فراموش نکنید که در مورد نتایج این رویداد به ما بگویید.

یافته ها

در طول کل روز، بچه ها موفق شدند 4 پروژه را آزمایش کنند و 192 باگ (134 مورد منحصر به فرد) و 7 مشکل با درخواست های ویژگی ایجاد کنند. البته صاحبان پروژه قبلاً از برخی از این اشکالات اطلاع داشتند. اما یافته های غیرمنتظره ای نیز وجود داشت.

همه شرکت کنندگان جوایز شیرین دریافت کردند.

باگلنی: BUgHunting. چگونه 200 باگ در روز پیدا کنیم؟

و برندگان قمقمه، نشان ها، گرمکن هستند.

باگلنی: BUgHunting. چگونه 200 باگ در روز پیدا کنیم؟

چیزی که جالب شد:

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

چه چیزی می تواند بهبود یابد:

  • پروژه های کمتری انجام دهید و زمان جلسه را به 1,5 ساعت افزایش دهید.
  • هدایا / سوغاتی ها را از قبل آماده کنید (گاهی اوقات تأیید / پرداخت یک ماه طول می کشد).
  • آرام باشید و بپذیرید که چیزی طبق برنامه پیش نمی رود و فورس ماژور وجود خواهد داشت.

بررسی

باگلنی: BUgHunting. چگونه 200 باگ در روز پیدا کنیم؟
آنا بیستریکوا، مدیر سیستم: «صدقه برای من بسیار آموزشی است. من روند آزمایش را یاد گرفتم و تمام "درد" آزمایش کنندگان را احساس کردم.
در ابتدا، در طول فرآیند آزمایش، به عنوان یک کاربر نمونه، نکات اصلی را بررسی می‌کنید: آیا دکمه کلیک می‌کند، آیا به صفحه می‌رود یا نه، آیا طرح‌بندی خارج شده است یا خیر. اما بعداً متوجه می‌شوید که باید بیشتر خارج از چارچوب فکر کنید و سعی کنید برنامه را "شکستن" کنید. آزمایش‌کننده‌ها کار دشواری دارند؛ کافی نیست که تمام رابط را "نقطه زدن" کنید، باید سعی کنید خارج از جعبه فکر کنید و بسیار مراقب باشید.
برداشت ها فقط مثبت بود، حتی اکنون، مدتی پس از رویداد، می بینم که چگونه کار روی اشکالاتی که پیدا کردم انجام می شود. خیلی خوب است که در بهبود محصول احساس مشارکت داشته باشید ^_^."

باگلنی: BUgHunting. چگونه 200 باگ در روز پیدا کنیم؟

دیمیتری سلزنف، توسعه دهنده فرانت اند: "تست در حالت رقابتی به شدت ما را برای یافتن باگ های بیشتر تشویق می کند). به نظر من همه باید برای شرکت در باغونتینگ تلاش کنند. آزمایش اکتشافی به شما امکان می دهد مواردی را پیدا کنید که در طرح آزمایشی توضیح داده نشده اند. به علاوه، افرادی که پروژه را نمی‌شناسند، می‌توانند در مورد راحتی خدمات بازخورد بدهند.»

باگلنی: BUgHunting. چگونه 200 باگ در روز پیدا کنیم؟

آنتونینا تاچوک، سردبیر ارشد: "من دوست داشتم خودم را به عنوان یک آزمایشگر امتحان کنم. این یک سبک کار کاملاً متفاوت است. شما سعی می کنید سیستم را بشکنید نه با آن دوست شوید. ما همیشه این فرصت را داشتیم که از همکارانمان چیزی در مورد آزمایش بپرسیم. در مورد اولویت بندی باگ ها بیشتر یاد گرفتم (مثلاً عادت دارم به دنبال اشتباهات گرامری در متون بگردم، اما "وزن" چنین اشکالی بسیار کم است؛ و بالعکس، چیزی که برای من خیلی مهم به نظر نمی رسید در نهایت به آن تبدیل شد. یک اشکال مهم که بلافاصله رفع شد).
در این رویداد، بچه ها خلاصه ای از تئوری تست را ارائه کردند. این برای افراد غیر فنی مفید بود. و چند روز بعد به این فکر افتادم که در حمایت از سایت دیگری با استفاده از فرمول "چه-کجا-چه موقع" می نویسم و ​​انتظاراتم از سایت و واقعیت را با جزئیات شرح می دهم."

نتیجه

اگر می خواهید زندگی تیم خود را متنوع کنید، نگاهی تازه به عملکرد بیندازید، یک مینی ترتیب دهید "غذای سگ خودت را بخور"، سپس می توانید برای برگزاری چنین رویدادی تلاش کنید و سپس با هم در مورد آن بحث کنیم.

بهترین ها و اشکالات کمتر!

منبع: www.habr.com

اضافه کردن نظر