К основному контенту

Тестирование user story

На приведенной ниже схеме наглядно представлено как качественно протестировать user story/ (Источник: http://www.xmind.net/m/V9WU. Автор Д. Манухина).

Первый этап к составлению тест кейсов это определение и согласование стратегии тестирования:
·       Определение уровней тестирования
·       Учет рисков по проекту/продукту
·       Построение матрицы взаимодействия компонентов
·       Определяем какой функционал будем тестировать, а какой нет
·       Определяем глубину тестирования, % приемлемого тестового покрытия и критерии выхода
·       Определяем временные рамки с учетом того, что user story могут передать в тестирование в конце итерации
·       Выполняем тестирование user story
Второй этап - определение необходимых видов тестирования user story.
- Функциональное
- Нефункциональное (ISTQB)
·       Reliability testing (надежности)
·       Usability testing (удобства использования)
·       Efficiency testing (эффективности)
·       Maintainability testing (работоспособности)
·       Portability testing (переносимости)
·       Baseline testing (основной функционал)
·       Compliance testing (в соответствии с требованиями)
·       Documentation testing (тестирование документации)
·       Endurance testing (на выносливость)
·       Load testing (нагрузочное)
·       Performance testing (производительности)
·       Compatibility testing (совместимости)
·       Security testing (безопасности)
·       Scalability testing (масштабируемость)
·       Volume testing (объемное)
·       Stress testing (стресс - тестирование)
·       Recovery testing (восстановления)
·       Internationalization testing and Localization testing (локализации (адаптации) и интернационализации)
Далее учитываем предъявляемые требования к характеристикам качества продукта и определяем необходимые техники тест – дизайна:
1.     Метод тестирования черного ящика (Black Box Testing Techniques)
- Классы эквивалентности (Equivalence Class Testing).
Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала – 0.
- Граничные значения (Boundary Value Testing).
Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10), и значения больше и меньше границ (0 и 11). Анализ граничных значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
- Комбинированное тестирование (Combinatorial)
·       Попарное тестирование (Pairwise Testing). Подробное описание данного метода можно изучить по ссылке (http://software-testing.ru/library/testing/test-analysis/1304-pairing)
·       Ортогональный массив (Orthogonal arrays). Двумерный массив, построенный со специальными математическими свойствами, так что при выборе двух любых столбцовмассива, каждому члену массива соответствует пара комбинаций
- Таблица принятия решений (Decision Table Testing).
Это способ компактного представления модели со сложной логикой. Простыми словами, это варианты действий при различных входных условиях.
- Тестирование состояний (State-Transition Testing)
- Доменный анализ (Domain Analysis Testing)
- Таблица использования (Use Case Testing)
- Дерево классификации (Classification trees).
Метод классификационного дерева поддерживает систематическое определение и описание тестовых примеров. Он основан на идее тестирования разделов. С помощью метода классификационного дерева входная область тестового объекта рассматривается в различных аспектах, оцененных соответствующим специалистом. Для каждого аспекта формируются непересекающиеся и полные классификации. Классы, полученные в результате этих классификаций, могут быть дополнительно классифицированы - даже рекурсивно. Тестовые примеры формируются путем объединения классов разных классификаций. Пошаговое разбиение входного домена с помощью классификаций представляется графически в виде дерева. Это дерево впоследствии используется для формирования таблицы комбинаций, в которой отмечены тестовые примеры. Расширения графической нотации и поддержки инструмента позволяют использовать этот метод даже для серьезных проблем с тестированием.
- Test Trees
- Графическое представление причинно-следственных связей (Cause Effect graphing).
Создание тестовых примеров (test case) при помощи графов причинно-следственных связей.
2. Тестирование белого ящика (White Box Testing Techniques)
- Тестирование потоков управления (Control Flow Testing).
Основанно на определении путей выполнения кода программного модуля и создания выполняемых тест кейсов для покрытия этих путей.
- Тестирования потока данных (Data Flow Testing)
3. Основанное на опыте (Experience-based)
- Предугадывание (Error guessing).
Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы "предугадать" при каких входных условиях система может выдать ошибку. Например, спецификация говорит: "пользователь должен ввести код". Тест аналитик, будет думать: "Что, если я не введу код?", "Что, если я введу неправильный код? ", и так далее. Это и есть предугадывание ошибки. 
- Исследовательское (Exploratory Testing)
Следующим этапом формулируем список возможных багов с помощью техники предугадывания. Проводим анализ  рисков:
- новых рисков, возможных при реализации текущей,
- проводим анализ взаимодействия новых и имеющихся рисков,
- доопределяем стратегию работы с ними
Проводим также анализ воздействия нового функционала на существующую матрицу взаимодействия и при необходимости корректируем ее.
На втором этапе мы выбирали способы тестирования. Часть можно автоматизировать, и, возможно, при тестировании других user story уже были написаны автотесты. Поэтому необходимо определить, необходимо ли писать новые автотесты или вносить корректировки в уже существующие.
Для тестирования возможно потребуется подготовка тестовых данных, создание которой также можно автоматизировать (при необходимости).
Подходя к завершению анализа user story, требуется определить, какие доработки необходимо внести в тест – кейсы для проведения регрессионного тестирования или добавить новые.
Проведя различный анализ user story, определяем способ и место фиксации тестов. У скриптового подхода:
- тест-кейсы
- приемочные тест-кейсы
- чек – листы
У исследовательского – фиксация сессии.
            В заключении, необходимо провести оценку временных трудозатрат, потраченных на каждый этап:
·       Создание тест-кейсов
·       Подготовка тестовых данных
·       Тестирование функционала
·       Нефункциональное тестирование
·       Работа с автотестами

Комментарии

Популярные сообщения из этого блога

Дымовое, критического пути и расширенное тестирование

Из приведенной ранее классификации тестирования (в статье " С чего начинать изучение тестирования? Конечно же с методов! ") нам осталось рассмотреть «по степени важности тестируемых функций». Но, на этом теория еще не заканчивается) Итак, по степени важности тестируемых функций разделяют следующие виды: - «Дымовое» (smoke) - тестирование, которое состоит из минимального набора тестов на явные ошибки. Дымовое тестирование на начальном этапе выявляет основные критические дефекты. Исходя из того, что данные проверки практически всегда одинаковы и редко претерпевают изменениям, целесообразно будет их автоматизировать. Ежедневная сборка продукта и smoke тестирование являются передовыми практическими методами. Программу, не проходящую "дымовой тест", не имеет смысла отдавать для более глубокого тестирования. - Критического пути ( critical path test ) — основной тип тестовых испытаний, во время которого значимые элементы и функции приложения проверяются н

