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

Дві поради, що допоможуть вам досягти успіху в автоматизації тестів

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

Всім привіт, я Владислав Бабич, Automation QA Technical Lead у Ciklum. Ні для кого не секрет, що автоматизація тестів — невідʼємна частина будь-якого нетривіального IT-проєкту. Вона дозволяє швидше запроваджувати зміни та випускати нові продукти, оскільки значно скорочує час, потрібний для тестування. У теорії все звучить достатньо райдужно та просто — але на практиці нам варто розуміти найкращі практики автоматизації.

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

Порада #1. Пишіть прогресивні тести замість роботи над регресією

Уявімо типову ситуацію: у команді є кілька automation-інженерів, що займаються UI/API-тестами. Вони працюють над регресією, зазвичай переписуючи мануальні кейси в автоматичні. Водночас у команді триває активна розробка та додається новий функціонал. AQA-інженери в цьому процесі практично не беруть участі, а девелопери не чекають на автоматичні тести. Функціонал випускають після тестування. У чому ж проблема?

Річ у тім, що регресія приносить менше користі, ніж тести активної розробки, тобто «прогресивні тести». Прогресивні тести — ті, що створюються разом з розробкою та є частиною DOD (Definition of Done) для наших user story. За такого підходу ми не випускаємо фічу без автоматизованих тестів.

Проблеми регресії

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

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

З висоти пташиного польоту цей процес виглядає приблизно так:

Інженер, який намагається закінчити автоматизацію регресії та наздогнати розробників

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

Що робити, якщо не вистачає часу на регресію? Таке теж можливо, адже AQA-інженерів зазвичай менше, ніж девелоперів — іноді навіть у декілька разів. Може бути складно встигати за розробкою, не кажучи вже про регресію.

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

Переваги прогресивних тестів

За прогресивної автоматизації ми не закриваємо user story, доки тести не написані. Це має низку переваг:

  1. Код одразу пишеться з урахуванням автоматизації, одразу додаються потрібні automation id (якщо ми говоримо про тести Selenium). Усі потенційні недоліки ми знаходимо на тому етапі, де їх ще легко виправити.
  2. Тести на будь-якому рівні допомагають знайти проблеми в архітектурі та сприяють кращому дизайну коду. Це дуже помітно на рівні юніт-тестів: якщо у тебе спагеті-код, то ти ніяк не напишеш до нього хороші юніт-тести. Часто сам факт присутності юніт-тестів у проєкті покращує дизайн коду. Такий самий принцип працює і на вищому рівні тестів. API- чи UI-тести допомагають знайти високорівневі проблеми архітектури цілої аплікації. Наприклад, якщо наші послуги не ізольовані правильно, то складно їх окремо протестувати і зробити мокапи. Це можна швидко знайти за допомогою тестів. А от працюючи лише над регресією, ми дізнаємося про це надто пізно.
  3. Ми знаходимо більше дефектів та отримуємо значну впевненість у функціоналі, який випускаємо. Подумайте — де буде найбільше дефектів? У частинах аплікації, які перебувають під активною розробкою і постійно змінюються, або в тих, які вже випущені і практично не змінюються?
  4. Ми не витрачаємо багато часу на роботу зі старими мануальними тест-кейсами, які ми хочемо автоматизувати. Дуже рідко мануальні кейси пишуться з урахуванням автоматизації. Вони написані для людини, тому логічно не підходять для коду. Часто доводиться звʼязуватися з тестером, який їх написав, уточнювати подробиці, розбивати один великий кейс на кілька маленьких тощо. Усе це потребує зайвого часу та зусиль.
  5. Будь-які інші проблеми, які могли б перешкодити нам автоматизувати тести, будуть швидко усунуті. Візьмемо для прикладу дрібний 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 тощо.

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

Висновки

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

👍ПодобаєтьсяСподобалось14
До обраногоВ обраному6
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

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

Мануальные QA могут помогать создавать тест кейсы вместе с AQA, или заниматься exploratory тестированием. Но в общем должен быть тренд — как можно меньше мануальной работы и максимум автоматизации.
Да, протестировать мануальнее вроде как быстрее, но это только в короткой перспективе. Не лучше ли сразу автоматизировать чтобы потом не повторять ту же работу?

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

