Классифицировать это
Подобно тому, как цикл тестирования программного обеспечения можно разделить на различные уровни, сам процесс тестирования можно разбить на различные категории. Первый общий элемент касается функционального тестирования — обеспечения того, чтобы продукт работал и что он делал правильные вещи — подход проверки и проверки. Различные категории функционального тестирования должны быть успешно завершены, прежде чем могут быть выполнены более высокие, более сложные уровни тестирования.
Модульное тестирование
Модульное тестирование или модульное тестирование, как его иногда называют, обычно выполняется на уровне разработчика. Этот тип тестирования обычно проводится кем-то кроме основного разработчика. Причина, по которой эта схема предпочтительна, заключается в том, чтобы как можно больше взглянуть на код. Кодер может сделать некоторые предположения, которые мешают ему / ей быть объективными в отношении функциональности устройства. Если другие тестируют устройство, это может не гарантировать безошибочный модуль, но он идет далеко в этом направлении.
Группа тестирования программного обеспечения может участвовать или не участвовать в этом уровне. Если они есть, то, скорее всего, это будет на более неформальном уровне. Совместная деятельность в это время поощряет командную работу и сплоченность. Цель здесь — всегда помнить об окончательном результате: успешной доставке продукта.
Интеграционное тестирование
Вот где команда тестирования может оказать большое влияние. Насколько хорошо разработанные до сих пор единицы работают друг с другом? Здесь важна не столько проверка, как будет выглядеть готовый продукт или как он будет работать; более того, насколько хорошо выпущенные в настоящее время модули функционируют вместе как новый компонент. Это соединяет строительные блоки, чтобы увидеть, чего мы достигли до сих пор.
Как я указывал в предыдущих статьях, этот тип тестирования должен проводиться в собственной тестовой среде. Команда тестирования должна уметь пробовать вещи, которые могут иметь разрушительные последствия для других. Нет ничего более тревожного для разработчика, чем неожиданное изменение данных, когда он / она пытается заставить сложный алгоритм функционировать ожидаемым образом.
Тестирование системы
Это первый раз, когда программа представляет собой единую сущность, ожидающую своей магии. На этом этапе команда тестирования должна документировать каждую найденную ошибку. Распределение рисков здесь очень важно. Ошибки могут быть очень низким риском: неправильный размер или цвет шрифта. Или они могут быть основными: нажатие клавиши «Старт» приводит к выключению компьютера. Большинство дефектов и связанные с ними риски будут где-то посередине. Команда тестирования должна иметь официальный способ сообщить о каждой ошибке, чтобы разработчик мог легко воспроизвести условие.
Проверка требований имеет первостепенное значение здесь. Это первый уровень, который активно оценивает функциональность всего приложения. Обеспечение того, чтобы конечный результат был желаемым, является конечной целью.
Тестирование системной интеграции
Системная интеграция должна выполняться, если не в системе клиента, в системе, максимально приближенной к структуре пользователей. Большинство основных дефектов должно быть обнаружено и исправлено к этому времени. Целью здесь является обеспечение того, чтобы приложение работало, когда оно установлено в конечном месте назначения.
Пользовательское тестирование
Как следует из названия, приемочное тестирование пользователя (или UAT) — это возможность клиента подтвердить подлинность продукта, который скоро будет доставлен. Пользователь может использовать существующие тестовые наборы или разрабатывать тесты по своему выбору. В любом случае, тестирование обычно выполняется лицами в группе пользователей или лицами, специально определенными для выполнения этой задачи. Цель состоит в том, чтобы иметь новые объективные взгляды на результат с другой точки зрения.
Регрессионное тестирование
Регрессионное тестирование может проводиться в любое время в процессе тестирования. Обычно это означает повторный запуск ранее пройденных тестов. Задача здесь состоит в том, чтобы гарантировать, что новые усовершенствования, добавленные для исправления или обогащения продукта, не были внесены. Это отличное время для внедрения автоматизации в схему тестирования (но это уже совсем другой вопрос).
Существует несколько других категорий тестирования, в которых участвует конечный пользователь: альфа и бета-тестирование. У каждого свои уникальные экологические обстоятельства.
Альфа-тестирование
Как правило, альфа-тестирование выполняется в контролируемой атмосфере на месте разработчика. Внешним пользователям предлагается поиграть с новым приложением в контролируемой среде. Местные эксперты, которые могут состоять из членов первоначальных групп разработки и тестирования, готовы ответить на любые вопросы, которые могут возникнуть.
Бета-тестирование
Бета-тестирование, с другой стороны, может быть выполнением нового приложения в производственной среде конечного пользователя. Часто он запускается рядом с существующей программой (если приложение является заменой) или может запускаться в настройке «песочницы», чтобы дать новым пользователям возможность привыкнуть к внешнему виду и ощущению нового элемента ,
Продолжение следует…
То, что я представил здесь, конечно, не является конечным подходом. Категории тестирования, когда и как они выполняются, являются частью постоянно меняющегося процесса. Каждый проект будет иметь свои требования и ограничения. Самым важным аспектом, который следует помнить, является подход к миссии с набором планов, которые можно адаптировать и модифицировать, чтобы обеспечить наиболее полный метод достижения конечного продукта, который будет максимально успешным.