ВІТАЛІЙ МИХАЙЛЮК «Онбордінг нових тестерів до команди: як ефективно навчати і інтегрувати новачків у команду тестування»
0 likes49 views
Lviv Direction QADay 2024 (Test & Team) ВІТАЛІЙ МИХАЙЛЮК «Онбордінг нових тестерів до команди: як ефективно навчати і інтегрувати новачків у команду тестування» qaday.org
ВІТАЛІЙ МИХАЙЛЮК «Онбордінг нових тестерів до команди: як ефективно навчати і інтегрувати новачків у команду тестування»
- 1. Onboarding новачків в команду тестувальників: як ефективно навчати і інтегрувати колег до проекту
- 2. “Висхідна зірка” соціальних мереж: ● 📸 Мій Instagram: @vitaliy_tvk (instagram.com/vitaliy_tvk) ● 📺 Автор Youtube каналу “Testing в кайф” присвяченого автоматизації та тестуванню в цілому: (youtube.com/@qapractices) Михайлюк Віталій (Senior Automation script specialist)
- 3. ● Більше 7-ми років досвіду у сфері тестування програмного забезпечення; ● Розробка та підтримка Playwright, WDIO автоматизованих скриптів; ● У вільний від роботи час беру участь в open source проектах, таких як testomatio/reporter; ● Сертифікований спеціаліст: ISTQB Foundation Level + готуюсь до здачі Test Automation Engineer Михайлюк Віталій (Senior Automation script specialist)
- 4. “Onboarding новачків в команду тестувальників: як ефективно навчати і інтегрувати колег до проекту” Тема зазначена мною для конференції: або, простіше кажучи: “Як ми збільшували нашу команду тестувальників з 2 до 10-ти спеціалістів на проекті за 2 місяці”
- 5. Ми Контекст, чому ми вирішили розробити “Onboarding” систему: Ми аутсорс компанія, яка доєдналася до Американсько го продукту, який займається аналізом фармацевтичн их матеріалів Нас було 2-оє тестувальників: - один займався мануальними перевірками фіч; - написання автоматичних скриптів для регресійного тестування Менеджер проекту ставить задачу: “Є запит на розширення команди розробників, а отже ми будемо збільшувати і команду тестувальників” Ми не можемо витрачати багато твого часу на навчання і тому подібне. Тому треба розробити систему для нових членів команди QA спеціалістів
- 6. Задача прийнята! Починаємо обговорення технічних деталей: Навчання та долучення нових спеціалістів має бути поетапним Документація по проекту ведеться, можливо, не в самому кращому варіанті але є опис функціоналу в Confluence, додаткові пояснення фіч в Jira. Час на залучення та приступання до “бойового тестування” 2-3 тижні Маємо отримати нового члена команди, який знає як тестувати продукт, як менеджити задачі, писати скрипти => готовий робити проект більш якісним.
- 7. Щоб витрачати менше часу на спілкування та роз’яснення поставлених задача їх краще всього якісно описати. Так як в мене був досвід роботи в Jira, Trello і таких всяких штуках, то було обрано інструмент, який мене менше всього “бісив” на той момент: Етап перший: Вибір інструменту для менеджменту
- 8. Після всіх консультацій та обговорень було прийнято рішення - Trello: ● зрозумілий інтерфейс; ● великий набір опцій для задач; ● різні плюшки по типу чек-листу відіграли також не малу роль при виборі системи. Плюс у розробників також був свій онбординг і тому деякі ідеї можно було просто перенести з одного проекту в інший
- 9. Щоб тобі задавали менше питань, треба детально та якісно описувати задачі. І тут важливим є обрання патерну для опису, який буде зрозумілим та не буде напрягати нових членів команди. Одна нарада з менеджерами проекту - ось у нас є адекватна заготовка Етап другий: Опис покрокової інструкції 1. Назва задачі. ● Назва має бути зрозумілою як для новачків так і для членів команди. ● Має бути короткою та лаконічною. Приклад: “Pharmacy project introduction #1”. 2. Опис задачі. Більш розгорнутий варіант назви: містить в собі деталі, step-by-step інструкції та всяку додаткову інформацію. Тут нічого особливого, все що має бути додано в задачу, все пишемо сюди.
- 10. 3. Додаткові матеріали. Тут у нас: ● посилання на сторінки Confluence; ● додаткові матеріали: пов’язані задачі, задачі з прикладами того, як це колись тестувалось і тд Опис покрокової інструкції: продовження 4. Завдання по засвоєним матеріалам. В кінці кожної задачі є 3-5 завдань, які треба виконати, щоб закріпити пройдені матеріали. 5. Коментарі та відповіді на запитання. Щоб не перевантажувати робочій чат повідомленнями: “А як це має працювати?” Кожен може залишити своє запитання, побажання чи покращення в задачу. На коментар додається відповідь/реакція
- 13. Опис задачі: Треба мати на увазі: чим більше деталей додано до задачі, тим менше буде безглуздих запитань! Як результат: Два рази на день я витрачав по 20-30 хвилин на менеджмент задач, а не цілий день на відповіді, скріни і тд
- 14. Тут все доволі просто, і нічого супер-пупер не вигадував. Стандартний набір колонок для задач в Trello: Етап третій: Налаштування борди 1. BACKLOG. Для загального скоупа задач по онбордингу. Тут описані задачі, які треба виконувати одна за одною. 2. IN PROGRESS. Задачі, що знаходяться в роботі. Тут є невелике правило: в роботі може бути не більше 2 задач (це чисто наше командне спостереження: якщо людина взяла більше 2 задач, то концентрація мінімальна і шансів на якісно виконані всі задачі лінійно зменшується).
- 15. Стандартний набір колонок для задач в Trello: Налаштування борди Дивись слайд далі зі скріном >>> 3. VALIDATION. Коли всі матеріали вивчено, пройдено всі завдання, додано коментарі та побажання - задачу можна закривати. 4. DONE. Коли задачу та матеріали перевірено - задачу можна закривати. Всі задачі рано чи пізно повинні бути в цій колонці.
- 17. Налаштування борди: примітка 1. Кожна задача створена в одному екземплярі Тобто: кожен новий член команди знаходить необхідну йому задачу, копіює її та асайнить на себе. Потім перетягує у відповідну колонку і починає свій процес навчання. 2. Вся відповідальність за задачі на новому тестувальнику На мій погляд - це правильно. Аналогією можна вважати шкільний процес: ти береш підручник -> підписав його -> склав іспит = повна відповідальність за те, що ти засвоїв!
- 18. Почну з того, що всі задачі пронумеровані від 1 до 30 і мають відповідне маркування: Етап четвертий: План навчання (маркування задач) Маркування задач по складності: ● швидкі задачі: виконуються за 1-2 години максимум; ● складні задачі: виконуються від 2 до 8 годин. Маркування задач по типу: ● пов’язані з документацією: ознайомлення з частинами проекту, налаштуваннями, модулями і тд; ● мануальне тестування: регресія, Smoke перевірки… ● автоматизація та написання скриптів: написання скриптів, впровадження автоматизації та пришвидшення загального етапу тестування.
- 20. Маркування задач: примітка Сірий лейбл. Прості за складністю. Такі задачі включають в себе базове знайомство, мало матеріалів та прикладів, одне-два легких завдання. Мають бути виконані за годину-дві максимум Жовтий лейбл. Складніші завдання. Тут вже задачі описані максимально повно: мають декілька більш складних завдань на перевірку. Такі задачі можуть виконуватися від пари годин до 2-4 годин робочого дня Таке маркування задача - це також додаткові орієнтири на те: ● до чого має бути готовим тестувальник при проходженні задачі; ● ментор знає, скільки часу може зайняти перевірка задачі.
- 21. ● План розроблений на 3 тижні. ● Задачі сгруповані таким чином, щоб виконуючи їх одну за одною - вкластися у відведений термін. ● Акцент - залучення в проект було по тижням (так би мовити міні спрінтам: міксуючи прості та складні задачі) Переходимо до самого цікавого - покрокового плану. 1-ий тиждень Основний акцент зроблено на знайомство з продуктом і базовим функціоналом. Новачки вивчають існуючу документацію, переглядають архітектуру проекту і виконують прості завдання, включаючи регресійне тестування старих тікетів. 2-ий тиджень Вдосконалення мануальних навичок. Новачки виконують "бойові" тікети з більш складними сценаріями тестування, що дозволяє перевірити їхню здатність до виявлення дефектів і розуміння бізнес-логіки.
- 22. 3-тій тиждень. Зосереджено на досконалому вивченні структури проекту, автоматизації тестування та виявленні підводних каменів. Тестувальники беруться за задачі, що вимагають специфічних знання Зверніть увагу: Задачі підписані по номерах і повинні виконуватися в строго визначеній послідовності. Поспіх і спроби виконати кілька завдань одночасно, особливо складних, можуть призвести до низької якості результатів. покроковий план: продовження
- 23. Фінальний тиждень: Найбільш динамічний. Ви отримаєте можливість активно взаємодіяти з командою, задавати питання, обговорювати результати і писати коментарі до тікетів. Ви стаєте невід'ємною частиною команди, і Ваша участь у процесі може суттєво вплинути на подальший розвиток проекту
- 24. Проблеми, з якими ми зіткнулися: Поступово підходимо до висновків. 1. Рівень засвоєння матеріалів: Новачки мають різний рівень підготовки і засвоєння матеріалів. Це може бути пов'язано з попереднім досвідом або індивідуальними здібностями. 2. Час на виконання задач: Тривалість виконання завдань може варіюватися в залежності від складності та особистих навичок. 3. Запитання та коментарі: Різна активність: хтось ставе більше запитань, а інші можуть не проявляти ніякої активності. Важливо навчити колег задавати “ефективні” питання і забезпечити підтримку наставників
- 25. Поступово підходимо до висновків. Плюси такого процесу навчання: 1. Високий рівень спеціалістів: Поступове введення в проект забезпечує якісну підготовку, що допомагає створювати висококваліфікованих спеціалістів 2. Поглиблене знання проекту: Навчання охоплює всі аспекти проекту, що дозволяє новачкам швидко стати експертами у своїй сфері 4. Оптимізація часу: Ефективно спланований процес онбордингу дозволяє максимально використовувати час і забезпечує продуктивне навчання новачків
- 26. Дякую за Вашу увагу! Якщо в когось є запитання, настав час їх задавати!