Тут нужно учитывать short term vs long term benefits.
В краткой перспективе, конечно, намного быстрее просто протестировать мануально. И действительно есть такие короткосрочные или маленькие проекты, где нет смысла инвестировать в автоматизацию.
Но в долгой перспективе, особенно если проект долго живёт, намного эффективнее писать сразу автоматы. Это займет дольше времени во время девелопмента, но в будущем это окупится не один раз. И это типичная ошибка которую допускают и я не советую ее повторять. Выглядит это так — проекты тестируют мануально, приводя похожие аргументы что это быстрее и легко, потом настпуает момент когда регрессия занимает слишком много времени, и тогда начинают вовлекать автоматизаторов. Но проект уже накопил очень много технического долга, а можно было сразу выбрать правильный подход с расчётом на будущее

Дам свої дві поради як перейти від мануального до сучасного тестування:
1) Звільняйте мануальних тестувальників! Просто скажіть: або ви автоматизуєте тест-кейси — або ми вас міняємо не того, хто це зробить. Бо нема більш консервативної людини, ніж мануальний тостер на великому проекті. Він звик роками робити одну і ту ж роботу — і отримувати за це гроші. І він буде робити усе аби так і залишалося: в тому числі казати що автоматизувати «неможливо» (для багатьох з манки — тостерів це насправді не можливо бо їх мізки не підходять опанувати навіть елементарне програмування).
2) Звільниться від QA взагалі! Мануальне тестування ви побороли ще на першому етапі. Отже зараз написання тестів — це програмування. А програмування девелопери зроблять швидше і краще! Тим більше що автор функціональности краще за усіх розуміє як вона працює. Якщо девелопери повинні писати юніт — тести, то чому б їм не написати також інтегрейшин, функціональні (автотести) та, можливо навіть тести навантаження?
Я працював на одну з топ-10 ІТ компаній де взагалі нема QA! Є Software engineer — людина, цілком відповідальна за планування, розробку, тестування і підтримку певної функціональності чи частини системи.

Я працював на одну з топ-10 ІТ компаній де взагалі нема QA! Є Software engineer — людина, цілком відповідальна за планування, розробку, тестування і підтримку певної функціональності чи частини системи.

А як у вас сапорт? Був завантажений запитами (чи, вибачаюся, може, багами?) від користувачів?

У той топ компанії сапорт — то окрема навіть не тіма, а офіси по усьому світу на тисячі робітників. Бо клієнтів мільйони.
Але там вміють рахувати гроші. Наприклад, є якась бага, яка виникає у 10% користувачів (наприклад аплоад «непідхожих» файлів). Пофіксити будь яку багу у такій системі — це кілька днів пошуків, 10 хвилин на виправлення, пів-дня на білд та деплоймент і ще декілька днів на регресію. При цьому інженер, який фіксить багу, не робить нових фічей — отже ще й збитки втрачених можливостей. І ще виправленої версії на проді доведеться чекати пів-року.
Замість цього людина на сапорті вибачиться, і за 15 хвилин допоможе клієнту обійти цю проблему. Виявляється що якщо баг можна обійти — то дешевше навчити користувачів його обходити!
І це ми не кажемо про тисяці багів, які є, але ніхто на них не скаржиться. Бо, як відомо, 80% користувачів використовують лише 20% можливостей системи! Тобто може роками існувати непрацюючий функціонал — і усім це байдуже. Тоді навіщо на це витрачати гроші?

Перве — ТАК.
Друге — НІТ. Дев дивиться з точки зору «як має працювати», а QA — як НЕ має працювати. Це не погано і не добре, так, просто, є. Тому, дев повинен писати код, як має бути, а QA шукати, як не має бути і шо ся робє.

Тоже согласен с первым пунктом, со вторым есть риск — всё таки есть ценность в том что у QA другая перспектива чем у девелопера. Девелопер будет пробовать доказать что его код работает, а QA наоборот — ищет ошибки

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

Спасибо)
А вы вовлекли девелоперов в автоматизацию? Так обычно случается когда AQA не успевают за девами, их обычно меньше

Можу зробити висновок шо автору пощастило.
1. Вимоги не змінюються в процесі.
2. Настільки прості фічі, що автоматизація не впливає на капасіті команди/таймлайн делівері
3. Регресія займає мало людино-годин (бо інакше зменшення того часу є пріорітетом для зменшення костів для делівері)
4. Регрессія вже автоматизована і не валяється з технічним боргом.
Звідси питання: ви б порадили так робити на проектах де >30 сервісів/апплікух де ви тільки починаєте впроваджувати автоматизацію і регрессія займає близько 500 людино-годин?

