Тестування в Agile

План уроку:

• Agile цінності в реальному житті

• Вплив тестувальника на якість

• Активності до початку спринту

• Активності під час спринту

• Активності після спринту

Причини виникнення дефектів

Agile manifest (Принципи Agile)

• Люди та взаємодія важливіші за процеси та інструменти

• Працюючий продукт важливіший за вичерпну документацію

• Співпраця із замовником важливіша за погодження умов контракту

• Готовність до змін важливіша за слідування початковому плану

Agile values в реальності

Люди та взаємодія важливіші за процеси та інструменти

Що значить

• Невелика суміщена команда, PO знаходитьсяразом із командою

• Крос-функціональна команда

• Команда, уповноважена приймати рішення

Що відбувається в реальності

• Команда розподілена, різниця у часі може становити 10 годин

• PO з боку клієнта та важкодоступний для команди

• У команду входять розробники та тестувальники, які працюють на повну ставку, але дизайнери, розробники, автоматизаціявходять до інших команд.

Працюючий продукт важливіший за вичерпну документацію

Що значить

• Готовий (тобто протестований) наприкінці спринту

Що відбувається в реальності

• Розробники пишуть код до останнього моменту спринту

• Тестування не може бути завершено у спринті

• Деякі типи тестування виконуються поза спринтами (регресійне, інтеграційне тощо).

Співпраця із замовником важливіша за погодження умов контракту

Що значить

• Команда визначає, що вона зобов'язується виконати наприкінці спринту.

• Вимоги змінюються, але терміни фіксовані

Що відбувається в реальності

• Замовник нав'язує команді обсяг терміни

• І змінює вимоги у рамках спринту

• І висуває не зовсім визначені вимоги

Готовність до змін важливіша за слідування початковому плану

Що значить

• Ретроспектива спринту – навчайтеся та вдосконалюйтесь, як стати ефективнішим

• Вітайте мінливі вимоги, навіть на пізніх стадіях розробки

Що відбувається в реальності

• Команда не наважується відкрито говорити про проблеми

• Занадто багато тиску на термінах розробки, щоб встигнути на ретроспективи!

• Ми маємо ретроспективи, але нічого не змінюється!

• Вимоги постійно змінюються, тому що вони не готові до початку розробки

Роль тестувальника в Agile

Де тестувальники можуть вплинути на якість

Активності до початку спринту

Grooming / Sprint Refinement

Коли Перед спринтом

Вхідні дані Користувацькі історії, створені та описані PO

Хто бере участь Вся команда, розробка та тестування, PO

Що роблять тестувальники перед grooming нарадою 

Аналізують користувацькі історії:

• Яка інформація відсутня та завадить нам провести тестування?

• Що дивно/нелогічно/суперечить іншим вимогам?

• Я знаю, як це перевірити?

• Чого не вистачає для перевірки? (наприклад, дані)

На grooming нараді

• Ставте питання з користувацьких історій

• Уточнюйте відповіді PO

• Заплануйте, якщо необхідно, додаткові обговорення

Що може піти не так

Що може статися

• Недостатньо історій існує/деталізовані в беклозі до грумінгу

• PO не знає, яка мета завдання або деталі

• PO не готовий відповісти на питання

• PO не приходить на грумінг

• Команда працює з кількома PO, і вони суперечать один одному

• PO пізніше змінює думку

• Вимоги змінюються на льоту

Що можна зробити

• Плануйте грумінг заздалегідь

• Підготовка та обмін питаннями з PO перед сесією

• Наполягайте на відхиленні незрозумілих історій на плануванні

• Ескалюйте проблему до вашого проєктного менеджера

• Зберігайте відповіді PO у загальному джерелі

• Записуйте відповіді

• Вимірювати та інформувати про вплив змін

Planning

Коли 1-й день спринту

Вхідні дані Користувацькі історії з уточненими вимогами (після грумінгу)

Хто бере участь Вся команда, розробка та тестування, PO

Що роблять тестувальники:

• Оцінюють тестування для кожної історії

• Обговорюють, чи не здається тестування неспіврозмірним

• розробці/занадто складним

• Можуть пропонувати історії з технічного боргу

• Можуть створююти задачі

Вихідні дані Sprint backlog: оцінені історії, які команда зобов'язується закінчити до кінця спринту

Що може піти не так

Що може статися

• Команда не може оцінити історію

• Клієнт наполягає на нижчих оцінках

• Члени команди мають великі відмінності між оцінками

Що можна зробити

• Переконайтеся, що історія відповідає критеріям INVEST

• Ще раз уточніть вимоги

• Розбийте історію на дрібніші шматочки

• Проконсультуйтеся з архітектором або будь-якими іншими експертами

• Обговоріть, що включено до оцінок членів команди

• Попросіть пояснити оцінки

• Надайте деталі оцінювання

• Поясніть ризики зниження оцінок – не буде жодних історій для здачі в кінці спринту, тому що команда не зможе виконати всі завдання, ризики якості – буде багато дефектів

