Контроль и оценка качества разработанной проектной и технической документации

Лекция №3 Контроль и оценка качества разработанной проектной и технической документации. Тестирование документации. Требования к документации. Техническая экспертиза документации. Тестирование требований. Техники тестирования требований. Ошибки при анализе и тестировании требований. Тестирование документации Качество документации — есть совокупность свойств, обусловливающих ее пригодность удовлетворять определенные потребности разработчиков и пользователей, связанные с разработкой, использованием и сопровождением программной документации в соответствии с её назначением. Таким образом, контроль и оценка качества документации заключаются в проверке наличия у документации подобных свойств. Итоги этого процесса могут быть как положительными (например, «документ обладает свойством понятности»), так и отрицательными (например, «пункты X и Y документа противоречат друг другу»). И если первый результат чаще всего является формулировкой экспертного заключения, то второй – это выявленный дефект, артефакт тестирования документации. По аналогии с тестированием ПО, тестирование документации – это процесс анализа и экспертизы документации с целью выявления дефектов. Где под дефектом будем понимать невыполнение требования, связанного с предполагаемым или установленным использованием. Собственно, требования и заключаются в наличии определённых свойств. Требования к документации Рассмотрим некоторые общепринятые свойства, которыми обладает хорошая документация:  Полнота. Документация должна содержать описание всей доступной функциональности, а не только наиболее значимой.  Актуальность. Любая документация должна содержать описание именно той функциональности, которая присутствует в приложении.  Структурированность документации. Все документы должны находится в полном порядке, по разделам. Также, текст должен быть с четкой структурой, чтобы можно было в любой момент вспомнить, где остановился или понять, в каком абзаце содержится именно та информация, которая нам необходима.  Адаптированность к быстрому поиску. У пользователя никогда не должно возникать проблем с поиском необходимой ему информации. Древовидная структура файлов, закладки и прочее должны быть на видном месте сразу, как пользователь открывает документ. Алфавитный указатель, поиск – должно присутствовать все, что поможет найти решение или описание проблемы.  Повсеместное наличие инструкций. Даже при выполнении абсолютно одинаковых манипуляций с программой необходимо пошаговое описа- ние действий во всех случаях. Это может быть как прямое повторение инструкций, так и ссылка на уже существующие. o Последовательность изложения. В некоторых сценариях важна последовательность выполнения действий. o Указание на необратимость действий. Если какое-то действие в инструкции влечёт за собой необратимые последствия для пользователя, то об этом стоит указать. o Подтверждение ожидаемого. После описания последовательности некоторых действий стоит указать ожидаемый результат. o Описание последствий отсутствия действий. Стоит добавить в документацию информацию о том, что будет, если пользователь не выполнит требуемые от него действия. o Наличие описания настроек по умолчанию. Если есть какие-либо настройки, и в них есть значения по умолчанию, то было бы хорошо, чтоб это было описано.  Термины и их значение. В любой документации может использоваться масса терминов, аббревиатур и сокращений. Каждый из них должен иметь свое значение и расшифровку.  Доступность пользователю. Документация должна быть максимально понятной для любой целевой аудитории.  Орфография, синтаксис, пунктуация. Техническая экспертиза документации Программный документ — документ, содержащий сведения, необходимые для разработки, изготовления, эксплуатации и сопровождения программного обеспечения. Эксплуатационный документ — программный документ, содержащий сведения, необходимые для обеспечения функционирования и эксплуатации программного обеспечения. Экспертиза программной и эксплуатационной документации по разработке, модернизации и внедрению программных средств информационных систем (программная документация) включает проверку документации на:  комплектность;  соответствие нормативно-технической документации (НТД);  присутствие в ней необходимых сведений для оценки автоматизированной системы и ее компонентов (описание программы, область применения, функциональные и технические характеристики и т.д.). Проверка документации на комплектность предполагает проверку соответствия требованиям нормативных документов. Например, ГОСТ 19.10177 «ЕСПД. Виды программ и программных документов» и ГОСТ 34.201-89 «Виды, комплектность и обозначения документов при создании автоматизированных систем». Требования к составу и структуре документов, выполненных по ГОСТ 34.201, установлены в РД 50-34.698 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». Проверка оформления документации (состав, структура, техническое исполнение) и согласованности доку ментов включает следующие разделы:  соответствие наименования (заголовка) документа требованиям НТД;  соответствие наименования (заголовка) документа его содержанию (по заголовкам разделов, подразделов, пунктов);  соответствие заголовков разделов, подразделов и пунктов требованиям НТД;  соответствие заголовков разделов, подразделов и пунктов их содержанию;  правильность употребления и оформления ссылок на НТД;  соответствие положений проверяемого документа положениям действующих НТД;  соответствие положений проверяемого документа положениям других документов той же системы документации и положениям документации на другие программные средства, взаимодействующие с данным;  соответствие текста нормам и правилам орфографии и пунктуации;  правильность употребления и написания терминов и других знаковых средств (терминологическая экспертиза). Проверка содержательной стороны документов (полнота, точность и доступность) оценивается экспертами на основе личного опыта с учетом установленных критериев оценки полноты, точности, доступности документа. Проверка соответствия состава и содержания программной документации требованиям установленных стандартов включает использование комплекса стандартов, регламентирующих документирование автоматизированной системы на различных стадиях его создания: стандарты серий «Информационная технология», «Единая система стандартов автоматизированной системы управления», «Единой системы программной документации»: ГОСТ 24.301, ГОСТ 24.302, ГОСТ 24.303, ГОСТ 24.304, ГОСТ 24.401, ГОСТ 24.402, ГОСТ 34.201, ГОСТ 34.602, а также серии ГОСТ 19.ХХХ. При проверки программной документации применяются также стандарты Международной организации по стандартизации, принятые в качестве межгосударственных и национальных стандартов, регламентирующие главным образом документирование программного обеспечения. К ним относятся: ГОСТ Р ИСО/МЭК 9126 «Оценка программной продукции», ГОСТ Р ИСО/МЭК ТО 9294 «Руководство по управлению документированием программного обеспечения», СТ РК ИСО/МЭК 6592, ГОСТ ИСО 9127. Оценка качества программной документации выполняется с использованием ГОСТ 28195 «Оценка качества программных средств. Общие положения», ГОСТ 28806-90 «Качество программных средств. Термины и определения», ГОСТ Р ИСО/МЭК ТО 9294-93 «Информационная технология. Руководство по управлению документированием программного обеспечения». Таким образом, данный подход к контролю качества направлен на проверку соответствия документации критериям, описанным в нормативных стандартах. Их перечень вариативен и может диктоваться как пожеланиями заказчика, так и внутренними нормами организации в которой создаётся ПО. Тестирование требований Условно документацию можно разделить на два кластера:  предназначенную для создания и/или доработки продукта (ТЗ, архитектурная/проектная документация, техническая документация, требования, спецификации и т.п.);  предназначенную для эксплуатации и/или сопровождения продукта (руководство разработчика, руководство пользователя, маркетинговая документация и т.п.). Для первой категории документов критически важно выполнить проверку требований, сформулированных в них. Требование (англ. requirement) — описание того, какие функции и с соблюдением каких условий должно выполнять приложение в процессе решения полезной для пользователя задачи. Они:  Позволяют понять, что и с соблюдением каких условий система должна делать.  Предоставляют возможность оценить масштаб изменений и управлять изменениями.  Являются основой для формирования плана проекта (в том числе плана тестирования).  Помогают предотвращать или разрешать конфликтные ситуации.  Упрощают расстановку приоритетов в наборе задач.  Позволяют объективно оценить степень прогресса в разработке проекта. Важно выполнить проверку документации, содержащей требования к продукту, до начала работы над ним. Ведь чем позже будет обнаружена ошибка (независимо от использованной модели разработки ПО), тем дороже обойдётся её исправление. Несогласованность, неясность требований может вылиться в создание продукта, который не нужен заказчику. Рисунок 1 — Свойства качественного требования Свойства качественного требования:  Завершённость, полнота (completeness). Требование является полным и законченным с точки зрения представления в нём всей необходимой информации, ничто не пропущено по соображениям «это и так всем понятно».  Атомарность, единичность (atomicity). Требование является атомарным, если его нельзя разбить на отдельные требования без потери завершённости, и оно описывает одну и только одну ситуацию.  Непротиворечивость, последовательность (consistency). Требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.  Недвусмысленность (unambiguousness, clearness). Требование описано без использования жаргона, неочевидных аббревиатур и расплывчатых формулировок и допускает только однозначное объективное понимание. Требование атомарно в плане невозможности различной трактовки сочетания отдельных фраз.  Выполнимость (feasibility). Требование технологически выполнимо и может быть реализовано в рамках бюджета и сроков разработки проекта.  Обязательность, нужность (obligatoriness) и актуальность (up-todate). Если требование не является обязательным к реализации, оно должно быть просто исключено из набора требований. Если требование нужное, но «не очень важное», для указания этого факта используется указание приоритета. Также исключены (или переработаны) должны быть требования, утратившие актуальность.  Прослеживаемость (traceability). Прослеживаемость бывает вертикальной (vertical traceability) и горизонтальной (horizontal traceability). Вертикальная позволяет соотносить между собой требования на различных уровнях требований, горизонтальная позволяет соотносить требование с тест-планом, тест-кейсами, архитектурными решениями и т. д.  Модифицируемость (modifiability). Это свойство характеризует простоту внесения изменений в отдельные требования и в набор требований. Можно говорить о наличии модифицируемости в том случае, если при доработке требований искомую информацию легко найти, а её изменение не приводит к нарушению иных описанных в этом перечне свойств.  Проранжированность по важности, стабильности, срочности (ranked for importance, stability, priority). Важность характеризует зависимость успеха проекта от успеха реализации требования. Стабильность характеризует вероятность того, что в обозримом будущем в требование не будет внесено никаких изменений. Срочность определяет распределение во времени усилий проектной команды по реализации того или иного требования.  Корректность (correctness) и проверяемость (verifiability). Фактически эти свойства вытекают из соблюдения всех вышеперечисленных (или можно сказать, что они не выполняются, если нарушено хотя бы одно из вышеперечисленных). В дополнение можно отметить, что проверяемость подразумевает возможность создания объективного тест-кейса (тест-кейсов), однозначно показывающего, что требование реализовано верно и поведение приложения в точности соответствует требованию. Техники тестирования требований 1) Взаимный просмотр (peer review). Взаимный просмотр («рецензирование») является одной из наиболее активно используемых техник тестирования требований и может быть представлен в одной из трёх следующих форм (по мере нарастания его сложности и цены):  Беглый просмотр (walkthrough) может выражаться как в показе автором своей работы коллегам с целью создания общего понимания и получения обратной связи, так и в простом обмене результатами работы между двумя и более авторами с тем, чтобы коллега высказал свои вопросы и замечания. Это самый быстрый, самый дешёвый и наиболее широко используемый вид просмотра.  Технический просмотр (technical review) выполняется группой специалистов. В идеальной ситуации каждый специалист должен представлять свою область знаний. Тестируемый продукт не может считаться достаточно качественным, пока хотя бы у одного просматривающего остаются замечания.  Формальная инспекция (inspection) представляет собой структурированный, систематизированный и документируемый подход к анализу документации. Для его выполнения привлекается большое количество 2) 3) 4) 5) 6) специалистов, само выполнение занимает достаточно много времени, и потому этот вариант просмотра используется достаточно редко (как правило, при получении на сопровождение и доработку проекта, созданием которого ранее занималась другая компания). Вопросы. Следующей очевидной техникой тестирования и повышения качества требований является (повторное) использование техник выявления требований, а также (как отдельный вид деятельности) — задавание вопросов. Главное, чтобы ваш вопрос был сформулирован таким образом, чтобы полученный ответ позволил улучшить требования. Тест-кейсы и чек-листы. Мы помним, что хорошее требование является проверяемым, а значит, должны существовать объективные способы определения того, верно ли реализовано требование. Продумывание чек-листов или даже полноценных тест-кейсов в процессе анализа требований позволяет нам определить, насколько требование проверяемо. На начальной стадии проверки, когда требования могут быть сформулированы неточно, расплывчато данная методика может быть ненужной. Но позже, имея чёткие требования, её применение позволит совместить процессы тестирования документации и разработки тесткейсов. Исследование поведения системы. Эта техника логически вытекает из предыдущей (продумывания тест-кейсов и чек-листов), но отличается тем, что здесь тестированию подвергается, как правило, не одно требование, а целый набор. Тестировщик мысленно моделирует процесс работы пользователя с системой, созданной по тестируемым требованиям, и ищет неоднозначные или вовсе неописанные варианты поведения системы. Этот подход сложен, требует достаточнойквалификации тестировщика, но способен выявить нетривиальные недоработки, которые почти невозможно заметить, тестируя требования по отдельности. Рисунки (графическое представление). Чтобы увидеть общую картину требований целиком, часто бывает удобно использовать рисунки, схемы, диаграммы, интеллект-карты и т. д. Графическое представление удобно одновременно своей наглядностью и краткостью. На рисунке очень легко заметить, что какие-то элементы «не стыкуются», что гдето чего-то не хватает и т.д. Если вы для графического представления требований будете использовать общепринятую нотацию (например, уже упомянутый UML), можно получить дополнительные преимущества: схему смогут без труда понимать и дорабатывать коллеги, а в итоге может получиться хорошее дополнение к текстовой форме представления требований. Прототипирование. Можно сказать, что прототипирование часто является следствием создания графического представления и анализа поведения системы. С использованием специальных инструментов можно очень быстро сделать наброски пользовательских интерфейсов, оценить применимость тех или иных решений и даже создать не просто «прототип ради прототипа», а заготовку для дальнейшей разработки, если окажется, что реализованное в прототипе (возможно, с небольшими доработками) устраивает заказчика. Ошибки при анализе и тестировании требований Изменение формата файла и документа. По какой-то непонятной причине очень многие начинающие тестировщики стремятся полностью уничтожить исходный документ, заменив текст таблицами (или наоборот), перенеся данные из Word в Excel и т.д. Это можно сделать только в одном случае: если вы предварительно договорились о подобных изменениях с автором документа. В противном случае вы полностью уничтожаете чью-то работу, делая дальнейшее развитие документа крайне затруднительным. Самое худшее, что можно сделать с документом, — это сохранить его в итоге в некоем формате, предназначенном скорее для чтения, чем для редактирования (PDF, набор картинок и тому подобное). Если требования изначально создаются в некоей системе управления требованиями, этот вопрос неактуален, но высокоуровневые требования большинство заказчиков привыкли видеть в обычном DOCX-документе, а Word предоставляет такие прекрасные возможности работы с документом, как отслеживание изменений и комментарии. Отметка того факта, что с требованием всё в порядке. Если у вас не возникло вопросов и/или замечаний к требованию — не надо об этом писать. Любые пометки в документе подсознательно воспринимаются как признак проблемы, и такое «одобрение требований» только раздражает и затрудняет работу с документом — сложнее становится заметить пометки, относящиеся к проблемам. Описание одной и той же проблемы в нескольких местах. Помните, что ваши пометки, комментарии, замечания и вопросы тоже должны обладать свойствами хороших требований (настолько, насколько эти свойства к ним применимы). Если вы много раз в разных местах пишете одно и то же об одном и том же, вы нарушаете как минимум свойство модифицируемости. Постарайтесь в таком случае вынести ваш текст в конец документа, укажите в нём же (в начале) перечень пунктов требований, к которым он относится, а в самих требованиях в комментариях просто ссылайтесь на этот текст. Написание вопросов и комментариев без указания места требования, к которым они относятся. Если ваше инструментальное средство позволяет указать часть требования, к которому вы пишете вопрос или комментарий, сделайте это (например, Word позволяет выделить для комментирования любую часть текста — хоть один символ). Если это невозможно, цитируйте соответствующую часть текста. В противном случае вы порождаете неоднозначность или вовсе делаете вашу пометку бессмысленной, т.к. становится невозможно понять, о чём вообще идёт речь. Задавание плохо сформулированных вопросов. Можно указать следующие виды подобных вопросов:  Первый вид возникает из-за того, что автор вопроса не знает общепринятой терминологии или типичного поведения стандартных элементов интерфейса.  Второй вид плохих вопросов похож на первый из-за формулировок: вместо того, чтобы написать «что вы имеете в виду под {чем-то}?», автор вопроса пишет «что такое {что-то}?». То есть вместо вполне логичного уточнения получается ситуация, очень похожая на рассмотренную в предыдущем пункте.  Третий вид сложно привязать к причине возникновения, но его суть в том, что к некорректному и/или невыполнимому требованию задаётся вопрос наподобие «что будет, если мы это сделаем?». Ничего не будет, т.к. мы это точно не сделаем. И вопрос должен быть совершенно иным (каким именно — зависит от конкретной ситуации, но точно не таким). И вновь, важно помнить о точности формулировок: иногда одно-два слова могут на корню уничтожить отличную идею, превратив хороший вопрос в плохой. Сравните: «Что такое формат даты по умолчанию?» и «Каков формат даты по умолчанию?». Первый вариант просто показывает некомпетентность автора вопроса, тогда как второй — позволяет получить полезную информацию. К этой же проблеме относится непонимание контекста. Часто можно увидеть вопросы в стиле «о каком приложении идёт речь?», «что такое система?» и им подобные. Чаще всего автор таких вопросов просто вырвал требование из контекста, по которому было совершенно ясно, о чём идёт речь. Написание очень длинных комментариев и/или вопросов. История знает случаи, когда одна страница исходных требований превращалась в 20–30 страниц текста анализа и вопросов. Это плохой подход. Все те же мысли можно выразить значительно более кратко, чем сэкономить как своё время, так и время автора исходного документа. Тем более стоит учитывать, что на начальных стадиях работы с требованиями они весьма нестабильны, и может получиться так, что ваши 5–10 страниц комментариев относятся к требованию, которое просто удалят или изменят до неузнаваемости. Критика текста или даже его автора. Помните, что ваша задача — сделать требования лучше, а не показать их недостатки (или недостатки автора). Потому комментарии вида «плохое требование», «неужели вы не понимаете, как глупо это звучит», «надо переформулировать» неуместны и недопустимы. Категоричные заявления без обоснования. Как продолжение ошибки «критика текста или даже его автора» можно отметить и просто категоричные заявления наподобие «это невозможно», «мы не будем этого делать», «это не нужно». Даже если вы понимаете, что требование бессмысленно или невыполнимо, эту мысль стоит сформулировать в корректной форме и дополнить вопросами, позволяющими автору документа самому принять окончательное решение. Например, «это не нужно» можно переформулировать так: «Мы сомневаемся в том, что данная функция будет востребована пользователями. Какова важность этого требования? Уверены ли вы в его необходимости?» Указание проблемы с требованиями без пояснения её сути. Помните, что автор исходного документа может не быть специалистом по тестированию или бизнес-анализу. Потому просто пометка в стиле «неполнота», «двусмысленность» и т.д. могут ничего ему не сказать. Поясняйте свою мысль. Сюда же можно отнести небольшую, но досадную недоработку, относящуюся к противоречивости: если вы обнаружили некие противоречия, сделайте соответствующие пометки во всех противоречащих друг другу местах, а не только в одном из них. Например, вы обнаружили, что требование 20 противоречит требованию 30. Тогда в требовании 20 отметьте, что оно противоречит требованию 30, и наоборот. И поясните суть противоречия. Плохое оформление вопросов и комментариев. Старайтесь сделать ваши вопросы и комментарии максимально простыми для восприятия. Помните не только о краткости формулировок, но и об оформлении текста. Перечитайте свой текст, исправьте опечатки, грамматические и пунктуационные ошибки и т.д. Описание проблемы не в том месте, к которому она относится. Классическим примером может быть неточность в сноске, приложении или рисунке, которая почему-то описана не там, где она находится, а в тексте, ссылающемся на соответствующий элемент. Исключением может считаться противоречивость, при которой описать проблему нужно в обоих местах. Скрытое редактирование требований. Эту ошибку можно смело отнести к разряду крайне опасных. Её суть состоит в том, что тестировщик произвольно вносит правки в требования, никак не отмечая этот факт. Соответственно, автор документа, скорее всего, не заметит такой правки, а потом будет очень удивлён, когда в продукте что-то будет реализовано совсем не так, как когда-то было описано в требованиях. Потому простая рекомендация: если вы что-то правите, обязательно отмечайте это (средствами вашего инструмента или просто явно в тексте). И ещё лучше отмечать правку как предложение по изменению, а не как свершившийся факт, т.к. автор исходного документа может иметь совершенно иной взгляд на ситуацию. Анализ, не соответствующий уровню требований. При тестировании требований следует постоянно помнить, к какому уровню они относятся, т.к. в противном случае появляются следующие типичные ошибки:  Добавление в бизнес-требования мелких технических подробностей.  Дублирование на уровне пользовательских требований части бизнестребований (если вы хотите увеличить прослеживаемость набора требований, имеет смысл просто использовать ссылки).  Недостаточная детализация требований уровня продукта (общие фразы, допустимые, например, на уровне бизнес-требований, здесь уже должны быть предельно детализированы, структурированы и дополнены подробной технической информацией). Литература 1. Куликов, С. C. Тестирование программного обеспечения. Базовый курс — Минск: Четыре четверти, 2017. — 312 с.