Тест-драйв: начало большого пути

«Нет хорошей разработки – есть плохо протестированная»

(надпись на могиле неизвестного тестировщика)

Всем привет.

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

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

Сразу внесу несколько оговорок. Я не являюсь профессиональным тестировщиком, поэтому постараюсь абстрагироваться от специализированной терминологии и говорить простым и понятным обывателю языком. Также я не буду рассматривать в своих материалах процедуру и принципы первичного тестирования реализованного функционала разработчиком. За отправную точку принимается условно готовый объект системы, поддерживающий элементарную работоспособность. Под такой работоспособностью мной понимается возможность запуска типового маршрута, создания документа / записи в справочнике или запуска сценария без падения в критичные ошибки. Критичной я называю такую ошибку, которая не даёт продолжить тестирование: без запуска маршрута я не могу проверить блоки, без создания документа я не могу проверить его карточку, и т.д.

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

Главный, отдельный, незыблемый принцип: никакого тестирования «под администратором». Нет, не так.

НИКАКОГО ТЕСТИРОВАНИЯ «ПОД АДМИНИСТРАТОРОМ»!!!

А теперь поехали по порядку.

1. Перед тестированием система должна быть настроена в соответствии с запроектированной настройкой перед вводом в эксплуатацию. Что это значит?

• должно быть создано достаточное количество тестовых пользователей. Под их учётными записями мы будем обращаться к объектам системы, проверяя их доступность и функциональность;
• эти пользователи должны быть включены в группы, предполагаемые к использованию в реальных условиях;
• пользователям и группам должны быть выданы соответствующие права доступа и привилегии;
• для групп должны быть установлены требуемые фильтраторы. Это позволит отследить возможные пересечения фильтруемых данных;
• для пользователей должны быть настроены требуемые замещения;
• для пользователей должны быть зарегистрированы сертификаты электронной подписи;
• должна быть создана необходимая орг.структура с заполнением должностей различных уровней и соблюдением иерархии подразделений;
• должны быть заполнены статические и специальные роли;
• должны быть заполнены «настроечные» справочники и классификаторы;
• должны быть созданы и настроены требуемые виды электронных документов, права на их создание и подписание;
• должны быть заполнены константы.

Эта задача существенно упрощается, если мы говорим не о первичном внедрении, а DIRECTUM в организации уже установлен и используется. Если организация согласна предоставить в наше распоряжение бэкап системы – мы получаем максимальное приближение к «боевым» условиям, что позволит провести тестирование более качественно, чем на «чистой» системе.

2. Второй пункт, по сути, является той же настройкой системы, но вынесен отдельно от вышеперечисленных. Во-первых, эта настройка достаточно редка и «опциональна», т.е. может встретиться далеко не на каждом проекте. А во-вторых, я считаю этот нюанс достаточно важным для выстраивания работы не только тестировщика, но и разработчика, и проектировщика. Как показывает опыт, редко кто вспоминает о том, что орг.структура организации может предполагать наличие нескольких работников у одного пользователя. Соответственно проектировщик должен выявить такую потребность при исследовании, а разработчик учесть её при реализации. Дорогие разработчики, как консультант, проектировщик и тестировщик искренне прошу вас, принимаясь за разработку, содержащую в себе определение работников для пользователей, уточните лишний раз – не требуется ли закрытие такой ситуации, даже если это явно не описано в документе. А для тестировщика перечислю возможные сочетания пользователей и работников, которые необходимо создать в системе для дальнейшей проверки:

• с пользователем не связан ни один работник;
• с пользователем связано несколько работников одной НОР;
• с пользователем связано несколько работников разных НОР;
• с пользователем связан один работник с состоянием записи «Действующая»;
• с пользователем связан один работник с состоянием записи «Закрытая»;
• с пользователем связан один работник с состоянием записи «Действующая» и 1 / несколько работников с состоянием записей «Закрытая» (при этом действующая запись должна быть последней созданной).

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

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

• с точки зрения удобства и логичности использования в разрезе бизнес-процесса;
• с точки зрения разумной «защиты от дурака»;
• с точки зрения намеренного и нечаянного вредителя.

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

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

И никакого тестирования «под администратором»! Я уже говорила, да?