Teamlead Roadmap

# Оптимизация количества тестирования

# Описание

Оптимизация тестирования — это выработка такой стратегии тестирования, которая позволит минимальными средствами снижать критичные риски по продукту.

# Почему ветка важна?

Менеджер:

  • Оптимизирует штат тестировщиков
  • Влияет на скорость доставки фичи до боя
  • Понимает, почему тестирование проводится так и занимает столько времени

Разработчик:

  • Понимает, что делают тестировщики и что от них ждать
  • Влияет на тестирование — от unit-тестов до testability

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

  • Понимает, что тестировать и насколько подробно
  • Чувствует меньше давления, что тестирование замедляет процесс работы команды
  • Участвует в тестировании вместе с командой

# Что будет, если её не делать?

  • Команда не будет понимать, сколько времени и сколько тестировщиков надо, чтобы снижать критичные риски в продукте:
    • Риск "раздувания" штата тестировщиков
    • Сложно планировать сроки, когда фича будет на бою
    • Непонятно насколько эффективно тестирование

# На кого может быть делегирована?

На процессных менеджеров или Scrum-мастеров. Частично делегируется на тестировщиков.

# Примеры плохого поведения

  • При оптимизации тестирования не учитываются краткосрочные и долгосрочные риски
  • За оптимизацию отвечает только отдел тестирования
  • Обвинение тестировщиков, что они медленно делают работу, вместо исследования процесса
  • Команда не понимает, что тестирование делает в текущем процессе
  • Оптимизация фокусируется только на скорости тестирования

# Примеры хорошего поведения

  • Оптимизация начинается с того, что команда и бизнес понимают, зачем им тестирование
  • Оптимизация тестирования затрагивает весь процесс разработки — от постановки задач до эксплуатации
  • Команда понимает как работать с дополнительными рисками, которые возникают при оптимизации тестирования

# Способы прокачки

# Практика

Прежде чем оптимизировать то тестирование, которое у вас уже есть, или строить новый процесс, поймите зачем вам нужно тестирование и нужно ли на самом деле?

Начните с того, что подумайте о рисках для вашего продукта. Опирайтесь на функциональные и нефункциональные требования. Например:

  • Что будет, если вы выпустите продукт с багом?
    • Насколько много ваших пользователей это затронет?
    • Насколько сложно будет пользоваться продуктом с этим багом? Будет ли это вообще возможно?
  • Что будет, если ваш продукт будет сложно поддерживать?
  • Что будет, если ваш продукт будет уязвим для взлома?
  • Что будет, если в вашем продукте будет сложно разобраться пользователям?
  • Как быстро вы поймёте, что у вас баг на бою и оцените, насколько он критичный?
  • Как быстро вы исправите баг, который нашли на бою?

Чтобы снизить эти риски, используйте три процесса — тестирование, проверку и мониторинг.

Тестирование — это процесс исследования и изучения продукта. Когда вы тестируете, вы узнаете как программа работает на самом деле, ну или не работает. Тестировщики не просто проверяют ТЗ, а используют всю свою креативность, опыт и знание продукта. Тестирование нельзя автоматизировать, как нельзя автоматизировать человеческое мышление (ну по крайней мере пока).

Проверка — подтверждение существующих ожиданий. Когда вы что-то проверяете — точно знаете, что должны получить, и убеждаетесь, что 2+2 все так же равно 4. Многие проверки можно эффективно автоматизировать.

Майкл Болтон сравнивает проверки с компиляцией программы, а тестирование — с программированием. Первый процесс формализован и проводится автоматически, для второго нужны люди и их знания и навыки.

Более подробно про тестирование и проверки — оригинал, перевод.

Мониторинг — процесс выявления проблем, которые возникают на бою у пользователей. Включите в него как технические показатели, так и показатели работы бизнеса. Важно, чтобы вы могли быстро среагировать на проблему — выкатить фикс или откатить проблемный код.

Используйте эти процессы все сразу или частично, в зависимости от ваших рисков.

Например, вы не прорабатываете детально ТЗ и рискуете не учесть что-то важное. Можно:

  • снизить риски за счёт тестирования — переложить на него тестирование требований, хранение знаний и выяснение как все работает на самом деле
  • принять эти риски, настроить мониторинг и реагировать уже на проблемы, которые могут возникнуть на бою.

Если же вы решили прописать все в ТЗ, то можно меньше тестировать и больше отдать на проверки — как ручные и автоматические. Такое часто бывает в заказной разработке на государственных проектах — утверждённое ТЗ и программа приёмо-сдаточных испытаний.

Если вы знаете, что определённые проблемы будут критичны для вашего бизнеса, то нужно тщательно тестировать и проверять места, в которых они могут быть. Например, важно, чтобы пользователи могли оплатить ваш продукт. Или баги могут подорвать доверие к вашему продукту, например если вы разрабатываете платёжную систему. Важно помнить, что нельзя протестировать абсолютно все и на 100% знать, что все работает. Но можно снизить риски.

Когда вы разрабатываете MVP — вам надо убедиться, что ваш продукт жизнеспособен. А значит можно ограничиться минимальными проверками.

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

# Видео

# Консультации

# Теория

# Статьи

# Подкасты

← Пирамида тестирования →