Это обычный сценарий: у начинающей компании появляется новая идея, и она нанимает несколько разработчиков, чтобы построить работающую модель идеи.
Из-за характера стартапов, то есть нехватки финансирования и короткого времени на разработку идеи, основные усилия сосредоточены на создании нового продукта, чтобы представить его публике для проверки воды и, естественно, тестирования. и обеспечение качества не является главным приоритетом для команды разработчиков.
После того, как становится очевидным, что идея была успешной, компания хочет расширить идею и начать нанимать больше разработчиков, но в то же время они также хотят, чтобы продукт был протестирован, прежде чем он станет общедоступным.
Какое-то время тестирование проводится любым сотрудником компании, и оно в основном носит спонтанный характер и не требует соблюдения соответствующих процедур.
Затем наступает момент, когда стартап-компания решает нанять своего первого старшего специалиста по контролю качества, чтобы начать внедрение нового процесса контроля качества для команды разработчиков.
В этой статье я предполагаю, что стартап - это веб-компания, например веб-сайт электронной коммерции.
Основная цель процесса обеспечения качества - обеспечить создание правильного продукта с первого раза. Это означает, что нам необходимо убедиться, что требования определены правильно, а команда разработчиков хорошо понимает функциональность новых функций, прежде чем приступать к написанию кода.
Важно отметить, что тестирование - это не этап, это действие, и что тестирование начинается с самого начала процесса разработки, прямо с момента написания пользовательских историй.
Тестирование должно поддерживать разработку, поэтому действия по тестированию должны выполняться параллельно с действиями по разработке, и на каждом этапе процесса разработки нам необходимо обеспечить тщательное тестирование кода.
Перед внедрением процесса тестирования нам необходимо знать текущую методологию и процесс разработки и, при необходимости, внести коррективы для улучшения процесса.
Если вы начинаете как первый специалист по контролю качества в компании, скорее всего, не будет проводиться регрессионное тестирование, и поэтому по мере разработки новых функций вы понятия не имеете, отрицательно ли они влияют на текущий работающий веб-сайт. Более того, вам нужно идти в ногу с командой разработчиков, чтобы тестировать новые функции, чтобы убедиться, что они работают правильно и в соответствии со спецификациями.
Параллельно выполняются как минимум две задачи: тестирование новых историй в спринте и выполнение некоторой степени регрессионного тестирования.
Тестирование новых функций имеет приоритет, поскольку вероятность обнаружения ошибок в новом коде выше, чем поломки текущего рабочего сайта. Но в то же время требуется регрессионное тестирование, чтобы гарантировать, что существующее приложение продолжает работать по мере того, как мы создаем новые функции.
Пакет регрессионного тестирования необходимо запустить сразу после обновления приложения, чтобы команда разработчиков могла получить быстрая обратная связь о работоспособности приложения.
Не хватает времени на написание регрессионных тестов, а также на то, чтобы не отставать от тестирования новых функций. Как мы можем разорвать этот круг?
Обычно в течение первых нескольких дней спринта разработчики заняты кодированием, поэтому новые функции не будут готовы к тестированию в течение некоторого времени. Это хороший шанс начать работу над регрессионными тестами.
Существуют передовые методы регрессионного тестирования, но, как правило, подход состоит в том, чтобы определить основные основные пути пользователя по всему веб-сайту, чтобы при каждой новой версии веб-сайта мы могли быть уверены, что приложение все еще можно использовать для большинства его пользователей. пользователей.
Необязательно быть исчерпывающим списком этих сценариев, достаточно будет только основных и наиболее важных, чтобы запустить небольшой регрессионный пакет, который может выполняться при каждой сборке. Позже, когда регрессионный пакет станет зрелым, мы сможем добавить больше сценариев.
Самое главное, эти сценарии регрессии должны быть автоматизированы.
В гибком проекте, где спринт обычно длится около двух недель, не хватает времени, чтобы провести все тестирование вручную. Есть тестирование новых историй, а также регрессионное тестирование. Хотя для тестирования новых функций имеет смысл проводить исследовательское тестирование, регрессионные тесты следует автоматизировать, чтобы уменьшить рутинную задачу многократного выполнения одних и тех же тестов вручную.
Конвейер развертывания или сборки в гибком проекте определяет, как история переходит от бэклога продукта к действующей производственной площадке. Он определяет процесс и действия, которые происходят на каждом этапе.
Чтобы реализовать успешный процесс QA, который гарантирует, что мы часто выпускаем качественный код, конвейер развертывания должен быть определен и соблюдаться всеми заинтересованными сторонами. Конвейер развертывания - это стержень доставки программного обеспечения.
Процесс должен быть основан на передовой практике и охватывать действия, выполняемые на каждом этапе.
Одно из самых важных занятий в гибком проекте - частые занятия по рассказам. Это когда владелец продукта, разработчики и тестировщики собираются в комнате и начинают прорабатывать и конкретизировать детали историй. Это важно, потому что все должны одинаково понимать историю, прежде чем приступить к разработке.
Обеспечение качества - это предотвращение дефектов, а не обнаружение, поэтому на семинарах по рассказам команда получает возможность задать вопросы о деталях истории, любых технических или конструктивных ограничениях и любых препятствиях на пути разработки историй.
Это прекрасная возможность начать выписывать критерии приема рассказов. Каждый должен внести свой вклад и начать думать о возможных сценариях для каждой истории, поскольку у каждой будет своя идея, поэтому чем больше внимания будет уделено истории, тем больше сценариев можно придумать и тем выше шанс предотвратить появление дефектов.
Как только все будут уверены в деталях и масштабах каждой истории, начинается разработка.
За качество продукта должны нести ответственность все, а не только тестировщики. Таким образом, необходимо провести достаточный объем «тестирования разработчика», чтобы гарантировать высокое качество написанного кода перед его развертыванием в тестовой среде для дальнейшего тестирования.
Конечно, каждая новая функциональность должна быть хорошо протестирована. Кроме того, необходимы интеграционные тесты, тесты API, а также тесты пользовательского интерфейса.
Партнерские проверки кода или «товарищеское тестирование» могут привлечь внимание к работе разработчика. Тестировщик может помочь в проверке модульных тестов, а также тестов API, чтобы убедиться, что написаны правильные тесты, а также в написании высокоуровневых автоматизированных тестов пользовательского интерфейса.
Чтобы эффективно тестировать новые функции, нам необходимо убедиться, что код работает не только на компьютере разработчика, но и в других средах, и интегрирован с кодом другого разработчика.
Непрерывная интеграция помогает выявлять любые проблемы сборки на ранних этапах процесса, поэтому, когда развертывание не удается, мы можем начать искать, откуда взялась проблема.
Среды тестирования дают тестировщикам и другим членам команды возможность протестировать новые функции перед их запуском.
При необходимости мы также должны выполнять нефункциональное тестирование, такое как тестирование производительности, нагрузки и безопасности. Довольно часто основное внимание уделяется обеспечению правильной работы функциональности, однако нефункциональному тестированию следует уделять такой же приоритет, особенно для веб-приложений, поскольку они могут подвергаться большой нагрузке и / или атакам.
Выполняя нефункциональное тестирование, мы можем быть уверены, что наше приложение сможет выдерживать нагрузку в часы пик и что оно не открыто для угроз безопасности.