Comments 3
Где тестирование документации ? Жизненный цикл программного обеспечения - не знаем ? Требования нужно тестировать. Чем раньше начнем тестировать , тем меньше затраты на переработку продукта. На основе требований пишутся код и тесты.
Я бы поправил название. Оно слишком громкое. А по факту, применимо исключительно к тестированию веб-приложений. Даже для desktop и mobile не очень подходит. Не говоря уже про более специфичные кейсы вроде embedded, medical, automotive, aircraft, etc.
Ещё бы неплохо больше ссылок на источники информации. Например, пирамида тестирования - взята из ISTQB Basic. Если заглянуть в syllabus advanced level. То там уже все ближе к реальности. Пирамида всегда строиться от архитектуры конкретного приложения. Колличество, слоёв между unit и system как раз от архитектуры зависит. У меня бывали проекты когда unit оборачивались в module, module оборачивались в component, component оборачивались в subsystem, а уже subsystem собирались в system. И везде свои протоколы коммуникаций.
Также, интересно посмотреть источник по sanity vs regression. У меня отложилось в памяти, что основная разница - это регрессия покрывает старый функционал, не тронутый последней итерацией. Т.е. тесты на писанные ранее. А вот sanity - это как раз тестирование последнего инкремента, а не просто абстрактного функционала. Именно того функционала, что был внесён/изменён в последнем спринте или более долгой итерации.
Неплохо было бы упомянуть мутационное тестирование и в целом то, что сами тесты нуждаются в проверках
Полное руководство по всем видам тестирования