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

Дымовое тестирование проверяет, готова ли программа к тестированию; другими словами, может ли команда тестирования принять программу, чтобы начать работать с ней? Это подмножество приемочного тестирования. Приемочным тестированием является любой вид тестирования, который проверяет, может ли система перейти в следующую фазу своего жизненного цикла, будь это тестирование, передача заказчику или подготовка его к использованию потребителем.
В зависимости от области работы приемочные тесты могут быть сценарными или импровизационными. Для крупных подрядных компаний или сложных проектов зачастую существует несколько тест-планов, проверяющих правильность работы различных частей системы, а также показателей качества (например, что во время тестового периода будет обнаружено не более трех значительных дефектов), которые должны быть оценены. Для небольших программ приемочное тестирование может заключаться в разрешении заказчику или пользователю поработать несколько минут с программой, чтобы понять, устраивает она его или нет.
Так как разработчики ПО обычно не являются специалистами в той области, для которой они создают программу, существует большая вероятность, что они создадут программу, которая не удовлетворит нужды потребителя. Даже если требования оговорены ясно, часто существуют характерные для данной предметной области неоднозначности и допущения. Например, для программиста понятна начинающаяся с нуля индексация — во многих популярных языках программирования нумерация элементов массива идет с 0, и мало кто из разработчиков Java напишет цикл for таким образом:
for (int j=1; j <= 10; j++) { ... }
Однако большинство людей, не являющихся программистами, тот факт, что индекс 1 будет указывать на второй элемент списка, приведет в замешательство.
Официальные приемочные тесты обычно определяются заранее и согласовываются разработчиком ПО и заказчиком. Если все тесты проходят или обе стороны приходят к приемлемому для них компромиссу, тогда говорят, что ПО принято заказчиком. Другие возможные решения включают частичный платеж, платеж после исправления определенных дефектов или понимание, что существует определенный уровень качества, не предполагающий прохождения всех тестов (т. е. проходят все основные тесты и по крайней мере 95% незначительных тестов).
Эксплуатационное тестирование, также называемое полевым тестированием, представляет собой тестирование системы в реальных (эксплуатационных) условиях. Часто во время процесса разработки или пошаговых проверок проблему не то что не могут найти — о ней даже не могут подумать. Эксплуатационное тестирование позволит найти эти упущенные из вида ошибки путем запуска системы в реальной среде. Например, каждая составляющая часть новой системы авионики может быть протестирована с использованием описываемых в этой книге техник, но система не пройдет эксплуатационное тестирование до тех пор, пока самолет, для которого разработано программное обеспечение, не поднимется в воздух. Зачастую эксплуатационное тестирование является последним видом выполняемого в системе тестирования, которое гарантирует, что система действительно будет работать правильно в реальных условиях. Это может быть довольно дорогой метод тестирования как с точки зрения настройки, так и с точки зрения риска. Например, если система авионики выйдет из строя и самолет полетит не так, как надо, цена этого отказа окажется чрезвычайно высокой; и даже если она работает правильно, полет самолета в течение нескольких часов окажется на несколько порядков дороже, чем покупка компьютерного времени для проведения симуляции и интеграционных тестов.
Другим видом приемочного тестирования является пользовательское приемочное тестирование. Обычно используемое в Agile-средах, пользовательское приемочное тестирование (ППТ — user acceptance testing, UAT) проверяет, что система соответствует целям пользователей и работает приемлемо для них. Обычно профильному специалисту (ПС — человек, не являющийся разработчиком и понимающий область, для которой написана программа) дается определенное количество задач, которые необходимо решить. ПС не получает инструкции о том, как выполнять задачи от тестировщика; он самостоятельно определяет, как использовать программу (при помощи соответствующей документации или вспомогательных материалов) для выполнения задач. Если, например, тестируется веб-браузер, для пользовательского приемочного тестирования можно пригласить опытного веб-серфера (если этот термин еще используется) как профильного специалиста. У ПС могут быть три задачи — зайти на главную страницу популярной поисковой системы, добавить страницу в закладки и вернуться на эту страницу через закладки. Участники команды могут наблюдать за действиями ПС, но они не должны никак ему помогать или что-то объяснять. Сдерживание участников команды от попыток оказать помощь может быть сложной задачей, т. к. те, кто разрабатывает программу, обладают более высоким уровнем знаний о системе и хотят показать пользователю "как надо лучше". Однако действия ПС по выполнению задач без какой-либо сторонней помощи покажут вам, что может быть сложным для пользователей, которые будут пользоваться программой самостоятельно.
Альфа-тестирование и бета-тестирование можно рассматривать как виды приемочного тестирования. Хотя эти термины могут иметь немного разные значения в различных областях, они подразумевают участие независимых пользователей или команд, использующих разрабатываемое программное обеспечение. Во всех случаях альфа-тестирование предшествует бета-тестированию при условии, что альфа-тестирование выполняется. В нем участвует очень небольшая группа выбранных заказчиков, чаще всего специалистов высокого класса или с высокими техническими навыками, которые используют программу. Иногда это может быть не заказчик, занимающийся тестированием, а группа тестирования, которая является сторонней по отношению к группе, участвовавшей в разработке. Бета-тестирование подразумевает доступ к релизу более широкого круга потребителей. Обычно оно проводится после альфа-тестирования для больших хорошо протестированных проектов. Однако ничто не может помешать команде отказаться от альфа-тестирования и передать программу напрямую большой группе людей — возможно, всей клиентской базе, оговаривая, что программа является бета-версией. Google славится этим; Gmail, например, технически находился в стадии бета-релиза первые 5 лет своего существования, в течение которых миллионы людей использовали этот почтовый сервис. Если вас не очень беспокоит, что в мире узнают о дефектах, бетатестирование может стать быстрым способом получить информацию об использовании и сообщения о дефектах от большого количества пользователей.
В онлайн-системах бета-тестирование часто может быть "смешано" с обычным использованием системы. У вас есть некий набор пользователей — скажем, интересующиеся новыми возможностями программы, или важные заказчики, или даже случайная выборка, — и у них есть доступ к новому функционалу, который вы хотите подвергнуть бета-тестированию. Обычно необходимо либо обсудить это с ними, либо убедиться, что они знают о том, что используемый функционал пока не является полным.
Похожим по концепции на приемочное тестирование является подход "кормление собак" (dogfooding) или "съешь сам свою собачью еду" (eat your own dogfood). Несмотря на несколько шокирующее название, это означает, что разрабатывающая программу команда сама использует эту программу. Это полезно в ситуациях, когда разрабатываемая система является знакомой компьютерным пользователям в общем (например, операционная система или текстовый редактор) или программистам в частности (среда разработки или компилятор). Обычно это невозможно до завершающих стадий проекта, когда наличие достаточного функционала уже позволяет относительно приемлемо пользоваться программой — ведь не имеет смысла "есть свою собачью еду", которая еще не готова. "Собачья еда" позволяет чрезвычайно быстро находить дефекты, т. к. программу использует вся команда, а не только тестировщики. Даже если другие участники команды не заняты целенаправленным поиском дефектов в системе, тот факт, что ее использует большое количество людей — и делает это так, как могли бы другие пользователи, — означает, что, скорее всего, будет обнаружено больше дефектов. Они, как правило, образуют кластеры в областях, в которых работают пользователи, позволяя собрать дополнительные метрики (по использованию и плотности дефектов в различных подсистемах). И как бонус у разработчиков, использующих свою программу, появляются дополнительные стимулы по обеспечению качества своего кода!