Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Як підтримувати системний цикл релізів застосунку. Погляд розробника й тестувальниці

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Привіт! Мене звати Роман Кириленко, я — iOS Engineer у продуктовій ІТ-компанії Quarks. Наша команда займається розробкою застосунків сервісу онлайн-знайомств Kismia для iOS та Android.

Оптимізація роботи та процесів — те, над чим ми працюємо постійно. Навіть відбудований упродовж років процес можна і треба переглядати, шукати в ньому вузькі місця та блокери, які заважають працювати ефективно. Усе це має відбуватися регулярно.

У цій статті ми з колегою Агатою Авраменко, Manual QA Engineer, розповімо, як ітеративно прийшли до циклічної системи релізів застосунків, і як це покращило життя команд розробки та тестування.

Для наочності, ми з різних позицій, QA та інженера iOS-розробки, опишемо весь процес — від підготовки до останнього етапу тестування фінальної збірки. І розкажемо, як нам вдалося навчитися правильно планувати спринт та мінімізувати перенесення релізів.

Тож кожен пункт у розробці коментуємо ми вдвох з Агатою, щоб показати процеси в команді з двох перспектив.

Від синхронних довільних релізів до циклічної системи

iOS Engineer: до того, як ми прийшли до поточного циклу, випуск нової версії застосунку відбувався за фактом виконання групи завдань.

Такий підхід здавався гнучкішим, проте згодом ми зрозуміли, що втрачаємо час. Щоразу реліз відбувався довільно, не було розуміння дати, ми могли дозволити собі розширювати об’єм задач.

Проблеми такого підходу не були відчутними, доки ми працювали невеликою командою. Щойно кількість менеджерів та розробників почала зростати, ми стикнулися з проблемою планування подальшої роботи, термінів реалізації тощо.

Зрозумівши це, ми звернулися до методики управління проєктами Scrum. Уже понад рік ми тримаємо цикл щотижневих релізів: один тиждень на iOS, наступний — на Android. Кожна команда розробки має спринт довжиною у два тижні, в кінці якого відбувається випуск версії застосунку.

Manual QA Engineer (App): оскільки ми одночасно підтримуємо дві платформи, розсинхронізація релізів — оптимальне рішення. Це значно знижує навантаження на QA, дає чітке розуміння пріоритетів. Один тиждень — концентрація на iOS, другий тиждень — на Android.

Раніше чіткого графіка не було, тому релізи для двох платформ могли збігатися. Працювати з ними одночасно було нереальним навантаженням для команди QA, адже інструменти для тестування iOS та Android на той момент відрізнялися значно більше. Ми стикалися з тим, що задачі постійно плуталися.

Зараз процес релізів став стабільним та менш стресовим для QA.

Етап 0. Підготовка до спринту

iOS Engineer: підготовка починається з опрацювання беклога продукту. Щотижня команди розробників кожної платформи виділяють одну (іноді дві) години, щоби пройтися по беклогу задач, які накопичилися з минулої такої зустрічі. На ній кожну задачу проводять крізь три етапи: рефайнмент, оцінка та декомпозиція.

  1. Рефайнмент полягає в тому, що розробники розбирають задачі, лишають питання та/ або уточнення для продуктової команди (дизайнеру, оунеру ідеї, аналітику). Для роботи із задачами команда використовує Jira. У ній є окремий розділ, куди потрапляють задачі для рефайнменту.
  2. Оцінка — розробники оцінюють задачу в сторіпоінтах за стандартною схемою: кожен пропонує свою оцінку (значення має бути числом Фібоначчі). Якщо оцінка у всіх збігається і немає питань, задача вважається оціненою. Якщо ні, її додатково обговорюють і приходять до консенсусу.
  3. Декомпозиція. Основна її ідея — розбити велику задачу на кілька дрібних, кожна з яких або буде суто технічною, або має бути такою, яку можна віддати на тестування. В Jira заводяться нові задачі, які додаються до тієї, яку розглядаємо. Додаткова умова: якщо оцінка завелика, то задачу треба ще раз декомпозувати. Вона не має займати більше ніж два дні, а краще — не більше за один день.

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

