План уроку:
Що таке регресія
Мета регресійного тестування
Підходи у регресійному тестуванні
Коли проводити регресійне тестування
Автоматизувати чи не автоматизувати
План уроку
• ЧЕК-ЛИСТ – це тестовий документ, який описує, які функції мають бути перевірені. Організований у вигляді списку завдань, функцій, які необхідно протестувати
• TEST CASE – це тестовий артефакт, що описує сукупність кроків, конкретних умов та параметрів, необхідних для перевірки реалізації тестованої функції або її частини.
• ТЕСТ-СЬЮТ – це набір тестів-кейсів, які об'єднані за загальним сенсом.
• СЦЕНАРІЙ ТЕСТУВАННЯ — послідовність дій над продуктом, які пов'язані єдиним обмеженим бізнес-процесом використання, і відповідних їм перевірок коректності поведінки продукту під час цих дій.
Регресійне тестування
Цілі регресії
Головна мета:
Забезпечення якості системи після змін в одній її частині.
Додаткові цілі:
• перевірка нового функціоналу у складі вже сформованої робочої системи.
• забезпечення якості ПЗ перед релізом.
Планування регресії
Позитивне тестування – дозволяє перевірити, чи працює система в нормальних умовах так, як задумувалося.
Позитивні тести – перевіряють, що те, що має працювати - працює.
Що нам потрібно знати для проведення цього виду тестування?
Що тестувати?
Чим тестувати?
Коли тестувати?
Підходи у виборі тестів
Аналіз впливу (Impact analysis) - Слід визначити функціонал або сукупність функцій, області (affected areas), які зазнали змін та сконцентруватися на них.
Аналіз ризиків (Risk analysis) - Шляхом аналізу визначаються модулі або області, де можуть виникнути дефекти
Вибір критичних сценаріїв (Critical users scenarious) - Виділяємо найбільш важливі/використовувані сценарії для користувача
1. Аналіз впливу (Impact analysis)
1. Визначте компоненти/області для нового функціоналу.
2. Проаналізуйте, які компоненти взаємодіють із новим функціоналом.
3. Проаналізуйте, яка загальна поведінка застосунку може бути схильна до впливу – продуктивність, UI, мобільна версія.
4. Поспілкуйтеся з розробником про неявні залежності функціоналу в коді.
2. Аналіз ризиків (Risk analysis)
Який функціонал матиме більше дефектів?
1. Розроблений поспіхом, новим розробником, недосвідченим розробником.
2. Не покритий модульними тестами.
3. Функції зі складною бізнес-логікою або технологічним стеком.
4. Функціонал, у якому зазвичай знаходимо багато дефектів.
Такі області мають бути охоплені регресійним тестуванням!
3. Вибір критичних сценаріїв (Critical users scenarios) тестування. Безпека
• Розробляйте end2end тести, щоб покрити основні сценарії використання застосунку.
• Сфокусуйтеся на позитивних сценаріях.
• Проведіть рев’ю сценаріїв користувачами / BА.
• Отримайте статистику щодо того, які компоненти використовуються більше, якщо ви можете це зробити.
Чим тестувати?
Об’єм регресії
• Як правило, у команді QA є готовий список тестів для обсягу регресії, який постійно оновлюється.
• Набір тестів для регресії може включати як функціональні, так і нефункціональні тести.
• Поширеною практикою є розподіл функціоналу між членами команди, які раніше не працювали з даними функціоналом для уникнення ефекту пестициду.
• Також, як і в регулярному тестуванні, важливим є розставлення пріоритетів при регресійному тестуванні. Це скоротить набір перевірок.
Склад тестів для регресії
• Безпосередньо саме регресійне тестування – повторне виконання всіх тестів, написаних і проведених раніше. Вони виконуються за вже існуючими тест-кейсами незалежно від того, чи були в ході їх проходження знайдені баги, чи ні.
• Тест-кейси після ретестінгу. Проводяться для перевірки виправлення виявленого та відкритого раніше багу.
• Тестування в новому білді вже виправлених багів у старих білдах. Це виконується для того, щоб перевірити, чи оновлення білда не відновило старих дефектів
Як організувати регресійну бібліотеку
1. Не всі нові тести слід додавати до бібліотеки регресії.
2. Структура важлива:
• за компонентами продукту;
• за рівнем тестування: Smoke, Acceptance, Regression
• наскрізні сценарії (End-to-end scenarios).
3. Пріоритети тестування повинні бути визначені, щоб у всієї команди було загальне розуміння.
4. Повинна бути визначена процедура підтримки бібліотеки регресії: тести повинні оновлюватися та видалятися.
5. Складіть матрицю простежуваності до автоматизованих тестів
Автоматизація регресійного тестування
Що автоматизувати:
•димове тестування;
•тести, які ви повторюєте кожні 1-2 тижні;
•бекенд-тести (набагато довше запускати вручну);
•однакові дії з користувацьким інтерфейсом, тести керовані даними;
Що не треба автоматизувати:
•Тести що потрібні не часто – на приклад раз на 3-6 місяців.
•Низькоприірітетні тести.
Коли тестувати?
Коли проводити регресійне тестування
• Після кожної відправки коду (commit) розробником?
• Після кожної розгортання (deployment) на якомусь з середовищ?
• В кінці спринта?
• Перед релізом?
Типова стратегія регресійного тестування
Q&A
Дякую всім за заняття!🙌🏻
❗️🎓Урок 7. Регресійне тестування
Нагадую, що дедлайн здачі домашніх робіт – до наступного уроку.
Якщо виникають складнощі, пишіть, допоможу із задоволенням 😌
Запис лекції тренер опублікує трохи пізніше 🖥
Не забудьте повторити матеріал та підготуватися до наступного уроку📚
Успіху і до зустрічі!🤩
Опис завдання:
Валідатор паролів повинен перевіряти вхідний пароль на відповідність заданим правилам безпеки.
Правила безпеки для паролів:
Пароль повинен містити щонайменше 8 символів.
Пароль повинен містити щонайменше одну велику літеру.
Пароль повинен містити щонайменше одну малу літеру.
Пароль повинен містити щонайменше одну цифру.
Пароль може містити спеціальні символи (!, @, #, $, %, ^, &, *).
Завдання:
Визначте класи еквівалентності для валідатора паролів на основі правил безпеки.