QA Fest 2016. Андрей Мясников. Тест-дизайн для чайников

1
ОБО МНЕ
В тестировании c 2009
Прошел путь от Junior Tester
до Team Lead
Стоял и курил у истоков
Radio QA
Блог
Ленивого
Тестировщика

ТЕСТ-ДИЗАЙН
ДЛЯ ЧАЙНИКОВ
АНДРЕЙ МЯСНИКОВ
ONLINE PRESENCE WOT, QA COORDINATOR

3
О ролях и сценариях
О тестовых окружениях
О базовых методиках тест-дизайна
О ЧЕМ МЫ СЕГОДНЯ БУДЕМ ГОВОРИТЬ?

4
Positive
Negative
Impossible (ad-hoc)
О РОЛЯХ И СЦЕНАРИЯХ
ГЛАВНОЕ О ТЕСТОВЫХ ДАННЫХ

5
Тест-аналитик отвечает за определение необходимости и
достаточности каждого цикла тестов и оценку общего качества
испытаний по результатам тестов. Так же он несет ответственность за
донесение до команды интересов заказчика, который не всегда имеет
четкое или актуальное представление о состоянии проекта.
Так же, он берет на себя ответственность за предпринятые активности
и найденные баги. Роль тест-аналитика может быть присвоена одному
человеку, а может быть и поделена между собой группой людей.
В некоторых компаниях эта роль иногда присваивается Тест-дизайнеру
или просто считается одной из обязанностей тестировщика.
КТО ТАКОЙ ТЕСТ-АНАЛИТИК?

6
Тест дизайн – это этап процесса тестирования ПО, на котором
проектируются и создаются тестовые случаи (тест кейсы), в
соответствии с определёнными ранее критериями качества и целями
тестирования.
Попросту говоря, задача тест-дизайнера сводится к тому, чтобы
используя различные стратегии и техники тест дизайна, создать набор
тестовых случаев, обеспечивающий оптимальное тестовое покрытие
тестируемого приложения. Однако, на большинстве проектов эти роли
не выделяется, а доверяется обычным тестировщикам, что не всегда
положительно сказывается на качестве тестов, тестировании и, как из
этого следует, на качестве программного обеспечения (конечного
продукта).
КТО ТАКОЙ ТЕСТ-ДИЗАЙНЕР?

7
Обработка требований и покрытие требований тестами
НЕМНОЖКО О ТРЕБОВАНИЯХ

8
Простые неподробные проверки
для небольших проектов.
Удобно на ранних стадиях
разработки, когда интерфейс и
функционал будут меняться.
ЧЕКЛИСТЫ

9
Лёгкость написания и актуализации
Лёгкость и скорость прохождения
Простота декомпозиции
в любой момент времени
ЧЕКЛИСТЫ +

10
Нет подробности
Трудно соотнести с требованиями
Высокой точности покрытия не
достичь никогда
Сложность снятия метрик и оценок
ЧЕКЛИСТЫ -

11
Сценарии и наборы сценариев,
необходимые для полного
покрытия функционала тестами.
ТЕСТОВЫЕ СЦЕНАРИИ

12
Обеспечивают высокую степень покрытия
Легко рекомбинируются при наличии грамотного
хранилища тестов (ergo Testlink, Testrail)
Возможность привязать ряд сценариев к требованиям
Прямая дорога к автоматизации
Простота снятия метрик
ТЕСТОВЫЕ СЦЕНАРИИ +

13
Долго и муторно пишутся.
Зачастую громоздко и мучительно подробны.
Много времени уходит на актуализацию.
Необходим хороший инструмент для
хранилища
ТЕСТОВЫЕ СЦЕНАРИИ -

14
КАРТА ФУНКЦИОНАЛА

15
Наглядность
Простота
Помогает понять принцип работы
Возможность формировать фокус-сценарии
КАРТА ФУНКЦИОНАЛА +

