Рівні інтеграції коду та об’єм тестів

Тестування, як вчать книжки, відбувається на трьох рівнях:

• Integration testing
• System testing
• Acceptance testing

Класична V-модель рівням тестування ставить у відповідність стадії розробки ПЗ. Але у теперішніх умовах саме таку відповідність можна робити хіба що для певних продуктових проектів.
Більшість компаній (принаймні, мені відома) все ширше використовують agile, зокрема scrum, де розробка проходить ітераціями, коли на виході кожної має з’являтися "potentially shippable product increment" - готовий до випуску приріст фунціональності, як би самостійна частина ПЗ. Всюди панує Git Flow, модульність, де кожну фічу розробляють незалежною, із можливістю її повного вимкнення на продакшені.

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

Тому, логічніше поставити у відповідність рівням тестування - стан коду, що перевіряється, тобто гілку у системі контролю версій:

• (Feature) Integration testing  ->  feature code branch
• System (Integration) testing  ->  develop code branch
• (System) Acceptance testing  ->  master code branch

Для оцінки об’єму ручного тестування на кожному з рівнів, спробуймо визначити мету, чи фокус ручних перевірок.

(Feature) Integration testing - Інтеграційне тестування перевіряє, чи працюють частини зміненої функціональності так, як належить. На цьому етапі (чи можна сказати, у цій гілці) має відбуватися "притирання" нових частин. У першу чергу перевіряємо нову фічу, чи її модулі працюють між собою. Можемо також зробити смоук-тест системи загалом.

System (Integration) testing - Системне тестування відбувається у гілці, де інтегруються між собою різні фічі та модулі системи. Мусимо перевірити усі нові функції, а також базові старі. Чи не відбулася регресія функціоналу продукту загалом.

(System) Acceptance testing - Приймальне тестування приймає систему загалом. Тут фокус тестування/розробки змінюється - пріоритетом над новим функціоналом є стабільна база коду. Спершу ретельно перевіряються основні функції, навіть ті, що прямо не змінювались. Лише після того - нові фічі.

Як щодо автоматизованих тестів?
До вчора я мав думку, що їх об’єм теж треба змінювати в залежності від середовища, гілки та, може, інших факторів.
Але Pavel Makhrinsky нагадав мені кілька причин, чому автоматизовані тести мусять запускатися на всіх гілках і якнайчастіше, за що йому окремо дякую. (Переказую хід моїх думок; насправді Павло щось казав, але я його не дуже уважно слухав, як завжди під час гарячої дискусії)

1.  - Для чого ми автоматизуємо? - Щоб не робити щось руками по кілька разів. - Тобто, щоб робити щось багато разів? - Так! - Якщо це так, то які можуть бути виправдання для не запуску автотестів? Їх пишуть задля повторного запуску! То треба запускати! 
• Ви автоматизуєте для економії людиногодин! Невже варто тепер економити процесорогодини? Скільки місяців роботи ще одного тестового середовища ви можете оплатити за тижневу зарплатню автоматизатора?
2.  Тестувати треба починати якнайраніше! Це вивчають на першому занятті будь-яких курсів тестувальників. Для пояснення є навіть окремий графік - вартість виправлення вади залежно від стадії розробки або часу, коли відбувається виправлення. То навіщо чекати?! Запускайте усі доступні автотести у гілці фічі щодня! Щогодини!
3. - Наші тести дуже довго запускаються і їх у нас багато. Навіть якщо ми купимо 10 серверів, увесь сет буде проганятися 10 годин... 
1. Оптимізуйте тести. Знайдіть найдовші місця і зробіть щось із ними!
2. Не обрізайте набір тестів, обріжте набір даних на середовищах із інтеграційними гілками. Обрізати дані (контрольовано, забезпечуючі необхідну варіативність) - це контрольоване і обмежене зменшення покриття. Зменшити набір тестів, а тим більше значно зменшити, - це пряме збільшення імовірності пропустити баг на продакшон. Краще не треба.
3. Використовуйте SauceLabs чи подібні сервіси, запускате тести не на своєму середовищі, запускайте по 50 сесій на 1 інвайронмент, розпаралельте процеси.
4. В розумних книжках пишуть, що "В першу чергу треба автоматизувати end-to-end сценарії". Це так. Коли ви тільки починаєте автоматизацію. Це не значить, що коли у вас вже є багато автоматизованих тестів, треба запускати тільки end-to-end сценарії. Див. 2.

Краще знати, що у нас не має автоматизації, ніж думати, що вона є, але не запускати її.

Дякую за увагу!