Техники тест-дизайна

Каждый раз на конференциях Инфостарта я наблюдаю одну и ту же картину: выходит докладчик с вдохновляющим рассказом про тесты – и зал загорается. Все радуются: «Ура! В 1С есть тесты! Мы сейчас начнем их писать и жизнь наладится! Ничего не будет падать! Будем выпускать релизы вообще без проблем! Все ошибки уйдут в прошлое!»

Когда-то и я был таким же. Помню, как под впечатлением доклада Артура Аюханова «Механизмы тестирования в 1С. Использование методики TDD (разработка через тестирование) в 1С» я два дня потратил на то, чтобы во всем этом разобраться. Я тогда работал на почасовке, и мне за эти два дня никто не заплатил. Но я написал тесты для загрузки касс. Через неделю получил задачку по доработке этой загрузки, внес изменения, прогнал тесты – все зеленое, идеально! А на следующий день оказалось, что ни одна из 30 касс не загрузилась.

В тот момент я перешел в «фазу разочарования» – подумал, что зря убил два дня, никакого толку от этих тестов нет, и я, наверное, уже никогда этим заниматься не буду. Но потом до меня дошло: сломалось не то, что я проверял тестами, а то, что я забыл покрыть. Мне хватило саморефлексии, чтобы это осознать.

Такая же растерянность наблюдается и у других людей после того как они воодушевились, начали писать тесты, а потом зашли в тупик. Они спрашивают: «Мы написали тесты, но ошибки все равно возникают. Тесты проходят слишком долго, проверяют одно и то же и блокируют друг друга. Как со всем этим жить?»

Я пришел к выводу, что когда дело касается освоения новых технологий – языка программирования, новых инструментов или методик – мы все джуны. И это нормально: нам, как и всем джунам, нужно просто учиться.

И я сейчас попробую поделиться своим опытом по тест-дизайну. Расскажу о том, чем я пользуюсь.

 

Немного терминологии

 

Процесс тестирования заключается в том, что мы по итогам выполнения задачи проверяем, насколько заявленные требования соответствуют реально реализованным.

Важно, что тестирование всегда должно проводиться в искусственных условиях, и я надеюсь, что никто не тестирует задачу сразу на проде.

Результаты тестирования можно классифицировать как сбой, баг или ошибку.

• Сбой – это несоответствие факта ожидаемому. В той самой ситуации, когда обычно говорят: «Это не баг, а фича», правильнее говорить: «Это не баг, а сбой».

• Баг – это недостаток, который может привести к полному отказу определенной функциональности. Допустим, вы открываете форму документа, а она вообще не открывается, это как раз и будет багом.

• А ошибка – это то, что приводит к неправильному результату. Например, вы делаете приходную накладную, проводите ее, а товара на остатки приходит в два раза больше, чем в документе. Это уже будет ошибкой.

Чтобы все это выявить, тестировщики пишут тест-кейсы – по сути, такие же программы, но только в виде сценариев проверки:

• Тест-кейсы представляют собой последовательности шагов, различных условий и параметров.

• Позволяют проверить, совпадает ли фактический результат с ожидаемым.

Процесс проектирования тест-кейсов называется тест-дизайн. Техники тест-дизайна, которыми я хочу с вами поделиться, помогают:

• исключить непродуктивные тесты;

• ускорить тестирование за счет сокращения количества тест-кейсов;

• покрыть как можно больше функциональности.

 

С чем мы работаем?

 

При тестировании программного обеспечения всю систему обычно раскладывают на несколько составляющих:

• Объект – сущность, которая может менять свои состояния. Сюда же можно отнести понятие «список объектов», потому что он тоже может являться объектом: если мы можем совершать какие-то действия над списком, он будет являться отдельным объектом.

• Действие – операция, которая изменяет состояние объекта.

• Параметры и значения – элементарные части объекта, которые используются при выполнении действий.

 

Рассмотрим форму списка контрагентов.

• Объект здесь – сам контрагент.

• Действия, которые с ним возможны – создать, изменить или удалить.

• Параметры – это способ выполнения этих действий: поля ввода, кнопки и т.д.

