Что такое пирамида тестирования, зачем она нужна и как её правильно применять?

Пирамида тестирования – это концептуальная модель, предназначенная для оптимального распределения тестов по уровням, с учетом их скорости, затратности и эффективности. В статье подробно рассматриваются три ключевых уровня пирамиды: юнит-тесты (основа), интеграционные тесты (средний уровень) и UI/E2E-тестирование (верхушка), а также объясняется их роль в обеспечении качества программного обеспечения. Анализируются основные виды пирамиды: классическая модель (Майк Коун) , песочные часы (Маурисио Аниче) , перевернутая пирамида и гибридный подход , применяемый в Agile и DevOps-проектах. Особое внимание уделяется перевернутой пирамиде , которая, несмотря на свою неэффективность в классическом тестировании, успешно применяется в геймдеве, мобильной разработке и AR/VR за счет фокуса на UI и пользовательские сценарии. Отдельный раздел посвящен связи пирамиды тестирования с DevOps и CI/CD , где объясняется, как правильное распределение тестов влияет на скорость развертывания, стабильность пайплайнов и качество продукта. Рассматриваются best practices для оптимизации тестирования, включая автоматизацию, параллельные запуски тестов, контрактное тестирование и интеграцию тестирования в CI/CD. В статье приводятся ссылки на авторитетные источники, такие как "Continuous Delivery" (Джез Хамбл, Дэвид Фарли), "Agile Testing" (Джанет Грегори, Лайза Криспин), "Game Testing: All in One" (Чарльз Шульц, Роберт Гребнер) и другие.

https://habr.com/ru/articles/888326/

#пирамида_тестирования #уровни_тестирования #интеграционное_тестирование #юниттестирование #системное_тестирование #приемочное_тестирование #devops #e2eтесты #api

Как защитить PROD от багов и себя от стресса

Сегодня хочу поговорить про баги на ПРОДе и о том как защитить команду от этого, ведь для реализации необходима помощь всей команды в выстраивании процессов разработки ПО. Прекрасное название этой статьи говорит само за себя - если не получается защитить команду от багов, то точно получиться защитить себя от стресса, ведь не все зависит от QA. Важно подсветить, что под багом подразумевается отличие ожидаемого результата от фактического. Мы ожидали, что при нажатии кнопки А будет окно В, но происходит совершенно другое. На схеме выше отображаются риски не только появления бага, но и не предусмотренных ошибок в виде программа не делает лучше, а только затрудняет использование. Первый риск: Идея попадает к аналитику Владелец продукта и аналитик на этапе проектирования тех. требований могут некорректно описать логику нового функционала (флоу). Заказчик имел ввиду одно, а по итогу в спецификациях совершенно другое. Решение данной проблемы может зависеть от правил взаимодействия с заказчиком в вашей команде. Второй риск: разработка по тех. требованиям Frontend и Backend разработчики берут задачи из бэклога в спринт, но в задаче может быть прикреплена устаревшая документация, ее может и вовсе не быть.

https://habr.com/ru/articles/804171/

#баги #тестирование #qa #qa_testing #разработка #testing #регрессионное_тестирование #приемочное_тестирование #процессы_разработки #команда_разработки