Что такое план тестирования
Нужен ли вам тест-план?
Документация как коммуникационное средство существует в первую очередь потому, что стороны, нуждающиеся в доступе к знаниям, разделены временными или пространственными рамками и неспособны синхронно делиться информацией.
Если все вы находитесь в одном пространстве, и вам не требуется долгоживущее подтверждение результатов ваших переговоров, то ценность документации сомнительна. Как гласит манифест Agile, люди и взаимодействия важнее полной документации. Не то чтобы у документации не было права на жизнь, но нужно тщательно выбирать, что и когда документировать. Очень важно соблюсти грамотный баланс, а также регулярно пересматривать его, дабы убедиться, что нужды всех заинтересованных сторон эффективно удовлетворены.
Я не собираюсь указывать вам, писать вам тест-план или не писать. Только вы можете определить, требуется ли вам этот документ в вашем конкретном контексте. Я лишь хочу, чтобы вы честно спросили себя, нужен ли вам этот тест-план?
Если вам кажется, что план вам нужен, то ниже – ряд вопросов, которые стоит задать, и несколько неплохих возможных ответов на них:
Вопрос: Кто запрашивает этот документ?
Ответ: заказчик, мы обязаны предоставить его по контракту.
Вопрос: Кто будет читать этот документ?
Ответ: Менеджер проекта, которому нужно убедиться, что я собираюсь протестировать продукт как минимум на удовлетворительном уровне.
Вопрос: Что читатель получит от этого документа?
Ответ: Вместе с прочей информацией – достаточную уверенность для релиза.
Вопрос: Что может улучшиться, если я прекращу писать тест-план?
Ответ: У меня будет больше времени для действительно ценной для проекта работы, потому что я не трачу время на то, что никто не будет читать.
Вопрос: Что может ухудшиться, если я прекращу писать тест-план?
Ответ: В проекте никто не будет иметь ни малейшего понятия, что именно я тестирую.
Вопрос: Кто заметит, если я прекращу писать тест-план?
Использование тест-плана как можно раньше в жизненном цикле проекта для поиска ответов на эти вопросы – это разновидность тестирования. Вы можете, например, спросить, есть ли критерии производительности, которые можно оценить и использовать для тестирования? Будет ли продукт выходить в интернет? Какие сценарии восстановления/избегания проблем должен поддерживать продукт? Задавая эти вопросы, вы подводите заинтересованных лиц к размышлениям о производительности, безопасности и устойчивости, и они займутся этим раньше, чем могли бы, не спроси вы их об этом.
Возможно, вы обязаны предоставить тест-план по контракту. В этом случае работайте совместно с заказчиком, чтобы уточнить, что он хочет узнать, и посредством какого механизма он хочет получить эту информацию.
Глаголы, а не существительные
«Планы бесполезны, но планирование бесценно» – Дуайт Эйзенхауэр.
Тест-планы статичны по своей природе, а планирование тестирования – динамический, дискурсный процесс обучения и переговоров. Документ, который никто не читает, бессмысленен. Создание того, что не принесет пользы проекту или его заинтересованным лицам, стоит денег и времени. План начнет приносить ценность только тогда, когда вы будете его использовать. Тест-план, который никто не читает, и который не информирует никого о тестировании – это трата вашего ценного времени, которое уместнее потратить на что-то более полезное.
Сбалансируйте создание подробного тест-плана и деятельность по планированию реального тестирования на период, покрытый этим планом. Если детальный план необходим, убедитесь, что вы учитываете риски, что что-то может остаться непокрытым или непротестированным. Тест-планы можно использовать как для информирования о том, что вы собираетесь тестировать, так и для того, чтобы сообщить, что вы, возможно, протестировать не сможете, если времени на это не хватит.
Заинтересованные лица – кто они?
Документы создаются для коммуникаций между людьми. Вам нужно понимать, кто эти люди в контексте связанной с тестированием информации. Кто ваши заинтересованные лица?
Если вы не уверены в ответе, определитесь, на какие вопросы о тестировании вам нужно получить ответ, а затем выясните, кто может ответить на них наилучшим образом, и спросите их об этом. Они должны быть задействованы в тестировании продукта или приложения. Объясните, почему вы задаете эти вопросы, и расскажите им, как их ответы улучшат ваше тестирование.
Тест-планом также могут пользоваться те, кому полезна информация, полученная в ходе запланированного тестирования. Найдите их, спросите, какая информация им требуется, и планируйте соответственно. Ниже – примеры заинтересованных лиц:
Тестировщики, которые хотят знать, что им предстоит тестировать в проекте. Тест-план может дать им подробную информацию об окружениях, версиях, или исходных данных. Тестировщики могут помочь вам улучшить план, основываясь на своем опыте, и добавить в него недостающую информацию и тест-подходы, о которых вы не подумали.
Менеджеры проекта хотят знать, что вы собираетесь тестировать, дабы быть уверенными в решении о выходе в релиз.
Техподдержка может рассказать об окружениях пользователей, о том, как они используют систему, и с какими проблемами сталкиваются. Эта информация может послужить основой для тестирования, покрывающего эти трудности.
Продакт-оунеры расскажут, как планируется использовать продукт, и, возможно, о случаях, когда пользователи используют его иначе. Эта информация полезна для создания профилей пользователей, помогающих в тестировании.
Продажники сообщат, какие продукты наиболее популярны, и как именно они применяются.
Если вы сомневаетесь, принадлежит ли человек к группе заинтересованных лиц, то всегда лучше включить его в процесс, нежели исключить. Никогда не знаешь, кто владеет информацией, которая может перевернуть подход к тестированию, или повлиять на его специфику. Со временем люди поймут механизмы сбора информации для тест-плана и то, как они могут помочь в его создании.
Как написать хороший тест-план: форма, структура и содержание
Тест-планы могут принимать какую угодно форму, например:
Хороший способ начать тест-план – это одностраничный план. Он поможет вам создать краткий и информативный документ.
С точки зрения содержания тест-планы обычно создаются, чтобы зафиксировать базовые ответы на «пять почему и как» тестирования. Содержание ваших планов может меняться по ряду причин (к примеру, от релиза к релизу или от спринта к спринту). Обновляйте ваш тест-план на основании полученной от релиза к релизу (или от продукта к продукту) информации.
Используйте ваши планы эффективно, чтобы улучшить процесс тестирования. Пусть он станет репозиторием для знаний организации. Сделали ошибку в релизе? Определите, как выловить ее в следующий раз, и добавьте в шаблон плана. Обычно забываете про какой-то тип тестирования? Отметьте, что это необходимо покрыть. Добавьте заметки о бедах и горестях пользователя, а также о том, что может дать вам полезную для тестирования информацию. Тест-план может стать основой для непрерывного совершенствования планирования и стратегии тестирования.
Со временем обновляйте шаблон, чтобы поддерживать и улучшать свое планирование. Пусть тетс-план работает на вас и формой, и структурой, и содержанием. Если он не работает – меняйте его.
Как оценивать тест-план
Когда ваш план готов, пересмотрите его. Оценка тест-плана может проводиться по-разному – лично я рекомендую личную встречу для его обсуждения. Такие встречи могут дать информацию о том, что еще необходимо добавить или покрыть. Они также делают тестирование продукта, приложения или релиза прозрачным для вас и вашей команды.
Пригласите на ревью заинтересованных лиц. Максимально сократите количество участников, но убедитесь, что все нужные роли присутствуют. Предположительный кворум может состоять из четырех человек или ролей – автор тест-плана (как правило, тестировщик), другой тестировщик, менеджер проекта, и представитель техподдержки. Однако для более крупных релизов можно подключать и других заинтересованных лиц – все зависит от вашей специфики.
Пройдитесь по каждому аспекту тест-плана и обсудите все его разделы. Выслушайте обратную связь, учтите информацию, которой делятся участники встречи.
Если план одобрен необходимым большинством, он не должен оставаться статичным. Когда тестирование начнется, используйте план для отслеживания усилий команды по достижению указанных в плане целей.
«Ни один план не выдерживает встречи с противником» – Хельмут фон Мольтке Старший.
«Только изменчивость постоянна» – Гераклит.
Как обновлять тест-план
Все меняется, и ваш план должен быть открыт переменам. Подход к планированию тестирования должен позволять справляться с изменениями, разъяснять, что вы будете делать иначе, какая информация вам необходима, и какую новую информацию (и кому) вы должны предоставить.
Договоритесь о подходящей частоте пересмотра тест-плана, или же используйте для этого любой достаточно весомый повод. Пересмотры не должны быть глобальными – пусть они соответствуют масштабу перемен. Это необязательно личные встречи: попросите людей просмотреть изменения и отправить вам комментарии по почте. Пусть всем будет легко помогать вам в поддержании плана в актуальном и рабочем состоянии.
Тест-планы работают на вас
Если ваше тестирование совсем не документируется, это может вызывать вопросы, на которые трудно найти ответ. Если вы способны показать ваш одобренный, обновляющийся, регулярно пересматриваемый тест-план вместе с результатами тестирования – у вас есть куда более солидная база для обсуждения тестирования, повышающая прозрачность того, что вы делаете для улучшения качества продукта.
Тест-план может помочь вам обдумать, какая подготовительная работа вам нужна. Это особенно важно, если вы не контролируете то, что может вам понадобиться в процессе тестирования. Если вам нужны серверы, данные или доступ к инструментам, то с шансами вы будете во всеоружии, как только они будут доступны – если вы заранее все спланируете. Очень важно быть готовым к действиям, как только появится что-либо, что можно тестировать.
Эта информация также полезна во время ретроспектив и пост-мортемов, позволяя лучше принимать решения и обсуждать, как можно улучшить тестирование.
Полезный тест-план
Используйте тест-план с пользой – как механизм для поиска ответов, как катализатор обмена информацией и достижения консенсуса, и для самоподготовки. Пусть он приносит ценность вам и остальным участникам проекта. Он должен работать на вас, а не против вас, а если он этого не делает – избавьтесь от него.
Об авторе
Ричард Патерсон руководит тестированием и безопасностью приложений в SAS R&D (Шотландия). Он считает себя не только тестировщиком, но и дизайнером, лидером и создателем.
За план тестирования замолвите слово
Приветствую участников уважаемого сообщества.
Я работаю тестировщиком (интернет-магазин). Вектор – управление тест-кейсами, QA — менеджмент, JUnit — тестирование, автоматизация, программирование на Java. Мне хотелось бы поделиться с коллегами своим опытом. Может, кому пригодится.
Предмет статьи – план тестирования и инструментарий для его составления.
Итак, есть задача – протестировать работу мобильной версии сайта на фронте. Есть собственное желание – оставить потомкам и коллегам вменяемый мануал по тестированию, когда не надо будет придумывать, что бы такое потестить. Я за взаимозаменяемость, универсальность и наглядность! Постулат – структура сайта должна быть представлена в виде дерева для облегчения восприятия и получения перспективы.
Пошаговый процесс построения дерева для плана тестирования:
1. Первый уровень: указание раздела «Страницы» и глобальные элементы (сквозные элементы – элементы шапки, подвал).
2. Второй уровень: перечисление страниц.
3. Третий уровень: перечисление общих свойств страницы и ее особых состояний (например, полная или пустая корзина).
4. Четвертый уровень:
— указание раздела «Элементы»,
— указание раздела «События» для страницы,
— перечисление крупных блоков элементов (например, блок товарных подкатегорий с большим количеством элементов),
5. Пятый уровень: перечисление типов элементов (текстовые блоки, ссылки, поля, кнопки, чекбоксы, счетчики, формы, фото, баннеры, иконки, значки, капча…).
6. Шестой уровень: перечисление названий элементов, относящихся к соответствующему типу элемента (например, названий полей для типа элемента «Поле»).
7. Седьмой уровень: указание на предмет тестирования по конкретному элементу и на раздел «Действия» / «События» для описания функционального тестирования:
7.1. Текстовый блок (конкретный):
— верное расположение на странице,
— корректный формат текста,
— корректное отображение верстки,
— элемент нельзя изменить,
…
7.2. Ссылки:
— верное расположение,
— возможность нажать,
— наличие нужного текста,
— нажатие не вызывает ошибку,
— ссылка ведет на нужную страницу,
— элемент нельзя изменить,
…
7.3. Поля:
7.3.1. Верное расположение,
7.3.2. Корректный формат,
7.3.3. Элемент нельзя изменить,
7.3.4. Действия (набор зависит от типов данных, которые содержатся в данном поле – например, числа, — и функционала элемента – например, поле для ввода):
7.3.4.1. Принимает верное значение.
7.3.4.2. Принимает ложное значение.
7.3.4.3. Не принимает текст.
7.3.4.4. Не принимает спецсимволы.
7.3.4.5. Не принимает инъекции.
7.3.4.6. Не принимает / интерпретирует число в другой системе исчисления.
7.3.4.7. Не принимает формулы и операции деления на 0.
7.3.4.8. Не принимает / интерпретирует в целое дробное число,
…
7.4. Кнопки:
7.4.1. Верное расположение,
7.4.2. Возможность нажать,
7.4.3. Наличие нужного текста,
7.4.4. Элемент нельзя изменить,
7.4.5. Действия:
7.4.5.1. Вызывает необходимую форму / запускает определенный процесс.
7.4.5.2. Нажатие не приводит к возникновению явной ошибки текущей страницы или в результатах процесса.
7.4.5.3. Нажатие не приводит к перемещению на другую страницу.
7.4.5.4. Нажатие не приводит к зависанию,
…
7.5. Чекбоксы / флаги:
7.5.1. Верное расположение,
7.5.2. Возможность выделить / снять выделение,
7.5.3. Элемент нельзя изменить,
7.5.4. Действия:
7.5.4.1. Выделение не приводит к возникновению ошибки на текущей странице.
7.5.4.2. Выделение не приводит к запуску постороннего процесса.
7.5.4.3. Выделение не приводит к зависанию,
…
7.6. Счетчики:
— верное расположение,
— отображение целого числа (количества единиц товара),
— корректный формат отображения,
— элемент нельзя изменить,
— соответствие числового значения счетчика исходной величине,
…
7.7. Формы:
7.7.1. Верное расположение,
7.7.2. Корректный формат отображения,
7.7.3. Элемент нельзя изменить,
7.7.4. Элементы:
7.7.4.1. Поля
7.7.4.2. Кнопки
7.7.4.3. Ссылки
…
7.7.5. События:
7.7.5.1. Очистка полей формы после отправки данных.
7.7.5.2. Очистка полей формы после обновления страницы.
…
7.8. Фото (с механизмом просмотра увеличенной фотографии):
7.8.1. Верное расположение,
7.8.2. Корректное отображение,
7.8.3. Возможность нажать,
7.8.4. Элемент нельзя изменить,
7.8.5. События:
7.8.5.1. Нажатие приводит к появлению увеличенной фотографии,
7.8.5.2. Нажатие не приводит к какой-либо ошибке,
…
Это описание плана тестирования, который охватывает, в основном, проверку свойств указанных элементов.
Сюда же, в разделы «События» и «Действия» я добавляю тест-кейсы для функционального тестирования:
— факт добавления выбранного товара в корзину после нажатия на кнопку «В корзину»,
— верный расчет стоимости доставки при выборе разных регионов и т.д.
Что даст мне удобное представление плана тестирования?
— перспективу (предстоящий объем работ);
— понимание структуры тестируемого объекта (и не обязательно сайта – даже ракеты);
— понимание степени покрытия тест-кейсами объекта тестирования;
— представление о том, тестирование чего я могу автоматизировать;
— в конце концов, +1 к ЧСВ (шутка).
Как известно, даже хорошему пилоту нужен самолет с крыльями.
Мой самолет с крыльями – это XMind 6.
Я создаю файл, где центральным элементом указываю, например, квадратик с текстом «ПланТестирования (мобильная версия)». После некоторого времени наброски плана в соответствии с принципом построения, описанным выше, план становится похож на корневую систему:
Да, у меня уже есть некоторое представление об объемах тестирования. Его будет много…
Первое, с чего я начал, указание раздела «Страницы» и глобальные элементы (сквозные элементы – элементы шапки, подвал):
Дальше — перечисление страниц:
Далее (см. Третий уровень – выше) – перечисление общих свойств страницы и ее особых состояний (например, полная или пустая корзина):
Далее (см. Четвертый уровень) — перечисление общих свойств страницы, событий для нее:
Далее — перечисление типов элементов (текстовые блоки, ссылки, поля…):
Далее – перечисление названий элементов, относящихся к соответствующему типу элемента:
И последний основной уровень – седьмой: указание на предмет тестирования по конкретному элементу и на раздел «Действия» / «События» для описания функционального тестирования:
Такой элемент как форма требует дополнительных уровней вложения, т.к. содержит в себе простые элементы – поля, кнопки и т.д.
И так для каждой страницы. Да, требуется время на составление. А как же еще? Зато теперь я имею на руках карту, которую смогу проецировать на мобильную версию в случае ее обновления — немного подкорректирую. А что мне даст удобное представление плана тестирования – прошу прочесть выше.
Зеленый флаг — тест прошел, красный — баг. Если хотя бы один тест завален, красный флаг проставляется у всех родителей — чтобы можно было с самого открытия плана понять: есть проблемы.
Все изменения по файлу программы можно учитывать с помощью Git’а.
Можно посадить коллегу или новенького на место тестировщика и дать ему такой план для ознакомления со структурой сайта и процессом тестирования. Мой способ ни в коем случае не заменяет системы управления тест-кейсами, а всего лишь добавляет ее.
Все данные публикации, касающиеся описания структуры плана, являются общими для большинства сайтов интернет-магазинов, поэтому не несут какой-либо коммерческой тайны.
Теория тестирования ПО просто и понятно
Привет, Хабр! Да-да, про тестирование ПО тут уже куча статей. Здесь я просто буду стараться структурировать как можно более полный охват данных из разных источников (чтобы по теории все основное было сразу в одном месте, и новичкам, например, было легче ориентироваться). При этом, чтобы статья не казалась слишком громоздкой, информация будет представлена без излишней детализации, как необходимая и достаточная для прохождения собеседования (согласно моему опыту), рассчитанное на стажеров/джунов (как вариант, эта информация может быть для общего понимания полезна ИТ-рекрутерам, которые проводят первичное собеседование и попутно задают некоторые около-технические вопросы).
ОСНОВНЫЕ ТЕРМИНЫ
Тестирование ПО (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). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для покрытия продукта тестами.