• Значения – данные, которые мы будем вводить в эти поля. Или способ того, как мы будем нажимать кнопки – мышкой или с помощью горячих клавиш.

Именно на объекты, действия, параметры и их значения и направлены техники тестирования: мы проверяем, как они взаимодействуют и какие результаты это дает.

 

Классы эквивалентности

 

 

 

Начнем с базовой техники – классы эквивалентности. Думаю, многие используют ее интуитивно, даже не зная названия.

Суть техники: все возможные значения можно разделить на группы (классы), внутри которых поведение системы одинаково – при любом значении из класса тест либо пройдет, либо не пройдет.

• Техника позволяет сократить количество тестов.

• При группировке значений сохраняется тестовое покрытие.

• Опытные тестировщики обычно уже мыслят такими наборами классов и понимают, какие группы в любом случае надо проверять.

Признаки эквивалентности тестов:

1. Обычно они направлены на поиск одной и той же ошибки.

2. Одновременно падают или проходят.

3. У них похожие входные и выходные данные.

4. Совершают одни и те же операции.

Если тесты явно эквивалентные, их можно заменить – один на другой.

 

Посмотрим на примере: у нас есть форма, где нужно указать процент по счету. Какие классы эквивалентности здесь есть:

• Класс эквивалентности с допустимыми значениями: от 0 до 100. Какое именно число введено – неважно, оно появится в поле.

• Классы эквивалентности с недопустимыми значениями:

  • меньше 0 (от -∞ до 0);

  • больше 100 (от 100 до +∞);

  • классы, про которые забывают – например, в числовое поле ради интереса можно ввести буквы, посмотреть, что получится;

  • спецсимволы: конец строки, возврат каретки.

 

Граничные значения

 

 

 

Следующая техника вытекает из классов эквивалентности и называется граничные значения. Тестировщики говорят, что именно здесь прячутся баги.

• Граничные значения – это места, где один класс эквивалентности перетекает в другой.

• Для граничных значений часто «забывают» описать поведение – аналитики упускают их в ТЗ, а тестировщики ленятся их проверить, раз уж и так «все вроде работает».

Возьмем пример. Допустим, в ТЗ прописано правило расчета скидки от количества:

• если человек купил меньше 5 штук, мы не даем ему скидку;

• больше 5 штук – 1%;

• больше 10 штук – 5%;

• больше 25 – 15%.

Здесь есть понятные классы эквивалентности:

• до 5;

• от 5 до 10;

• от 10 до 25;

• и больше 25.

И есть граничные значения: 0, 5, 10, 25.

Чтобы определиться с нужными для этой задачи тестами, мы берем граничные значения и отступаем по чуть-чуть влево и вправо.

• Берем 0, отступаем чуть-чуть вперед – 1.

• Берем 5, отступаем чуть-чуть назад – 4.

• Вспоминаем, что у нас есть классы эквивалентности и объединяем 1 и 4 в одно значение – выбираем посередине 3.

В итоге получаем набор кейсов для значений: 0, 3, 5, 8, 10, 13, 25 и 28.

Обратите внимание, как много проверок потребовалось в таком простом примере. А теперь представьте, сколько проверок нужно для реальной системы с десятками полей и множеством условий.

В этом случае применяют технику попарного тестирования.

 

Попарное тестирование

 

 

Техника попарного тестирования – чисто статистическая.

• Она основана на том, что большинство дефектов возникает при взаимодействии не более двух значений параметров. Можно и трех, но статистически двух достаточно.

• Когда много параметров/значений, необязательно проверять всех со всеми. Но если вы не проверите каждую пару параметров, пользователь по-любому наткнется на ошибку на проде.

Рассмотрим пример – у нас есть сеть книжных магазинов, имеющая ряд параметров:

1. Город: представительства есть в Москве, Петербурге и Екатеринбурге.

2. Действие: в магазине можно купить книгу или продать.

3. Жанры: фантастика, детектив, компьютерная литература, женский роман.

4. Место операции: можно купить/продать книгу или онлайн в интернет-магазине, или прийти в магазин ногами.

5. Время работы: в магазине есть рабочие и нерабочие часы.

Если проверять каждую возможную комбинацию параметров, получается 96 тест-кейсов. Это много.

