Программные ошибки тестирование документации

Как тестировать документацию. Простой алгоритм

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

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

Введение

Повторенье — мать учения, пробежимся по базовым определениям, чтоб изъясняться на одном языке:

Тестирование (testing) — процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ с целью определить, что они соответствуют описанным требованиям, показать, что они подходят для заявленных целей и для определения дефектов. (Источник — ISTQB Glossary)

Итак, тестирование — это процесс с тремя вопросами к тестируемому объекту

• соответствует ли он требованиям? 

• подходит цели? 

• какие есть дефекты (баги)?

Статическое тестирование (static testing): тестирование артефактов разработки программного обеспечения, таких как требования, дизайн или программный код, проводимое без исполнения этих артефактов. Например, с помощью рецензирования или статического анализа. (Источник — ISTQB Glossary)

Статический анализ выполняется специальным программным обеспечением. Мы же практикуем рецензирование.

Рецензирование (review): оценка состояния продукта или проекта с целью установления расхождений с запланированными результатами и для выдвижения предложений по совершенствованию. (Источник — ISTQB Glossary)

Алгоритм тестирования документации

Здесь напомню, что жизненный цикл тестирования у нас такой:

1. подготовка/планирование,

2. проектирование тестов,

3. выполнение тестов,

4. отчетность,

5. завершающие действия (опционально).

Ревью (==рецензирование) документации — это тоже тестирование. 

А значит, имеем алгоритм

1.  Готовимся — выясняем, с чем мы собираемся иметь дело: 

   1. с какой целью создается документ, его официальное определение,

   2. какие обязательные сведения в нем должны содержаться,

   3. какие сведения дополнительны, но хорошо бы иметь,

   4. находим примеры в интернете, формируем личную насмотренность.

2. Проектируем Check list:

   1. включаем в него общепринятые требования в компании,

   2. подбираем подходящие best practices с просторов сети,

   3. если есть идеи потенциальных дефектов, записываем.

3. Выполняем рецензирование:
   Entry criteria: Документ соответствует цели своего создания.

   1. читаем, проверяем выполнение пунктов Check list.

4. Exit criteria: найдено 1-2 minor дефекта.
   Формируем отчетность: 

   1. cоставляем список дефектов, рекомендаций по улучшению, нераскрытых вопросов,

   2. ранжируем в порядке серьезности и приоритетности,

   3. отправляем автору,

   4. после получения обновленного варианта возвращаемся в шаг 3.

Entry criteria (критерий входа) — условие, выполнение которого обязательно для основного рецензирования. Если оно не выполняется, тестирование останавливается, документ передается на доработку.

Exit criteria (критерии выхода) — условия, когда тестирование считается успешно завершенным и документ можно использовать для дальнейшей работы по назначению.

Да, я приемлю считать работу над документом успешно завершенным, если в моем видении там осталась 1-2 очень незначительных замечания. Бесконечное полирование съедает драгоценное время, к тому же в рецензировании присутствует субъективность, что минорный дефект для меня — то допустимая норма для другого.

Пример тестирования требований

Какой самый частый документ, который вы тестируете? Я — Jira ticket, тип Story. Задача в Джире, которая будет_включена/уже_включена в новый спринт — типичный объект раннего тестирования. Чем она вернее и полнее описана изначально, тем больше шансов вовремя получить качественный функционал.

У каждой команды могут быть регламентированы свои стандарты оформления тикетов, прежде всего стоит поискать в документации или поинтересоваться у старших коллег, есть ли принятые стандарты в вашей компании. Есть ли их нет опираемся на распространенные общепринятые нормы ниже.

Подготовка

Jira задача с типом Story — документ, описывающий функционал, который необходимо спроектировать, написать код и протестировать.

Для меня Jira задача обязательно должна содержать:

• summary — короткое заглавие,

• description — описание предстоящей работы,

• user story — вид бизнес требования на разговорном языке, используется в Agile,

• acceptance сriteria — это критерии, которым должна соответствовать работа, для того, чтобы быть принятой заказчиком.

Дополнительно могут быть:

• use cases — прописанные сценарий пользования системой с новым функционалом,

• release number — номер релиза к которому он готовится,

• epic — основной тикет, который объединяет в группу другие,
  И т.п. 

Check list

• user story — небольшая изолированная единица функциональности, которую можно продемонстрировать, 

• user story написана в формате As a < type of user >, I want < some goal > so that < some reason >,

• ticket подходит к целям спринта,

