Найти тему

Переход по навигационной ссылке в сценариях тестирования

Сегодня размышления про соблазнительный шаг «Навигационная ссылка». С чего это вдруг повеяло деянием, вызывающее моральное падение в таком безгреховном занятии, как тестирование ПО? Ладно, ладно не все так безгрешно! У каждого тестировщика есть свои баги в шкафу (и в голове), которые он не предал анафеме и не закопал на кладбище контроля качества.

Но вернемся к шагу «Навигационная ссылка». В чем собственно соблазн? Я бы даже сказал - искушение. В том, что ссылкой хочется увлечься и изменить с ней другим шагам, нарушая все логические законы построения сценариев тестирования.

Окно программы «1С:Управление нашей фирмой» с примером получения навигационной ссылки на форме элемента справочника «Номенклатура»
Окно программы «1С:Управление нашей фирмой» с примером получения навигационной ссылки на форме элемента справочника «Номенклатура»

Судите сами. Как строится классический сценарий тестирования? Ответ кроется в самом термине «сценарий тестирования» - это последовательность действий, которые связаны единым ограниченным бизнес-процессом использования. И его основой является повторение действий пользователя. А что будет делать пользователь, чтобы попасть в необходимый ему объект программы? Взаимодействовать с интерфейсом: переходить сначала в раздел (подсистему) командного интерфейса, а далее непосредственно на форму списка или элемента объекта (справочника, документа, обработки и т.д.). Вот вам и последовательность действий. Действий! Их несколько, Карл!

А что предлагает навигационная ссылка при использовании ее в сценариях тестирования?

1. Кратчайшим путем к цели

Прямой переход к форме. Всего один шаг и необходимая форма открыта. Компактно, с точки зрения визуального восприятия сценария тестирования. Как правило, в нем много строк-шагов, а тут нам предлагается сократить их количество. Быстро, с точки зрения действий. Вместо двух действий: переход в раздел и на форму, одно: сразу переход на форму.

Окно программы «1С:Управление нашей фирмой» с открытой обработкой записи сценария тестирования. В примере в одном сценарии тестирования продемонстрированы два примера перехода к форме элемента справочника «Номенклатура»: верхний по навигационной ссылке, нижний (после шага-разделителя) - через интерфейс программы
Окно программы «1С:Управление нашей фирмой» с открытой обработкой записи сценария тестирования. В примере в одном сценарии тестирования продемонстрированы два примера перехода к форме элемента справочника «Номенклатура»: верхний по навигационной ссылке, нижний (после шага-разделителя) - через интерфейс программы

И сразу бонус! Для формы списка навигационная ссылка представлена несколькими видами:

  • Можно перейти непосредственно на форму списка.
  • Можно перейти на форму списка с текущими настройками. А это значит, что в ссылке сразу хранятся такие нужные настройки как отборы и режим просмотра. Соответственно нет необходимости устанавливать данные настойки другими шагами сценариев тестирования.
  • Можно перейти на форму списка с текущими настройками и строкой. А здесь к установленным настойкам добавлено еще и позиционирование на нужной строке.
  • А можно сразу получить навигационную ссылку на объект текущей строки в форме списка.
Окно программы «1С:Управление нашей фирмой» с примером получения разных видов навигационных ссылок на форме списка справочника «Штрихкоды»
Окно программы «1С:Управление нашей фирмой» с примером получения разных видов навигационных ссылок на форме списка справочника «Штрихкоды»

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

2. В обход закрытых дверей

Не все объекты есть в интерфейсе. Объектов нет, значит и пользователь туда не полезет. Зачем покрывать тестами? Спорно. Рядовой пользователь может и не полезет, а вот администратор может. Они вообще многое что могут, просто не хотят. Потому необходимость открывать такие формы случатся реже, а значит ошибки поживут подольше. Но проверять надо, так как непокрытый тестами скрытый функционал ответственности не снимает.

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

3. Если нет разницы, то зачем переплачивать?

Хорошо. Глянем со стороны критичности, когда при попытке открыть форму возникает ошибка, из-за которой открыть форму невозможно. Если перейти на такую «поломанную» форму через командный интерфейс или по навигационной ссылке, то будет ли разница? Например, через интерфейс - есть ошибка, по навигационной ссылке - нет ошибки. Как бы не хотелось, но такого чуда не произойдет. В большинстве случаев, разницы никакой нет. Если форма не открывается из-за критической ошибки, то каким бы способом ее не пытались открыть - она не откроется. А значит, ошибка в любом случае будет обнаружена.

Так почему бы не соблазниться и не начать использовать переход по навигационной ссылке во всех сценариях тестирования?

Рояль замедленного действия в кустах

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

