Кто-нибудь пробовал такой подход при написании тест кейсов?

Дано: есть большая программа, с большим количеством разных окон. На большинстве окон есть некоторые элементы, поведение которых совпадает (и соответственно тестировать их нужно одинаково). Есть определенные свои специфичные элементы, а так же попадаются как бы исключения из общих правил.
Цель: создать инструмент (структуру/концепцию) для написания тестов (тест кейсов или просто описание проверок), чтобы не пришлось много раз описывать поведение одного и того же элемента на нескольких окнах.
Представляется нечто похожее на наследование в программировании. То есть «базовый класс» (например, окно программы) имеет какие-то элементы, которые нужно проверять определенным способом. У него имеются «классы наследники», которые наследуют все элементы и их проверки + имеют какие-то свои особенные элементы и описание их проверок. У «наследника» могут быть еще «наследники» и т д. Так же один такой «класс» может быть «наследником» нескольких «классов».

Жизнеспособен ли такой подход? Пробовали ли Вы сделать что-либо подобное? Есть ли специальные инструменты для создания таких тестов? Что можно почитать на эту тему?

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

Я думаю, при таком подходе, вы быстро запутаетесь, "выберите меню: ..., выполните шаги документа "...", п. ..." а если еще и в нем будут вложенные документы, а если там еще и зависимость есть.... Сочувствую тому, кто это будет тестировать и тем-более тому, кто это будет поддерживать.
И что значит одинаковый функционал? Одинаковый совсем-совсем или чем-то все-таки разный? Тесты должны быть максимально простые, независимые и легко модифицируемые, тем-более в тк не должно быть ссылок на тк и тем-более на другие документы.

Жизнеспособен ли такой подход? Пробовали ли Вы сделать что-либо подобное?

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

Есть ли специальные инструменты для создания таких тестов?

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

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

Да и еще. Сама по себе задача, наверное, достаточно тривиальная

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

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

Например какой? (Гугл по запросу "виртуальные тест комплекты" ничего внятного не нашел)

Я думаю, при таком подходе, вы быстро запутаетесь, "выберите меню: ..., выполните шаги документа "...", п. ..." а если еще и в нем будут вложенные документы, а если там еще и зависимость есть.... Сочувствую тому, кто это будет тестировать и тем-более тому, кто это будет поддерживать.

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

И что значит одинаковый функционал?

Предположим, это система управления документацией. Есть разные типы документов, но при этом, независимо от типа есть кнопка «Посмотреть следующий» или «Сохранить изменения» и т д

Предположим, это система управления документацией. Есть разные типы документов, но при этом, независимо от типа есть кнопка «Посмотреть следующий» или «Сохранить изменения» и т д

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

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

ОК, предполагаем дальше (на основе реальных событий конечно)
Документов 20 разных (с постоянно увеличивающимся количеством), массив данных соответственно разный. У каждого документа много полей ввода разных типов: строка, число, форматированный текст, дата, выбор из листа значений (уникальные для каждого типа документа), где то поля вообще не редактируемые и надо проверить правильность автоподстановки.
Везде разная длинна полей ввода, количество полей ввода тоже произвольное, они могут быть обязательными или нет, могут иметь или не иметь значение по умолчанию.
Необходимо проверить, что документ сохраняется при введении корректных данных, и выводится определенное сообщение об ошибке при введение некорректных (данные могут быть некорректны по разным причинам: несовпадение типов, неподдерживаемые символы, превышение лимита ввода >> всё это разные сообщения об ошибке)
При всем при этом типов полей ввода не так уж и много (не более 10) и сообщения об ошибках при невалидных данных зависят от типа поля ввода.
Создавать для каждого документа свой массив данных долго (надо же еще описывать ожидаемый результат при введении невалидных данных).

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

