XML для тестировщиков (III - Specifications)

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

• XSD-схема;
• Спецификация в виде текстового документа;
• Примеры XML документов.

У каждого из этих представлений есть плюсы и минусы. Они накладывают свой отпечаток на процесс подготовки к тестированию, а так же на сроки выполнения работ. О специфических аспектах работы с различными представлениями требований к XML и пойдет речь в этой статье.

XSD-схема

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

Плюсы
Основной плюс подхода - это многократная применимость документа. Проработку схем, обычно, осуществляет архитектор или ведущий разработчик проекта. Затем выполняется согласование полученного документа со специалистами, занятыми в разработке внешнего модуля или системы. После этого XSD-схему используют все экспертизы: аналитики - при уточнении формализованных бизнес требований; разработчики - для быстрого построения программного кода; тестировщики - для построения сценариев тестирования.

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

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

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

Алгоритм работы
Проверенный временем "рецепт успеха" по преодолению сложностей работы с XSD-схемами выглядит следующим образом.

Ингредиенты

• XSD-схема;
• Знания в области XML и XSD (черпаются из литературы, статей и подобных источников);
• Инструментарий для работы: уже упоминавшийся текстовый редактор с подсветкой синтаксиса (XML для тестировщиков (I - Introduction)), утилита для просмотра XML документов и формирования XML по XSD (платная и мощная Altova XMLSpy или open-source аналоги, например, XMLMaker, XMLPad);
• Утилиты для автоматизированной подготовки тестовых данных, если количество файлов для тестирования превышает сотню (в моей практике это специальные макросы для Excel).

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

1. Изучить схему, задать все возникающие вопросы автору схемы. Если предполагается хранение данных, полученных в виде XML, в базе данных проекта, то нужно сравнить ограничения по формату в XSD-схеме с ограничением полей в физической модели базы. Обычно уже на этом этапе находится пара-тройка несоответствий.
2. С помощью утилит или вручную подготовить примеры готовых к использованию XML документов. А также все необходимые артефакты для автоматизированной подготовки данных (если необходимо) и проверить правильность формирования файлов на одном примере для каждого вида сообщений.
3. Составить сценарии тестирования на базе XSD-схемы и функциональных требований. И на этом этапе обычно поджидает несколько сюрпризов и корректировок.
4. Подготовить весь набор данных (файлов XML) для тестирования.

Спецификация в виде текстового документа

Спецификация представляет собой текстовый документ, описывающий состав полей XML документа и требования к ним. В лучшем случае описание представлено в виде структурированного набора таблиц, в худшем - многословное текстовое описание.

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


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

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

Для команды разработки текстовые спецификации являются проклятьем. Они влекут за собой огромное количество copy-paste операций, ведь из текста документа нужно "слепить" что-то подобное XSD-схеме. При использовании операций "копирования" и "вставки" всегда происходят ошибки, которые в большинстве случаев перерастают в дефекты.

Алгоритм работы
Останавливаться отдельно на инструментарии нет смысла, т.к. он идентичен тому, что приведен выше в разделе про XSD-схемы.

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

1. Изучить документ и задать все возникающие вопросы. При этом очень важно не бояться выходить с инициативой провести "очную ставку" со всеми экспертизами. Коллективный разбор документа на совещании поможет сэкономить кучу времени на последующие коммуникации, "разборы полетов" и переработки.
2. В случае, если уже известен специалист, который будет отвечать за проведение интеграционного тестирования со стороны заказчика (субподрядчика), обсудить с ним предложенный документ. Уверена на 99%, что у него будет свое видение, отличающиеся от вашего.
3. Будет не лишним обсудить документ с экспертом по разработке модулей для работы с XML. Это принесет положительный результат, если описанные интерфейсы средней и высокой сложности. Для простых вещей такого рода консультации не нужны. И главное не перебивать, эксперту всегда есть что сказать, ваша задача - запомнить (а еще лучше зафиксировать) самое важное.
4. Затем все по известной схеме: сверяемся с ограничениями базы данных (если необходимо), готовим примеры XML файлов, проверяем правильность формирования с помощью утилит на одном контрольном примере, составляем сценарии тестирования, готовим все наборы тестовых данных.

Примеры XML документов

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

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

Если ничего нет, нужно озвучить проблему руководителю проекта. Это его святая обязанность "добыть" информацию. Зачастую это помогает.

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

Заключение

Способов формализации требований существует огромное множество. У каждого из них есть свои плюсы и минусы, а так же причины, по которым было принято решение оформлять требования именно так (лень - это тоже причина, и она имеет свой вес :)). Главное - с любым источником информации об XML документах можно работать и качество дальнейшего тестирования зависит от тщательности проведения исследования данных и подготовки тестовых наборов. О том, какие именно тесты необходимо применять в случае XML документов речь пойдет в одной из следующих статей.