Во-первых, проверка наличия объекта в интерфейсе. Жил себе справочник «Номенклатура» в разделе «Склад». Потом сделали ребрендинг интерфейса и на радостях забыли его добавить в этот раздел. Автотест перешел на форму списка справочника «Номенклатура» напрямую по навигационной ссылке и отработал с положительным результатом проверки, говоря тем самым, что справочник прекрасно функционирует. Команда разработки довольна, а конечный пользователь нет: «Нафига нам Ваш новый интерфейс, когда номенклатуру нельзя создать!»

Во-вторых, проверка промежуточных форм. Чтобы открыть форму списка справочника «Номенклатура» из командного интерфейса необходимо зайти в необходимый раздел (подсистему) и в нем перейти на форму списка справочника. А если в сам раздел невозможно зайти из-за ошибки? Значит при прямом переходе на форму списка справочника «Номенклатура» эта ошибка будет пропущена.

В-третьих, проверку открытия форм, на которые применены какие-либо отборы. Например, если открыть справочник «Единицы измерения» из карточки элемента номенклатуры, то на форме будут отображаться единицы измерения только для данной номенклатуры, т.е. применены отборы по номенклатуре. А вот, если открыть справочник по навигационной ссылке (при условии, что нет запрета на прямое открытие), то будут отображаться все единицы измерения без отборов по номенклатуре. И в таком случае, можно либо пропустить ошибку, связанную с применением отборов. Либо получить предупреждение с видом ошибки, что данная форма не открывается напрямую. Но для автотеста это будет ошибка.

Плюсы отметили. Минусы тоже. Теперь меняем угол обзора.

Разделяй и комбинируй

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

Рассмотрим на примере: необходимо проверить работоспособность всех отчетов (их 20 шт), которые собраны на отдельной форме «Отчеты» в разделе «Производство».

1. Для сценария тестирования с логикой работы через командный интерфейс каждый из 20-и автотестов будет выполнять:

  • Переход в раздел «Производство»
  • Переход на форму «Отчеты» (со списком всех отчетов)
  • Открытие необходимого отчета, установка параметров, формирование и проверка результата
Окно программы «1С:Управление нашей фирмой» с открытой обработкой записи сценария тестирования. В примере продемонстрирован пример перехода к форме отчета «Запасы» через интерфейс программы с последующим заполнением параметров и формирования отчета
Окно программы «1С:Управление нашей фирмой» с открытой обработкой записи сценария тестирования. В примере продемонстрирован пример перехода к форме отчета «Запасы» через интерфейс программы с последующим заполнением параметров и формирования отчета

Если будет ошибка блокирующая дальнейшую работу автотеста на уровне раздела «Производства» или формы «Отчеты», то все 20 автотестов завершаться с ошибкой. Но при этом они найдут одну и ту же ошибку, а до проверки самих отчетов дело даже не дойдет. Происходит потеря времени на ожидание исправления ошибки и повторный прогон автотестов.

2. Для сценария тестирования с логикой работы через переход по навигационной ссылке каждый из 20-и автотестов будет выполнять:

  • Переход к необходимому отчету, установка параметров, формирование и проверка результата
Окно программы «1С:Управление нашей фирмой» с открытой обработкой записи сценария тестирования. В примере продемонстрирован пример перехода к форме отчета «Запасы» по навигационной ссылке с последующим заполнением параметров и формирования отчета
Окно программы «1С:Управление нашей фирмой» с открытой обработкой записи сценария тестирования. В примере продемонстрирован пример перехода к форме отчета «Запасы» по навигационной ссылке с последующим заполнением параметров и формирования отчета

Если будет ошибка блокирующая дальнейшую работу автотеста на уровне раздела «Производства» или формы «Отчеты», то автотесты их не зафиксируют, так как нет взаимодействия с интерфейсом. Но зато все отчеты будут проверены.

3. А теперь разделим сценарии и скомбинируем подходы:

  • Сделаем отдельный автотест, который проверяет работу с командным интерфейсом: переходит в раздел «Производство» и на форму «Отчеты».
  • И 20-ь автотестов по проверке отчетов, где переход к каждому отчету осуществляется по навигационной ссылке.

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

Так, изменять или не изменять? Почти как у Уильяма, отца нашего Лебедя Эйвона.

Все зависит от решаемых задач и логики построения сценариев тестирования.

Однозначно, переход по навигационной ссылке придется использовать для объектов, которые не добавлены в интерфейс программы и на их форме возможно получить ссылку. Альтернативой здесь может быть вызов форм средствами кода в шаге «Процедура на встроенном языке». И тут возможностей больше: можно вызывать любые формы программы, обходя запреты на их вызов. Но, только в том случае, если есть навык написания кода на 1С.

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

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

Хотя, не слушайте меня. Если мне пришлось наступить на грабли, то это только мои грабли. И совершенно не означает, что у вас должно быть точно также. У вас будет легко, понятно и с нужным результатом! Просто пробуйте!

-8