Тестування, як вчать книжки, відбувається на трьох рівнях:
- Integration testing
- System testing
- Acceptance testing
Класична
V-модель рівням тестування ставить у відповідність стадії розробки ПЗ.
Але у теперішніх умовах саме таку відповідність можна робити хіба що
для певних продуктових проектів.
Більшість компаній (принаймні, мені відома) все ширше використовують agile, зокрема scrum, де розробка проходить ітераціями, коли на виході кожної має з’являтися "potentially shippable product increment" - готовий до випуску приріст фунціональності, як би самостійна частина ПЗ. Всюди панує Git Flow, модульність, де кожну фічу розробляють незалежною, із можливістю її повного вимкнення на продакшені.
Таким чином, часто кожна фіча вже є окремим продуктом, що пройшов усі стадії розробки. І усі ці рівні тестування відбуваються, або мали б відбуватися, щодня.
Більшість компаній (принаймні, мені відома) все ширше використовують 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