Здесь как раз и помогает попарное тестирование. Есть много разных программ, которые позволяют его реализовать, но мне больше всего нравится PICT. Он умеет собирать минимальный набор проверок, при котором все параметры хотя бы раз встречаются в паре друг с другом.

• PICT прекрасно работает в онлайне. Единственное, что в онлайне она не очень любит русский язык, поэтому я на слайде все перевел на английский.

• Причем если вы поставите консольную версию с GitHub, там есть русский язык и все прекрасно работает.

Работает это так:

• Формируем списки для каждого параметра: название и значения через запятую.

• Загружаем эти списки в программу.

• На выходе получаем сильно сокращенный набор кейсов.

Например, в данном примере получилось 12 кейсов вместо 96. При этом каждое сочетание параметров все равно проверяется.

PICT формирует кейсы в удобном формате – там есть настройка на разделитель строк, и можно просто скопировать результат, чтобы использовать как блок «Примеры» в Vanessa, если вы этим пользуетесь.

У PICT есть и дополнительные возможности – например, там можно учесть условия:

• У интернет-магазина нет нерабочего времени – совершение операций в онлайне доступно круглосуточно.

• В Екатеринбурге нет офлайн-магазина.

• Продавать фантастику в онлайне запрещено.

Вручную учесть все подобные условия в тест-кейсах сложно. А PICT позволяет указать эти условия с помощью простых правил (справа на слайде), и программа подберет корректные комбинации автоматически.

В итоге у нас опять получился компактный набор из 12 тест-кейсов, но все условия выполняются.

На этом простые техники закончились, далее будут более сложные.

 

Диаграмма состояний и переходов

 

 

 

Перейдем от работы со значениями к работе с объектами. И первая техника здесь – это диаграмма состояний и переходов.

Ее суть проста – мы описываем цикл жизни нашего объекта.

1. Выбираем объект системы.

2. Берем большой лист бумаги или онлайн-доску и выписываем вообще все состояния, которые у этого объекта системы могут быть.

3. Продумываем действия – как из одного состояния перетекать в другое.

4. При необходимости добавляем параметры для этих действий.

 

 

Рассмотрим пример – в качестве объекта возьмем документ «Заказ покупателя». У него могут быть состояния:

• Создан

• Заполнен

• Отмене

• Оплачен

• Собран

• Отгружен

• Завершен

 

 

Диаграмма переходов между этими состояниями будет выглядеть примерно так:

• Сначала мы создаем заказ – состояние «Создан».

• Менеджер его заполняет – состояние «Заполнен».

• Контрагент оплачивает – состояние «Оплачен».

• Заказ уходит в сборку на склад, там его собирают – состояние «Собран».

• Клиент товар забирает – у заказа состояние «Отгружен».

• Закончили работать с заказом и выходим из диаграммы– состояние «Завершен».

Можно добавить еще и альтернативные ветки – например, руководитель отдела продаж (РОП) может сразу отклонить сделку и заказ моментально получает статус «Завершен».

Эта техника хорошо отражает привычные сценарии пользователя. Просто идя по стрелкам, мы можем создавать готовые тест-кейсы. А если вы умеете сохранять в тесте состояние объекта, вы можете быстро протестировать любой переход для любой точки диаграммы.

Но пользователи же любят совершать и неочевидные действия. Для таких случаев используют следующую технику – цепочки действий.

 

Цепочки действий: стандартные и обобщенные

 

Эта техника может показаться сложной для понимания, но хорошая новость в том, что она разделена на две:

• стандартные цепочки действий;

• и обобщенные цепочки действий.

 

 

Самое прекрасное в стандартных цепочках действий – то, что над ними практически не надо думать. Просто берете и используете.

Например, над любым объектом системы можно совершить очевидные действия:

• создать;

• изменить и сохранить;

• и удалить.

 

Комбинируя эти действия, можно получить готовые проверки для любого объекта. Частично эти готовые цепочки действий покрываются дымовыми тестами, а то, что не покрывается, можно дополнить своими тест-кейсами.

Самые простые примеры готовых цепочек действий:

• Создать, изменить, удалить.

• Создать, изменить, изменить – так появляется «дважды измененный объект» – мы проверяем, что объект после изменений сохранил их и его еще раз после этого можно изменить.