16
Если приложение большое - вешайтесь
Если много интенраций - вешайтесь
Если источник данных не достоверен –
ну вы поняли.
КАРТА ФУНКЦИОНАЛА -

17
Сценарии могут быть ориентированы на любую цель.
Слышали про туры?
Проверка части функционала
Проверка логики
Проверка GUI
Проверка юзабилити
ОРИЕНТАЦИЯ СЦЕНАРИЕВ

18
Фокус-сценарий – сценарий,
направленный на проверку
одной функциональности или
одного состояния в продукте
ФОКУС-СЦЕНАРИЙ

19
Реальные
Виртуальные
Смешанные (stabbed)
Гибридные
О ТЕСТОВЫХ ОКРУЖЕНИЯХ
ТЕСТОВЫЕ ОКРУЖЕНИЯ

20
Классы эквивалентности и метод границ
Метод минимальных проверок
Диаграммы и таблицы переходов
Метод значений по умолчанию
Pair-wise
Тестирование на основе рисков
О БАЗОВЫХ МЕТОДИКАХ ТЕСТ-ДИЗАЙНА
ВВЕДЕНИЕ В ТЕСТ-ДИЗАЙН

21
Основной и, пожалуй, самый главный метод тест-дизайна.
Базируется на том, что для машины некоторые значения являются эквивалентными.
Как это работает?
Проверяем значения за границами
Выделяем возможные классы эквивалентности
Определяем границы классов
Проверяем вывернутость класса
Проверяем граничные значения
КЛАССЫ ЭКВИВАЛЕНТНОСТИ И МЕТОД ГРАНИЦ

22
Уменьшение объёма тест-кейзов
Уменьшение времени на тесты
Возможность получить высокие
результаты при низких затратах
Лучшее понимание механики продукта
КЛАССЫ ЭКВИВАЛЕНТНОСТИ И МЕТОД ГРАНИЦ +

23
Используется максимум изменений при минимуме проверок. Проверяются
только позитивные значения тестов.
МЕТОД МИНИМАЛЬНЫХ ПРОВЕРОК

24
Максимум покрытия при минимуме
тестов. (Имеется ввиду – максимальное
покрытие значений, которые может
покрыть ОДИН тест)
Самый простой подход
Быстро
МЕТОД МИНИМАЛЬНЫХ ПРОВЕРОК +

25
Можно пропустить баги, встречающиеся
в комбинациях значений
Самый простой подход
Не проверяется работа всех комбинаций
МЕТОД МИНИМАЛЬНЫХ ПРОВЕРОК -

26
1. Выписываем возможные состояния, пишем стандартные переходы.
2. Пишем нестандартные переходы, отметаем невозможные переходы
ДИАГРАММЫ ПЕРЕХОДОВ

27
Отличный способ визуализации состояний продукта
Позволяет увидеть варианты переходов, которые
можно пропустить
Можно отследить баг, сузив его локализацию до
конкретного перехода
Лучше помогает осознать внутреннюю механику
продукта
ДИАГРАММЫ ПЕРЕХОДОВ +

28
Можно упустить неочевидные переходы
При слишком сложной структуре продукта может
стать запутанной и громоздкой
Является лишь прелюдией
к применению других методов
Бесполезен при незнании хотя бы
базовой механики работы продукта
ДИАГРАММЫ ПЕРЕХОДОВ -

29
ТАБЛИЦЫ ПЕРЕХОДОВ

30
Есть инструменты, которые создадут
таблицу за вас
Видны все возможные варианты
переходов
Можно исключить повторения или
изоморфные варианты
ТАБЛИЦЫ ПЕРЕХОДОВ +

31
Применяется только при наличии
диаграммы
Зачастую является менее очевидной
чем диаграмма
Если составлять вручную для большого
приложения - вешайтесь
ТАБЛИЦЫ ПЕРЕХОДОВ -

