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

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на 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): після того, як релізи в застосунках стали прогнозованими, усім членам команди стало зрозуміло, коли запускати експерименти, починати розробку та тестування.

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

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