• Также важно проверять, что происходит со связью. Например, у нас иерархический справочник: сначала создаем элемент, потом группу, далее помещаем элемент в группу, удаляем группу, и проверяем, что после этого случилось с элементом.

За простыми словами «создать», «изменить», «удалить» скрывается много сценариев:

• Создать. Как мы можем создать объект: через меню, хоткеями или загрузкой данных откуда-нибудь.

• Что мы в нем можем изменить: код, наименование, добавить комментарий.

• Как удалить: из карточки объекта или через хоткей.

Таким образом даже простая цепочка «создать, изменить, удалить» разрастается в набор тест-кейсов.

На слайде – сценарий стандартной цепочки действий по проверке подразделений.

Эта цепочка проверяет типовое создание двух подразделений, установку связи между ними и корректность работы пометки на удаление для родительского элемента.

Плюсы стандартных цепочек:

• Они значительно сокращают время тестирования – если базовые проверки не проходят, остальные сценарии проверять бессмысленно.

• Ускоряют нахождение багов – как раз за счет сокращения времени тестирования.

• Похожи на те действия, которые пользователь в любом случае совершит.

Минусы:

• Важно помнить о предусловиях: вы вряд ли сможете прогонять цепочки бесконечно, если не почистите за собой справочник.

• У стандартных цепочек нет единой цели – они просто проверяют существующие действия системы.

• За счет «краткости построения» стандартные цепочки не проверяют все действия, которые может совершить пользователь.

 

 

А чтобы построить цепочки, которые пользователь может совершить случайно, применяют обобщенные цепочки действий.

В таких цепочках выделяют три основных звена:

• Генератор – задает начальные условия.

• Трансформатор – отвечает за действия по изменению объекта.

• Монитор – проверка конечного результата.

 

 

Мы берем большой лист бумаги и выписываем вообще все возможные трансформаторы и мониторы для объекта.

Правила построения обобщенных цепочек достаточно простые.

1. Все начинается с Генератора – здесь нам нужны предусловия.

2. Все заканчивается Монитором.

3. Чтобы цепочки были нормальные, надо, чтобы встретились все пары Генератор+Трансформатор и Трансформатор+Трансформатор.

4. Еще говорят, что неплохо было бы хотя бы в какой-то из цепочек вызвать Монитор дважды подряд, чтобы понять, что это на самом деле Монитор, а не Трансформатор. Бывают такие ситуации, когда ты думаешь, что открываешь отчет, а он в этот момент почему-то меняет данные.

5. И хорошее правило, которое позволяет уменьшить количество тестов – цепочки можно склеивать.

Рассмотрим пример: нужно протестировать, как отображаются остатки товара в 1С:

• Генератор (Г) тут простой – мы просто заходим в 1С.

• Первый трансформатор (Т1) – заводим приходную накладную.

• Второй трансформатор (Т2) – заводим расходную накладную.

• Первый монитор (М1) – смотрим остатки в отчете по остаткам.

• Второй монитор (М2) – смотрим остатки в карточке о товаре.

После этого мы начинаем мозговой штурм или используем инструменты генерации тест-кейсов – тот же PICT позволяет создавать цепочки – и создаем набор коротких и длинных цепочек, охватывающих все действия пользователей:

• Первая простая цепочка: Г – Т1 – М1 – М2.

• Вторая простая цепочка: Г – Т2 – М2 – М1. Обратите внимание, мы здесь проверяем, что мониторы являются мониторами.

• Две сложных цепочки:

  • Г – Т1 – Т2 – М1 – М1.

  • Г – Т2 – Т1 – М2 – М2.

• А потом мы подумали, что можем это склеить, нарисовать большую цепочку:

  • Г – М1 – Т1 – Т1 – М2 – Т2 – М1 – М2.

Зато мы проверили все действия пользователя.

У коротких цепочек:

• Плюсы:

  • Их легко повторять сколько угодно раз.

  • От начала до конца проходят быстро.

  • Если вы нашли ошибку, вы просто еще раз перезапускаете цепочку.

• Минус:

  • Бывает, что генератор занимает много времени.

У длинных цепочек:

