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

22 2

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

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

 

 

 

Всем привет.

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

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

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

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

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

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

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

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

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

  1. Второй пункт, по сути, является той же настройкой системы, но вынесен отдельно от вышеперечисленных. Во-первых, эта настройка достаточно редка и «опциональна», т.е. может встретиться далеко не на каждом проекте. А во-вторых, я считаю этот нюанс достаточно важным для выстраивания работы не только тестировщика, но и разработчика, и проектировщика. Как показывает опыт, редко кто вспоминает о том, что орг.структура организации может предполагать наличие нескольких работников у одного пользователя. Соответственно проектировщик должен выявить такую потребность при исследовании, а разработчик учесть её при реализации. Дорогие разработчики, как консультант, проектировщик и тестировщик искренне прошу вас, принимаясь за разработку, содержащую в себе определение работников для пользователей, уточните лишний раз – не требуется ли закрытие такой ситуации, даже если это явно не описано в документе. А для тестировщика перечислю возможные сочетания пользователей и работников, которые необходимо создать в системе для дальнейшей проверки:
  • с пользователем не связан ни один работник;
  • с пользователем связано несколько работников одной НОР;
  • с пользователем связано несколько работников разных НОР;
  • с пользователем связан один работник с состоянием записи «Действующая»;
  • с пользователем связан один работник с состоянием записи «Закрытая»;
  • с пользователем связан один работник с состоянием записи «Действующая» и 1 / несколько работников с состоянием записей «Закрытая» (при этом действующая запись должна быть последней созданной).
  1. Для тестирования следует создать необходимое и достаточное количество тестовых данных, предусматривающих возможность имитации различных ситуаций, создания всевозможных комбинаций, условий и т.д. Под тестовыми данными я подразумеваю, например, создание нужных документов и записей справочников, не являющихся классификаторами, наполнение источников данных для отчётов и т.п.
  2. При проведении тестирования необходимо помнить о том, что системой будут пользоваться люди. Недостаточно проверить безупречное функционирование строк кода, облечённых в типовой маршрут или карточку справочника и закрывающих требуемую задачу. Необходимо «влезть в шкуру» рядового пользователя и оценить разработанный функционал:

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

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

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

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

Святослав Тимонин

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

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

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

По своему скромному опыту работы с системой DIRECTUM могу сказать, что тема поднятая вами, действительно очень актуальна, и её нужно обсуждать как можно глубже и шире. Например, недавно столкнулся ошибкой типа "значение переменной не определено", имевшей место в одной из прикладных функций в стандартной поставке DIRECTUM 5.0.3. Хотелось бы надеяться, что больше не придётся краснеть перед клиентами из-за таких грубых ошибок в прикладной разработке.

Со всеми остальными принципами тестирования полностью согласен. Буду с нетерпением ждать следующей вашей статьи в этой серии!

Валентина Писанова

Здравствуйте, Святослав.

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

Возможно я недостаточно внятно озвучила предполагаемую целевую аудиторию моих материалов, поэтому попробую повторно осветить основные моменты:

  • ни эта статья, ни цикл в целом не ориентированы напрямую на разработчиков - ни на начинающих, ни, уж тем более, на опытных. Скорее на таких же консультантов, как и я, тестирующих прикладную разработку, выполняемую в рамках заказных решений;
  • некоторым разработчикам с малой долей вероятности могут быть полезны последующие статьи цикла, рассматривающие конкретные объекты системы DIRECTUM, но я трезво оцениваю свои шансы сказать действительно новое слово в разработке. Что касается конкретно этой статьи, если разработчики чаще будут вспоминать о возможных соотношениях работников с пользователями (и напоминать об этом остальной команде проекта) - я уже буду счастлива;
  • ни эта статья, ни цикл в целом не будут говорить о тестировании стандартного функционала системы DIRECTUM, т.к. он, увы, не является зоной моей ответственности. Только заказная разработка, только хардкор;
  • ни эта статья, ни цикл в целом не будут говорить о "первичном" тестировании кода, выполняемом разработчиками - оставлю это поле для деятельности профессионалов, если найдутся желающие.

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

Авторизуйтесь, чтобы написать комментарий