Активності під час спринту

Мета тестувальника – надавати моментальний зворотний зв'язок розробникам.

Як можна виявити дефекти раніше щоб запобігти їм

• Отримайте чіткі вимоги після grooming

• Спільна робота з розробниками:

  • Поясніть, що ви збираєтеся тестувати, покажіть свої чек-лісти / тест-кейси

  • Уточніть разом питання, що стосуються користувацьких історій

  • Наполягайте на використанні кращих методик розробки: модульні тести, код ревью, стандарти кодування і т. д.

  • Наполягайте на налаштуванні безперервного розгортання для тестування - не витрачайте час на очікування нових збірок

• Не відкладайте «спеціальний» тип тестування до кінця релізу

Ідеальний таймлайн тестування у спринті

Щоб побудувати ідеальний таймлайн, треба

• Визначення піраміди тестування

• Інтеграція автоматичних тестів у конвеєр CI/CD

• Виконуйте часто:

  • Модульні тести - після кожного коміту

  • Димові тести - після розгортання збірки (деплою)

  • Регресійні тести - вночі (на вимогу або за розкладом)

Щоб побудувати ідеальний таймлайн, треба

Що може статися під час спринту

Що може статися

• Тестове середовище не працює

• Немає тестових даних

• Залежності від інших команд/систем

Що можна зробити

• Якщо це відбувається часто, налаштуйте резервне тестове середовище

• Якщо це викликано проблемами з розгортанням збірки => CI/CD, автоматизація тестів, модульних тестів

• Обговоріть це з головним розробником/менеджером. Загальний час, який ми втрачаємо, є найсильнішим аргументом

• Як ми можемо отримати якомога більш «справжні» дані?

• (реплікація, анонімізація, генерація)

• Розробіть макети і заглушки (mocks and stubs)

• Узгоджуйте терміни з іншими командами

Що може статися

• Розробники займаються розробкою до останнього дня

• Багато дефектів у функціоналі

Що можна зробити

• Домовтесь про день, коли перші розроблені історії будуть передані на тестування

• Домовтесь про кількість днів або годин до закінчення спринту, коли всі історії будуть доставлені

• Скорочення capacity команди на кількість ненабраних story points

• Додати Модульні тести, авто тести на CI/CD, які виконуються перед розгортанням збірки

• Локальне тестування розробниками перед передачою на тестування QA інженерам

• Визначте основну причину помилки: проблеми з навколишнім середовищем, проблеми з вимогами, проблеми з кодом (модульні тести проходять?)

Активності після спринту

Ретроспектива. Що й Навіщо

Ретроспектива - це зустріч, де команда обговорює, що може бути змінено, так щоб зробити наступний спринт більш цінним.

Чому ретроспектива важлива

• Допомога у виявленні та вирішення проблем команди і області для покращень

• Мотивує команду: команда почуває себе в силах змінити процес так, як вони хочуть

• Дозвольте сказати «спасибі» членам команди і поділитися найкращими практиками всередині команди

• Тімбілдінг

Як провести ретроспективу ефективно

• Не звинувачуйте інших

  • Говоріть про факти, а не про людей

• Зосередьтеся не на проблемах, зосередьтеся на рішенні

• Підготуйтеся

  • Заздалегідь проаналізуйте спринт (чи все було доставлено вчасно? Чи все було зроблено вчасно? Чи все було зроблено?)

  • Не тільки підіймайте проблеми, але й пропонуйте рішення

• Використовуйте факти та цифри

  • Наприклад, тестування було з затримкою на Х днів

Ретроспектива. Що, якщо

Що може статися

• Команда соромиться відкрито говорити про проблеми

• Занадто багато тиску на термінах розробки, немає часу на ретроспективи!

• У нас є ретроспективи, але нічого не змінюється

Що можна зробити

• Нагадайте команді про мету ретро: знайти рішення, а не винних

• Організуйте ретро так, щоб у кожного була можливість висловити/написати свою думку

• Це перше питання для обговорення на зустрічі!

• Подумайте про те, що можна зробити разом

• Під час ретро команда голосує за дії, які мають бути зроблені у наступному спринті. Включіть їх до беклогу

• Для кожної дії – власник та часова шкала (навіть невеликий крок у правильному напрямку)

• Почніть ретро з огляду дій, які мають бути зроблені з попереднього ретро

Q&A 

Дякую всім за заняття!🙌🏻

❗️🎓Урок 10. Тестування в Agile

❗️🖥 Матеріали до уроку

❗️📖 Домашня робота до уроку

Нагадую, що дедлайн здачі домашніх робіт – до наступного уроку.

Якщо виникають складнощі, пишіть, допоможу із задоволенням 😌

Запис лекції тренер опублікує трохи пізніше 🖥

Не забудьте повторити матеріал та підготуватися до наступного уроку📚

Успіху і до зустрічі!🤩