• Плюс:

  • Генератор мы вызываем всего один раз.

• Минус:

  • Найти ошибку посередине такой цепочки бывает тяжело.

Дальше посмотрим на расширенные техники.

 

Расширенные техники

 

Эти техники особенно полезны, когда вы только-только начинаете погружаться в тестирование или у вас в принципе непротестированный объект. Они дают хорошее покрытие, но имеют два недостатка: требуют много времени и быстро устаревают.

 

Таблица принятия решений

 

 

Первая расширенная техника называется таблица принятия решений. Суть в том, что, мы составляем таблицу, колонки которой соответствуют тест-кейсам. И в строки этой таблицы выписываем:

• Начальные условия.

• Действия, которые можем совершить.

• Конечный результат.

В результате каждая колонка становится готовым тест-кейсом.

 

 

Рассмотрим на примере. Мы выдаем кредит. Условия:

1. Возраст от 18 до 55.

2. Официальное трудоустройство.

3. Выплаты меньше трети дохода.

Нам надо проверить, выдать кредит или нет.

На первом этапе таблицу стоит нарисовать целиком, выписать все комбинации условий, которые есть.

А потом ее можно оптимизировать:

• Например, тест №3 здесь абсолютно бессмысленный, потому что там противоречащие условия – мы его можем выкинуть.

• Или мы можем сократить количество условий (сразу проверить вхождение в диапазон от 18 до 55 лет, не забыв при этом про граничные значения).

 

Анализ прав

 

 

Следующая техника – анализ прав. Мы проверяем, что пользователь может или не может делать в системе:

• Определяем физические права – то, что задано ролями или группами доступа из последних версий конфигураций.

• И смотрим логические роли – например, если мы являемся автором документа, у нас один набор прав, а когда мы открываем чужой документ, у нас другой набор прав.

Как это работает:

1. Находим все объекты.

2. Выявляем для них все действия.

3. Выявляем все физические роли.

4. Выявляем все логические роли.

5. Дальше мы комбинируем действия и логические роли, проверяя:

   1. что пользователь может выполнить;

   2. что пользовать НЕ может выполнить;

   3. а еще очень важно проверить, как поведет себя система, когда пользователь не может выполнить действие – вряд ли пользователь сильно обрадуется, когда он открывает документ, а ему написано «Отказано в доступе». Что ему теперь делать? Куда бежать? Непонятно.

В итоге получается таблица, похожая на таблицу принятия решений. В ней фиксируются варианты действий вроде:

• «Изменить свой»;

• «Изменить чужой»;

• «Удалить свой»;

• «Удалить чужой».

Каждая такая комбинация – это отдельный тест-кейс.

Важный момент: здесь не стоит применять технику классов эквивалентности. Например, если в первой строке таблицы везде стоит «Да», может показаться, что достаточно проверить только эту роль. Это не так – здесь все варианты должны быть протестированы.

 

Предугадывание ошибок и исчерпывающее тестирование

 

Теперь можно немного выдохнуть – в завершение рассмотрим две самые простые техники тестирования.

 

 

Одна из них называется предугадывание ошибок.

Суть подхода: мы используем собственный жизненный опыт и интуицию. У каждого тестировщика и просто пользователя накапливается багаж знаний о типичных сбоях. Все это стоит применять. Например:

• В поле даты я всегда пытаюсь ввести 31 февраля – просто посмотреть, что из этого получится.

• В числовое поле я обязательно попробую ввести текст.

• В текстовое поле я вставлю кусок «Войны и мира», чтобы посмотреть, что после этого произойдет с системой. Еще туда бывает интересно добавлять иероглифы.

Опирайтесь на свой опыт и придумывайте интересные кейсы, которые, возможно, даже не придут в голову пользователям. А возможно, как раз это они и сделают.

И последняя техника, которая сильно выделяется, называется исчерпывающее тестирование. Это своего рода недостижимый идеал и «святой Грааль». Суть этой техники в том, чтобы проверить абсолютно все варианты без использования классов эквивалентности и сокращения условий.

Например, если у нас есть поле для ввода процента, то в идеале мы должны проверить абсолютно все значения – от 0 до 100 и далее до бесконечности.

