Для кого ця стаття?
Ця стаття розповість про те, як нам вдалося впровадити процес модульного тестування в команди, що працюють за класичною каскадною моделлю, а так само в команди з гнучкою методологією (agile). У нашій організації в будь-якій команді за загальний процес і наповнення спринту завданнями відповідають проджект менеджери, які також беруть участь в обговоренні видів тестування, необхідних під кожну задачу (спільний мозковий штурм.) і приймають кінцеве рішення. Тому моя стаття буде в першу чергу націлена на проджект менеджерів в командах (тільки тому що у нас вони займають саме таку роль) і всіх тих, хто за обов'язком служби займається схожими завданнями.
Для яких команд це підійде?
Я хотіла б показати вам процес впровадження модульного тестування для 2-х типів команд. У командах, які працюють за гнучкою методологією і в командах, які вибрали для себе каскадний стиль роботи.
Нижче на діаграмі показано схематичний пристрій команд за ролями:
З цієї схеми можна укласти те, що проджект менеджер, отримуючи завдання від власника продукту, погоджує їх з усіма учасниками процесу і за результатами включає (чи ні) їх у спринт.
Чим модульне тестування відрізняється від звичайного?
Тепер хотілося б розповісти що ж таке модульне тестування і як це реалізовано в нашому випадку:
Почну з того, що фахівцями модульного тестування є експерти у своїх галузях (під цим найчастіше розуміється конкретна система). Вони володіють найширшим бек граундом і необхідними технічними навичками. Кожна система вимагає своїх знань, десь це експертні знання Pl/SQL, десь конкретних мов розробки, а десь тільки багаторічний досвід роботи з конкретною системою. Ми не зачіпаємо front-end системи. Ми стоїмо на сторожі систем middle і back рівнів.
Напевно ні для кого не секрет, що розробка/доопрацювання будь-якої фічі включає в себе зміни в системах на різних рівнях. Кожен модульний тестувальник перевіряє новий функціонал тільки в рамках своєї системи. Тестується код, відповідність контрактів без застосування інтерфейсу. Вибірка тестових даних також відбувається не наосліп, а на основі принципу мінімального набору даних, що покриває максимальну кількість варіації вихідних параметрів. Для нас головне функціональна і технічна правильність написаного коду.
Перша відмінність модульного тестування від інших видів полягає в тому, що ми дивимося в код і орієнтуємося на незмінність зафіксованих контактів/вихідних параметрів. Якщо вони зафіксовані і не порушуються, то в процесі інтеграції систем фіча включається без проблем.
І друге - це суттєве зниження часу на тестування доопрацювання за рахунок експертизи. Інтеграційне тестування дивиться фічу цілком, ми ж розглядаємо її по частинах. Які завдання вирішує модульне тестування? Виходячи з усього вищесказаного можна підвести риску і відповісти на питання: які ж завдання вирішує модульне тестування?
- Тестування функціоналу в розрізі «своєї» системи.
- Технічне тестування коду на предмет не тільки обробки коректних даних, а й формування помилок і винятків.
- Передача функціоналу в інтеграційне тестування без критичних багів і блокуючих дефектів.
Це мабуть 3 основних моменти, які хотілося б виділити. Можна довго розмовляти про те, що помилки знайдені в процесі розробки або ж відразу після неї правляться швидше і менш болісно, але це ви і без мене знаєте. Так само як знаєте, що конкретно описаний погляд на рівні коду, розробником сприймається набагато простіше, ніж загальний погляд в рамках процесу.
Користь впровадження модульного тестування
Після прочитання всього цього виникне питання, а які плюси від впровадження модульного тестування можна отримати? Раніше я привела 2 схеми роботи команд, і тепер опишу стосовно кожної з них:
Команда, що працює за аджайлом методології. Нижче на схемі наведено місце модульного тестування в команді такого типу:
У даному випадку модульне тестування підключається на пізній стадії розробки, коли відбувається фактично вже «вилизування» коду, а вся основна функціональність розроблена. Модульному тестувальнику НЕ ТРЕБА починати в процес з початку, щоб глянути чи правильно виконана розробка на бек офісній системі або інтеграційній шині.
В аджайл команді всі учасники процесу до початку розробки знають які фічі вони взяли в спринт і розуміють як вони повинні працювати з точки зору кінцевого користувача. У підсумку ми приходимо до того, що час, який необхідно витратити, перш ніж фахівець приступить до тестування, близько до нуля. Нам не потрібно писати тест-кейси (не поспішайте дивуватися як же так, а як же передача знань тощо), ми відразу ліземо в код і приступаємо.
Після закінчення розробки ми отримуємо, що далі в тестування завдання йде вже перевіреним і таким, що не містить критичних багів (як з боку розробки, так і з боку аналізу). А що з некритичними? Такі баги зустрічаються, але вкрай рідко і зазвичай вони зав'язані на дуже специфічні тестові дані. Кожен такий кейс обробляється і заноситься у віки команди. Але це ще не всі плюшки, які виходять на виході!
При наявності в команді модульного тестування автоматизатора (а він у нас є!), на виході ми також отримуємо автоматизовані модульні тести! Це може бути набір тестів на будь-якому обраному тестовому фреймворку, або набір скриптів, які об'єднані в єдиний пак і викликаються на вимогу/розклад. Далі ці тести включаються в якийсь регрес пак, який містить в собі і автоматизовані модульні тести і тести відділу автоматизації (трохи пізніше ми розглянемо, чим вони відрізняються) і проганяється перед виведенням завдань спринту на бій. Що він нам дає думаю ясно і без моїх пояснень.
Також допускається, що підключення інтеграційного тестування паралельно з модульним тестуванням. Поки команда тестування через фронтові системи дійде до middle або back систем, тестування буде виконано вже більш ніж на 70-80%. Тобто. ніяких простоїв, пов'язаних з необхідністю правки коду, у них не буде. Це що стосується аджайл-команди.
Тепер подивимося як йдуть справи в командах, які працюють за каскадним принципом. Схема з включеним модульним тестуванням виглядає так:
Тут ми бачимо, що інтеграційне тестування починається після закінчення модульного. Це основна і принципова відмінність від вже розглянутого варіанту. Поки завдання не пішло з модульного тестування, інтеграційне тестування не починається. Готуються тестові сценарії, тестові дані.
В іншому процес не змінюється, ті ж дані на виході і ті ж плюшки, що і в agile командах.
Трохи вище я обіцяла поговорити про те, чим же відрізняються автоматизовані модульні тести, від автотестів команди автоматизації. Відмінність дуже проста і на поверхні. У 99% команда автоматизації автоматизує не конкретне доопрацювання, а процес.
Розглянемо на прикладі запиту інформації по карті через інтернет банк. Команда автоматизації пише кейс на рівні фронту (логін/перехід на вкладку/вибрали карту/натиснули кнопку запросити баланс) Всі ми знаємо скільки за часом буде виконуватися такий тест. А на виході ми отримаємо або є інформація, або її немає. У дуже рідкісних випадках ми отримаємо розуміння в якій системі/якому функціоналі сталася помилка.
Що з автоматизованими модульними тестами? Беремо той же приклад. Тест написаний на інтеграційний рівень, якому на вхід подається заповнений контракт (витягується з фронтової системи), далі відбувається трансформація, виклик системи джерела, обробка результатів і формування відповіді для системи приймача. У кожній точці стоїть перевірка. Залишилося перевірити, а чи точно все що треба повернула система джерело? Далі ви знаєте рішення даної загадки. Тим самим ми отримуємо не один, а два тести, які виконуються в кілька разів швидше і дають вичерпні знання в разі помилки. Не витрачаємо час на аналіз і розбір логів.
Як впровадити модульне тестування?
Погодьтеся, що простої цілої команди протягом скільки-небудь тривалого часу це вже катастрофа? Тому основна користь від впровадження проміжного етапу модульного тестування в команду досить очевидна. Залишилося тільки донести її до всіх учасників процесу і зацікавлених в кінцевому результаті осіб.
Для початку потрібно прийняти як даність, що не всі розуміють що взагалі за звір - модульне тестування. Необхідно провести деяку роз'яснювальну роботу серед команди і доступно викласти все те, що розглядалося вище з приводу відмінностей такої команди від класичних тестувальників.
Після підготовчої роботи основне завдання - домогтися впровадження підходу з модульним тестуванням хоча б у тестовому режимі, виділивши на це невелику частину ресурсів.
Після проведення кількох показових спринтів з новою формацією команди доказами ефективності такого підходу слугуватимуть:
- Знайдені на етапі модульного тестування дефекти. (тут можна провести аналогії з раніше знайденими дефектами того ж рівня і показати різницю в часі простою команди до моменту їх усунення)
- Якість переданого в інтеграційне тестування функціоналу.
- Реакцію розробників, з якими будуть говорити зрозумілою їм мовою.
- У разі додавання до процесу модульного тестування автоматизації - готові автоматизовані модульні тести, що дозволяють у майбутньому уникнути частини ручних перевірок функціоналу.
Висновок:
У підсумку, по завершенні всіх перерахованих вище операцій з впровадження, модульне тестування має стати невід'ємною частиною процесу, яка дозволить:
- Скоротити кількість пропущених дефектів.
- Прискорити процес виводу нового функціоналу до кінцевого користувача.
- Амортизувати процес взаємодії між командами ручного тестування та розробкою.
- Створити та підтримувати накопичувальну базу низькорівневих автотестів, що не залежать від змін інтерфейсної частини.
