ad hoc testing что это
Что такое исследовательское тестирование?
И чем оно отличается от тестирования по сценариям (сценарного тестирования)
Этот пост является переводом статьи Джеймса Баха What is Exploratory Testing? Это первый перевод из серии статей Баха про исследовательское тестирование и все, что с ним связано с сайта http://www.satisfice.com. Если вы нашли неточность в переводе или ошибку в терминологии прошу сообщить о ней в комментариях к статье.
Исследовательское тестирование является мощным и приятным подходом к тестированию. В некоторых случаях оно может быть более продуктивным, чем привычное тестирование по сценариям. Я не встречал еще тестировщика, который бы не применял исследовательское тестирование, хотя бы на бессознательном уровне. Тем не менее, мало кто из нас подробно изучал этот подход, и он еще не так признан в нашей области. Пора нам прекратить его отрицание, и публично признать исследовательский подход, таким какой он есть: научным мышлением в режиме реального времени. Друзья, это классная вещь!
Параллельное проектирование и выполнение тестов
Простейшее определение исследовательского тестирования — это разработка и выполнения тестов в одно и то же время. Что является противоположностью сценарного подхода (с его предопределенными процедурами тестирования, неважно ручными или автоматизированными). Исследовательские тесты, в отличие от сценарных тестов, не определены заранее и не выполняются в точном соответствии с планом. Звучит это просто, но на практике все весьма туманно. Это происходит из-за того, что «определенный» не означает что мы жестко фиксируем все и вся. Даже в том случае, если тщательно определены все тестовые сценарии, то работа с большим количеством интересных деталей (например, как быстро печатать на клавиатуре, или какие виды поведения программы признать ошибочными) остаются на усмотрение тестировщика. Кроме того, даже в свободной форме поисковой сессии тест будет включать в себя ограничения состоящие в том, какую часть продукта тестировать или какую стратегию использовать. Хороший исследовательский тестирировщик будет записывать идеи тестов и использовать их в последующих циклах испытаний. Такие заметки иногда очень похожи на сценарии тестирования, даже если они таковыми не являются. Исследовательское тестирование иногда путают с «ad hoc» тестированием. Ad hoc тестирование обычно относится к процессу импровизации, поиска ошибки экспромтом. По определению, любой может заниматься ad hoc тестированием. Термин «исследовательское тестирование» (придумал Cem Kaner, в книге Testing Computer Software) обозначает вдумчивый подход к ad hoc тестированию. За последние десять лет, Джеймс Уиттакер, Сем Канер и я работали для выявления навыков и техник позволяющих эффективно использовать исследовательское тестирование. Например, полностью определены и сформулированы процессы исследовательского тестирования, см. General Functionality and Stability Test Procedure for Microsoft’s Windows 2000 Compatibility Certification program.
Баланс между исследовательским и сценарным тестированием
Если каждый следующий тест, который мы выполняем, выбирается по результатам предыдущего теста, это означает, что мы используем исследовательское тестирование.Мы начинаем заниматься поисками и исследованиями, когда мы не можем сказать, какие тесты должны быть выполнены, или когда мы еще не имели возможности эти тесты создать, то есть мысль об их написании даже не приходила нам в голову. Если мы идем по сценариям, и на свет выплывает новая информация, которая предлагает нам лучшую стратегию тестирования, мы можем перейти к поисковому режиму (как и в случае обнаружения новой ошибки, которая требует подробного рассмотрения). С другой стороны, мы больше следуем сценарному подходу, когда 1) неопределенность в том, как мы хотим проверить, мала 2) новые тесты относительно неважны, 3) необходимость обеспечения эффективности и надежности в выполнении этих тестов стоит усилий по работе с подобными тестами, 4)мы готовы платить за написание и поддержание тестов.
Результаты исследовательского тестирования не обязательно радикально отличаются от тех, которые мы получаем с помощью сценарного тестирования и оба этих подхода к тестированию являются полностью совместимыми. Такие компании, как Nortel и Microsoft обычно используют оба подхода в одном проекте. Тем не менее есть много важных различий между двумя подходами.
Зачем проводить исследовательское тестирование?
Наиболее обсуждаемыми темами в управлении эффективным исследовательский циклом тестирования являются тестировщик, стратегии тестирования и отчетность. Сценарный подход к тестированию является попыткой механизировать процесс тестирования, когда берется идея из головы тест-дизайнера и излагается на бумаге. Подобный способ тестирования очень полезен. Но тестировщики, использующие исследовательский подход, придерживаются мнения, что запись тестовых сценариев и следование им «отупляет» тестировщика, мешая ему быстро находить ключевые проблемы. Чем более интеллектуальным мы можем сделать тестирование, тем больше шансов у нас будет, что мы протестируем приложение правильно и успеем сделать это вовремя. В этом и заключается мощь исследовательского тестирования: богатство этого процесса ограничивается только широтой и глубиной нашей фантазии, а также нашим пониманием природы тестируемого приложения.
Сценарное тестирование занимают свою нишу. Я могу себе представить ситуации в тестировании, когда эффективность и воспроизводимость настолько важны, что мы должны написать сценарии для них или их автоматизировать. Например, в случае, когда тестовая платформа регулярно бывает недоступна, как в случае клиент-серверных приложений, в которых есть только несколько настроенных серверов и они должны быть разделены между командами разработки и тестирования. Здравый смысл подсказывает нам, что мы должны заранее тщательно проработать сценарий тестов, чтобы получить максимальную отдачу во время выполнения тестов в выделенное нам время. Исследовательское тестирование особенно полезно в сложных ситуациях тестирования, когда мало что известно о продукте, или как часть подготовки набора сценариев тестов. Основное правило заключается в следующем: исследовательское тестирование используется в тех случаях, когда выполнение следующего теста неочевидно, или когда вы хотите выйти за рамки очевидного. По моему опыту, это происходит в большинстве случаев.
Способы тестирования игр. 6 типов
За последние годы индустрия видеоигр еще больше выросла, поэтому если в 2018 году рынок видеоигр стоил более 130 млрд долларов, то в 2020 году, по оценкам Global Data, он будет стоить более 300 млрд долларов. Этот рост также приводит к росту конкуренции в индустрии видеоигр, поэтому компании по разработке игр должны быть конкурентоспособными в играх, которые они запускают. В настоящее время ассортимент игр, из которых игроки могут выбирать, очень велик, поэтому требования игроков к качеству возросли. Видеоигры должны быть развлекательными и без багов.
Почему необходимо тестирование игр?
QA тестировщики ищут недочеты и слабые места, которые можно устранить до того, как продукт будет представлен публике. Кроме того, с помощью различных методов они должны убедиться, что такие аспекты, как эмоциональная связь с игрой и уровень интереса находятся в оптимальном состоянии. Ниже мы подробно описываем некоторые из распространенных методов, используемых специалистами по QA-тестированию игр.
Тестировщики игр следят за любыми графическими нарушениями в интерфейсе, такими как отсутствие графики, отсутствие цветов, проблемы с расположением или проблемы с анимацией и клиппингом. После выявления всех ошибок и недочетов тестировщики составляют список и отправляют его разработчикам игры для исправления. После того как разработчики игры устраняют проблемы, они направляют игру обратно в QA группу для повторного тестирования.
2. Комбинаторное тестирование
С помощью этого метода тестирования игры вы можете сначала проверить, сколько тестов требуется игре. Затем техника комбинаторного тестирования анализирует и тщательно изучает все игровые выходные и входные данные, что позволяет получить четкое представление о различных возможных комбинациях и результатах. Этот вывод имеет важное значение для тестирования, поскольку предполагает, что комбинаторное тестирование параметров может обеспечить высокоэффективное выявление неисправностей.
3. Интуитивное тестирование (ad-hoc)
Этот метод не является формальным, напротив, все процедуры выполняются случайным образом. Этот метод игрового тестирования также называется «угадыванием ошибок» и заключается в обнаружении ошибок с помощью случайного подхода. Поэтому нет необходимости в специальной документации, такой как документы с требованиями, планы тестирования, тест-кейсы или надлежащее планирование тестирования в отношении графика и порядка выполнения тестов.
4. Тестирование совместимости
5. Методология “чистой комнаты” (Cleanroom Testing)
Методология “чистой комнаты” проверяет и улучшает показатели стабильности и надежности игрового программного обеспечения. Используя методология “чистой комнаты”, можно выявить главную причину возникновения багов и мелких ошибок. Тестировщики игр должны создавать тесты, которые воспроизводят игру точно так же, как игроки. Это означает, что им будет легче понять, чем занимаются игроки.
6. Регрессионное тестирование
В преддверии старта курса Game QA Engineer приглашаем всех желающих на бесплатный демоурок в рамках которого вы узнаете как создаются игры, в чем особенности их тестирования. Почему в играх особенные сроки? Подробно рассмотрим как тестировать баланс и почему автоматизация не спасает? А также будем практиковаться и протестируем анимацию «Лепрекон».
Исследовательское тестирование: когда его стоит применять и как это делать
Многие скептически относятся к исследовательскому тестированию, так как считают, что это пустая трата времени и ресурсов. Но на самом деле это не так. В этой статье я расскажу, когда исследовательское тестирование принесет проекту пользу. В русскоязычной литературе дается очень много различных определений для термина «исследовательское тестирование». Нередко под этим понятием подразумевается ad-hoc тестирование и наоборот. Почему так сложилось исторически можно узнать там — Исследовательское тестирование 3.0. Чтобы при чтении статьи не возникало путаницы, сверим часы и зафиксируем определения.
Что такое исследовательское тестирование
Ad-hoc тестирование
Под ad-hoc тестированием будем понимать тестирование без использования спецификаций, планов и разработанных тест-кейсов: чистая импровизация.
Исследовательское тестирование
Более формальная версия ad-hoc: тестирование, не требующее написания тест-кейсов, но подразумевающее, что каждый последующий тест выбирается на основании результата предыдущего теста. А по Сэму Канеру, «Testing Computer Software», «исследовательское тестирование» — вдумчивый подход к ad-hoc тестированию.
Сценарное тестирование
Классическое тестирование по предварительно написанным и задокументированным сценариям.
Перечитайте эти пункты еще раз, но уже с мыслью о том, почему плюсы сценарного тестирования могут оказаться минусами для исследовательского и наоборот.
Когда можно применять исследовательское тестирование в чистом виде
Мало времени
Если тестовая документация написана, но времени на прохождение тестов уже нет, нужно выбирать наиболее критичные области приложения, которые реально протестировать за имеющееся время. Составить чек-лист с идеями и тестировать вокруг них.
Сложности с требованиями
Требований нет, они не полны или устарели и нет возможности их актуализировать.
Небольшой проект
Продукт маленький, и разработка тестовых сценариев займет больше времени, чем сам процесс тестирования.
Когда можно применять исследовательское тестирование в дополнение к обычному тестированию
Пришел внезапный запрос на изменения
Времени на разработку новых сценариев нет, так как все заняты другими запланированными задачами или изменения потребуют переработать большую часть документации. В этой ситуации тестирование исследовательским методом может быть наиболее оптимальным.
Когда хочется перестраховаться
Продукт уже протестирован по сценариям, но всё еще хочется убедиться в том, что ничего не было упущено.
Когда одним исследовательским тестированием не обойтись:
Приложение стандартизованное
Приложения, работающие по стандартам и гостам, а также системы, для которых малейшее отклонение может быть критичным. Это могут быть приложения, отвечающие за полеты ракет или проводящие финансовые операции.
Проводится интеграционное тестирование
В этом случае исследовательское тестирование возможно, например, при тестировании API. Но обычно интеграционное тестирование проводится для проверки взаимодействия внутренних компонентов приложений. Эта работа хорошо покрыта документацией и часто автоматизируется.
Тестовые сценарии отдаются на аутсорс
Аутсорс аутсорсу рознь, но контролировать поставленную задачу и процент ее выполнения проще по формализованным сценариям.
Длительный проект
Тестировщики могут быть подключены к проекту на время определенной фазы, а после, пока разработчики реализовывают новый функционал, заниматься другими проектами. Если долго не тестировать конкретную функциональность, то ее специфика забывается.
Развенчание мифов или как применять исследовательское тестирование
«Исследовательское тестирование невозможно проконтролировать, им нельзя управлять. Сложно определить, когда пора остановиться и покрыт ли весь функциональность»
Иногда исследовательское тестирование воспринимают как антоним к сценарному и относятся к нему как к тестированию в полном хаосе.
На самом деле эффекта измеримости и распараллеливания задач добиться достаточно просто. Хватает зафиксировать объем работ и разделить его на измеримые по времени части.
«Нельзя доверить выполнение тестирования первому встречному»
Отчасти это действительно так. Но и сценарное тестирование не следует отдавать «случайному» человеку. На практике невозможно хорошо тестировать продукт, следуя только по заранее подготовленным шагам. Всегда возникает желание отступить от тщательно выверенных сценариев и поработать с деталями — добавить негативных проверок, проверить работу с прерываниями и так далее. И это хорошо, так как покрыть продукт тестами на 100% невозможно и никогда нельзя до конца исключить фактор человеческой ошибки.
В целом, улучшение навыков QA-команды всегда является одной из целей QA-подразделения. Используя исследовательское тестирование, инженеры задействуют интуицию и опыт, накопленные ранее и привыкают постоянно анализировать продукт.
«Сложно „продать“ исследовательское тестирование заказчику, объяснить его необходимость»
На самом деле для заказчика важен результат и прозрачность процессов. В данном случае результат – это продукт, удовлетворяющий представлениям заказчика о качестве. А необходимой прозрачности процессов можно достигнуть с помощью грамотных отчетов.
Выводы
Исследовательское тестирование — не означает полное отсутствие документации и хаос, а является мощным инструментом.
Используя ранжирование типов тестирования от полностью исследовательского до полностью сценарного, детализируя структурно составленные чек-листы, можно подобрать оптимальный уровень документации для вашего проекта и сэкономить время.
Сценарное и исследовательское тестирование являются полностью совместимыми и компенсируют недостатки друг друга. Можно покрыть детальными тестами сложные технические аспекты проекта и написать поверхностные чек-листы для пользовательского интерфейса.
Будьте гибкими. Вырабатываете стратегию, которая наилучшим образом подойдет для вашего продукта. Качественных вам проектов.
Теория тестирования ПО просто и понятно
Привет, Хабр! Да-да, про тестирование ПО тут уже куча статей. Здесь я просто буду стараться структурировать как можно более полный охват данных из разных источников (чтобы по теории все основное было сразу в одном месте, и новичкам, например, было легче ориентироваться). При этом, чтобы статья не казалась слишком громоздкой, информация будет представлена без излишней детализации, как необходимая и достаточная для прохождения собеседования (согласно моему опыту), рассчитанное на стажеров/джунов (как вариант, эта информация может быть для общего понимания полезна ИТ-рекрутерам, которые проводят первичное собеседование и попутно задают некоторые около-технические вопросы).
ОСНОВНЫЕ ТЕРМИНЫ
Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом. Чем занимаются в тестировании:
планированием работ (Test Management)
проектированием тестов (Test Design) — этап, на котором создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями. Т.е., определяется, КАК будет тестироваться продукт.
анализом результатов (Test Analysis)
Основные цели тестирования
техническая: предоставление актуальной информации о состоянии продукта на данный момент.
коммерческая: повышение лояльности к компании и продукту, т.к. любой обнаруженный дефект негативно влияет на доверие пользователей.
Верификация (verification)
Валидация (validation)
Соответствие продукта требованиям (спецификации)
Соответствие продукта потребностям пользователей
Дефект (баг) — это несоответствие фактического результата выполнения программы ожидаемому результату.
Следует уметь различать, что:
Error — это ошибка пользователя, то есть он пытается использовать программу иным способом (например, вводит буквы в поля, где требуется вводить цифры). В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message).
Bug (defect) — это ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так, как планировалось. Например, внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.
Failure — это сбой в работе компонента, всей программы или системы (может быть как аппаратным, так и вызванным дефектом).
Жизненный цикл бага
Серьезность (Severity) — характеризует влияние дефекта на работоспособность приложения. Выставляется тестировщиком.
Градация Серьезности дефекта
Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.
НЕКОТОРЫЕ ТЕХНИКИ ТЕСТ-ДИЗАЙНА
Эквивалентное Разделение (Equivalence Partitioning) — это техника, при которой функционал (часто диапазон возможных вводимых значений) разделяется на группы эквивалентных по своему влиянию на систему значений. ПРИМЕР: есть диапазон допустимых значений от 1 до 10, выбирается одно верное значение внутри интервала (например, 5) и одно неверное значение вне интервала — 0.
Анализ Граничных Значений (Boundary Value Analysis) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных. Если брать выше ПРИМЕР: в качестве значений для позитивного тестирования берется минимальная и максимальная границы (1 и 10), и значения больше и меньше границ (0 и 11). BVA может применяться к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.
Причина / Следствие (Cause/Effect — CE). Подразумевается ввод условий, для получения ответа от системы (следствие).
Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).
Исчерпывающее тестирование (Exhaustive Testing — ET) — подразумевается проверка всех возможные комбинации входных значений. На практике не используется.
Попарное тестирование (Pairwise Testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить общее количество тест-кейсов. Используется для тестирования, например, фильтров, сортировок. Этот интересный метод заслуживает отдельного внимания и более подробно рассматривается в статье по ссылке (в конце которой упоминаются инструменты для автоматизации применения PT ).
Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
Таблица принятия решений (decision table) — инструмент для упорядочения бизнес-требований, которые должны быть реализованы в продукте. Применяется для систем со сложной логикой. В таблицах решений представлен набор условий, одновременное выполнение которых приводит к определенному действию.
Пример таблицы принятия решений
ВИДЫ ТЕСТИРОВАНИЯ
Классификация по целям
Функциональное тестирование (functional testing) рассматривает заранее указанное поведение и основывается на анализе спецификации компонента или системы в целом, т.е. проверяется корректность работы функциональности приложения.
Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.
Тестирование пользовательского интерфейса (GUI Testing) — проверка интерфейса на соответствие требованиям (размер, шрифт, цвет, consistent behavior).
Тестирование удобства использования (Usability Testing) — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Состоит из: UX — что испытывает пользователь во время использования цифрового продукта, и UI — инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс».
Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
Инсталляционное тестирование (installation testing) направленно на проверку успешной установки и настройки, а также обновления или удаления приложения.
Конфигурационное тестирование (Configuration Testing) — специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.)
Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться, т.е. обеспечивать сохранность и целостность данных, после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети).
Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.
Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.
Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
Тестирование стабильности или надежности (Stability / Reliability Testing) — это проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.
Стрессовое тестирование (Stress Testing) позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса (например, повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера) и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса.
Объемное тестирование (Volume Testing) — тестирование, которое проводится для получения оценки производительности при увеличении объемов данных в базе данных приложения.
Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
Классификация по позитивности сценария
Позитивное — тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
Негативное — тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций; при таком тестировании часто выполняются некорректные операции.
Классификация по знанию системы
Тестирование белого ящика (White Box) — метод тестирования ПО, который предполагает полный доступ к коду проекта, т.е. внутренняя структура/устройство/реализация системы известны тестировщику.
Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
Тестирование чёрного ящика (Black Box) — метод тестирования ПО, также известный как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, которая не предполагает доступа (полного или частичного) к системе, т.е. основывается на работе исключительно с внешним интерфейсом тестируемой системы.
Классификация по исполнителям тестирования
Альфа-тестирование — является ранней версией программного продукта, тестирование которой проводится внутри организации-разработчика; может быть вероятно частичное привлечение конечных пользователей.
Бета-тестирование — практически готовое ПО, выпускаемое для ограниченного количества пользователей, разрабатывается в первую очередь для тестирования конечными пользователями и получения отзывов клиентов о продукте для внесения соответствующих изменений.
Классификация по уровню тестирования
Модульное (компонентное) тестирование (Unit Testing) проводится самими разработчиками, т.к. предполагает полный доступ к коду, для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде, проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).
Интеграционное тестирование (Integration Testing) направлено на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое, т.е. проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.
Подходы к интеграционному тестированию
Снизу вверх (Bottom Up Integration) Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения.
Сверху вниз (Top Down Integration) Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами.
Большой взрыв («Big Bang» Integration) Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.
Системное тестирование (System Testing) — это проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования и т.д., и оцениваются характеристики качества системы — ее устойчивость, надежность, безопасность и производительность.
Операционное тестирование (Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема.
Классификация по исполнению кода
Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки. Например, путем анализа кода (code review). Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте. Также к этому виду относится тестирование требований, спецификаций и прочей документации.
Динамическое тестирование проводится на работающей системе, т.е. с осуществлением запуска программного кода приложения.
Классификация по хронологии выполнения
Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок, т.е. проверяется исправление багов.
Регрессионное тестирование (regression testing) — это тестирование после внесения изменений в код приложения (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям, т.е. проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвали новых багов.
Приёмочное тестирование проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
ДОКУМЕНТАЦИЯ
Требования — это спецификация (описание) того, что должно быть реализовано. Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Основные атрибуты требований:
Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
Недвусмысленность — требование должно содержать однозначные формулировки.
Проверяемость (тестопригодность) — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
Приоритетность — у каждого требования должен быть приоритет (количественная оценка степени значимости требования).
Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию:
Что нужно тестировать?
Как будет проводиться тестирование?
Когда будет проводиться тестирование?
Критерии начала тестирования.
Критерии окончания тестирования.
Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.
Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для покрытия продукта тестами.