Сьогодні сфера тестування програмного забезпечення вимагає від QA-інженера повної компетенції в TestOps та навичок розробки якісних автоматизованих тестів.
Це відбувається через стрімкий розвиток CI/CD та важливість роботи QA-інженерів з трубопроводами.
Але чому CI/CD має вирішальне значення для кожного тестувальника сьогодні?
На це питання є кілька відповідей:
- Можливість автоматичного запуску тестів;
- Контроль якості на основі Quality Gates;
- Створення якісного процесу випуску.
Як все виглядало до і після впровадження CI/CD.
CI/CD
Можливість автоматичного запуску тестів
Можливість запускати тести локально застаріла.
Тепер ми можемо запускати тести через CI/CD, оскільки це його основне завдання.
Уявімо, що у нас є DevOps і ми передали завдання редагування пайплайнів з тестами.
Таким чином, ми повністю ігноруємо можливість реалізації другого основного параметру СІ/КД - якості моніторингу на основі “Воріт якості”.
Контроль якості за допомогою “Воріт якості”
Що таке “Quality Gates”, або іншими словами - забезпечення якості програмного коду?
Уявімо, що весь програмний код - це замок.
Щодня команда розробників створює нові рядки коду для нових функцій, які можуть зламати замок.
Основне завдання тестувальників - перевірити функціональність кожної функції та зменшити ризик появи багів у готовому продукті.
Але в цьому випадку QA-лабораторія не має гарантії контролювати всі метрики, оскільки немає захисту від людського фактору (хтось не виконав завдання, хтось виконав, але не злив його у виробництво тощо).
Тільки використання автоматизованих тестів виправляє цю проблему.
Кожен наступний тест буде відповідати за виконання важливої метрики тестування.
Якщо не дотримуватися “меж” метрики, “ворота” будуть закриті і не проштовхнуть функцію в онлайн середовище.
І функція не буде додана до програмного коду, поки не будуть виконані всі тести, отже, всі потенційні помилки будуть знайдені і виправлені.
Етапи тестування КІ/КД
Щоб повністю автоматизувати тестування програмного забезпечення, нам потрібно розробити спеціальний список тестів для проходження пайплайну.
Для тестування ми можемо використовувати метод “Fail first”. У цьому випадку в першу чергу виконуються функціональні тести (функціональність збірки, стиль коду та виконання статичного аналізу).
Приклад конвеєра CI/CD
Зі збіркою все зрозуміло: якщо продукт не зібраний, функція не реалізована в продукті.
Процес стилізації коду слід перенести на CI/CD, щоб миттєво уніфікувати вимоги та не витрачати час на помилки стилю коду під час проведення рев’ю коду.
Статичний аналіз є важливим інструментом для аналізу якості створеного програмного коду. Він може виявити численні критичні помилки, які неодмінно призведуть до збоїв у функціонуванні програмного забезпечення.
Далі йдуть тести другого рівня: групи юніт-тестів з аналізом тестового покриття та контролем досягнення необхідних показників, а також системи інтеграції тестів з усіма доступними для аналізу звітами.
Крім того, можуть бути різні нефункціональні тести, такі як scr-тести, тести продуктивності, юзабіліті-тести та тести безпеки.
Основні вимоги до трубопроводів:
- Він повинен надавати максимальну кількість функцій, враховуючи вимоги відділу контролю якості;
- Час, необхідний для виконання конвеєра, не повинен сповільнювати розробку (зазвичай це займає до 20 хвилин).
Як CI/CD допомагає побудувати процес випуску релізів
Ci/CD не лише допомагає автоматично запускати тести та впроваджувати деякі метрики забезпечення якості програмного коду, але й дає можливість ручним тестувальникам побудувати якісний процес постійного релізу.
Іноді процес випуску програмного забезпечення є складним і залежить від численних ручних дій.
Іноді це повністю ручний процес: розробники створюють один артефакт, тестують збірку, а потім надсилають її відповідальному за запуск функції у виробництво.
Така структура роботи може містити численні вузькі місця - тільки уявіть, що може статися, якщо хтось із працівників піде у відпустку або захворіє.
Процес релізу кожної проектної команди виглядає абсолютно по-різному, але зазвичай він включає наступні кроки:
- У гілці git постійно запускається збірка продукту;
- Кожна збірка тестується всіма загальноприйнятими способами;
- Перевіряється реліз-кандидат продукту та виконуються фінальні тести;
- Якщо третій крок виконано успішно, реліз-кандидат переходить у виробництво.
Будь-яка сучасна система CI/CD може побудувати цей процес. Але вона має бути зручною як для команди розробників, так і для відділу тестування.
0 коментарів