Подскажите пожалуйста. Новый проект, тестов нет вообще. Есть веб-форма с несколькими вкладками, проходя по которым последовательно, пользователь создает некий документ. При этом, процесс создания может иметь несколько различных flow, в зависимости от выбираемых пользователем значений и отмечаемых им радиобаттонов и пр. Есть полностью опциональные вкладки формы или секции во вкладках. Некоторые моменты процесса создания имеют сложную логику.
Нужно как-то покрыть это все дело тест-кейсами, которые на первом этапе будут использоваться для ручного тестирования, а затем будут автоматизироваться.
Пока ни до чего не додумалась лучше, чем разбить процесс создания по местам ветвления сценариев и по вкладкам формы. Чтобы на выходе получились отдельные не очень большие блоки, из которых можно было бы собирать нужный flow.
Но, может быть, есть идеи, как это можно лучше организовать? Общепринятые практики?
Также не совсем понятно, создавать ли отдельно кейсы с минимумом проверок (которые буду чем-то вроде смок-тестов и будут также использоваться для создания предусловий для более поздних стадий процесса создания документа) и отдельно кейсы с более углубленными проверками. Или же стараться сразу вписать в каждый кейс все возможные проверки (включая ограничения полей, проверку на обязательное заполнение, инъекции и пр ). Но мне кажется это нецелесообразным и чрезмерным.
Извините за сумбурность изложения, если не очень понятно, я постараюсь уточнить стартпост. Заранее спасибо за ответы.
Спасибо большое! Техника интересная.
А как быть, если действия на одной вкладке могут изменить в принципе содержание следующей вкладки? Или конечной вкладки? Пока я не очень понимаю, как это реализовать в таблице.
и в любом случае, мне кажется, что без разбиения на блоки не обойтись…
1). Постройте flow diagram. Задача данной диаграммы - визуализировать состояния системы и те действия, которые ведут к их изменениям.
Правила следующие:
Если из формы А различными действиями можно перейти к формам Б и В - не экономьте место на диаграмме, делайте ветвление, пусть даже результирующие формы будут похожи.
Если действие на форме А меняет форму А - тоже делаем отдельное состояние системы А’.
Если какие-то действия пользователя должны приводить к ошибкам - это тоже должно быть отображено на диаграмме и соответствующим образом обработано.
2). Затем строим список тест кейсов по принципу:
проверить, что действие X переводит AUT из состояния А в состояние Б.
проверить, что форма Б имеет внешний вид и функциональные элементы, соответствующие требованиям.
Большое спасибо за ответы. Посмотрела видео, похоже, то, что я хочу сделать, называется State-Based Testing. К сожалению, именно эта техника на видео рассмотрена как-то невнятно. Но насколько я поняла, мы составляем тест-кейсы из блоков состояний системы. Правильно ли я понимаю, что на приведение системы к каждому из состояний есть отдельный тест-кейс? То есть, это по сути, те самые “кирпичики”, на которые я хочу разбить процесс.
Пример: есть несколько состояний системы:
А1 - валидно заполненная первая вкладка формы с отмеченным радиобаттоном, для открытия второй вкладки
А2 - валидно заполненная первая вкладка формы с отмеченным радиобаттоном без открытия второй вкладки, а переходу сразу к третьей вкладке.
B1 - Валидно заполненная вторая вкладка
С1 - Валидно заполненная третья вкладка
и т.д. в зависимости от того насколько может ветвиться flow.
И потом, когда мы собрали все возможные состояния системы, мы можем составлять тест кейсы из этих состояний, к примеру:
Тест-кейс 1: А1-B1-C1-…n1
Тест-кейс 2: A1-B1-C1- …n2
Тест-кейс 3: A2-C1-…n1
и так далее. С тем условием, что комбинация должна привести к завершению процесса. Таким образом мы покроем все варианты flow.
Или я неправильно понимаю эту технику?
Составление таблицы в моем случае мне уже кажется не очень хорошей идеей. Я не представляю, какой она будет огромной, ну и как реализовывать в ней точки ветвления? По сути, точка, в которой начинается alternate flow - это Action таблицы, с момента начала Alternate flow нужно писать новые Condition и Action т.е. таблиц придется также составлять несколько. Как-то все это запутанно выглядит…
Также хочу сказать, что создание документа - это лишь самый первый этап другого Workflow, в котором также есть места ветвления (например, проверка документа пользователями с различными ролями, а также самой системой, на каждом этапе flow может пойти по другому пути), т.е. это тольк верхушка айсберга и, повторюсь, без разбиения на части и компоновки в последующем этих частей я не представляю, как все это реализовать.
В любом случае вам стоит составить полную диаграму, как посоветовал @Defender
Глядя на нее можно будет определить общее количество возможных пользовательских действий и выделить все признаки, которые влияют на изменение системы. То есть у вас будет наглядная карта интерфейса, глядя на которою можно будет составить модель для pairwise testing и скормить её какому-нибудь инструменту типа PICT, получив на выходе оптимальный набор тест-кейсов.
Так я ж расписал правила построения диаграммы Это оно и есть.
Да.
Можно и так. Но я бы считал состоянием системы “открыта новая форма”, “открыта новая подформа”, “выведена ошибка” а приведенный Вами пример скорее действием, необходимым для перехода системы из состояния А в состояние Б и на диаграмме Ваши А1 отмечал бы стрелочками между А и Б.
End-to-end тест-кейсы - это круто, но если Вы их напишете сразу - скорее всего, Вы что-нибудь пропустите, если состояний много. Правильный вариант ИМХО в данном случае: кейс должен тестировать переход из состояния А в состояние Б, затем следующий кейс тестирует соответствие состояния Б спецификации. Для этого кейс должен иметь precondition, в котором описывается состояние А, из которого мы перешли (для кейса типа 1), а для кейса типа 2 precondition будет “система введена в состояние Б”. После чего составить traceability matrix, показывающую зависимости между состояниями и переходами vs тестов.
Уже потом, если будет время, желание и силы - оптимизировать кол-во тестов, сводя те, что можно свести, в end-to-end тесты. Но этот шаг глубоко опционален: поскольку система вполне может допиливаться, диаграмма будет меняться. В этом случае, имея небольшие тесты с минимумом зависимостей, достаточно легко их модифицировать. Имея же end-to-end тесты, легко попасть на модификацию всего набора тестов и получить maintenance hell.
Спасибо большое! Некоторые вещи непонятны, опять же, что за traceability matrix, надо читать.
По предусловиям я понимаю, так и планирую делать.
С end-to-end кейсами непонятно, вы предлагаете на первом этапе формально описать кейсы? Но с меня просят как раз end-to-end, чтобы тестировщик мог по ним ходить. Или я вас неверно поняла?
Тестировщик может ходить по любым кейсам ))
Обычный кейс должен иметь precondition “система приведена в целевое состояние А”.
End-to-end кейс - это последовательность действий провести систему из самого начального состояния в одно из конечных, проверяя попутно все промежуточные состояния.
Возможно, в вашем случае достаточно будет проверить несколько самых часто используемых сценариев, к-рых конечное количество, не много, но они покрывают, например, 90% использования вашего продукта. Инфой по таким сценариям обычно владеют бизнес аналитики или заказчики.
testomat.io управление авто тестами
Это оно и есть.