Scrum мінус план тестування дорівнює POC на стероїдах.
У наш час більшість успішних проектів починаються з перевірки концепції (POC), відносно невеликої оцінки ідеї, де вибрану технологію та пакет функцій спочатку перевіряють, оцінюють на потенційний вплив на бізнес-користувачів, а потім, після перевірки заслуговує на інвестиції, повнорозмірна проектна група призначена для розробки та доставки повнофункціонального продукту та розгортання його у виробництві.
Це ідеальний кейс для команди Scrum. Команда може швидко розробити прототип, додаючи істотні нові функції кожного спринту, а бізнес-користувачі можуть спостерігати в реальному часі за швидким прогресом і тим, як ідея будується з нуля протягом приблизно 10 спринтів. Він справляє сильне враження (що в будь-якому випадку є основною метою POC), але він також має одну важливу властивість – мінімальна кількість або відсутність тестування, і навіть думати про процес тестування було б чистим жартом.
Це не весела діяльність у команді Scrum, і людям здебільшого сподобається ідея розробки без процесів, які сповільнюють їх. В основному це те, що будь-яка тестова діяльність буде робити неявно. І кому потрібна непотрібна повільність протягом часу, який нам потрібен, щоб найбільше вразити кінцевого користувача?
Стан, який відбувається, якщо команда проекту продовжує працювати таким же чином після завершення періоду POC, я використовую для того, щоб назвати POC на стероїдах – виробнича система, яка збільшується в розмірах і функціях, але все ще поводиться як POC – готовий продукт із приховані дефекти та незвідані кутові випадки, які чекають лише серйозного збою.
Але до того, як він перейде туди, команді буде важче від спринту до спринту не відставати від стабільних випусків, оскільки виправлення проблем з перебігом стане лише складнішим.
Ось кілька методів, які показали свою ефективність, коли я мав справу з подібними проблемами, і які, на мою думку, можна назвати найкращими методами впровадження надійних процесів тестування, але при цьому не надто перешкоджати прогресу розробки – адже це те, до чого ми всі хочемо бути команда Scrum.
Розподіліть біль
З чого ще ми можемо почати, коли маємо справу з непотрібним клопотом, як не з розділення болю :).
Під цим я маю на увазі створення плану, який вимагатиме від розробників невеликих додаткових дій тут і там, але це значно сприятиме досягненню спільної мети з часом, поступово, але послідовно.
#1. Розробіть код модульного тестування для кожної створеної частини нового коду
Якщо вам вдасться переконати ваші scrum-команди додати до пункту Definition Of Done розробку модульних тестів для кожного нового коду, створеного під час спринту, то з довгострокової точки зору це буде великим досягненням.
Причини досить очевидні:
Це змусить розробників подумати про різні нестандартні шляхи коду. –
- Такі модульні тести можна підключати до автоматизованих конвеєрів DevOps і виконувати під час кожного окремого розгортання в середовищі розробника або тестуванні. Крім того, показники з конвеєра можна легко експортувати, а потім використовувати для демонстрації бізнес-користувачам відсоткового охоплення тестових випадків, безпосередньо прив’язаних до вихідного коду.
Найголовніше – почати якнайшвидше. Чим пізніше почнеться розробка модульних тестів, тим більше відволікатиме розробників додавати їх під час спринту.
- Для зворотної розробки модульних тестів для вже існуючого коду знадобляться значні зусилля. Деякі частини коду можуть бути створені іншим розробником, і поточному розробнику не зовсім зрозуміло, як це має працювати в кожній окремій частині коду. У деяких випадках це може дійти так далеко, що додавання модульного тесту до модифікованого коду займе більше часу, ніж розробка зміни функції для спринту (це стан, який напевно ніхто не обчислював під час планування спринту).
#2. Створіть процедуру виконання всіх частин модульних тестів у середовищі розробки
Навіть перед створенням запиту на об’єднання нового коду в гілку Master стандартною діяльністю має бути тестування як коду функції, так і коду модульного тестування в середовищі розробника. Роблячи це, буде гарантовано, що:
- Код модульного тестування фактично працює для кожної частини (зрештою, це просто ще один код, який потрібно перевірити). Дуже часто цей крок взагалі пропускається. Якимось чином передбачається, що якщо модульний тест все-таки підключено до конвеєра DevOps, він зрештою буде виконано та протестовано десь за замовчуванням. Однак це не що інше, як переміщення проблем на верхні рівні спринтерської діяльності, де команда зазвичай має менше часу та більше стресу, щоб завершити кожну зобов’язану історію.
- Новий код функції перевірено розробником на базову функціональність. Очевидно, що від цього тесту не можна очікувати, що бізнес-функціональність буде повністю перевірена, але принаймні цей тест підтвердить, що код поводиться так, як його задумав розробник (нехтуючи поки що той факт, що бізнес-логіка може бути неправильно зрозумілим під час розробки).
#3. Очікуйте виконання модульного тесту після злиття коду в головну гілку
Одна справа мати функціональний код на локальній гілці (де ніхто, крім власника гілки, не розробляє нову функцію), але зовсім інша справа мати той самий код, що працює після запиту на отримання та злиття в основну гілку.
Головна гілка містить зміни від інших членів команди Scrum, і навіть якщо конфлікти вирішено, і все виглядає добре, код після злиття та вирішення конфліктів залишається в основному неперевіреним фрагментом коду, і ризиковано надсилати його далі без попередньої перевірки він все ще працює добре.
Тож те, що тут виявилося ефективним, — це просто попросити виконати те саме модульне тестування, яке вже проводилося раніше в середовищі розробника, а також у середовищі, створеному з версії коду головної гілки.
Для розробників це може бути ще один додатковий крок, який вони повинні включити у своє життя, але це не так багато зусиль, оскільки в цьому випадку нічого нового не потрібно винаходити – просто повторно виконати те, що вже було зроблено один раз.
Тепер цей крок можна пропустити в одному конкретному випадку:
- Автоматизовані модульні тести в конвеєрах DevOps настільки всеохоплюючі, що вони вже охоплюють усе ручне тестування, яке виконується поверх цього.
Хоча досягнення цього стану безумовно можливо, я ніколи не відчував такого стану в реальному житті. Ймовірно, для розробників було б занадто багато часу, щоб створити такі глибоко деталізовані автоматизовані модульні тести. Для власника продукту може стати неприйнятним дозволити команді приділяти стільки часу цій діяльності, оскільки це матиме явний вплив на кількість доставлених історій протягом спринту.
Однак перевага вмісту спринту ніколи не може бути виправданням для того, щоб не проводити модульні тести або навіть мінімізувати їх. Зробивши це, команда знову переведе до такого стану, коли коду бракує занадто багато модульного тестування, і тоді для надолуження може бути вже занадто пізно (знову ж таки, більше зусиль для завершення модульного тесту, ніж фактичне зміна коду для спринту).
З усіх цих причин я б без вагань рекомендував повторно виконати модульні тести на версії головного коду. Це такі низькі зусилля порівняно з тим, яку цінність це принесе.
Він зробить останню перевірку готовності головної гілки до етапу тестування випуску. Крім того, це допоможе знайти більшість технічних помилок (наприклад, помилки, які перешкоджають успішному виконанню вихідного коду до успішного завершення), залишивши на наступному етапі зосередитися виключно на перевірці бізнес-функціональності.
Підготуйтеся до функціонального тестування
Усі попередні дії з тестування повинні привести до одного конкретного висновку – головний код гілки вільний від технічних помилок і без проблем виконуваний для наскрізних функціональних потоків.
Це етап, який може легко охопити лише одна людина, і цій людині навіть не потрібно мати технічну освіту.
Насправді, набагато краще, якщо це буде виконано кимось, відключеним від розробників, але з функціональним усвідомленням того, як бізнес-користувачі очікують поведінки коду. Необхідно виконати дві основні дії:
#1. Цільовий функціональний тест нових історій про спринт
В ідеалі кожен спринт має привносити нову функціональність (приріст цілі спринту), яка раніше не існувала, і тому вона має бути перевірена. Важливо переконатися, що нова частина програмного забезпечення працює настільки, щоб бізнес-користувачі були щасливі мати її зараз, оскільки вони, очевидно, чекали її з нетерпінням принаймні весь останній спринт :).
Це такий сумний досвід, коли нарешті оголошено про випуск (довго) обіцяної функції, а днями виявляється, що вона насправді не працює належним чином.
Тому правильне тестування нової функціональності спринту має вирішальне значення. Щоб досягти успіху, рекомендовано заздалегідь зібрати важливі тестові випадки від відповідних зацікавлених сторін (від власника продукту або навіть від кінцевих користувачів) і скласти список усіх таких тестових випадків, необхідних для вмісту всередині спринт.
На перший погляд це може виглядати приголомшливо, але, з мого досвіду, з цим цілком впорається одна людина. Оскільки спринти здебільшого досить короткі (як-от двотижневий період), у будь-якому разі майже ніколи не буває забагато нового вмісту, оскільки спринт також містить додаткові дії, як-от історії технічної заборгованості, документація, історії про дизайн/розвиток тощо.
Потім виконуються тестові приклади, перш за все, з метою перевірки бажаної функціональності. У разі виникнення будь-якої проблеми з результатами звертаються лише до відповідного розробника (того, кому належать зміни, пов’язані з цим конкретним дефектом), щоб вирішити проблему, сподіваємося, швидко.
Таким чином, розробники витрачатимуть мінімум часу на функціональне тестування та зможуть зосередитися на діяльності, яка їм найбільше подобається.
#2. Виконання регресійних тестів
Інша частина функціонального тестування повинна полягати в тому, щоб переконатися, що все, що працювало досі, також працюватиме після наступного випуску. Для цього і потрібні регресійні тести.
Тестові випадки для регресійних тестів найкращі, якщо їх регулярно підтримувати та переглядати перед кожним випуском. Виходячи зі специфіки конкретного проекту, найкраще, щоб вони були простими, але охоплювали більшість основних функцій і важливі наскрізні потоки, що проходять через всю систему.
Зазвичай у кожній системі є такі процеси, які стосуються багатьох різних областей, і це найкращі кандидати для регресійних тестів.
У деяких випадках регресійні тести навіть неявно охоплюють нові функції в спринті, наприклад, якщо нова історія в спринті змінює певну частину існуючого потоку.
Отже, у більшості випадків виконати регресійні тести поряд із тестуванням нових історій спринту зовсім не складно, особливо якщо це робиться регулярно перед кожним виробничим випуском, а періодичність виробничих випусків не надто мала.
Наполягайте на виконанні перевірок якості перед кожним випуском продукції
Тест забезпечення якості (QA) є останнім кроком перед випуском у виробництво, і часто цей тест пропускається як неважливий. Особливо, якщо команда scrum керується агресивно для нового контенту.
Навіть бізнес-користувачі скажуть, що їх цікавлять нові функції, а не стільки збереження функціональності чи низька кількість дефектів. Але знову ж таки – з часом це головна причина, чому команді розробників доведеться сповільнитися, і тоді бізнес-користувачі все одно не отримають те, про що просять.
Перевірка якості повинна виконуватися виключно людьми поза командою Scrum, в ідеалі самими бізнес-користувачами в спеціальному середовищі, яке максимально наближене до майбутнього виробництва. Крім того, власник продукту може замінити тут кінцевих користувачів.
У будь-якому випадку це має бути чистий, функціональний тест з точки зору кінцевого користувача, без жодного зв’язку з командою розробників Scrum. Він представлятиме остаточний вигляд продукту та використовуватиметься таким чином, який, можливо, ніхто з команди scrum не очікував (зовсім не ідеальний випадок, але це точно може статися). Ще є час для останніх виправлень.
Крім того, може стати зрозуміло, що очікування не були добре зрозумілі команді scrum, і в такому випадку ми можемо принаймні узгодити план подальших дій ще задовго до фактичного випуску продукції. Це, знову ж таки, не ідеальний випадок, але все ж набагато краще, ніж визнати невдачу відразу після звіту про успішний випуск продукції.
Куди йти далі?
Застосування цих практик до щоденної роботи зі scrum може серйозно привести вас до більш стабільних і передбачуваних звичок випуску спринтів, не затримуючи випуски виробництва або витрачаючи весь спринт просто на підготовку до наступного випуску, або навіть не змушуючи кожного в команді scrum робити те, що вони не роблять. Я не дуже люблю або не знаю, як ефективно виконувати більшу частину спринту, тобто.
Але напевно не варто зупинятися на цьому.
Включення тесту продуктивності – це одна з тем, яку слід назвати тут. Вони часто ігноруються або вважаються непотрібними, вичищаючи в першому раунді «оптимізації діяльності Scrum». Проте я завжди сумнівався щодо того, як можна очікувати розвитку виробничої системи з часом, якщо її продуктивність регулярно не перевіряється.
Перехід на один рівень вище також означає впровадження автоматизованих тестів.
Я вже розглянув одну групу автоматизованих тестів (модульні тести в конвеєрах). Однак ви можете розробити повні наскрізні регресійні тести, повністю автоматизовані та виконуватися самостійно після кожного розгортання в тестовому середовищі. Це ще більше звільнить команду розробників scrum, але для розробки та підтримки таких автоматизованих тестів потрібна спеціальна команда. Це стане постійною роботою, оскільки щоразу, коли виробничий код змінюється, деякі існуючі автоматизовані тести можуть стати недійсними, тому їх потрібно оновити, щоб продовжувати працювати в конвеєрах. Це зусилля, за яке готові платити лише деякі, але переваги для команди розробників scrum були б великими.
Це теми, які виходять далеко за рамки цієї статті та з’ясування правильного розкладу та часу для кожного типу тесту, згаданого тут, щоб ви могли зробити це в межах вікна спринту. Буду радий зануритися наступного разу!