Сегодня размышления про соблазнительный шаг «Навигационная ссылка». С чего это вдруг повеяло деянием, вызывающее моральное падение в таком безгреховном занятии, как тестирование ПО? Ладно, ладно не все так безгрешно! У каждого тестировщика есть свои баги в шкафу (и в голове), которые он не предал анафеме и не закопал на кладбище контроля качества.
Но вернемся к шагу «Навигационная ссылка». В чем собственно соблазн? Я бы даже сказал - искушение. В том, что ссылкой хочется увлечься и изменить с ней другим шагам, нарушая все логические законы построения сценариев тестирования.
Судите сами. Как строится классический сценарий тестирования? Ответ кроется в самом термине «сценарий тестирования» - это последовательность действий, которые связаны единым ограниченным бизнес-процессом использования. И его основой является повторение действий пользователя. А что будет делать пользователь, чтобы попасть в необходимый ему объект программы? Взаимодействовать с интерфейсом: переходить сначала в раздел (подсистему) командного интерфейса, а далее непосредственно на форму списка или элемента объекта (справочника, документа, обработки и т.д.). Вот вам и последовательность действий. Действий! Их несколько, Карл!
А что предлагает навигационная ссылка при использовании ее в сценариях тестирования?
1. Кратчайшим путем к цели
Прямой переход к форме. Всего один шаг и необходимая форма открыта. Компактно, с точки зрения визуального восприятия сценария тестирования. Как правило, в нем много строк-шагов, а тут нам предлагается сократить их количество. Быстро, с точки зрения действий. Вместо двух действий: переход в раздел и на форму, одно: сразу переход на форму.
И сразу бонус! Для формы списка навигационная ссылка представлена несколькими видами:
- Можно перейти непосредственно на форму списка.
- Можно перейти на форму списка с текущими настройками. А это значит, что в ссылке сразу хранятся такие нужные настройки как отборы и режим просмотра. Соответственно нет необходимости устанавливать данные настойки другими шагами сценариев тестирования.
- Можно перейти на форму списка с текущими настройками и строкой. А здесь к установленным настойкам добавлено еще и позиционирование на нужной строке.
- А можно сразу получить навигационную ссылку на объект текущей строки в форме списка.
Только задумайтесь, одним шагом закрывается множество действий: переход к форме списка в интерфейсе, настройка нужного отображения формы (например, установка режима просмотра списком для иерархических справочников) и позиционирование на нужной строке.
2. В обход закрытых дверей
Не все объекты есть в интерфейсе. Объектов нет, значит и пользователь туда не полезет. Зачем покрывать тестами? Спорно. Рядовой пользователь может и не полезет, а вот администратор может. Они вообще многое что могут, просто не хотят. Потому необходимость открывать такие формы случатся реже, а значит ошибки поживут подольше. Но проверять надо, так как непокрытый тестами скрытый функционал ответственности не снимает.
И тут на помощь приходит навигационная ссылка. Надо признать, что не на всех формах она присутствует, но на большинстве необходимых объектов она есть, и этого хватает для достижения цели по контролю качества.
3. Если нет разницы, то зачем переплачивать?
Хорошо. Глянем со стороны критичности, когда при попытке открыть форму возникает ошибка, из-за которой открыть форму невозможно. Если перейти на такую «поломанную» форму через командный интерфейс или по навигационной ссылке, то будет ли разница? Например, через интерфейс - есть ошибка, по навигационной ссылке - нет ошибки. Как бы не хотелось, но такого чуда не произойдет. В большинстве случаев, разницы никакой нет. Если форма не открывается из-за критической ошибки, то каким бы способом ее не пытались открыть - она не откроется. А значит, ошибка в любом случае будет обнаружена.
Так почему бы не соблазниться и не начать использовать переход по навигационной ссылке во всех сценариях тестирования?
Рояль замедленного действия в кустах
Соблазн - состояние туманное. Не всегда можно заметить, что под ногами. Что же упускается при создании сценариев тестирования с быстрым переходом по навигационной ссылке к нужной форме?
Во-первых, проверка наличия объекта в интерфейсе. Жил себе справочник «Номенклатура» в разделе «Склад». Потом сделали ребрендинг интерфейса и на радостях забыли его добавить в этот раздел. Автотест перешел на форму списка справочника «Номенклатура» напрямую по навигационной ссылке и отработал с положительным результатом проверки, говоря тем самым, что справочник прекрасно функционирует. Команда разработки довольна, а конечный пользователь нет: «Нафига нам Ваш новый интерфейс, когда номенклатуру нельзя создать!»
Во-вторых, проверка промежуточных форм. Чтобы открыть форму списка справочника «Номенклатура» из командного интерфейса необходимо зайти в необходимый раздел (подсистему) и в нем перейти на форму списка справочника. А если в сам раздел невозможно зайти из-за ошибки? Значит при прямом переходе на форму списка справочника «Номенклатура» эта ошибка будет пропущена.
В-третьих, проверку открытия форм, на которые применены какие-либо отборы. Например, если открыть справочник «Единицы измерения» из карточки элемента номенклатуры, то на форме будут отображаться единицы измерения только для данной номенклатуры, т.е. применены отборы по номенклатуре. А вот, если открыть справочник по навигационной ссылке (при условии, что нет запрета на прямое открытие), то будут отображаться все единицы измерения без отборов по номенклатуре. И в таком случае, можно либо пропустить ошибку, связанную с применением отборов. Либо получить предупреждение с видом ошибки, что данная форма не открывается напрямую. Но для автотеста это будет ошибка.
Плюсы отметили. Минусы тоже. Теперь меняем угол обзора.
Разделяй и комбинируй
А что если подойти к составлению сценариев тестирования более продуманно и аккуратно разделить или скомбинировать разные проверки? Возможно, в таком случае, может получиться хороший результат.
Рассмотрим на примере: необходимо проверить работоспособность всех отчетов (их 20 шт), которые собраны на отдельной форме «Отчеты» в разделе «Производство».
1. Для сценария тестирования с логикой работы через командный интерфейс каждый из 20-и автотестов будет выполнять:
- Переход в раздел «Производство»
- Переход на форму «Отчеты» (со списком всех отчетов)
- Открытие необходимого отчета, установка параметров, формирование и проверка результата
Если будет ошибка блокирующая дальнейшую работу автотеста на уровне раздела «Производства» или формы «Отчеты», то все 20 автотестов завершаться с ошибкой. Но при этом они найдут одну и ту же ошибку, а до проверки самих отчетов дело даже не дойдет. Происходит потеря времени на ожидание исправления ошибки и повторный прогон автотестов.
2. Для сценария тестирования с логикой работы через переход по навигационной ссылке каждый из 20-и автотестов будет выполнять:
- Переход к необходимому отчету, установка параметров, формирование и проверка результата
Если будет ошибка блокирующая дальнейшую работу автотеста на уровне раздела «Производства» или формы «Отчеты», то автотесты их не зафиксируют, так как нет взаимодействия с интерфейсом. Но зато все отчеты будут проверены.
3. А теперь разделим сценарии и скомбинируем подходы:
- Сделаем отдельный автотест, который проверяет работу с командным интерфейсом: переходит в раздел «Производство» и на форму «Отчеты».
- И 20-ь автотестов по проверке отчетов, где переход к каждому отчету осуществляется по навигационной ссылке.
Количество автотестов увеличилось в сравнении с предыдущими вариантами, но при этом получилось покрыть проверкой взаимодействие с интерфейсом и каждый отчет отдельно. И сделать это независимо. А за один прогон таких автотестов можно найти больше ошибок разного вида. Да и по времени, несмотря на увеличение количества автотестов, будет работать быстрее, так как нет необходимости каждый раз переходить в интерфейсе к необходимому отчету.
Так, изменять или не изменять? Почти как у Уильяма, отца нашего Лебедя Эйвона.
Все зависит от решаемых задач и логики построения сценариев тестирования.
Однозначно, переход по навигационной ссылке придется использовать для объектов, которые не добавлены в интерфейс программы и на их форме возможно получить ссылку. Альтернативой здесь может быть вызов форм средствами кода в шаге «Процедура на встроенном языке». И тут возможностей больше: можно вызывать любые формы программы, обходя запреты на их вызов. Но, только в том случае, если есть навык написания кода на 1С.
В остальных случаях переход по навигационной ссылке стоит использовать с осмотрительностью - не упускается ли какая-то важная проверка? И если упускается, то обязательно восполнить ее дополнительными проверками.
Для себя я решил, что переход по навигационной ссылке - это классная современная функция, которой не стоит пренебрегать при написании сценариев тестирования. Да, с ней придется почесать лоб, затылок или все вместе и наступить на грабли ни один раз, но она того стоит. Так как при ее использовании можно увеличить скорость прохождения автотестов и уменьшить количество повторяющихся проверок. Да и мышление меняется. Попробуйте!
Хотя, не слушайте меня. Если мне пришлось наступить на грабли, то это только мои грабли. И совершенно не означает, что у вас должно быть точно также. У вас будет легко, понятно и с нужным результатом! Просто пробуйте!