[Тестирование IT-систем, DevOps] Software Developer In Test: как мы отказываемся от регрессионного тестирования
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Сегодня подробно расскажем о том, как мы трансформируем процессы тестирования: внедряем стандарты автоматизации и встраиваем автоматические тест-планы в процесс разработки. В начале прошлого года мы в True Engineering сформулировали корпоративную стратегию «Общего инжиниринга», в рамках которой мы разрабатываем свою базу подходов и стандартов и унифицируем рабочий процесс. Мы разработали единые требования к ведению проектов, а также к архитектуре, развертыванию и поддержке наших продуктов.Для оптимизации процесса тестирования, основной целью которой было сокращение time-to-market (TTM) продуктов, мы взяли на вооружение концепцию SDET (software developer in test). Она предполагает, что QA-инженер сопровождает продукт на протяжении всего жизненного цикла, а не подключается к тестированию в самом конце. Такой подход гарантирует нам не только снижение времени на тестирование, но и непрерывный контроль качества.Как мы внедряем SDET в работу наших командSDET в нашем понимании – это определенный набор функций от составления общей стратегии тестирования до написания автоматических тестов и ручного тестирования, если это потребуется. Эти функции можно отдать отдельному специалисту, но мы выбрали другой вариант – распределить их внутри наших команд.Общие требования к процессу тестирования для всех команд
- Регрессионный чек-лист в Azure DevOps - встроен в CI/CD;
- Набор автотестов, покрывающих регрессионный чек-лист;
- Отчеты в разрезе регрессионного чек-листа по результатам прогона;
- Составление чек-листа до начала разработки фичи;
- Разработка автотестов по чек-листу;
- Метрики покрытия тест-планов автотестами.
Кастомизация пайплайнов Azure DevOpsПайплайны Azure DevOps позволяют запускать автоматические тесты и получать по ним отчет. При этом было непонятно, как сопоставить этот отчет с чек-листом и сформировать его в нужном для нас виде. Поэтому мы разработали кастомное расширение для Azure DevOps, которое ассоциирует автотесты и тест-кейсы.
Как наши команды внедряют принципы SDET в свою работу
- Силами разработчиков настраивают тестовое окружение и пайплайны Azure DevOps;
- Определяют типы автотестов для покрытия кода (unit-тесты, интеграционные, сценарные);
- Учатся писать соответствующие типы тестов по нашим стандартам;
- Составляют план по написанию автоматических smoke-тестов для проверки ключевых функций;
- Настраивают отчеты по автотестам на основе тест-планов;
- Прорабатывают дорожную карту и план по внедрению SDET в проекте, согласовывают с заказчиком и включают соответствующие задачи в спринты;
- Выбирают и настраивают инструмент для измерения покрытия кода (Sonar Qube, JaCoCo или Cobertura). Актуально только для Unit-тестов - задача состоит в том, чтобы контролировать и поддерживать необходимую степень покрытия кода.
Покрытие кода автотестами – процесс, который может длиться бесконечно, и подходить к нему нужно адекватно. Мы всегда тщательно рассчитываем объем нужного покрытия/ критичность покрываемых функций/затраты на него. Во-первых, не все фичи в принципе хорошо тестируются автотестами. Например, фичи с монотонной, понятно описываемой логикой долго и муторно тестировать вручную, но для автоматизированного тестирования это идеальный вариант. В то же время небольшие доработки вроде изменения цвета на одной кнопке проще будет проверить руками.Во-вторых, наш опыт показывает, что уровень автоматизации должен быть достаточно высок, но приблизиться к 100% он может только на продуктах, которые не развиваются. В условиях, когда рынок и бизнес почти мгновенно реагируют на новшества, продукты должны быть гибкими и проактивными. TTM и возможность изменять продукт под новые идеи и вызовы играют здесь ключевую роль.
===========
Источник:
habr.com
===========
Похожие новости:
- [Системное администрирование, *nix, DevOps] В поисках идеального DevOps. Кого сейчас ищут на рынке IT?
- [Тестирование IT-систем, Usability, Аналитика мобильных приложений, Законодательство в IT, IT-компании] Тинькофф, Я вас люблю и ненавижу…
- [Системное администрирование, DevOps, Микросервисы, Kubernetes] Что такое service mesh, когда внедрять, альтернативы Istio и другие ответы экспертов с АМА-сессии Слёрм по service mesh
- [Управление персоналом, Карьера в IT-индустрии, DevOps, Удалённая работа] «Изменить настройки в голове гораздо сложнее, чем на сервере». Как мы ищем инженеров в Southbridge
- [Тестирование IT-систем, IT-стандарты, Учебный процесс в IT, IT-компании] Управляемое тестирование: с чего мы начинаем, чтобы не было мучительно больно
- [.NET, C#, DevOps] Подводные камни сбора метрик в Windows (часть 1)
- [Тестирование IT-систем, Go, Tarantool] Как я сократил код для нагрузочного тестирования в три раза
- [DevOps, Облачные сервисы] Бесплатный курс «Инженер облачных сервисов Yandex.Cloud» от Яндекс.Практикума и Yandex.Cloud
- [Работа с видео, Amazon Web Services, DevOps, Google Cloud Platform] Облачная WebRTC CDN: сколько стоит, где разместить?
- [Работа с видео, Amazon Web Services, DevOps, Google Cloud Platform] Cloud services for WebRTC CDN: How much does it cost? Where to place it?
Теги для поиска: #_testirovanie_itsistem (Тестирование IT-систем), #_devops, #_software_developer_in_test, #_software_development_in_test, #_testirovanie_itsistem (
Тестирование IT-систем
), #_devops
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 25-Ноя 05:15
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Сегодня подробно расскажем о том, как мы трансформируем процессы тестирования: внедряем стандарты автоматизации и встраиваем автоматические тест-планы в процесс разработки. В начале прошлого года мы в True Engineering сформулировали корпоративную стратегию «Общего инжиниринга», в рамках которой мы разрабатываем свою базу подходов и стандартов и унифицируем рабочий процесс. Мы разработали единые требования к ведению проектов, а также к архитектуре, развертыванию и поддержке наших продуктов.Для оптимизации процесса тестирования, основной целью которой было сокращение time-to-market (TTM) продуктов, мы взяли на вооружение концепцию SDET (software developer in test). Она предполагает, что QA-инженер сопровождает продукт на протяжении всего жизненного цикла, а не подключается к тестированию в самом конце. Такой подход гарантирует нам не только снижение времени на тестирование, но и непрерывный контроль качества.Как мы внедряем SDET в работу наших командSDET в нашем понимании – это определенный набор функций от составления общей стратегии тестирования до написания автоматических тестов и ручного тестирования, если это потребуется. Эти функции можно отдать отдельному специалисту, но мы выбрали другой вариант – распределить их внутри наших команд.Общие требования к процессу тестирования для всех команд
Как наши команды внедряют принципы SDET в свою работу
=========== Источник: habr.com =========== Похожие новости:
Тестирование IT-систем ), #_devops |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 25-Ноя 05:15
Часовой пояс: UTC + 5