Тест план и тестовая модель - что это?

Test Plan (тест план)  — это документ или совокупность документов, расписывающих всю тестовую активность (цели, подходы, ресурсы и график запланированных тестовых активностей)  в пределах одного проекта, все работы проводимые командой тестирования или одним тестировщиком. В стандарте IEEE 829 перечислены пункты, из которых должен состоять тест-план:   1) Test plan identifier (идентификатор);   2) Introduction (описание/цель) - Предельно краткое описание цели разработки приложения (частично это напоминает бизнес-требования);   3) Features to be tested (Области, подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые будут подвергнуты тестированию. В некоторых случаях здесь также приводится приоритет соответствующей области. 4) Features not to be tested (Области, не подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые не будут подвергнуты тестированию. Причины исключе

Советы для молодых тестировщиков или как составлять тест - кейс =)

Тест (test) представляет собой набор операций, предназначенных для получения одного или большего числа ожидаемых результатов в некоторой программной системе. Тест-кейсы должен помочь тестировщику (даже начинающему) провести проверку продукта без ознакомления со всей документацией. В тест – кейсе желательно избегать зависимостей от других тест – кейсов. Тест кейс в основном состоит из * Основных параметров - id (номер) - уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь (например, дать ссылку в баге). - Автор – имя и фамилия тестировщика, который написал тест – кей. - Название — краткое описание сути проверки. - Предусловие – предварительные шаги. - Шаги – что нужно сделать, чтобы что-то получить. - Ожидаемый результат – тот результат, который соответствует документации или здравому смыслу =). - Фактический результат – то, что получилось в итоге действия в шаге. - Постусловия – заключительные ша