Home

Автор: Ли Хокинс (Lee Hawkins)
Оригинал статьи
Перевод: Ольга Алифанова

Это третья часть из цикла статей, в котором я отвечу на самые распространенные вопросы о тестировании согласно результатам автодополнения в поисковых системах.

В этой статье я отвечу на вопрос "Когда должно начинаться тестирование?" (и связанный с ним вопрос "Когда тестировать?").

Самое время дать ответ на этот вопрос, потому что сейчас в отрасли много шума про "сдвиг" тестирования не только влево, но и вправо. Идея "сдвига влево" в том, что тестирование должно больше сдвигаться к началу (и продолжаться до завершения) цикла разработки, а сдвиг вправо – про тестирование "на проде" (то есть после того, как ПО вышло в релиз и используется пользователями). Мне кажется, что в середине образовался зазор, где раньше выполнялась большая часть тестирования (на самом деле, возможно, она и сейчас там) – тестирование готового продукта людьми до того, как он выйдет в релиз.

Начнем с того, что мы понимаем под тест-деятельностью, и кто ей занимается.

Если у команды есть отдельные тестировщики, то они могут участвовать в дизайн-митингах и задавать вопросы о том, как на самом деле действуют пользователи. Они могут изучать юзер-стори (и другие заявления о том, как должно работать ПО) и искать несоответствия и прочие проблемы. Тестировщики также могут сотрудничать с разработчиками, помогая им генерировать идеи для юнит- и API-тестов. Умеющие программировать тестировщики могут работать в паре с разработчиками, локально тестируя новую функциональность еще до того, как она формально попадет в билд. Если в команде тестировщиков нет, этим и многим другим будут заниматься разработчики – возможно, при помощи внешнего тренера по качеству/тестированию, если организация работает по такой модели. Вся эта деятельность выполняется до того, как система готова к тестированию целиком, поэтому это именно то, о чем, возможно, сейчас говорят как о "сдвиге влево".

На "сдвиг" тестирования влево, судя по всему, сильно влияет движение Agile. Практики вроде Дженет Грегори и Лизы Криспин написали книги по Agile-тестированию, раскрывающие многие похожие темы, но не описывающие их как "сдвиг влево". Идея, что критическое мышление тестировщиков может принести пользу с самых ранних стадий разработки, кажется мне достаточно здравой. Однако термин "agile-тестировщик" я воспринимаю странным – предпочитаю думать о тестировании как о тестировании как таковом, без "agile" в качестве контекста (этот контекст позволяет сдвиг влево, в то время как другие подходы к разработки могут усложнить этот сдвиг или сделать его невозможным).

В более "традиционных" подходах к разработке (а также в дисфункциональных agile-командах) тестирование сдвигается к концу цикла (спринта/итерации), когда создана "готовая к тестированию" версия ПО. Тестирование в этой точке очень значимо и требуется даже тогда, когда выполнена деятельность "сдвига влево". Если тестирование в этой точке только начинает свою работу, есть высокий шанс накопления проблем, которые можно было заметить раньше, и решение этих проблем на таком позднем этапе может быть куда сложнее (к примеру, может быть невозможно внести значительные архитектурные изменения). Чтобы снизить риск и изучить продукт, оценивая его по ходу разработки, тестировщики должны искать способы тестировать инкрементную интеграцию даже в таких ситуациях.

Идея, что "тестирование на проде" – это приемлемая и потенциально полезная штука, довольно нова в нашем деле. Когда я начинал карьеру тестировщика, предположение о тестировании на проде звучало как плохая шутка. В голову сразу приходит релиз Windows Vista от Microsoft. Конечно, с тех пор изменились и используемые технологии, и методы деплоя, поэтому не стоит удивляться, что тестирование релизного ПО нынче кажется более разумной мыслью. Наблюдая за реальной работой на проде, мы можем узнать многое из того, что никогда не сымитируем в дорелизных окружениях, а автоматический мониторинг и откат дают нам возможность "отозвать" плохую версию куда быстрее – это вам не забирать назад миллионы 3,5-дюймовых дискет! Подход "сдвига вправо" может дать нам ценную тест-информацию, но, повторюсь, он не заменяет другое тестирование, выполняемое в ходе цикла разработки.

Думая о том, когда должно начинаться тестирование, полезно шире мыслить о том, что такое "тест-деятельность" в отрыве от исключительно системного тестирования полного продукта, а также ясно представлять себе тест-миссию. Тестирование должно начинаться настолько рано, насколько это имеет смысл в вашем контексте (к примеру, вы, возможно, начнете тестировать в agile-окружении раньше, чем при водопаде). Разные типы тестирования могут стартовать в разное время, и помните, что критический подход к юзер-стори, дизайну, и т. д. – это тоже тестирование. Используйте информацию с прода, чтобы узнать о том, как приложением пользуются реальные люди, и применяйте ее к своему дорелизному тестированию.

В качестве заключения советую вам бороться за возможность тестировать ПО до релиза с подключением людей (а не только полагаясь на набор "зеленых" результатов автотестов) – неважно, сдвигается ли ваша команда влево, вправо, или вообще не танцует.

Обсудить в форуме