Тестирование

Тестирование

Тестировщиком

Опасность:

  • Ответственность за качество кода делегирована на тестировщика.
  • Сроки поставки кода зависят от тестировщика.
  • Разработчик постоянно переключается с задачи на задачу

Ручное

Опасность:

  • Разработчик медленнее получает обратную связь от кода.
  • На тесты тратится много времени.
  • Непрерывная поставка кода невозможна.

Автоматизированное

DORA утверждает, что лучшие команды использую автоматизированное тестирование в 90% случаев.

Как тестировать в парадигме Continuous Delivery

  1. Откажитесь от асинхронной проверки качества, которая влияет на скорость выкладки на сервер.
  2. В code review используйте синхронные стратегии проверки качества: парное программирование, или стратегия незамедлительного code review.
  3. Используйте те виды асинхронного тестирования, которые не влияют на выкладку: проверку безопасности, полное регресс-тестирование, проверку удобства пользования.
  4. Собирайте обратную связь от написанного продукта в понятном разработчику виде. Разработчик должен анализировать логи ежедневно, используя инструменты визуализации логов.
  1. Максимальное время на тесты — 10 минут.
  2. Используйте только атомизированные тесты, не зависящие от внешних обстоятельств.
  3. Запускайте тесты сразу после коммита. Результаты исполнения тестов должны мгновенно приходить автору коммита.

Начните с этих автоматизированных тестов

  1. Статический анализ. Исполняется на рабочем месте разработчика (IDE) при сборке и в процессе разработки. Быстрый
  2. Юнит-тесты. IDE, при сборке или в процессе разработки. Быстрый.
  3. Функциональные тесты критического функционала. При сборке. Медленные.

Что компания Google говорит об автоматизированном тестировании

Другие статьи

Смотреть все

Принципы построения интеграций

Читать

Цели проекта

Читать

Фреймворк Cynefin

Читать

Ваша заявка отправлена успешно

Отправить снова

Базовый курс управления и построения IT-контура компании. Поток 05.09.23

Контакты

С вами свяжется модератор курса Алексей Клоков