Тест план (Test Plan) — это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Рекомендации по написанию Тест Плана
Каждая методология или процесс пытаются навязать нам свои форматы оформления планов тестирования. Предлагаю вам, как пример, шаблоны тест планов от RUP (Rational Unified Process) и стандарт IEEE 829:
- Test Plan Template RUP
- Test Plan Template IEEE 829
Присмотревшись внимательнее становится ясно, что оба документа описывают одно и тоже, но в разной форме. В случае, если вам не подходит стандартный шаблон или вы решили придумать свой собственный, более подходящий для вас формат документа, то из опыта можем сказать, что хороший тест план должен как минимум описывать следующее:
- Что надо тестировать?
- описание объекта тестирования: системы, приложения, оборудования
- Что будете тестировать?
- список функций и описание тестируемой системы и её компонент в отдельности
- Как будете тестировать?
- стратегия тестирования, а именно: виды тестирования и их применение по отношению к объекту тестирования
- Когда будете тестировать?
- последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки
- Критерии начала тестирования:
- готовность тестовой платформы (тестового стенда)
- законченность разработки требуемого функционала
- наличие всей необходимой документации
- .
- Критерии окончания тестирования:
- результаты тестирования удовлетворяют критериям качества продукта:
- требования к количеству открытых багов выполнены
- выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF)
- выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB)
Позитивность тестов, негативное тестирование / Урок 14 / Тестировщик с нуля
ZBB = Zero Bug Bounce
После завершения фазы разработки новой функциональности, начинается фаза стабилизации, когда разработчики занимаются только исправлением дефектов. В какой-то момент, когда скорость исправления начинает превосходить скорость открытия новых, может наступить момент, когда у вас будет 0 открытых/активных дефектов (ZB — Zero Bugs). Именно тогда и можно сказать, что мы выходим на стадию — Zero-Bug Bounce. Начиная с этого момента каждый новый дефект проходит проверку, и если он не критичен для данного релиза, то он переносится на следующий. Если же дефект оказался критичным, то его придется исправить, что значит, что мы вышли из состояния ZB, и нам придется вернуться туда еще раз, пока мы, наконец, не удовлетворим все критерии готовности продукта к выпуску.
Тестирование для дегенератов
Ответив в своем тест плане на вышеперечисленные вопросы, можно считать, что у вас на руках уже есть хороший черновик документа по планированию тестирования. Далее, чтобы документ приобрел более менее серьезный вид, предлагаем дополнить его следующими пунктами:
- Окружение тестируемой системы (описание программно-аппаратных средств)
- Необходимое для тестирования оборудование и программные средства (тестовый стенд и его конфигурация, программы для автоматизированного тестирования и т.д.)
- Риски и пути их разрешения
Виды тест планов
Чаще всего на практике приходится сталкиваться со следующими видами тест планов:
Явное отличие Мастер Тест Плана от просто Тест Плана в том, что мастер тест план является более статичным в силу того, что содержит в себе высокоуровневую (High Level) информацию, которая не подвержена частому изменению в процессе тестирования и пересмотра требований. Сам же детальный тест план, который содержит более конкретную информацию по стратегии, видам тестировании, расписанию выполнения работ, является «живым» документом, который постоянно претерпевает изменения, отражающие реальное положение дел на проекте.
В повседневной жизни на проекте может быть один Мастер Тест План и несколько детальных тест планов, описывающих отдельные модули одного приложения.
Рецензия и Утверждение
Для увеличения ценности вашего тест плана рекомендуется проводить его периодическое рецензирование со стороны участников проектной группы. Это можно сделать просто договорившись между собой или же реализовать в виде «процедуры утверждения». Как пример, приведем список участников проектной группы, утверждение которых мы считаем необходимым:
- Ведущий тестировщик
- Тест менеджер (менеджер по качеству)
- Руководитель разработки
- Менеджер Проекта
Каждый из перечисленных участников проекта, перед утверждением, проведет рецензию и внесет свои комментарии и предложения, которые помогут сделать Ваш тест план более полным и качественным.
Вывод
Воспользовавшись вышеуказанными советами, у вас будет больше шансов написать хороший документ, нежели придумывать все самим.
Источник: protesting.ru
Как писать тест-кейсы: полное руководство
Во время тестирования QA-инженер работает с большим количеством документации. Чеклисты, наборы тестов, тестовые сценарии, планы тестирования, отчеты о тестировании, анализ тестирования — это лишь часть списка документов, которые должны уметь создавать тестировщики. Здесь речь пойдет о тест-кейсах.
Что такое тест-кейс и зачем он нужен
Тест-кейс — это четкое описание действий, которые нужно выполнить для проверки отдельной функции вашего приложения.
Тестировщик создает тест-кейс, чтобы проверить, работает ли определенная фича должным образом, и чтобы подтвердить, что функционал, UI/UX и другие параметры системы удовлетворяют всем соответствующим стандартам, руководствам и требованиям клиентов.
Чем отличаются тест-кейс и чеклист
Тест-кейсы используются для сложных проектов. Например, когда от поведения системы зависит человеческая жизнь. Это могут быть проекты, связанные с пожарной безопасностью, здравоохранением, финансами и т. д. В таких случаях все нужно тестировать очень тщательно.
Чеклист QA — это список того, что нужно протестировать. Благодаря ему процесс тестирования проходит более четко и аккуратно.
Обычно при работе с простыми системами — сайтами, мобильными приложениями и т. д. — нет необходимости в тест-кейсах. Часто в команде бывает только один-два тестировщика, которые хорошо знают свой продукт. В таком случае время, потраченное на создание и поддержку тест-кейсов, никогда не окупится. Лучше создать чеклист со списком функций, которые нужно проверить — это будет более рационально.
Позитивные, негативные и деструктивные тест-кейсы
В позитивных тест-кейсах используются корректные входные данные и сценарии ожидаемой работы системы. Цель здесь — убедиться, что программный продукт выполняет то, что должен делать, и что система не выдаст ошибку, если это не предусмотрено.
В целом позитивное тестирование гарантирует, что система соответствует требованиям при позитивных сценариях нормального использования.
Например, если поле пароля принимает десять символов, пользователь должен иметь возможность создать такой пароль.
Негативные тест-кейсы используют некорректные входные данные и проверяют, не делает ли программа того, чего не должна делать. Негативное тестирование призвано гарантировать, что при получении некорректных входных данных система не будет работать по нормальному сценарию (например, выбросит ошибку).
Если вернуться к нашему примеру, пользователь не должен иметь возможность создать пароль, состоящий из 11 символов.
Деструктивные тест-кейсы создаются, чтобы узнать предел прочности системы. Нагрузочное тестирование — распространенный вариант деструктивного тестирования.
Для деструктивного тестирования QA-специалисты могут применять следующие методы:
- создание большой нагрузки на систему, чтобы это привело к ее отказу;
- злонамеренное внедрение JavaScript в веб-форму;
- фаст-кликинг в попытках взломать веб-страницу и т. д.
Атрибуты тест-кейса для ручного тестирования
Как и все тестировочные документы, тест-кейс имеет определенный формат. Он содержит следующие атрибуты:
Кроме того, для некоторых тест-кейсов могут потребоваться дополнительные атрибуты:
- Требования к среде — специальное оборудование, программное обеспечение и т. п. вещи, необходимые для выполнения тест-кейса и не перечисленные в соответствующей спецификации проекта тестирования.
- Специальные процедурные требования — особые процедуры настройки, выполнения или очистки, уникальные для этого тест-кейса.
- Межкейсовые зависимости — тест-кейсы, которые нужно выполнить перед этим тест-кейсом.
Характеристики хорошего тест-кейса
Прежде всего, тест-кейс не должен быть зависимым или связанным с другими тест-кейсами. Он должен быть полным и самодостаточным. Следует избегать расплывчатых описаний шагов или ожидаемых результатов. Любые ограничения, отсутствие необходимой информации или чрезмерное количество деталей делают тест-кейсы менее эффективными.
Короче говоря, хороший тест-кейс:
- понятен любому члену команды;
- аккуратно и точно написан;
- соответствует требованиям;
- воспроизводим;
- пригоден для многократного использования.
Best practices в написании тест-кейсов
Под best practices мы подразумеваем правила, которые помогают создавать простые, понятные и полезные тест-кейсы:
- Перед созданием нового тест-кейса убедитесь, что он не дублирует ни один из уже существующих в системе.
- Убедитесь, что тест-кейс покрывает 100% требований, которые вы должны проверить.
- Помните о теории методов тестирования, таких как анализ граничных значений, разделение эквивалентности, техника перехода состояния, угадывание ошибок.
- Помимо требований к системе, всегда помните о конечном пользователе, который будет взаимодействовать с системой.
- Не забудьте указать учетные данные, если они необходимы для выполнения теста.
- Позаботьтесь о тестировщиках, которые будут работать с этим тест-кейсом в будущем. В частности, убедитесь, что все ссылки верны и кликабельны. Пожалуйста, не используйте ссылки на продакшен.
- Используйте повелительное наклонение, например: «Перейдите на главную страницу», «Введите данные», «Кликните» и т. д. Такая формулировка упрощает понимание этапов тестирования и ускоряет их выполнение.
Формирование тест-кейсов
Обычно при написании тест-кейсов тестировщики пользуются таблицами Excel. Но вы также можете использовать инструменты управления тестированием, такие как TestRail.
Примеры тест-кейсов для ручного тестирования
Позитивный тест-кейс
Давайте попробуем создать наш собственный тест-кейс для ручного тестирования функции поиска на e-commerce сайте компании FootWear. Начнем с позитивного теста.
ID: FWSF-1. (Лучше использовать числа в возрастающем порядке. FWSF = FootWear Search Functionality. Попробуйте придумать комбинацию букв, имеющую отношение к проекту или функции, которую вы собираетесь тестировать).
Предусловия: Нужно иметь предварительно настроенные продукты из разных категорий, отображаемые на сайте. (Для проверки функциональности нам необходимо иметь элементы, доступные для поиска. Вы можете настроить это в панели администратора или в базе данных).
Шаги:
- Откройте домашнюю страницу. (Ссылка не обязательна, ее наличие может затруднить поддержку тест-кейса в будущем).
- Введите в поле поиска ключевое слово, связанное с названием доступного продукта.
- Выполните поиск, кликнув значок поиска или нажав Enter.
- Проверьте результаты.
Ожидаемый результат: На странице результатов поиска отображаются все релевантные результаты.
Деструктивный тест-кейс
Еще один пример — деструктивный тест-кейс.
ID: FWSF-2.
Предусловия: Подготовьте SQL-запрос, который вы собираетесь вставить в поиск.
Шаги:
- Откройте домашнюю страницу.
- Введите SQL-запрос в поле поиска.
- Выполните поиск, кликнув значок поиска или нажав Enter.
- Проверьте, правильно ли отображаются результаты, нет ли сообщений об ошибках на странице результатов поиска.
Ожидаемый результат: Для защиты от SQL-инъекций отображение предупреждающих сообщений должно быть отключено.
Негативный тест-кейс
Наконец, вот вам негативный тест-кейс.
ID: FWSF-3.
Предусловия: Выпишите недопустимые значения для поля ввода поиска из системных требований.
Шаги:
- Откройте домашнюю страницу.
- Введите комбинацию недопустимых значений в поле поиска.
- Выполните поиск, кликнув значок поиска или нажав Enter.
- Проверьте, отображается ли предупреждающее сообщение «Пожалуйста, используйте только допустимые символы».
Ожидаемый результат: Отображается предупреждающее сообщение «Пожалуйста, используйте только допустимые символы». Поиск можно продолжить.
Итоги: тестирование тест-кейса
Итак, мы разобрали основы написания тест-кейсов. Совет напоследок: чтобы проверить, насколько хорош ваш тест-кейс, покажите его человеку, который ничего не знает о проекте, над которым вы работаете. Вопросы, которые вы услышите, помогут определить слабые места вашего тест-кейса. Обратите внимание на эти моменты и постарайтесь внести изменения как можно скорее, иначе в будущем для поддержки тест-кейсов потребуется гораздо больше времени и усилий.
Источник: testengineer.ru
Как придумывать тесты для программ
Как должен выглядеть хороший тест-кейс?
Опубликовано: 27.03.2015 | 95603
С тем, что тест-кейсы призваны помочь установить соответствие тестируемого функционала заявленным требованиям, мы уже разобрались в прошлой статье. Теперь самое время понять, что же представляют из себя подобные тестовые сценарии.
Проверенный шаблон
Наша практика показывает, что сценарии должны быть написаны по определенному шаблону. Это позволяет облегчить процесс работы с ними по проекту. Хороший тестовый сценарий обязательно включает в себя:
- Описание – отражает цель проверки.
- Предусловие (предварительные шаги) – содержит список шагов, которые необходимо выполнить до начала теста.
- Шаги – метод выполнения теста, описанный по шагам.
- Ожидаемый результат – предусмотренное поведение системы после прохождения по шагам.
- Статус кейса – проставляется в соответствии с тем, соответствует ли фактический результат ожидаемому.
Перечисленные пункты – обязательный минимум. Однако в некоторых случаях целесообразно расширение набора составляющих. Так, в сценариях могут появляться такие пункты, как глубина покрытия ТК, приоритет проверки, флаг включения в автотесты, id обнаруженных багов, связанных с проверкой и прочее.
Обязательные требования к тест-кейсам
- Отсутствие зависимостей друг от друга. Поскольку тесты могут дополняться, меняться, терять свою актуальность и удаляться – как в таком случае поступать с тестами, на которые ссылались эти кейсы? Кроме того, взаимосвязь может ввести в заблуждение, будто работа продукта соответствует ожиданиям.
- Четкие формулировки и высокая вероятность обнаружения ошибки.
- Наличие детальной, но не избыточной информации. Если проверке подлежит процесс авторизации, тест-кейс должен содержать логин и пароль.
- Легкая диагностика ошибок. Обнаруженная ошибка должна быть очевидной.
- Исследование соответствующей (непосредственно той, что нужно) области приложения, выполнение нужных действий.
Углубиться в проект мало, или Кому поручить написание тест-кейсов
Создание тест-кейсов – довольно сложный процесс, который требует не только основательного углубления в проект, но и определенных навыков. И потому тест-дизайнеры, в чью компетенцию входит эта работа, должны:
- Налаживать эффективную коммуникацию с разработчиками, менеджерами и пользователями для сбора данных по проекту и проведения QA-анализа.
- Правильно расставлять приоритеты, отделять более важное от менее значимого.
- Одинаково легко видеть систему в целом и проводить декомпозицию, чтобы была проверена каждая отдельная фича.
- Точно формулировать мысли и уметь их донести до коллег и заказчика.
- Умело применять техники тест-дизайна.
Выбор правильной техники тест-дизайна (способа создания тестов) особенно важен, ведь именно от этого зависит эффективность самих тестов.
Можно создать огромное количество тест-кейсов, которые мы будем даже не в состоянии выполнить или которые помогут нам выявить лишь тривиальные проблемы. Только правильно выбранная техника позволит свести к минимуму количество тестов, которые необходимо пройти, чтобы выявить серьезные ошибки. Это ключевой момент в написании сценариев, и мы непременно расскажем о техниках тест-дизайна подробнее в будущих статьях.
Пишем тест-кейсы – что дальше?
А дальше отправляем их на ревью, после чего – либо на автоматизацию, либо в план ручного тестирования.
Рис.:Пример оформления тест-кейсов
Имейте в виду, что автоматические тесты требуют более полного описания, включая, скажем, зависимые значения для проведения расчетов. Для ручной же проверки такая детализация не имеет смысла, равно как и для небольших по объему проектов; особенно для стабильных компаний с небольшой текучкой кадров, где большое количество досконально описанных тест-кейсов – лишние затраты на обслуживание тестирования.
Каких результатов ждать?
1. Положительного, когда ожидаемый результат совпал с фактическим.
2. Отрицательного, когда ожидаемый результат не совпал с фактическим, выявлена ошибка.
Однако существует и третий вариант, когда прохождение теста блокируется каким-либо дефектом.
Так что, по сути, результата может быть всего два. Кстати, каждый конкретный тест-кейс призван решить конкретную задачу, проверить конкретный элемент «цепочки» и ожидаемый результат для этого элемента всегда один. Прочего быть не должно.
Рекомендации в помощь
В завершение нам остается разве что поделиться парой хороших советов:
- Приступайте к тестированию как можно раньше, ещё до выхода первого билда.
- В первую очередь проводите позитивные тесты и только потом переходите к негативным.
- Начинайте с простых проверок. Используйте типовые пользовательские данные для ввода в систему. Если тест не пройдет даже на таких значениях, существование проблемы станет очевидным.
- Сложные и негативные сценарии запускайте только после проверки простых. Если продукт хорошо справляется с очевидными задачами, испытайте его реакцию на неочевидные.
- Раскладывайте приложение на отдельные модули и для каждого из которых составляйте список проверок (чек-лист).
- Не забывайте обновлять тесты, как только была обнаружена ошибка или изменена функциональность.
Успехов!
Источник: qawebmart.ru