Дві поради, що допоможуть вам досягти успіху в автоматизації тестів
Всім привіт, я Владислав Бабич, Automation QA Technical Lead у Ciklum. Ні для кого не секрет, що автоматизація тестів — невідʼємна частина будь-якого нетривіального IT-проєкту. Вона дозволяє швидше запроваджувати зміни та випускати нові продукти, оскільки значно скорочує час, потрібний для тестування. У теорії все звучить достатньо райдужно та просто — але на практиці нам варто розуміти найкращі практики автоматизації.
У цій статті я поділюся двома підходами, які, попри свою користь, досить рідко обговорюються та застосовуються у спільноті тестувальників. Вони точно допоможуть вам вивести ваші навички з автоматизації на новий рівень.
Порада #1. Пишіть прогресивні тести замість роботи над регресією
Уявімо типову ситуацію: у команді є кілька automation-інженерів, що займаються UI/API-тестами. Вони працюють над регресією, зазвичай переписуючи мануальні кейси в автоматичні. Водночас у команді триває активна розробка та додається новий функціонал. AQA-інженери в цьому процесі практично не беруть участі, а девелопери не чекають на автоматичні тести. Функціонал випускають після тестування. У чому ж проблема?
Річ у тім, що регресія приносить менше користі, ніж тести активної розробки, тобто «прогресивні тести». Прогресивні тести — ті, що створюються разом з розробкою та є частиною DOD (Definition of Done) для наших user story. За такого підходу ми не випускаємо фічу без автоматизованих тестів.
Проблеми регресії
За класичним сценарієм, AQA-інженера запрошують у проєкт та просять автоматизувати мануальні тест-кейси для вже написаного функціоналу. Менеджер чи лід розраховує на те, що у якийсь момент ми закінчимо регресію і після цього почнемо працювати над новими фічами.
Насправді це трапляється нечасто — такий підхід працює тільки у ситуаціях, коли технологія вже майже закінчена (але це також означає, що тоді автоматизацію вводять занадто пізно). Дуже рідко ми «наздоганяємо» активну розробку: доки пишемо тести, аплікація не стоїть на місці. Тестери постійно накопичують технічний борг, адже виходять нові функції, не покриті автоматизацією, а також множаться мануальні тест-кейси, які потім доведеться автоматизувати.
З висоти пташиного польоту цей процес виглядає приблизно так:
Інженер, який намагається закінчити автоматизацію регресії та наздогнати розробників
А якщо є інший вихід? Ми можемо перестати накопичувати технічний борг і переконатися, що новий функціонал не випускається без тестів. Старий же поступово допрацьовуватимемо.
Що робити, якщо не вистачає часу на регресію? Таке теж можливо, адже AQA-інженерів зазвичай менше, ніж девелоперів — іноді навіть у декілька разів. Може бути складно встигати за розробкою, не кажучи вже про регресію.
У такому випадку ми пріоритезуємо прогресію. Не відмовляємося від регресії повністю, але насамперед пишемо тести для нових функцій. Що в такому разі робити з регресією — я розповім трохи згодом.
Переваги прогресивних тестів
За прогресивної автоматизації ми не закриваємо user story, доки тести не написані. Це має низку переваг:
- Код одразу пишеться з урахуванням автоматизації, одразу додаються потрібні automation id (якщо ми говоримо про тести Selenium). Усі потенційні недоліки ми знаходимо на тому етапі, де їх ще легко виправити.
- Тести на будь-якому рівні допомагають знайти проблеми в архітектурі та сприяють кращому дизайну коду. Це дуже помітно на рівні юніт-тестів: якщо у тебе спагеті-код, то ти ніяк не напишеш до нього хороші юніт-тести. Часто сам факт присутності юніт-тестів у проєкті покращує дизайн коду. Такий самий принцип працює і на вищому рівні тестів. API- чи UI-тести допомагають знайти високорівневі проблеми архітектури цілої аплікації. Наприклад, якщо наші послуги не ізольовані правильно, то складно їх окремо протестувати і зробити мокапи. Це можна швидко знайти за допомогою тестів. А от працюючи лише над регресією, ми дізнаємося про це надто пізно.
- Ми знаходимо більше дефектів та отримуємо значну впевненість у функціоналі, який випускаємо. Подумайте — де буде найбільше дефектів? У частинах аплікації, які перебувають під активною розробкою і постійно змінюються, або в тих, які вже випущені і практично не змінюються?
- Ми не витрачаємо багато часу на роботу зі старими мануальними тест-кейсами, які ми хочемо автоматизувати. Дуже рідко мануальні кейси пишуться з урахуванням автоматизації. Вони написані для людини, тому логічно не підходять для коду. Часто доводиться звʼязуватися з тестером, який їх написав, уточнювати подробиці, розбивати один великий кейс на кілька маленьких тощо. Усе це потребує зайвого часу та зусиль.
- Будь-які інші проблеми, які могли б перешкодити нам автоматизувати тести, будуть швидко усунуті. Візьмемо для прикладу дрібний UI-дефект, що має дуже низький пріоритет, і який легко обійти мануально. Нам доведеться чекати, поки девелопер звільниться і його виправить. Але якщо ми працюємо над тим же функціоналом, що і девелопери, одночасно з ними — будь-які дрібні проблеми будуть швидко виправлені. Код ще «свіжий» і нікому не потрібно займатися context switching.
Ще один важливий момент, якому не надають належної уваги: якщо ми не працюємо разом з девелоперами над одними завданнями, у нас дуже страждає якість командної роботи. Досвід показує, що у таких проєктах тестери живуть на своєму ізольованому острівці. Спілкування з девелоперами та мануальними QA дуже обмежене: зазвичай це випадки, коли ми знаходимо дефект або у нас є якесь питання.
Крім того, працюючи разом з девелоперами, в рази збільшуються шанси того, що ми зможемо їх залучити до автоматизації. Чому це важливо зробити — обговоримо у наступній частині.
Порада #2. Залучайте девелоперів до автоматизації
Зазвичай кількість тестерів у проєкті на порядок менша за кількість девелоперів. І якщо тести є частиною DoD (Definition of Done), ми можемо не встигати за розробниками. А навіть якщо і встигаємо, то згадайте дилему з минулого розділу: що робити, коли не вистачає часу на прогресію та регресію?
Вирішення обох проблем — допомога від розробників та залучення їх до процесу автоматизації. Коли команда досить зріла та має гарну самоорганізацію, ми можемо довірити прогресивні тести нашим девелоперам (під нашим наглядом), а самі — займатимемось регресією. Якщо вам вдалося залучити розробників до автоматизації — вітаю, у вас дуже високі шанси на успіх.
Ні — овертестингу, так — тестовій піраміді
Я думаю, що всі вже знайомі з тестовою пірамідою:
Основна її ідея полягає в тому, що більшість тестів повинні писатися на низькому рівні, тому що такі тести швидше та надійніше. Але якщо девелопери і тестери не співпрацюють на регулярній основі, як можна дотримуватися цього правила? Ніяк.
У проєктах, де AQA-інженери ізольовані, комунікації практично немає. Отже, передбачувано відбувається «овертестинг» — кейси, які можна написати на нижніх рівнях, робляться чи повторюються на вищих.
Коли автоматизація стає загальним продуктом усієї команди, такої проблеми не виникає. Ми маємо чітке розуміння того, що і на якому рівні ми тестуємо.
Наприклад, AQA-інженер може створювати тест-кейси, і разом з девелопером вирішувати, що з цього буде покрито у юніт-тестах, а що — на інших рівнях. Зверніть увагу, що це в рази простіше реалізувати при прогресивному тестуванні, яке ми обговорювали вище. Якщо ми працюємо тільки над регресією, нам доведеться постійно відривати девелопера від його поточної роботи і просити, щоб він повернувся до старих юніт-тестів і доповнив їх. Інтуїція мені підказує, що він не буде задоволений таким підходом до роботи.
В ідеальному випадку, з часом межа між тестувальником і девелопером розмивається, і над автоматизацією працює ціла команда. Це не означає, що спеціалізація Dev/QA зникає. Це означає, що за автоматизацію відповідальні всі.
Якщо хочете надихнутися, зверніть увагу на те, як це реалізували на проєкті VSTS в Microsoft. Необов’язково для цього влаштовуватись працювати саме в цю компанію, є чимало наших проєктів, де також вдалося впровадити подібну практику у командах. Я маю досвід роботи на таких і скажу, що автоматизація там була набагато успішнішою.
Важливість використання спільної мови програмування
Як ви вже самі здогадалися, краще використовувати одну й ту ж мову програмування для back-end і тестів. На жаль, я нерідко зустрічав менеджерів, які вирішують використовувати іншу мову програмування для автоматизації. Наприклад, Python: за їхньою логікою, на ньому легше писати тести, легше знайти спеціалістів тощо.
Але вони зазвичай не розуміють, що в довгостроковій перспективі стріляють собі ж у ногу. Будь-яка уявна користь від такого рішення швидко зникає. Якщо ми вибираємо іншу технологію для тестів, то:
- шанс того, що ми залучимо девелоперів до написання тестів, дуже низький: вони не будуть знайомі з технологією або не захочуть її вчити;
- ми не ділимося найкращими практиками та досвідом, тому втрачається можливість робити загальні code reviews;
- можливість ділитися кодом, наприклад, через спільні бібліотеки, також зникає;
- девелопер навряд чи захоче ставити інше IDE (Integrated Development Environment), щоб запускати наші тести локально перед коммітом. Так, у нас для цього завжди є CI, але на практиці запуск вибіркових тестів перед коммітом зберігає багато часу та зусиль.
Психологічні блоки з обох сторін та як їх побороти
Припустимо, що у вас не залишилося сумнівів стосовно того, наскільки корисно працювати над автоматизацією цілою командою. Тепер ви хочете впровадити це на практиці. Вам може пощастити, і девелопери з ентузіазмом сприймуть вашу ідею, але так трапляється не завжди. Ви можете зіткнутися з сумнівами чи прямим опором.
«Це поза нашими обов’язками»
«Це що, виходить, ми повинні все самі робити? Імплементацію та тести? А ви тоді чим займатися будете?»
Готуйтесь чути подібні фрази на початку — це абсолютно нормально. Люди за своєю натурою остерігаються змін та додаткових, як їм здається, обовʼязків. Спробуйте уявити себе на їхньому місці: це справді може звучати загрозливо для вашої зони комфорту. Тому ваше завдання — спокійно та впевнено показати команді користь такого рішення.
Це може вимагати певного часу, тож важливо набратися терпіння. А поки:
- Порушуйте цю тему регулярно.
- Просіть допомоги у девелоперів, якщо ви маєте труднощі в автоматизації або просто не встигаєте.
- Проявіть ініціативу і просіть частину ваших тест-кейсів покрити у юніт-тестах (а там і до функціональних недалеко).
- Виберіть девелопера, найбільш відкритого до змін, і спробуйте спочатку залучити його до написання тестів. Інші згодом надихнуться його прикладом.
- Ставте калібрувальні питання, не нав’язуючи при цьому своєї думки:
«Як нам справлятися самим, якщо темп розробки швидший за темп автоматизації і ми не встигаємо?»
«Як ми досягнемо успіху, якщо ми не працюємо як одна команда над автоматизацією?»
Якщо ви правильно вибудовуєте комунікацію, у відповідь на ці питання ви зазвичай почуєте пропозицію допомогти.
А якщо ви не переконали свою команду відразу, то дуже важливо бути терплячими і продовжувати дотримуватися інших кращих практик в автоматизації: написання стабільних і якісних тестів, регулярний запуск на CI тощо.
Згодом (і з кожним новим знайденим дефектом) цінність автоматизації в очах команди тільки зростатиме. Завдяки цьому інвестиція усіх колег в автоматизацію вже не буде здаватися такою великою.
Висновки
У цій статті ми з вами обговорили дві поради, які допомагають отримати максимальну користь від автоматизації. Перша — написання прогресивних тестів. Друга — залучення девелоперів до автоматизації. Навіть окремо один від одного, ці інструменти залишаються надзвичайно потужними та приносять багато користі. Однак, поєднані ці принципи справді допомагають вивести автоматизацію на новий рівень.
22 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів