Домой » Тестирование » Как настроить QA с нуля

Как настроить QA с нуля

QA в Agile

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

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

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

На первом этапе тестированием занимается кто-нибудь из свободных разработчиков. Такое тестирование, по большей части, не документировано и не стандартизировано. Далее наступает момент, когда компания решает нанять для этих целей тест-лида и приступить к организации QA отдела.

Для примера будем рассматривать работу над реализацией web-проекта электронной коммерции.

Реализация процесса QA

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

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

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

Регрессивное тестирование / Sprint — тестирование

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

По крайней мере два процесса тестирования идут параллельно: тестирование нового функционала и выполнение некоторых стадий регрессии.

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

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

Автоматизированное тестирование

В Agile проекте (гибком проекте), где спринт обычно длится длительное время (от нескольких дней до нескольких недель), не хватает времени, чтобы всё протестировать вручную. Редко на проектах автоматизируют все функции, хотя бывает и такое. Более подробно про автоматизацию читайте в других моих статьях. Однако, будет не лишним лишний раз упомянуть, что автоматизация всё прочнее внедряется в проекты.

Развёртывание проекта

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

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

Про TDD (разработку через тестирование) можете подробнее почитать в отдельной статье. Здесь лишь упомяну, что это довольно распространённая практика в построении больших проектов. Разработчики тестируют свои модули сами. Если при TDD код “подгоняется” под тесты, то при Unit – тестировании, которое тоже не редко используется, тесты пишутся уже после написания кода.

Непрерывная интеграция / Среды тестирования

Для того, чтобы эффективно тестировать новые функции, мы должны убедиться, что код работает не только на машине разработчика, но и на других средах, а также интегрирован с кодом другого разработчика.

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

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

Нефункциональное тестирование

В Agile, при необходимости, мы также должны выполнить нефункциональное тестирование: нагрузочное, безопасности и т.д. Для web – приложений нагрузочное тестирование играет такую же роль, как и функциональное. Т.к. количество посетителей ничем не ограничено. Выполняя нефункциональное тестирование, мы можем быть уверены, что наше приложение сможет обрабатывать нагрузку в часы пик и защищено от атак. Новые виды тестирования добавляются уже в процессе развития проекта, если владелец видит в нём перспективы. При создании проекта под заказ, команда тестировщиков формируется заранее и весь процесс идёт немного по-другому.

Добавить комментарий

Войти с помощью: 

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*
*