Home

Автор: Деннис Мартинез (Dennis Martinez)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

«Когда начинать автоматизировать тесты?»

Мой краткий ответ на этот вопрос зачастую звучит так – «Найдите время на запуск процессов тест-автоматизации прямо сейчас». Ранее я бы сказал «как можно раньше», но теперь понял, что этот ответ открыт для интерпретаций. Значит ли это, что команде нужно бросить все и заняться тестированием? Или это значит, что нужно подождать, пока не появится возможность для работы над ним? Когда есть недопонимания, вопрос откладывается, и рано или поздно о нем забывают.

Однако «прямо сейчас» также не означает прямо сию секунду – поэтому ответ все еще туманен. Конечно, предпочтительно заниматься тестированием со старта разработки продукта (или максимально близко к старту), но для большинства компаний этот вариант не подходит. Как упомянуто ранее, у стартапа, как правило, есть вещи куда важнее, отъедающие тонны ресурсов. Разработка и запуск тест-автоматизации в начале требует времени и сил – в стартапе, пытающемся вырасти в компанию, нет ни того, ни другого.

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

Итак, когда же начинать тест-автоматизацию?

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

Вот в чем секрет: времени на начало автоматизации тестирования не будет никогда, пока вы ее не начнете

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

Не все автоматизированные тесты равноценны

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

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

Юнит-тестирование

Когда внедрять: как только началась разработка

Юнит-тестирование – одна из первых вещей, которые нужно рассмотреть, внедряя тест-автоматизацию в любом приложении. Юнит-тест – одна из наименьших – если не наименьшая – деталей продукта, которую команда может протестировать. Эти тесты легко писать, они быстро прогоняются и просты в поддержке. Прогон этих тестов не особо замедлит команду, а исправление сломавшихся из-за внутренних изменений тестов не займет у разработчика много времени. Ценность, которую продукт получает от юнит-тестов, значительно превышает небольшие усилия по их созданию и исполнению.

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

API-тестирование

Когда внедрять: как только у тестировщиков появляется доступ к API в тест/стейдж-окружении

Большинство современных приложений включают в свою экосистему какую-либо разновидность API. Иногда это внутренний API для взаимодействия с другими приложениями, а иногда – публичный API, доступный для клиентов извне организации. Вне зависимости от типа доступа, у API, как правило, высокая бизнес-ценность, и они требуют долгосрочной стабильности. Любой API выиграет от автоматизированного тестирование, которое внедряется, как только команда тестирования получает доступ к API в тест/стейдж-окружении.

Почему нужно ждать появления API в тест-окружении перед тестированием? По моему опыту, это связано с тем, что на этом этапе процесса разработки API достаточно стабилен, чтобы команда писала тесты, не волнуясь о постоянных переменах. Тестирование API более обширно с технической точки зрения, эти тесты будут медленнее и крупнее юнит-тестов. Однако они все еще достаточно невелики и быстры, чтобы запускать и поддерживать их, прикладывая небольшие относительно других тестов усилия.

End-to-end тестирование

Когда внедрять: как только приложение достаточно стабильно для деплоя на прод, или уже находится на проде

В то время как такие формы тестирования, как юнит, функциональное и API, выигрывают от раннего внедрения, end-to-end тесты – их полная противоположность. Эти тесты обширнее и значительно медленнее при прогоне, чем большинство API-тестов. Это означает, что end-to-end тесты дорого обновлять и поддерживать – не говоря о нагрузке на команду тестирования, когда что-то идет не так. Когда ваше приложение часто меняется, что норма для компаний на ранних этапах, вы сведете себя с ума, пытаясь угнаться за ним со своими end-to-end тестами.

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

Нагрузочное тестирование / тестирование производительности

Когда внедрять: только в том случае, если компании это необходимо

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

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

Ручное тестирование

Когда внедрять: до начала разработки

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

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

Заключение

Небольшие стартапы и компании на ранних стадиях жизненного цикла проводят большую часть дня, пытаясь выжать максимум из своих ограниченных в доступности ресурсов. У них едва хватает времени и средств на то, чтобы получить успешный продукт или нанять людей в помощь. Из-за этого кажущегося бесконечным напряжения нужны компромиссы, чтобы выжить. В большинстве случаев одним из этих компромиссов будет сокращение времени на тестирование и качество, или перенос их на поздние этапы.

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

Автоматизированные тесты принимают множество форм, и у каждой есть определенные достоинства. К примеру, юнит-тесты быстры в исполнении и передаче обратной связи в ходе разработки, а end-to-end тесты лучше работают на выявление регрессий в полностью готовом продукте. Типами тестирования, освещенными в статье, тестирование в небольших компаниях не ограничивается. Однако идея тут в том, что не все тесты равноценны. Работа над правильными для текущего момента тестами эффективнее повысит качество вашего приложения, если сравнивать с попытками сделать все и сразу.

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