Документов 20 разных (с постоянно увеличивающимся количеством), массив данных соответственно разный. У каждого документа много полей ввода разных типов: строка, число, форматированный текст, дата, выбор из листа значений (уникальные для каждого типа документа), где то поля вообще не редактируемые и надо проверить правильность автоподстановки.
Везде разная длинна полей ввода, количество полей ввода тоже произвольное, они могут быть обязательными или нет, могут иметь или не иметь значение по умолчанию.

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

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

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

В том то и дело, что хотелось бы чуток улучшить подобный подход. Лень расписывать одни и те же проверки в духе: проверьте, что если в поле Х нельзя ввести более… (здесь заглянуть в базу данных и посмотреть размер поля) символов.
Вторая цель – это создать некую структуру для накопления знаний о программе, о том, как она должна себя вести. И если в какой-то момент решили изменить название этого поля Х на У, избежать редактирования кучи документов, где оно упоминается.
На выходе хочется получить нечто, куда можно ввести параметры набора полей(их названия, длину, тип) + шаблон проверок для каждого типа с ожидаемым результатом и нажать кнопочку "Сформировать лист проверок" Хотя, конечно, утопично наверное :))))))

ПыСы: в примере был обрисован только один из возможных способов работы с этими документами, в реальности их гораздо больше и они тоже зависят от типа документа.

В том то и дело, что хотелось бы чуток улучшить подобный подход. Лень расписывать одни и те же проверки в духе: проверьте, что если в поле Х нельзя ввести более… (здесь заглянуть в базу данных и посмотреть размер поля) символов.

Что вы хотите выловить этой проверкой? Если вы будете руководить парметрами теста, данными из базы, то вы ж ничего не проверите. Такая проверка всегда будет положительной. Если поле должно быть по тз 5 символов, и кто-то что-то меняя, его сделал размерностью 3 символа, то вы считаете с базы что должно быть 3 символа и проверите с текущим(тоже 3 символа) - проверка совпадет. Проверка по тз никогда не выполнится.

Что вы хотите выловить этой проверкой? Если вы будете руководить парметрами теста, данными из базы, то вы ж ничего не проверите. Такая проверка всегда будет положительной. Если поле должно быть по тз 5 символов, и кто-то что-то меняя, его сделал размерностью 3 символа, то вы считаете с базы что должно быть 3 символа и проверите с текущим(тоже 3 символа) - проверка совпадет. Проверка по тз никогда не выполнится.

Если UI позволяет ввести 500 символов, а бд имеет 100 символов под это поле, то при попытке сохранить изменения в лучшем случае данные будут обрезаны (выведено непонятное для простого человека сообщение об ошибке), в худшем будет неприятное падение с критической ошибкой.

ТЗ на такие мелочи нет :)

Исходя из сказанного - прежде чем советовать какой-либо метод - нужно исходить из ваших возможностей.
К примеру, если у вас в штате 5 тестировщиков которые занимаются тестированием данного процесса, и вы работаете в одной связке, то можно писать более подробные тесты, но без фанатизма.
И + если у вас есть время этим заниматься и впоследствии поддерживать.
Максимальная точность (подчеркну_без фанатизма_) вреда не принесет, а будет даже полезной.

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

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

если ему важна четкая документация, то тут уже не бегом.. ту уже уделяем Х времени написанию, и Х времени тесту.


итп.

Советовать что-то определенное тут сложно, во всяком случае, мне)

Как по мне так: Копи-Паст ещё никто не отменял.
Вот поступит к вам на работу новый Тестировщик и начнет читать: Первые два поля тестируем так как описано в доке "№ ГСМК-52-35", а в ней подробное описание тестирования второго поля а про первое пишет "смотри доку № ГСМК-50-21". В этоге сидит этот бедняга с 5-6 открытыми доками и офигевает от жизни. =)
Мое мнение: Каждая документация по тестированию отдельной функциональности/страницы итд должна быть самодостаточной. А скопировать пару тестов из другой доки - не особая проблема (За исключением момента изменения в требованиях. Там править по всех доках надо будет)

ПС: Все это только мои мысли в слух

