MVP. Как выводить на рынок товары и услуги, которые нравятся покупателям - Дэн Олсен

проверяет, работает ли новая или улучшенная функция так, как ожидалось, – согласуется ли она с соответствующими пользовательскими историями и проектными артефактами. В некоторых случаях реализация продукта отклоняется от проекта. Часто это происходит из-за ошибок или недопонимания, но возможно также, что разработчик внес свои корректировки намеренно, поскольку реализовать поставленную перед ним задачу в точном соответствии с указанными требованиями оказалось невозможно, либо он или она выбрали решение, требующее меньших затрат. Даже в тех случаях, когда продукт реализован в точном соответствии с техническим заданием, впоследствии члены команды могут осознать, что они упустили из виду или не предусмотрели нечто важное. Любая из этих и подобных им проблем должна быть выявлена на этапе валидационного тестирования.

Второй из требующих проверки аспектов состоит в том, чтобы ни одна из имеющихся функциональных возможностей продукта не была непреднамеренно нарушена в процессе создания новой или улучшения существующей функции. Другими словами, после добавления в состав продукта функции D вы хотите убедиться, что функции A, B и C работают так, как они работали до внедрения функции D. Это называется регрессионным тестированием. В этом контексте слово «регресс» означает «ухудшение текущего состояния», то есть внесение в существующий функционал ошибки, которой там раньше не было.

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

Разработка через тестирование

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

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

Непрерывная интеграция

Многие команды для ускорения разработки продуктов применяют метод непрерывной интеграции. Чтобы объяснить, что это значит, нужно начать с описания того, как разработчики программного обеспечения осуществляют управление создаваемым кодом. Обычно для этого используют систему контроля версий, позволяющую отслеживать и управлять всеми вносимыми в программный код исправлениями. Контроль версий также упрощает процесс восстановления кодовой базы до любого предшествующего состояния, благодаря чему нежелательные изменения могут быть отменены. На момент написания этой книги, пожалуй, самой популярной системой контроля версий для Agile-разработки является Git.

Когда разработчики собираются внести в код изменения или дополнения, они обращаются к актуальной стабильной версии кодовой базы, которую называют «мэйнлайн» или «транк». Системы контроля версий позволяет разработчикам создавать отдельные копии транка, которые они могут изменять, не затрагивая оригинал. Когда разработчики завершают создание новой функции, они фиксируют внесенные изменения в системе контроля версий. Прежде чем это сделать, каждый разработчик должен провести модульное тестирование своего кода, написав соответствующие тестовые примеры и проведя на них проверку. Поскольку в команде несколько разработчиков работает параллельно, каждый из них вносит свои изменения. Перед добавлением нового кода в транк все изменения объединяются или «интегрируются» для создания новой версии целого продукта. На этом этапе, чтобы убедиться в работоспособности обновленного продукта, проводят интеграционное тестирование.

Исторически сложилось, что такая интеграция, как правило, производилась вручную. Вместе с тем метод непрерывной интеграции подразумевает применение автоматизированного процесса сборки последних изменений кода для создания новой версии продукта. Новая сборка тестируется в автоматизированном режиме, и разработчики получают уведомление о том, какие тесты прошли успешно, а какие нет. После устранения возникших проблем и успешного прохождения всех тестов происходит развертывание кода. Разные команды проводят непрерывную интеграцию с различной периодичностью: некоторые делают это на ежедневной основе, другие – несколько раз в день, а третьи – после каждой фиксации кода. Непрерывная интеграция помогает командам быстрее выявлять и устранять проблемы, что в конечном счете повышает скорость выполнения итераций. Это соответствует принципу бережливого производства, согласно которому выявление дефектов должно происходить на как можно более ранней стадии, чтобы свести потери к минимуму. Вместо того чтобы позволять проблемам накапливаться, непрерывная интеграция дает возможность приступить к решению любой проблемы сразу после ее возникновения. Еще одним преимуществом данного метода является то, что ваш программный код всегда находится в состоянии, пригодном для выдачи, что обеспечивает команде возможность предоставления обновленного продукта заказчику в любое время. Естественно, что эффективность применения непрерывной интеграции в значительной мере зависит от масштаба охвата функционала продукта тестовыми примерами: чем он шире, тем лучше.

Непрерывное развертывание

Многие команды, применяющие непрерывную интеграцию, также практикуют непрерывное развертывание, когда код, успешно прошедший все тесты, развертывается автоматически. Некоторые компании выполняют автоматическое развертывание в промежуточной среде (внутренняя среда,