• описание функциональности понятно
  (например, нет неизвестных терминов, сленга),

• acceptance criteria тестируемы
  (например, система должна работать стабильно весь год или интерфейс должен быть удобный — не тестируемые критерии),

• функциональность не зависит от другой функциональности в спринте
  (либо зависимость указана),

• требования к новому интерфейсу обозначены,

• функциональность приоритезирована,

• новый функционал не противоречит, согласуется с существующим ранее.

Рецензирование

Мое рецензирование jira задач не похоже на классическое книжное ревью, потому что у нас часто бывает, что Product Manager торопится и не прописывает все детали. По классическому алгоритму я должна бы собрать все замечания и вернуть ему документ на доработку. Но, когда мы говорим про Jira ticket это ненужная потеря времени, и я просто сама в процессе рецензирования дописываю недостающее. Важно, если хоть немного сомневаюсь в чем-то, прошу его проверить и подтвердить верность моих суждений, а вместе с тем адресую замечания, которые остаются. Получается рецензирование на рецензирование.

Кстати, интересный факт, я всегда считала, что заполнение jira ticket полностью обязанность Product Manager. Но недавно у нас проводила тренинги Liz Keogh, английский agile консультант, и она рассказала, что на сегодня считается успешной практикой, когда раздел Acceptance criteria заполняют именно разработчики. Это на уровне документации заставляет их детально подумать, 

• как они будут реализовать программный код,

• что непонятно, и какой информации не хватает в требованиях.

Отчетность

Мне удобно, когда диалог по правкам ведется в комментариях к задаче. Если ответа долго нет, всегда можно напомнить на ежедневной встрече.

Заключение

В этой части просто повторю, что уже писала в одной из своих ранних статей. Не верю, что бывают универсальные алгоритмы, которые подойдут в любую команду, но верю, что насмотренность на чужие (даже самые простые) практики дает фундамент генерировать те способы работы, которые поднимут уровень рабочего комфорта в вашем случае. Удачи!

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

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

Если ошибка в требованиях будет найдена на этапе тестирования требований, её решением может быть лишь исправление нескольких слов в тексте, в то время как найденный дефект в уже реализованном программном продукте, может привести до закрытия проекта.

Как известно, хорошая документация должна обладать следующими свойствами:

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

Примеры часто встречающихся дефектов документации:

• противоречия пунктов/разделов в документе друг другу;
• недостаточная детализация требований, их неоднозначное толкование;
• нет глоссария, где могли быть указаны все неизвестные термины.

Тестирование документации цель:

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

Перспективы использования тестирования документации:

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

Брайан Хэнкс в своём материале на тему требований ‘Requirements in the Real World’ подчеркивает, что:

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

Когда же тестирование документации наиболее актуально:

• заказчик активно участвует в разработке проекта, он принимает каждый новый релиз;
• заказчик имеет доступ к документации и может контролировать её актуальное состояние.

Помимо уменьшения рисков, устранения несоответствий, тестирование документации может решать важные вопросы, касающиеся бизнес-целей проекта:

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

Какая документация подвержена тестированию:

• продуктная документация — это план проекта, требования к программному продукту, функциональные спецификации, архитектура и дизайн, тест-кейсы, технические спецификации;
• проектная документация [понятие более широкое] — включает в себя продуктную документацию, а также пользовательскую и сопроводительную документацию, маркетинговую документацию.

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

Тестирование документации и требований относится к разряду нефункционального тестирования. Существуют специальные техники для тестирования документации и требований:

1. review требований

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

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

 3) тест-кейсы — требование должно быть проверяемым, значит должны существовать способы проверки корректности реализованного требования. Чем тщательнее продуман чек-лист, тем вероятнее определение проверяемости требований. Прежде, чем записывать возможные тест-кейсы, убедитесь в том, что вы понимаете требование. Для хорошего понимания конкретного требование поможет анализ других требований, которые вполне возможно будут каким либо образом связаны. Но если требование так и не удалось понять — скорее всего в нем есть неточность или ошибка. Когда же все требования будут хорошо сформулированы и протестированы, можно продолжать использование этой техники, совмещая разработку тест-кейсов с дополнительным тестированием.

 4) исследование поведения системы: тестировщик моделирует процесс работы  системой, созданной по тестируемым требованиям и ищет неоднозначные варианты поведения системы (чем-то мне напоминает исследовательское тестирование).  

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

Как проводить тестирование документации

Узнайте, как проводить тестирование документации ПО, обеспечивая точность, полноту и понятность для пользователей.

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

