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

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

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

Опасность:

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

Ручное

Опасность:

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

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

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

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

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

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

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

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

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

Смотреть все

Ikigai-гайд

Читать

Системный анализ и PDCA-цикл

Читать

Serverless

Читать

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

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

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

Контакты

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