Понятно, что это вряд ли получится, но в отдельных случаях, когда нужно проверить ограниченный диапазон, этот подход применяют.

 

Закрепляем

 

Закрепим, что и когда использовать.

1. Когда мы работаем с параметрами и значениями, мы применяем классы эквивалентности и за счет этого сокращаем повторные тесты.

2. Граничные значения обязательны, потому что именно здесь прячутся баги.

3. Если у нас много параметров/значений, попарное тестирование хорошо оптимизирует тест-кейсы.

Для описания сценариев используем:

1. Диаграмму состояний переходов – она описывает жизненный путь объекта.

2. Таблицу принятия решений, где каждый столбец представляет собой тест-кейс.

3. Цепочки событий – с их помощью мы проверяем стандартные действия. В цепочках событий есть уже готовые цепочки, комбинации которых позволяют придумать интересные действия пользователя.

Что можно почитать?

• Я выделил два основных сайта в Рунете, позволяющих ознакомиться с тестированием: testengineer.ru и software-testing.ru – там можно читать все подряд.

• Есть интересная книга Ольги Назиной «Тест-дизайн. Практическое руководство для начинающих». Легко читается.

• И две хардкорные книги по тестированию, если вы в душе тестировщик:

  • Куликов Святослав «Тестирование программного обеспечения. Базовый курс»

  • Рон Петтон. Software Testing

 

Вопросы и ответы

 

Вы рассказывали про метод граничных значений, что в случае, если у нас есть интервалы: от 1 до 5, от 5 до 10, от 10 до 25, нам достаточно проверить только граничные значения и значения из этих интервалов, например, 1, 5 и 10, 26. Но что, если программист допустит ошибку и вместо условия «меньше 5» напишет «меньше 4»? Получается, что такой тест ошибку не выявит?

Обычно техника граничных значений применяется следующим образом: сначала берем граничные значения, а затем немного отступаем от них. Причем отступ делаем не на целые единицы, а, например, вычитаем одну десятую процента и проверяем уже полученные значения. Даже если в задаче ожидаются целые числа, система сама округлит значение и выполнит проверку.

А если проблема с тестами, я в 2022 году рассказывал про мутационное тестирование, оно как раз помогло бы найти ошибку в этом тест-кейсе.

Какими именно инструментами можно пользоваться для такого тестирования? Например, для проверки граничных значений.

Основные инструменты: ручка, бумага и голова.

В тестировании есть два подхода – «черный ящик» и «белый ящик». Все перечисленные техники используются в случае «черного ящика» – когда мы не знаем, что написано в коде, и строим тесты, исходя из документации. Никакие сканеры кода здесь не применяются.

Для попарного тестирования есть готовые программы, которые генерируют тесты, исходя из условий.

Для рисования диаграмм перехода есть онлайн-доски Miro и другие подобные сервисы.

Как обрабатывать кейсы с большим количеством условий?

Не всегда нужно проверять абсолютно все. В таких случаях стоит применять классы эквивалентности, чтобы упростить и сократить количество проверок. Если много именно входных условий, то, возможно, этот кейс стоит разбить на несколько.

Чтобы обеспечить качественное покрытие тестами, необходима хорошая документация либо четко прописанные требования. Обычно тест-кейсы строятся на их основе. Как у вас решается проблема составления документации и участвуют ли тестировщики в этом процессе?

Все зависит от конкретной команды. Если в команде есть отдельные тестировщики, они подключаются к тестированию еще на этапе описания требований. Программист еще не взял задачу в работу, а тестировщик уже изучает требования и думает над теми кейсами, которые будет использовать.

В нашей команде только два разработчика, отдельного тестировщика нет, и мы договариваемся между собой – оставляем в фича-файлах комментарии, к каким задачам данный тест относится, чтобы можно было посмотреть, почему он написан именно так.

Как тестировать бизнес-процессы – стоит ли их проверять полностью, от ввода первички до проверки результатов в отчетах? Или все-таки стоит дробить процесс на атомарные операции?

Здесь важно учитывать: чем длиннее цепочка (например, в случае с обобщенными цепочками действий), тем сложнее отлаживать ошибки. Если тест упал посередине, всё приходится прогонять заново.