Что такое тестирование документации

Тестирование документации — это процесс проверки документации на наличие ошибок, неточностей и пробелов. Это включает в себя проверку следующих аспектов:

• Полнота и актуальность информации
• Понятность и ясность изложения
• Правильность терминологии и стиля
• Отсутствие орфографических и грамматических ошибок

Виды документации для тестирования

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

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

Шаги тестирования документации

Тестирование документации включает следующие основные шаги:

1. Определение целей и ограничений — определите, что именно вы хотите проверить и какие ограничения (время, ресурсы) у вас есть.
2. Планирование — определите, какие виды документации будут тестироваться, и разработайте план и сценарии тестирования.
3. Тестирование — выполните тестирование согласно разработанным сценариям, активно используя продукт и проверяя документацию на соответствие реальному поведению.
4. Анализ результатов — соберите и проанализируйте результаты тестирования, определите основные проблемы и возможные пути их устранения.
5. Внесение изменений и повторное тестирование — внесите необходимые изменения в документацию и проведите повторное тестирование для проверки результатов.

Советы для тестирования документации

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

Заключение

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

Тест-кейсы и чек-листы. Мы помним, что хорошее требование является проверяемым, а значит, должны существовать объективные способы определения того, верно ли реализовано требование. Продумывание чек-листов или даже полноценных тест-кейсов в процессе анализа требований позволяет нам определить, насколько требование проверяемо. Если вы можете быстро придумать несколько пунктов чек-листа, это ещё не признак того, что с требованием всё хорошо (например, оно может противоречить каким-то другим требованиям). Но если никаких идей по тестированию требования в голову не приходит — это тревожный знак. Рекомендуется для начала убедиться, что вы понимаете требование (в том числе прочесть соседние требования, задать вопросы коллегам и т.д.). Также можно пока отложить работу с данным конкретным требованием и вернуться к нему позднее — возможно, анализ других требований позволит вам лучше понять и это конкретное. Но если ничто не помогает — скорее всего, с требованием что-то не так. Справедливости ради надо отметить, что на начальном этапе проработки требований такие случаи встречаются очень часто — требования сформированы очень поверхностно, расплывчато и явно нуждаются в доработке, т.е. здесь нет необходимости проводить сложный анализ, чтобы констатировать непроверяемость требования. На стадии же, когда требования уже хорошо сформулированы и протестированы, вы можете продолжать использовать эту технику, совмещая разработку тест-кейсов и дополнительное тестирование требований.

Автор: Ирина Соколова, Senior QA Engineer, qualsolife.ru

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

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

Введение

Повторенье — мать учения, пробежимся по базовым определениям, чтоб изъясняться на одном языке:

Тестирование (testing) — процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ с целью определить, что они соответствуют описанным требованиям, показать, что они подходят для заявленных целей и для определения дефектов. (Источник — ISTQB Glossary)

Итак, тестирование — это процесс с тремя вопросами к тестируемому объекту

• соответствует ли он требованиям? 

• подходит цели? 

• какие есть дефекты (баги)?

Статическое тестирование (static testing): тестирование артефактов разработки программного обеспечения, таких как требования, дизайн или программный код, проводимое без исполнения этих артефактов. Например, с помощью рецензирования или статического анализа. (Источник — ISTQB Glossary)

Статический анализ выполняется специальным программным обеспечением. Мы же практикуем рецензирование.

Рецензирование (review): оценка состояния продукта или проекта с целью установления расхождений с запланированными результатами и для выдвижения предложений по совершенствованию. (Источник — ISTQB Glossary)

Алгоритм тестирования документации

Здесь напомню, что жизненный цикл тестирования у нас такой:

1. подготовка/планирование,

2. проектирование тестов,

3. выполнение тестов,

4. отчетность,

5. завершающие действия (опционально).

Ревью (==рецензирование) документации — это тоже тестирование. 

А значит, имеем алгоритм

1.  Готовимся — выясняем, с чем мы собираемся иметь дело: 

   1. с какой целью создается документ, его официальное определение,

   2. какие обязательные сведения в нем должны содержаться,

   3. какие сведения дополнительны, но хорошо бы иметь,

   4. находим примеры в интернете, формируем личную насмотренность.

2. Проектируем Check list:

   1. включаем в него общепринятые требования в компании,

   2. подбираем подходящие best practices с просторов сети,

   3. если есть идеи потенциальных дефектов, записываем.