Для успішного рефайнменту ми вибудували додаткові процеси на рівні лідів команд розробки та менеджерів напрямів проєкту. Продуктова команда завчасно презентує лідам задачі, над якими планується робота упродовж наступних тижнів, одного або двох місяців (залежно від планів). Вони формуються з урахуванням загальних цілей команди, продукту та компанії.

Цей роадмап розглядається та актуалізується з поточною інформацією щотижнево: учасники помічають задачі, функціонал яких уже доступний користувачам, презентують нові ідеї лідам, отримують короткий зворотний зв’язок від них. Так менеджери одразу розуміють складність ідеї, долученість сторонніх команд, можливість реалізації тощо.

Етап 1. Планування: як врахувати всі чинники

iOS Engineer: по завершенню двотижневого спринту команда розпочинає планування нового. На вході цього процесу маємо список задач (ті, що були підготовлені цією ж командою на етапі рефайнменту беклогу), та високорівневий роадмап, який відображає пріоритети.

На етапі планування важливо визначити та врахувати все, що впливає на успішність спринту: зовнішні чинники, доступність команди, складність задач.

Кожна команда розробників довгий час оптимізовувала і прораховувала свою швидкість — кількість сторіпоінтів, які вони можуть закривати за два тижні. Це значення адаптується під умови наступного спринту (наприклад, випадає святковий вихідний чи хтось із команди не буде працювати декілька днів).

Далі закладається набір задач на ту кількість сторіпоінтів, яку узгодили розробники між собою з урахуванням пріоритетів і технічних залежностей.

Після цієї зустрічі продуктову команду інформують, що спринт сформовано. Вона може внести корективи у спринт, після чого він запускається.

Етап 2. Підготовка тестової документації

Manual QA Engineer (App): коли спринт сформовано, команда QA береться за роботу над тестовою документацією. Задачі діляться на двох тестувальників, тож написання документації займає 1–2 дні. Цей час є певним буфером, оскільки розробка щойно почалася, і задач на тестування ще немає.

Ознайомлення з юзер-сторі ми починаємо на етапі написання тест-кейсів. Це покращує розуміння продукту, дає неупереджений погляд на функціонал. Ми дивимося на нього не в контексті технічних або продуктових змін, а саме так, як його бачитиме кінцевий користувач.

Нещодавно ми перейшли на нову TMS. Це пришвидшило процес написання тестової документації, а також ми перестали писати цілі набори тест-кейсів на реліз.

Натомість ми просто вносимо зміни у вже існуючі, помічаємо тести номером задачі. Якщо фічу приймають, як сталий функціонал, тест переходить із драфту в активний тест та передається на автоматизацію, а з опису забирається номер. Якщо від фічі відмовляються, ці тест-кейси просто видаляються.

У процесі написання тест-кейсів завжди прораховується не тільки «щасливий сценарій» для користувача. Спираючись на дизайн та опис задачі, ми намагаємося максимально покрити тестами й edge cases. Якщо для цього необхідні певні зміни в макетах, описі механіки, ми одразу комунікуємо про це. На цьому етапі ми завжди інформуємо про незрозумілі моменти, незручність для користувача або недостатньо продуману механіку фічі.

Деякі команди залучають QA до процесу рефайнменту, щоб одразу врахувати такі моменти, але ми поки не бачимо в цьому необхідності. Завершення написання тестової документації збігається з дистрибуцією перших білдів нового релізу, тому задачі беруться на тестування максимально швидко.

Етап 3. Імплементація та робота з форс-мажорами