Когда я только начинал писать тесты, мне хотелось проверять процесс целиком, ведь именно так действует пользователь. Но со временем я пришел к выводу, что лучше писать короткие, быстро воспроизводимые тесты – они дают больше пользы. Удобно, например, снять снапшот базы и запускать тест с него.

Выстраивайте приоритеты – отбирайте, что в системе нужно протестировать обязательно, а что можно пропустить. И здесь неважно, речь идет об интеграционных или юнит-тестах – если интеграция критически важна, ее, естественно, стоит закрыть тестом.

Вы сказали, что в вашей команде отдельного тестировщика нет. Сколько времени у вас уходит на тестирование, и как вы это преподносите заказчикам?

У нас продуктовая разработка, и тестирование действительно занимает много времени. Долгое время это было серьезной проблемой.

В итоге мы включили этап тестирования в саму задачу и теперь оцениваем ее целиком – сразу на этапе планирования учитываем и реализацию и тестирование.

В итоге получили два плюса:

• Перешли на систему оценки «в попугаях» вместо часов – после этого планировать стало проще, всем рекомендую.

• В каждую задачу уже заложено время на тестирование, и мы понимаем, что успеем сделать, а что не успеем. Мы не выделяем время на тестирование отдельно – мы его объединяем с временем реализацией и планируем вместе.

Как готовятся данные для тестов? Они каждый раз рандомные или есть база и тесты прогоняются всегда на одних и тех же данных? И есть ли человек, который отвечает за подготовку данных для тестов?

Выделенного человека нет. Мы сами готовим все данные.

Для подготовки данных есть множество инструментов. Например, в Vanessa-ADD есть инструмент для загрузки и подготовки данных «Сериализатор MXL».

Да, перед каждым тестом мы готовим среду, делаем срез не всей базы сразу, а только то, что мы будем использовать, причем постараемся сделать так, чтобы это не пересекалось с другими данными.

А структура теста стандартная – предусловия, загрузка всех данных, тест и проверка результата.

Вы рассказывали о тест-кейсах. А как насчёт тест-планов? Составляете ли вы рекомендации по тому, как тестировать задачи с помощью этих же методик?

Если в команде есть выделенные тестировщики, там у них есть внутренние рекомендации по написанию кейсов, и их ревью со стороны других тестировщиков. У них обычно есть тест-планы на новые задачи и на регрессию, потому что регрессия – процесс долгий, и лучше иметь заранее подготовленный набор проверок. У нас же всё проще: мы полагаемся на автоматические тесты, и все планы у нас фактически лежат в виде фича-файлов

Как вы тестируете процессы со сложным алгоритмом, у которых много точек входа?

В таких случаях удобно строить диаграмму состояний с переходами между ними. В идеальном мире мы хотим прогнать весь процесс от начала до конца, но на практике этого не требуется: достаточно видеть общую картину и тестировать небольшие фрагменты алгоритма по частям.

Приходилось ли собеседовать тестировщиков? Если да, то какие задания обычно даете кандидатам?

Я сам тестировщиков не нанимал, но у меня жена проходила собеседование на тестировщика, поэтому я знаю, что там спрашивают. Чаще всего кандидату дают практическое задание: есть тестовый стенд с простой формой, например, регистрация или ввод пароля, и нужно прямо на месте показать, как он будет ее проверять. Формат бывает разный: онлайн или офлайн, в офисе просто выдают ноутбук и наблюдают за ходом работы.

Вы говорили, что у таблиц принятия решений есть два недостатка – они требуют много времени и быстро устаревают. Почему быстро устаревают?

Диаграмму состояний и переходов при добавлении/изменении/ удалении нового условия проще поправить – один кусок вырезать, а другой добавить.

А с таблицей сложнее – при добавлении новой строки условия все кейсы приходится пересчитывать целиком. Например, если в кейсе выдачи кредита мы решим, что будем выдавать только при наличии российского гражданства, нам придется пересчитывать всю таблицу.

Многим людям таблицы нравятся больше – в них проще разбираться, чем в диаграмме, но их сложнее поддерживать в актуальном состоянии. Я предпочитаю пользоваться таблицами, только когда прихожу на блок, где до меня тестов не было.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.