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

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

Опасность:

• Ответственность за качество кода делегирована на тестировщика.

• Сроки поставки кода зависят от тестировщика.

• Разработчик постоянно переключается с задачи на задачу

Ручное

Опасность:

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

• На тесты тратится много времени.

• Непрерывная поставка кода невозможна.

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

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

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

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

4. Максимальное время на тесты — 10 минут.
5. Используйте только атомизированные тесты, не зависящие от внешних обстоятельств.
6. Запускайте тесты сразу после коммита. Результаты исполнения тестов должны мгновенно приходить автору коммита.

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

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

‍

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

‍