1. Конечно меняются, таких проектов не бывает
2. Неправда, автоматизация всегда влияет на capacity, но это учитывается. Это инвестиция в будущее, вместо того чтобы сделать как можно быстрее в короткосрочной перспективе и накапливать технический долг
3. Регрессия в любом случае будет увеличиваться если проект не стоит на месте, и постоянно добавляются новые фичи. Идеальное решение — девелоперы пишут прогрессивные тесты, AQA — занимаются регрессией. Тогда и тех долг не увеличивается и регрессия сокращается
4. Пункт выше — не обязательно чтобы вся регрессия уже была автоматизирована

Прогрессивные тесты полезны и в таких проектах, конечно это требует больше усилий если у проекта большой технический долг. Но в любом случае подход «работаем только над регрессей» не решает эту проблему, т.к он будет постоянно увеличиваться от новых фич без автоматизации

Порада #2. Залучайте девелоперів до автоматизації

Перекваліфікація з automation qa в management, спідран any%

Ні для кого не секрет, що автоматизація тестів — невідʼємна частина будь-якого нетривіального IT-проєкту.

Вимушений сказати, що не так.

Минулий проект був геть нетривіальний (телефонія в роутері, 6 років розробки) і обійшовся без виділених авто- чи юніт-тестів (пару десятків тестів написала команда, що робить основну прошивку роутера).

Поточний проект має купу end-to-end тестів, але не має QA.

І я б не сказав, що в попереднього була вища концентрація багів за поточний.

Обидва широко вживають асерти, релізи не часті (але часті й не потрібні), обмежена (тисячі) кількість юзерів.

В 99% случаев сложные проекты получают много пользы от (правильной) автоматизации, разве что по каким-то техническим причинам это невозможно, что очень странно. Чтобы реально сделать сравнение и понять, нужно было бы сравнить как выглядел бы тот же проект с и без автоматизации. То что у вас не было автоматизации и вы справлялись, не значит что это самый оптимальный подход :)

Или до/после автоматизации
Часто именно так и бывает, в проект внедряют автоматизацию и сразу меняются метрики в лучшую сторону.

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

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

А ще — мануальні тестувальники дешевші та, часто, стабільніші, бо менший попит на ринку.

Понимаю, у меня не было опыта в embedded, может там действительно это немного иначе выглядит. Насчёт тех книжек, то интересно, учитывали ли они другие пользы от автоматизации кроме сокращения времени на регрессию.
Например то что намного легче делать рефакторинг, т.к. есть «safety net» из тестов, которые быстро найдут баги. Также то что автотесты запускаются регулярно, и фидбек будет намного раньше перед релизом, и нет такого что во время мануальной регрессии вдруг находятся десятки багов и срочно их все нужно успеть пофиксить. Мануальные тестеры физически не смогут постоянно делать всю регрессию вручную.
Но я конечно соглашусь, что чем чаще релизы в проекте тем автоматизация приносит еще больше пользы

Не помню — книжки читал 15 лет назад. Тогда еще рефакторинг не был в моде, кажется.

Автотесты тормозят смену функциональности — их надо переписывать. Если проект динамичный — смен функциональности будет больше, чем «пустых» рефакторингов без изменения поведения.

Автотесты дают быстрый фидбек на изменения, но их минусы:
* создание автотестов занимает существенное время, то есть, фидбек появляется намного похже в жизненном цикле проекта или фичи. Мануальщик дает первый фидбек мгновенно.
* хуже покрытие, потому что заскучавший мануальщик с плохой кармой сделает такое, что девелоперу в хэловинском кошмаре не наснится. А тесты всегда идут по одному пути.
Написать качественный рандомизированный фреймворк с генератором ошибок — надо еще уметь. А расшифровать, почему он зафейлился — та еще камасутра.

Да, тесты дают лучше предсказуемость релизов по срокам. При этом проекты, хорошо покрытые тестами, релизятся с тысячами багов (Хром какой-нибудь bugs.chromium.org/p/chromium/issues/list )

Это правда, но всё равно есть польза от участия AQA/QA (приготовление тест кейсов, ревью тестов), т.к. у тестеров другое мышление чем у девелоперов.
У нас в нынешнем проекте когда девелопер сам пишет тесты, то обязательно должно быть ревью от AQA

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