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

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

Цель заключается в том, чтобы проверить, соответствует ли программа, приложение или сайт тем бизнес–требованиям, которые были заложены изначально. Обычно для этого используют метод «Черного ящика», то есть смотрят на продукт глазами конечного пользователя, а не как профессионалы, которые знают, где искать и на что смотреть.

Зачем проводится приемочное тестирование:

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

• Проверить, действительно ли все функции работают и поведение программного продукта соответствует тому, каким оно должно быть в реальности.

• Убедиться в том, что готовый продукт будет эффективным и востребованным на рынке.

Чем приемочное тестирование отличается от системного и пользовательского?

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

Юнит–тестирование.

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

Пример.

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

Интеграционное тестирование.

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

Пример.

Компания занимается разработкой интернет–магазина. Рабочий процесс разбит на несколько итераций, в рамках которых выполняются задачи по отдельно взятым модулям. Это может быть модуль:

• Отвечающий за управление товарами.

• Отвечающий за обработку заказов.

• Осуществляющий прием и отмену оплаты.

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

Системное тестирование.

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

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

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

Приемочное тестирование.

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

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

Приемочное тестирование имеет свои разновидности, о которых расскажем ниже.

Пользовательское тестирование (UAT) User Acceptance Testing.

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

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

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

Бизнес–тестирование (BAT), Business Acceptance Testing.

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

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

Контрактное тестирование (CAT) Contract Acceptance Testing.

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

Сам документ, который подписывается обеими сторонами, имеет название – Соглашение об уровне обслуживания (SLA – Service Level Agreement). Договор заключают до начала релиза.

Правовое тестирование (RAT) Regulations Acceptance Testing.

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

Если компания по каким–либо причинам примет решение выпустить релиз продукта на рынок вопреки тому, что программа или приложение не соответствуют законодательству, то это приведет к ответственности. Могут даже возбудить уголовное дело и назначить не только штраф, но и реальный тюремный срок.

Эксплуатационное тестирование (OAT) Operational Acceptance Testing.

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

Альфа–тестирование (Alpha Testing).

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

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

Бета–тестирование (Beta Testing).

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

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

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

Анализ требований.

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

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

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

Определение и написание сценариев тестирования.

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

Тестирование.

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

В случае, если были обнаружены ошибки и баги, то продукт отдается на доработку.

Подтверждение соответствия бизнес–целям.

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

Что можно считать критериями успешного приемочного тестирования?

Совместимость.

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

Соблюдение предварительных требований.

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

Безопасность.

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

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

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

К проверяющим есть ряд требований, которые позволят определить их степень адекватности и компетенций.

Аналитическое и логическое мышление.

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

Владение инструментами тестирования.

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

Владение методологией тестирования.

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

Абстрактное мышление.

Приемочное тестирование имитирует манеру поведения конечного пользователя. Если речь идет не о beta–тестировании, то проверкой занимается чаще всего тестировщик. У него имеются профессиональные знания, которые могут повлиять на исход результата, но для этого и существуют различные подходы. Например, он может использовать monkey testing, чтобы «случайным» образом сломать программу, как это гипотетически может сделать пользователь.

В зависимости от типа тестирования, проверкой занимаются разные люди.

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

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

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

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