Мої нотатки зі статті “Change-Driven Testing” за авторством Dr. Sven Amann and Dr. Elmar Jürgens
Примітка автора. Рекомендую ознайомитись із першоджерелом.
Проблема
тестування повільне, тому люди пишуть багато автотестів
автотестів стає дуже багато, на кожен PR не запустиш усі
нічні прогони тестів допомагають частково: бо треба знайти саме той коміт, що зламав master
автотести вирішують питання efficiency (продуктивності), але залишається питання effectiveness (результативності чи корисності)
Change-Drive Testing
Суть - концентрація на тестуванні змін. Підхід - заснований на даних, як і Business Intelligence. Тому й дістав назву Test Intelligence.
Дані збираються:
з системи контроля версій
з тікет системи (JIRA)
профайлерів для покриття коду
систем менеджменту тестів
Основна ідея Change-Driven testing - "Існуючі тести впадуть тільки, якщо виникнуть нові помилки. Нові помилки виникнуть, коли відбулися зміни в коді".
Пропонується тестувати в два етапи
Для продуктивності тестуємо тільки те, чого торкнулись зміни. Застосовуємо для цього Test Impact Analysis
Для результативності тестуємо усі можливі зміни. Для цього є Test-Gap Analysis.
Важливо! Під змінами розглядають саме зміни в поведінці чи функціональності, а не рефакторінг.
Test Impact Analysis (TIA)
Мета - знайти саме ті тести, що перевірять конкретні зміни в коді.
Test Impact Analysis проходить в два етапи
Крок вибору тестів (Test Selection step): визначаємо тести, на які вплинули зміни. Це можуть бути модульні тести в самому PR, а також усі, що використовують конкретний змінений метод.
Крок пріоретизації тестів (Test Prioritization step): використовуємо "жадібну" (greedy) еврістику - обираються тести, що покривають найбільше зміненого коду за одиницю часу.
Test Gap Analysis (TGA)
Мета - порівняти зміни в коді з сукупним тестовим покриттям та знайти таким чином зміни, що не покриті жодним тестом (test gaps).
Примітка автора. Test-Gap аналіз розкритий достатньо розмито. Треба напевне писати авторам з конкретними питаннями
Як результат, будується treemap
Обмеження, або чому підхід не "панацея"
обидва підходи TIA та TGA не враховують зміни в конфігурації та даних системи
TIA розраховує, що покриття стабільне - тобто кожне виконання тесту дає те ж саме покриття. Це працює для автотестів, але погано працює для ручного тестування
TGA не враховує наскільки ретельно була протестована зміна. Тільки - чи усі методи в конкретному PR були покриті.
Результати
До впровадження Test Impact аналізу - на кожен PR запускались тести на CI та фідбеку треба було чекати 45 хвилин.
Після впровадження Test Impact аналізу - 1.5 хвилини на перший тестовий запуск саме тих тестів, які потрібно плюс 45 секунд на ретест після фікса проблеми.
автори використовують Test-Gap аналіз для побудови treemap діаграм навіть при змінах на UI. Одразу позначено червоним місця, де потрібно додати тестів
Висновок
Виглядає доволі цікаво. До того ж - я точно знаю, що Test Impact аналіз працює й доволі успішно. Але треба докласти чимало зусиль, щоб додати його в проєкт. Деякі інструменти, типу Sealights “обіцяють” легку інтеграцію, але насправді не така вже вона й легка.
До того ж хочу зазначити, що Test Impact аналіз - може бути не тільки для автотестів. Це можна пробувати проводити вручну. Так само, як Test Gap аналіз.
