Для чего нужна тестовая документация
Тестирование документации к программным продуктам
Перечень качеств, на которые можно ориентироваться при тестировании документации:
1. Работоспособность сценариев
Самое главное качество, которым должна обладать документация. Сценарии должны быть описаны точно, их выполнение должно приводить к достижению целей, для выполнения которых создан продукт. Если есть альтернативные сценарии, то они должны быть упомянуты.
2. Полнота описания
Очевидный пункт, подразумевающий, что каждый элемент функционала, будь то элемент интерфейса, такой, как кнопка, флажок, всплывающая подсказка и т.д. или же вводимая команда, или реакция на действия должны быть описаны. В том числе стоит учитывать, что пользователю может потребоваться отыскать в документации алгоритм действий при появлении определенного сообщения.
3. Уделение внимания обязательным пунктам
Не должно быть такого, что какие-либо обязательные и важные действия пользователя упоминаются вскользь, нужно уделить внимание описанию всех необходимых действий. Документация не должна напоминать кредитный договор, в котором все дополнительные условия описаны мелким шрифтом. Например, стоит явно прописать информацию о том, что если в конфигурационном файле будет запятая вместо точки то приложение не будет запускаться. Подобно тому, как в кредитном договоре стоит на видном месте прописать то, что процентная ставка станет 300% годовых вместо 20% в случае неуплаты платежа в срок.
4. Актуальность описания
Если тестируется документация к программному продукту, у которого много версий, то следует обратить внимание на актуальность описания. Может оказаться так, что в текущей версии функционал был изменен, но в документацию это не попало. Или же в последий момент было принято решение не включать фичу в текущий релиз, а она уже описана в документации. Также стоит обратить внимание на актуальность годов, контактных данных, системных требований, лицензионного соглашения, скриншотов.
5. Адаптированность к тому, что пользователь будет в спешке
Важное качество. Редко когда бывает так, что документацию читают неспешно на досуге. Чаще всего люди обращаются к документации, когда у них что-то не работает, велика вероятность того, что пользователь читает документацию в нерабочее время. Здесь можно порекомендовать минимизировать количество цепочек действий с зависимостями. Выполнение сценария не должно напоминать прохождение квеста. Было бы хорошо, чтобы все необходимые условия для выполнения сценария были описаны до сценария. Можно привести такую аналогию: Если требуется прибить полку к кирпичной стене, то помимо полки в обязательном порядке потребуется перфоратор, бур, дюбель-гвозди.
6. Адаптированность к тому, что пользователь будет раздражен
Эмоциональная реакция при взаимодействии с программными продуктами имеет очень большое сходство с реакцией при взаимодействии с другими людьми. В случае, если пользователь читает документацию из-за того, что у него возникли какие-либо неполадки, скорее всего он будет в раздраженном состоянии. Здесь можно рекомендовать делать атомарность предложений и абзацев. Например, вместо > лучше прописать >
7. Структурированность, адаптированность к быстрому поиску
Документация должна иметь четкую структуру и пользователь должен иметь возможность быстро найти в ней информацию по оглавлеию. Можно провести параллель с качеством фотоаппарата: простой фотоаппарат должен иметь такие конструктивные характеристики, чтоб можно было быстро задействовать его, не упустив момента. Если фотоаппарат будет долго доставаться из чехла и долго включаться, то в нужный момент может он может оказаться бесполезен. Применительно к документации и справке, если для поиска какой-то информации нужно много времени, то пользователь может бросить поиск т.к. у него не хватит терпения выполнять действия.
8. Наличие указания на необратимость действий
Если какие-либо действия пользователя необратимы, то стоит явно об этом указать. Например, при удалении чего-либо в программе, потом далеко не всегда можно это восстановить. Также стоит добавить информацию о том, как можно обратить те или иные действия. Например, мы хотим внести в программу множество данных, но не уверены в том, что они верные, стоит явно указать способ, каким образом можно будет потом обратить наши действия, например, восстановление настроек).
9. Подтверждение ожидаемого
После описания последовательности некоторых действий стоит указать ожидаемый результат. Подобно тому, как стоит попробовать суп после того, как туда добавили соль и специи.
10. Описание последствий отсутствия действий пользователя
Стоит добавить в документацию информацию о том, что будет, если пользователь не выполнит требуемые от него действия. Например, если пользователь не задаст ip-адрес сетевого интерфейса, то через этот интерфейс не получится отправлять пакеты.
11. Ясность изложения информации
Должна использоваться наиболее подходящая к тестируемым объектам терминология. Если используется специфический термин, то стоит его отдельно описать. Если возможно двоякое толкование термина, то следует уточнить какое именно используется.
12. Логика и согласованность
В сценариях должно указываться какие действия с какой целью делаются. Должен быть понятен смысл выполняемых действий.
13. Последовательность изложения
В некоторых сценариях важна последовательность выполнения действий. Например, при варке супа мы сначала наливаем воду, а затем добавляем другие ингредиенты, такие, как картофель. Если же сначала положить картофель, а воду залить намного позже, то вместо супа получится что-то несъедобное.
14. Орфография, синтаксис, пунктуация
Разумеется, текст должен быть описан грамотно. Орфографию можно проверить в MS Word или другими средствами. Для проверки синтаксиса и пунктуации необходимо вчитываться в текст, понимать его смысл, понимать значения каждого из используемых терминов.
15. Наличие описания настроек по умолчанию
Если есть какие-либо настройки, и в них есть значения по умолчанию, то было бы хорошо, чтоб это было описано. Пользователь захочет найти информацию о настройках по умолчанию, если он менял настройки, но не запоминал изменений, и после этого программа перестала корректно работать.
16. Адаптированность к аудитории
Если продукт рассчитан на простых пользователей, то в документации к нему действия пользователя должны описываться простыми понятными терминами. Если же продукт рассчитан на пользователей Apple либо на администраторов Linux, то стоит учитывать особенности этих пользователей. Руководства к серверному и управляющему ПО часто ориентированы на системных администраторов.
17. Атомарность сценариев
Больше применимо к справке, но зачастую пользователям нужна информация лишь об одном элементе функционала. И нет желания и возможностей изучать полностью документацию. Не стоит заставлять пользователя изучать весть продукт, если есть возможность этого не делать. Например, если нужно поменять шрифт в текстовом редакторе, не следует указывать в документации о том, что прежде чем это делать необходимо изучить историю текстовых редакторов, изучить перечень функций текстового редактора, изучить что такое шрифты и т.д.
18. Адаптированность к наименее возможной квалификации пользователей
Не всегда люди задаются вопросом о том, как функционирует программа, им важен результат. И стоит учитывать, что продукт могут использовать разные пользователи. Например, системному администратору, имеющую высокую квалификацию, может потребоваться показать на пальцах результаты работы с использованием продукта директору. А директор может заглянуть в документацию, если показанные результаты очень важны в рамках его деятельности. Тут стоит как можно меньше использовать сложные технические термины, для понимания которых придется открывать интернет. Домохозяйке не обязательно знать как функционирует микроволновая печь, но ей важно знать, что в ней можно варить и не следует помещать внутрь металлические предметы. Также домохозяйке, в отличие от ученого, следует знать, что не стоит помещать яйца в микроволновку.
Кому нужна качественная документация
Часто замечаю, что мало кто обращает на качество документации. Действительно, кому она приносит выгоду и какую? Подозреваю, что многие команды при разработке программных продуктов создают документацию лишь потому, что задачу по созданию документации поставили вышестоящие лица. И понижение приоритета обеспечения качества документации обусловлено тем, что нет возможности подсчитать в цифрах выгоду, которую это дает. К сожалению, я не могу представить такую статистику в цифрах.
Выгоду от наличия документации можно сравнить с выгодой создания дополнительной инфраструктуры при постройке жилья. С одной стороны, при продаже главную роль играет площадь жилья: цена назначается за квадрат. Но если присмотреться — цена в некоторых домах значительно превосходит цену в других. И обусловлено это в первую очередь окружающей инфраструктурой (стоянки, лифты, газоны, и т.д.).
Наличие качественной документации дает плюсы: пользователи не стремятся отказаться от продукта, снижается нагрузка на техподдержку, внутри команды разработки возникает меньше вопросов о том, как должен функционировать продукт, легче его продавать.
Документация тестирования
Что такое документация тестирования?
Как мы все знаем, тестирование является одним из наиболее важных этапов в разработке программного обеспечения. Перед каждым этапом очень важно вести полную документацию, чтобы иметь систематический и запланированный подход и избежать любых будущих проблем. Таким образом, перед началом процесса тестирования готовится документ, содержащий все артефакты, которые помогают в оценке охвата тестирования, отслеживания требований, матрицы прослеживаемости и общих требуемых усилий. Тестовую документацию можно подготовить до или во время процесса тестирования программного обеспечения. Это пакет, содержащий все необходимые документы с полной информацией о цикле тестирования, охвате тестирования, процессе выполнения теста, последующем процессе тестирования и т. Д.
Зачем нам нужна документация для тестирования?
Если говорить о реальных сценариях, то теперь для разработки программного обеспечения используется методология Agile, что означает, что программное обеспечение разрабатывается небольшими итерационными циклами, и тестирование программного обеспечения проводится вместе с разработкой. Поскольку над ней работает большая группа людей (включая как разработчиков, так и тестировщиков), должна быть определена и задокументирована систематическая процедура, которой будет следовать каждый член команды перед тестированием продукта, который включает тестовое покрытие, стратегию тестирования, цикл испытаний, данные испытаний, планирование испытаний, порядок сообщений об ошибках и т. д.
Документация тестирования играет жизненно важную роль в тестировании программного обеспечения. Это помогает сэкономить усилия, время и стоимость всего проекта путем определения каждого процесса, который будет выполняться при тестировании программного обеспечения, и устранения неясностей. Он обеспечивает систематический подход и дает тестировщику обзор всего продукта.
Ниже приведены некоторые причины, по которым существует необходимость в тестировании:
1. Тестирование покрытия
Тестовая документация помогает определить общий процесс и помогает команде тестирования достичь максимального охвата тестированием. Поскольку все документы о тестовых примерах, результатах тестов и циклах тестирования присутствуют, тестировщики могут легко определить охват теста после каждой цели.
2. Достижение сроков выпуска продукции
Все данные, относящиеся к статусу тестирования проекта, легко видны всем членам команды и руководителю группы, напоминая каждому из них о текущем состоянии проекта и приближающихся сроках.
3. Обеспечивает хорошую подготовку для освежителей
Хорошо подготовленная тестовая документация по проекту не только помогает команде тестирования в их работе, но и служит хорошим учебным материалом для новичков и новичков в отрасли для их практических знаний о том, как все работает в режиме реального времени.
4. Помогает в устранении неопределенности
Одна из основных причин наличия тестовой документации заключается в том, что она помогает устранить путаницу, которая может возникнуть после любого конкретного процессора во время доставки. Временами возникает конфликт между тестировщиками и разработчиками в отношении их работы. Поскольку все тестирование, регистрация ошибок и функции продукта уже определены в документах, в будущем не будет места для двусмысленности.
5. Определение бюджета проекта
Это также помогает компаниям во многом определить требования, объем работы, ресурсы и другое необходимое программное обеспечение, которое помогает определить общий бюджет проекта.
Преимущества использования тестовой документации
Некоторые из преимуществ использования тестовой документации в проекте упомянуты ниже:
Примеры тестовой документации
3. Сценарий тестирования. Он включает в себя различные сценарии тестирования или функцию продукта, для которой необходимо создать и выполнить тестовые случаи.
4. Тестовый пример: он содержит все детали относительно тестовых случаев, которые должны быть выполнены, такие как предварительные условия, постусловия, ожидаемые результаты и результаты тестового примера.
5. Тестовые данные. Содержит все тестовые данные, необходимые для выполнения тестовых случаев, имеющих тестовые сценарии.
6. Отчет об испытаниях. Это полный отчет о результатах испытаний, прошедших или не прошедших проверку. Он содержит все обобщенные данные результатов теста.
7. Политика тестирования. Этот документ содержит процессы и политики компании или любые политики тестирования, которые необходимо соблюдать во время тестирования продукта.
8. Отчет о дефектах : этот документ содержит все дефекты / ошибки, возникшие в ходе тестирования продукта, и их текущее состояние для общей оценки продукта и будущие ссылки.
Вывод
Таким образом, статья четко описывает, что такое тестовая документация и почему она важна в реальных проектах. Не каждый проект имеет тестовую документацию, так как это зависит от различных факторов, таких как тип приложения и политики компании. Небольшие проекты, как правило, не имеют или имеют очень мало тестовой документации, поскольку они также требуют много времени, что, в свою очередь, требует нескольких дней для подготовки и, следовательно, ограничивает бюджет проекта. Каждый проект и каждая компания, внедряющая тестовую документацию, имеют свою разную компоновку, но в целом все описывают каждую деталь, касающуюся тестирования продукта.
Рекомендуемые статьи
Для чего нужна тестовая документация
ГОСТ Р 56922-2016/
ISO/IEC/IEEE 29119-3:2013
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ
Тестирование программного обеспечения
Software and systems engineering. Software testing. Part 3. Test documentation
Дата введения 2017-06-01
1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ) на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»
Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5 (пункт 3.5).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА
Введение
Международная организация по стандартизации (ИСО) и Международная электротехническая комиссия (МЭК) образуют специализированную систему всемирной стандартизации. Национальные органы по стандартизации, которые являются членами ИСО или МЭК, участвуют в разработке международных стандартов через технические комитеты, созданные соответствующей организацией для определенных областей технической деятельности. Технические комитеты ИСО и МЭК сотрудничают в сферах, представляющих взаимный интерес. Другие международные правительственные и неправительственные организации, связанные с ИСО и МЭК, также принимают участие в деятельности по разработке стандартов. В сфере информационной технологии ИСО и МЭК учредили совместный технический комитет ИСО/МЭК СТК 1.
Стандарты Института инженеров по электротехнике и радиоэлектронике (ИИЭР) разработаны в сообществах и комитетах по координации стандартов ИИЭР, входящих в состав бюро стандартов ассоциации стандартов ИИЭР. ИИЭР разрабатывает свои стандарты на основе одобренного Американским национальным институтом стандартов консенсусного процесса разработки, который для достижения конечного результата объединяет различные точки зрения и интересы добровольцев. Добровольцы не обязательно являются сотрудниками института и работают на безвозмездной основе. При том что ИИЭР курирует процесс и устанавливает правила обеспечения справедливости в консенсусном процессе разработки, он не проводит независимые оценку, испытание или проверку точности какой-либо информации, входящей в состав своих стандартов.
Международные стандарты разрабатываются в соответствии с правилами, приведенными в Директивах ИСО/МЭК, часть 2.
Основная задача совместного технического комитета состоит в подготовке международных стандартов. Проекты международных стандартов, принятые совместным техническим комитетом, распространяются среди национальных органов по стандартизации для вынесения решения. Для публикации в качестве международного стандарта требуется одобрение по крайней мере 75% национальных органов по стандартизации, участвующих в голосовании.
Следует обратить внимание на возможность того, что при внедрении этого стандарта может потребоваться использование документа, защищенного патентными правами. При публикации настоящего стандарта не рассматривались вопросы наличия или соответствия каких-либо связанных со стандартом патентных прав. ИСО/ИИЭР не несет ответственность ни за идентификацию существенных для стандарта патентов или патентных заявок, для которых может требоваться лицензия, ни за расследование юридической правильности или области применения патентов либо патентных заявок, ни за определение каких-либо условий лицензирования или условий предоставления гарантийных писем либо патентных заявлений и форм лицензирования, если таковые имеются, ни за какие-либо приемлемые недискриминационные лицензионные соглашения. Пользователи этого стандарта должны принять во внимание то, что определение действия каких-либо патентных прав и риска нарушения таких прав полностью лежит на их собственной ответственности. Дополнительная информация может быть получена в ИСО или Ассоциации стандартов ИИЭР.
ИСО/МЭК/ИИЭР 29119-3 подготовлен Подкомитетом 7 «Системная и программная инженерия» совместного технического комитета ИСО/МЭК СТК 1 «Информационные технологии» в сотрудничестве с комитетом по стандартам системной и программной инженерии компьютерного сообщества ИИЭР в соответствии с организационным соглашением о партнерском сотрудничестве по разработке стандартов между ИСО и ИИЭР.
Серия стандартов ИСО/МЭК/ИИЭР 29119 под общим названием «Системная и программная инженерия. Тестирование программного обеспечения» состоит из следующих частей:
— Часть 1. Понятия и определения;
— Часть 2. Процессы тестирования;
— Часть 3. Документация тестирования;
— Часть 4. Методики тестирования.
Цель создания серии стандартов тестирования программного обеспечения ИСО/МЭК/ИИЭР 29119 состоит в том, чтобы определить общую модель тестирования программного обеспечения, которая может использоваться любой организацией при выполнении различных форм тестирования программного обеспечения. В настоящем стандарте представлены шаблоны и примеры документации тестирования, которая создается в ходе процесса тестирования. Шаблоны, приведенные в приложениях, отражают полную структуру процесса тестирования, описанного в ИСО/МЭК/ИИЭР 29119-2 «Процессы тестирования», то есть процесса тестирования, для которого создается документация. В приложении A изложены основы содержания каждого документа.
Приложение B содержит список всех информационных элементов, определенных в разделах 5, 6 и 7 настоящего стандарта, с соответствующим уровнем требования соответствия (необходимо/следует/можно) ИСО/МЭК/ИИЭР 29119-2 «Процессы тестирования». Приложение C содержит общие сведения о примерах. В приложениях D-S приводятся примеры применения шаблонов. Приложение T показывает взаимосвязь с существующими стандартами. Библиография приводится в конце настоящего стандарта.
Понятия и терминология документации тестирования программного обеспечения определены в ИСО/МЭК/ИИЭР 29119-1 «Понятия и определения».
Актуальная модель процесса тестирования определена в ИСО/МЭК/ИИЭР 29119-2 «Процессы тестирования». В этом стандарте представлено описание процессов тестирования, которые определяют процессы тестирования программного обеспечения на организационном уровне, уровне управления тестированием и уровне динамического тестирования. Кроме того, там представлены информативные диаграммы, описывающие процессы.
Методы проектирования тестирования программного обеспечения, которые могут быть использованы в разработке тестирования, определены в ИСО/МЭК/ИИЭР 29119-4 «Методики тестирования».
Серия международных стандартов ИСО/МЭК/ИИЭР 29119 дает возможность всем заинтересованным лицам контролировать и выполнять тестирование программного обеспечения в любой организации.
1 Область применения
Настоящий стандарт определяет шаблоны документации тестирования программного обеспечения, которые могут использоваться в любой организации, любом проекте или каком-либо действии тестирования проекта. Здесь описана документация тестирования, которая является результатом процессов, определенных в ИСО/МЭК/ИИЭР 29119-2 «Процессы тестирования». Иерархия документации тестирования представлена на рисунке 1 и в приложении A на рисунке A.1.
Настоящий стандарт применим к тестированию всех моделей жизненного цикла разработки программного обеспечения.
Целевая аудитория настоящего стандарта включает в себя: тестеров, менеджеров тестирования, разработчиков и менеджеров проектов и особенно ответственных за руководство, управление и реализацию тестирования программного обеспечения, но не ограничена этим списком.
Документы, описанные в настоящем стандарте, могут со временем создаваться в нескольких версиях. Однако обращение к нескольким версиям документов лежит вне области применения настоящего стандарта, потому что относится к вопросам менеджмента конфигурации.
2 Соответствие
2.1 Предполагаемое соответствие
Требования настоящего стандарта, содержащиеся в разделах 5, 6 и 7, устанавливают требования для многих документов тестирования, приемлемых для использования в течение полного жизненного цикла программного обеспечения. Допускается, что в конкретных проектах или организациях может не возникать потребности в использовании всех документов, определенных в настоящем стандарте. Поэтому практическая реализация настоящего стандарта обычно заключается в выборе совокупности документов, пригодных для организации или проекта. Существуют два типа соответствия условиям настоящего стандарта: полное и адаптированное. Соответствие может быть заявлено для организаций, проектов, проектов с несколькими исполнителями и услуг, как это определено в заявлении о соответствии.
Информационные элементы, определенные в разделах 5, 6 и 7, соответствуют выходным данным ИСО/МЭК/ИИЭР 29119-2 «Процессы тестирования». Приложение В является справочным и представляет обзор нормативных требований к разделам ИСО/МЭК/ИИЭР 29119-2, в которых описано создание информационных элементов, определенных в разделах 5, 6 и 7.
Для простоты ссылок в настоящем стандарте на каждый документ ссылаются как на опубликованный в виде отдельного печатного документа. Названия и содержание документов могут быть изменены (дополнены, объединены или переименованы), и использование номенклатуры конкретных документов, определенных в разделах 5, 6 и 7, не должно требовать соответствия. Документы считаются соответствующими, если они не опубликованы, а доступны в электронной форме, если они разделены на отдельные части или тома или объединены с другими документами в один документ.
2.2 Типы соответствия
Возможны заявления о соответствии двух типов. Выбранный тип соответствия должен быть идентифицирован в заявлении о соответствии документации.
2.2.1 Полное соответствие
2.2.2 Адаптированное соответствие
Содержание документов тестирования, определенных в разделах 5, 6 и 7, может быть адаптировано на базе адаптированного соответствия ИСО/МЭК/ИИЭР 29119-2 «Процессы тестирования» и/или на основе конкретных потребностей организации или проекта. В каждом случае адаптации, если не представлен информационный элемент, определенный в разделах 5, 6 и 7, необходимо предоставить обоснование. Все решения по адаптации должны быть документированы с их обоснованием, включая учет любых применимых рисков.
Решения по адаптации должны быть согласованы с соответствующими заинтересованными сторонами.
Адаптированное соответствие может быть достигнуто в следующих случаях:
a) Минимальная совокупность требуемой документации тестирования определена адаптацией процессов и действий в соответствии с разделом 2 ИСО/МЭК/ИИЭР 29119-2 «Процессы тестирования».
b) Минимальная совокупность требуемой документации тестирования определена в соответствии с конкретными потребностями организации и/или проекта.
c) Минимальная совокупность требуемых информационных элементов в документах определена в соответствии с конкретными потребностями организации и/или проекта.
1 В отдельных проектах, особенно в тех, которые следуют методике динамичной разработки, адаптация может быть применена ко всем документам настоящего стандарта, допуская их краткую форму или представление в альтернативном формате (например, устном или формате слайдов).
2 Возможно использование различных названий документов, но в таких случаях для облегчения оценки соответствия обычно представляют соответствие локально используемых названий настоящему стандарту.
3 Нормативные ссылки
ИСО/МЭК/ИИЭР 15289:2011 Системная и программная инженерия. Содержание информационных продуктов жизненного цикла (документация)
ИСО/МЭК/ИИЭР 29119-1 Системная и программная инженерия. Тестирование программного обеспечения. Часть 1. Понятия и определения
ИСО/МЭК/ИИЭР 29119-2 Системная и программная инженерия. Тестирование программного обеспечения. Часть 2. Процессы тестирования
Другие стандарты, полезные для реализации и интерпретации настоящего стандарта, приведены в разделе «Библиография».
4 Термины и определения
В настоящем стандарте применены термины и определения, приведенные в ИСО/МЭК/ИИЭР 24765, а также следующие термины с соответствующими определениями.