32
(aka Метод атомарных проверок)
Проверка одного значения, отличного от дефолтных значений, в то время как
остальные остаются на своих местах.
Выписываем все необходимые элементы,
которые надо протестировать.
Выписываем их возможные значения.
Составляем таблицу истинности.
Вычеркиваем взаимоисключающие состояния
МЕТОД ЗНАЧЕНИЙ ПО УМОЛЧАНИЮ

33
Возможность покрыть все возможные
сочетания
Трудно упустить какие-либо значения
Систематичность подхода
МЕТОД ЗНАЧЕНИЙ ПО УМОЛЧАНИЮ +

34
Трудоёмкий процесс написания
Долго проходить
Без использования инструментов есть
возможность что-то упустить
Плох сам по себе, но хорошо работает с
методом классов эквивалентности
МЕТОД ЗНАЧЕНИЙ ПО УМОЛЧАНИЮ -

35
Базируется на построении ортогональных массивов.
Это такой массив, где в любых двух столбцах комбинация двух параметров
встречается только один раз.
(или вот посложнее: Ортогональный массив: двумерный массив, построенный со специальными математическими свойствами,
так что при выборе двух любых столбцов массива, каждому члену массива соответствует пара комбинаций. )
Классифицируем все элементы
Находим независимые элементы
Составляем таблицы пар (Allpairs)
Составляем сценарии Pair-wise
При необходимости убираем некоторые независимые элементы.
PAIR-WISE

36
Колоссальное сокращение сценариев
Колоссальное сокращение времени на тесты
Простота в обращении
Количество тестов = перемножение двух
максимальных наборов значений
PAIR-WISE +

37
Есть шанс неправильно классифицировать или
пропустить элемент, после чего весь тест будет эпик
фейлом
Есть вероятность неправильно выстроить сценарии
Эффективно применяется ТОЛЬКО после метода
классов эквивалентности.
Сложно локализуемое покрытие
PAIR-WISE -

38
RBT – вид тестирования, который выстраивает приоритеты тестов в зависимости от
важности и «влиятельности» функционала, который может отвалиться.
Приоритезируем функционал таким образом,
что самым приоритетным является тот,
вероятность отвалиться у которого максимальна.
Получившиеся приоритеты упорядочиваем по стоимости.
Составляем проверки на основе этих приоритетов
ТЕСТИРОВАНИЕ НА ОСНОВЕ РИСКОВ

39
Позволяет экономить время, тестируя
только те места, куда «падают бомбы»
Позволяет минимизировать затраты,
если пользователю попадет бажный
продукт
ТЕСТИРОВАНИЕ НА ОСНОВЕ РИСКОВ +

40
Есть вероятность упустить что-то очень важное
Самым дорогим и ломающимся не всегда является
основной функционал. Поэтому есть возможность
пропустить баги в нём.
Необходимость каждый раз переделывать проверки
ТЕСТИРОВАНИЕ НА ОСНОВЕ РИСКОВ -

41
«Advanced software testing»
(Rex Black)
«Тест-дизайн от А до Я»
(А. Баранцев)
«Ключевые моменты в процессах
тестирования» (Rex Black)
Тренинг «Школа Тест-дизайна»
(А. Баранцев & Michael Bolton)
ПРИБОРЫ И МАТЕРИАЛЫ
На почитать и послушать

СПАСИБО ЗА ВНИМАНИЕ!

ANDREY MYASNIKOV
Блог Ленивого Тестировщика:
lazy-tester.blogspot.com
ANY QUESTIONS?
Skype: flegma86 radio-qa.com

QA Fest 2016. Андрей Мясников. Тест-дизайн для чайников

More Related Content

What's hot (15)

Viewers also liked (20)

Similar to QA Fest 2016. Андрей Мясников. Тест-дизайн для чайников (20)

More from QAFest (20)

QA Fest 2016. Андрей Мясников. Тест-дизайн для чайников