Вот поступит к вам на работу новый Тестировщик и начнет читать: Первые два поля тестируем так как описано в доке "№ ГСМК-52-35", а в ней подробное описание тестирования второго поля а про первое пишет "смотри доку № ГСМК-50-21". В этоге сидит этот бедняга с 5-6 открытыми доками и офигевает от жизни. =)

мысли вслух (с)
- если у вас так все перевезяно и ссылается на друг друга - это уже фейл.
если не эпик)

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

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

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

Я думаю, все понимают, что доками такое писать это самоубийство.

Я, собственно, о том же.

Возможно, приведен неудачный пример.)

Как по мне так: Копи-Паст ещё никто не отменял.
Вот поступит к вам на работу новый Тестировщик и начнет читать: Первые два поля тестируем так как описано в доке "№ ГСМК-52-35", а в ней подробное описание тестирования второго поля а про первое пишет "смотри доку № ГСМК-50-21". В этоге сидит этот бедняга с 5-6 открытыми доками и офигевает от жизни. =)
Мое мнение: Каждая документация по тестированию отдельной функциональности/страницы итд должна быть самодостаточной. А скопировать пару тестов из другой доки - не особая проблема (За исключением момента изменения в требованиях. Там править по всех доках надо будет)

мысли вслух (с)
- если у вас так все перевезяно и ссылается на друг друга - это уже фейл.
если не эпик)

Копи-Паст - зло. Очень большое. Это такой рассадник багов, что мама не горюй. Я как то мельком проходил по сайту очень известной IT-шной фирмы и обнаружил, что в трех разных местах сумма отчислений считается тремя разными способами. И даже НДС считается разными способами. Эпик фейл как следствие простого copy-paste.
Но иногда copy-paste допустим.

Вырожденные варианты:
1. Сверхмалые проекты (до человекогода). Можно обойтись минимумом документации. Вплоть до того, что иметь один единственный документ в котором и собрано все - от концепции до тестовых примеров. Копи-Паст не нужен.

2. малые проекты (до десяти человеколет). Если copy-paste очень, очень сильно нужен - можно делать. Но лучше переделать структуру документации. С ростом объема документации copy-paste все более и более нежелателен.

пропустим средние проекты

3. Большие проекты (от 100 человеколет). Ну здесь явно нужно использовать полноценные системы документирования. АфторИт и подобные. На самый худой конец даже шарепоинт подойдет.
В этих системах отдельно набиваются кусочки информации и отдельно настраиваются профили публикации. Что гарантирует, что один и тот же кусочек документации в разных документах будет всегда одинаковым. Работать с такими системами непросто, нужно сильно поработать над собой. Но оно того стоит.

Копи-Паст - зло. Очень большое. Это такой рассадник багов, что мама не горюй.

в целом - согласна на все 100%

но

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

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

Представляется нечто похожее на наследование в программировании. То есть «базовый класс» (например, окно программы) имеет какие-то элементы, которые нужно проверять определенным способом. У него имеются «классы наследники», которые наследуют все элементы и их проверки + имеют какие-то свои особенные элементы и описание их проверок. У «наследника» могут быть еще «наследники» и т д. Так же один такой «класс» может быть «наследником» нескольких «классов».

Кое что похожее используется у нас - в некоторых проектах.
Из инструментов используем QC (Quality Center).
Только там не "наследование классов", а "использование подпрограмм".
Такой подход очень помогает писать и поддерживать тесты, в частности E2E.
Например, каждый сценарий начинается со входа в систему. Вход в систему описывается десятком шагов. Вот и написаны несколько "подпрограмм" (кирпичиков). Одна из них используется в самом тесте.И т.д.
В результате, каждый сценарий представляет собой просто цепочку "подпрограмм".
Написать новый сценарий (проходящий через пару десятков окон) - дело 5-ти минут.
Исправления вносить - тоже просто и быстро.

Мне лично подобный подход очень нравится.