iOS Engineer: після внесення коректив у спринт, починається імплементація. Щоденно розробники всіх напрямів збираються на короткий дзвінок (до 15 хв), на якому кожен стисло розповідає, що робив учора, що планує робити сьогодні, що може йому заважати. Такий дзвінок ми проводимо вранці перед початком роботи, так можна вирішити питання залежностей у команді.

Водночас важливо, щоби жоден член команди не чекав наступного дня, щоби повідомити про якусь проблему. Якщо він стикається з помилками в дизайні, невідповідністю або пропущеними вимогами, відсутністю реалізації від іншої команди (наприклад, бекенду) тощо, він має порушити це питання одразу. Це один із ключових факторів, що впливає на успішність спринту, а отже й релізу.

Якщо команда бачить, що певні проблеми виникають регулярно (наприклад, протягом 2–3 спринтів), це означає, що в одному з процесів є недоліки, які потрібно знайти та вирішити.

У своїй команді я звертав увагу на такі моменти:

  • затримки код-ревʼю;
  • затримки процесу локалізації;
  • затримки в роботі із зовнішніми командами розробки;
  • доступність членів команди онлайн упродовж робочого дня тощо.

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

Якщо під час спринту стає зрозумілим, що ми не встигаємо зарелізити запланований функціонал, ми адаптуємо набір задач до поточної ситуації.

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

Водночас якщо команда не встигає, або навпаки, — завершує роботу раніше запланованого, це свідчить про проблему в процесі оцінки. У таких випадках треба адаптувати загальну кількість сторіпоінтів, яку заплановано в роботу.

Такі неточності зазвичай відбуваються через зміни у складі команди та вирішуються впродовж 1–2 спринтів.

Робота в командах розробки між платформами побудована у схожий спосіб, проте адаптована під кожну команду окремо. Зазвичай розробники розподіляють задачі між собою, беруть їх у роботу.

У кожній команді не менше двох розробників, тому кожен проходить додаткову перевірку на рівні вихідного коду, після чого задача або її блок може бути відправлена на тестування, якщо це можливо.

Це дозволяє нам оперативно отримувати зворотний зв’язок від команди тестувальників за кожним блоком, а не чекати, доки вся ідея буде реалізована, і тільки тоді віддавати її на тестування. Тобто замість каскаду ми отримуємо ітеративне тестування — це ще один важливий фактор успішності спринту.

Етап 4. Тестування релізу

Manual QA Engineer (App): для команди QA реліз відбувається щотижня, але для різних платформ. Проте це не означає, що протягом усього тижня ми тестуємо лише одну з них. Якщо на борді є задачі від різних команд, першочергово ми візьмемо на тестування задачу тої платформи, реліз якої запланований на цей тиждень.

У команді ми узгодили правило не перетримувати задачі в статусі QA: вони там знаходяться тільки в момент реального тестування.

Якщо знайдено баг, задача вертається на розробку. Якщо декілька багів, — створюється окрема задача та передається розробнику. Основна переходить у статус «QA passed», але до неї блокером лінкується задача з багом.

Цей підхід дозволяє реально оцінити час розробки та тестування, а також полегшує формування набору задач для релізів у майбутньому.

Задачі розбираються тестувальниками за пріоритетами, які виставили розробники. Також ми намагаємося завжди бути в контексті нового функціоналу, який випускає кожна з платформ.

Наприклад, якщо я тестувала фічу «А» на Android, цю задачу на iOS візьме мій колега. Це допомагає команді QA завжди бути в курсі функціональності, яка існує в застосунках, та як вона працює на кожній з платформ.

Через динамічний процес розробки та швидкі зміни в застосунках ми прийшли до чудового рішення — запису демо. Після того, як розробники закінчують багфікс по задачі, вони записують демо реалізованого функціоналу та завантажують в окремий канал, де є всі члени команди.

Менеджери, дизайнери та аналітики на цій стадії можуть зробити свої зауваження або пропозиції, якщо є необхідність. Це полегшує процес розробки і тестування, бо всі правки робляться в моменті, а не через місяці, коли вже мало хто памʼятає контекст.