3. Выполняем рецензирование:
   Entry criteria: Документ соответствует цели своего создания.

   1. читаем, проверяем выполнение пунктов Check list.

4. Exit criteria: найдено 1-2 minor дефекта.
   Формируем отчетность: 

   1. cоставляем список дефектов, рекомендаций по улучшению, нераскрытых вопросов,

   2. ранжируем в порядке серьезности и приоритетности,

   3. отправляем автору,

   4. после получения обновленного варианта возвращаемся в шаг 3.

Entry criteria (критерий входа) — условие, выполнение которого обязательно для основного рецензирования. Если оно не выполняется, тестирование останавливается, документ передается на доработку.

Exit criteria (критерии выхода) — условия, когда тестирование считается успешно завершенным и документ можно использовать для дальнейшей работы по назначению.

Да, я приемлю считать работу над документом успешно завершенным, если в моем видении там осталась 1-2 очень незначительных замечания. Бесконечное полирование съедает драгоценное время, к тому же в рецензировании присутствует субъективность, что минорный дефект для меня — то допустимая норма для другого.

Пример тестирования требований

Какой самый частый документ, который вы тестируете? Я — Jira ticket, тип Story. Задача в Джире, которая будет_включена/уже_включена в новый спринт — типичный объект раннего тестирования. Чем она вернее и полнее описана изначально, тем больше шансов вовремя получить качественный функционал.

У каждой команды могут быть регламентированы свои стандарты оформления тикетов, прежде всего стоит поискать в документации или поинтересоваться у старших коллег, есть ли принятые стандарты в вашей компании. Есть ли их нет опираемся на распространенные общепринятые нормы ниже.

Подготовка

Jira задача с типом Story — документ, описывающий функционал, который необходимо спроектировать, написать код и протестировать.

Для меня Jira задача обязательно должна содержать:

• summary — короткое заглавие,

• description — описание предстоящей работы,

• user story — вид бизнес требования на разговорном языке, используется в Agile,

• acceptance сriteria — это критерии, которым должна соответствовать работа, для того, чтобы быть принятой заказчиком.

Дополнительно могут быть:

• use cases — прописанные сценарий пользования системой с новым функционалом,

• release number — номер релиза к которому он готовится,

• epic — основной тикет, который объединяет в группу другие,
  И т.п. 

Check list

• user story — небольшая изолированная единица функциональности, которую можно продемонстрировать, 

• user story написана в формате As a < type of user >, I want < some goal > so that < some reason >,

• ticket подходит к целям спринта,

• описание функциональности понятно
  (например, нет неизвестных терминов, сленга),

• acceptance criteria тестируемы
  (например, система должна работать стабильно весь год или интерфейс должен быть удобный — не тестируемые критерии),

• функциональность не зависит от другой функциональности в спринте
  (либо зависимость указана),

• требования к новому интерфейсу обозначены,

• функциональность приоритезирована,

• новый функционал не противоречит, согласуется с существующим ранее.

Рецензирование

Мое рецензирование jira задач не похоже на классическое книжное ревью, потому что у нас часто бывает, что Product Manager торопится и не прописывает все детали. По классическому алгоритму я должна бы собрать все замечания и вернуть ему документ на доработку. Но, когда мы говорим про Jira ticket это ненужная потеря времени, и я просто сама в процессе рецензирования дописываю недостающее. Важно, если хоть немного сомневаюсь в чем-то, прошу его проверить и подтвердить верность моих суждений, а вместе с тем адресую замечания, которые остаются. Получается рецензирование на рецензирование.

Кстати, интересный факт, я всегда считала, что заполнение jira ticket полностью обязанность Product Manager. Но недавно у нас проводила тренинги Liz Keogh, английский agile консультант, и она рассказала, что на сегодня считается успешной практикой, когда раздел Acceptance criteria заполняют именно разработчики. Это на уровне документации заставляет их детально подумать, 

• как они будут реализовать программный код,

• что непонятно, и какой информации не хватает в требованиях.

Отчетность

Мне удобно, когда диалог по правкам ведется в комментариях к задаче. Если ответа долго нет, всегда можно напомнить на ежедневной встрече.

Заключение

В этой части просто повторю, что уже писала в одной из своих ранних статей. Не верю, что бывают универсальные алгоритмы, которые подойдут в любую команду, но верю, что насмотренность на чужие (даже самые простые) практики дает фундамент генерировать те способы работы, которые поднимут уровень рабочего комфорта в вашем случае. Удачи!

Обсудить в форуме