Останній етап — смоук-тестування фінальної збірки. Велика частина функціонала застосунків уже покрита автотестами, і це покриття регулярно збільшується. Саме тому на цей етап перед відправкою ми витрачаємо відносно небагато часу.

У нашої команди є негласне правило, що ми не беремо в роботу фінальний білд після 5 вечора. Навіть найуважніший спеціаліст втомлюється та може пропустити якісь баги.

Тому, якщо є можливість, ми переносимо реліз на ранок наступного дня, коли зі свіжою головою можемо протестувати release candidate.

Висновки

iOS Engineer: отже, для себе ми виділили низку переваг циклічного релізу:

  1. Систематичність, яка дозволяє продуктовій команді чіткіше планувати майбутню роботу.
  2. Регулярне проведення A/B тестування функціонала, який ми впроваджуємо для користувачів.
  3. Можливість отримати швидкий зворотний зв’язок від користувачів застосунку, виявляти системні збої, помилки тощо.

Це не кінцевий список переваг циклу, якого ми дійшли, проте це основні для нас точки опори.

Manual QA Engineer (App): після того, як релізи в застосунках стали прогнозованими, усім членам команди стало зрозуміло, коли запускати експерименти, починати розробку та тестування.

Звісно, бувають моменти, коли щось йде не за планом, але таких ситуацій стало менше. Команді стало легше розставляти пріоритети, зʼявилося відпрацьоване флоу, у яке легко онбордити нових співробітників.

І найголовніше — ніхто вже не питає щодня «Коли там реліз?».

👍ПодобаєтьсяСподобалось7
До обраногоВ обраному5
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Яку TMS використовує QA команда ?)

Дякую за статтю! А чому декомпозиція іде після оцінки? Спочатку ж декомпозуєшь, а потім оцінюєшь вже невеличкі задачі, щоб зрозуміти скільки часу займе вся фіча. Інакше здається немає сенсу великого в декомпозиції.

Насправді так і є. Композицією ми називаємо вже процес заведення задач в джирі, тому тут він іде після оцінки 🙃
Коли команда проводить оцінку, вона розбирає задачу на блоки, і оцінює вже ці блоки. Далі вони або агрегуються в одну, або під кожен блок заводиться задача.
Дякую, що підсвітили!

Дякую за те що поділилися досвідом!
Поділюся, що здивувало:

1/ «Деякі команди залучають QA до процесу рефайнменту, щоб одразу врахувати такі моменти, але ми поки не бачимо в цьому необхідності.»
>> qa це невідʼємна частина команди. Тим більше ви ж наче скрам намагаєтеся втілити. Як це не вся команда приймає участь в рефайнменті? Тестувальники можуть вже на планінгу сказати що взагалі не можна брати в спринт, бо дуже ризиковано чи залежність тощо.
По друге, з тексту здалося що qa не оцінює фічі. Друзі, це велика помилка. Дуже.

2/ «У такому разі лід розробки, який відповідає за спринт, обирає, що робити: не випускати фічу або випустити її частково, додатково погоджуючи своє рішення з продуктовою командою.»
>> Яка у вас роль продакт оунера/менеджера? Чому розробники вирішують долю спринту? Це і близько не скрам і далеко від логіки.

3/ «Водночас якщо команда не встигає, або навпаки, — завершує роботу раніше запланованого, це свідчить про проблему в процесі оцінки»
>> Оцінка це не вагу міряти. 100500 факторів і, лише один з них це проблема оцінки (до речі без qa у вас же ж 🙂). І не можна навіть супер команді робити завжди сталу кількість поінтів. Слідкують за середнім хоча б. І одразу адаптувати поінти це помилка, це підгонка в чистому вигляді.

4/ «Якщо декілька багів, — створюється окрема задача та передається розробнику. Основна переходить у статус „QA passed“»
>> Стейкхолдерів не бентежить статус пассед коли насправді Ні? Хіба не можна придумати статус?
Розробники вам кажуть дякую за таску для них чи лаять про себе, бо це вони мають їх створювати?

5/ Нічого в статті не описано як працюєте зі старими багами в новому спринті

6/ «Тому, якщо є можливість, ми переносимо реліз на ранок наступного дня»
>> Тобто реліз все ж таки можна зміщувати спокійно? Чи це форс мажор?

7/ Не зрозумів з демкою. Їі просто записують і всі інші стейкхолдери, оунери просто дивляться?
А де ж демо сессія, жива з фідбеком голосом, обговоренням тощо. Дивно

Дуже дякую за такий розгорнутий коментар

Перш за все хочу зазначити, що метою цієї статті було поділитись саме власним досвідом. Наші процеси не претендують на ідеальність і вони точно не претендують на «правильний скрам». І суб’єктивно не бачу сенсу сліпо слідувати всім його канонам — команда працює на результат, а не на залік.

1. QA інженери дійсно невіддільна частина команди. Проте в нашій конфігурації доцільності підключати їх на рефаймент немає. Пробували, зрозуміли що це марна трата часу, здебільшого самих інженерів.
Скоуп спринта залежить від продуктової команди, а ліди напрямків валідують можливість ризиків і залежностей. Це точно не задача qa.
Дійсно, оцінка задачі в нас не включає оцінку тестування, суто ресурс команди розробки. Це і правда не дуже добре працює при масштабуванні команді, але в поточному складі це не створює нам проблем. Проте ми це пам’ятаємо.

2. В контексті питання продукт менеджер виконує роль «замовника» фічі, а задача команди розробки (ліда, розробників, тестувальників) цю фічу втілити.
Ліди вирішують долю спринта тому, що тільки вони можуть побудувати відповідність між замовленням і виконанням. Продукт менеджер фокусується на формуванні продукту, команда на реалізації.

3. 100500 факторів то забагато, і з цим треба щось робити. Ми свої фактори знаємо і безперервно з ними працюємо, максимально намагаємось врахувати на плануванні.
Стосовно середнього гарний поінт, забули описати це.

4. Під стейкхолдерами тут мається на увазі оунер фічі? Якщо так, то статус qa passed йому взагалі ні про що не каже, це технічний статус.
Статус можна придумати, і їх в нас є. І в кожного статусу є свій/свої стейкхолдери.
І конфліктів з розробниками це не створює.

5. В беклозі баги майже не затримуються, вони закриваються в рамках поточного спринта. Тому в тих рідкісних випадках коли є старі баги вони просто добираються в скоуп спринта.
Є дрібні задачі, які належать категорії «не повпливає на користувача, але повпливає на продукт довгостроково / повпливає на кодову базу». Такі задачі можуть слугувати розвантаженням в спринті, і ми зазвичай беремо їх потрохи в кожен спринт (щоб не набирати самі тільки спліт-тести). Це доволі суб’єктивний момент, який вирішується лідами, проте і задачі не занадто важливі для продукту в короткостроковому сенсі.

6. Це є форс мажором, наче ніде не писали що це частина процесу. Такі випадки дуже рідкі.

7. Такий підхід (жива сесія демо) для нас не працював, і ми прийшли до такого собі асинхронного процесу. В команді чимало стейкхолдерів фічі (продукти, дизайнери, аналітики, та і будь-який член команди може внести свою аргументовану думку), і такі живі сесії сильно розтягуються по часу і з’їдають ресурс розробки та тестування.
Ми спробували робити це асинхронно — нічого не втратили (вся команда в контексті, всі питання вирішуються), та виграли час. До того ж продукти не чекають день ікс коли ми покажемо демо аби дати зворотний зв’язок, це в нашому кейсі також було вагомим аргументом.

Підписатись на коментарі