Home

Автор: Игнат Смычков

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

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

Давай определим, зачем вообще нужно тестировать документы?

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

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

• Разносторонний взгляд на одни и те же буквы, на удивление, позволяет более понятно сформировать мысль для всех

• Знакомство с тем, что в дальнейшем будут вообще разрабатывать

С чего же начать ?

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

1. Согласование старта вычитки с компетентным лицом, который у вас отвечает за вопросы подобного рода

2. Ознакомление с документом (так же называется "первичная вычитка")

3. Вычитка документа от лица “незаинтересованной стороны”

4. Вычитка документации от лица “Разработчика”

5. Вычитка документации от лица QA

6. Формирование запроса на читы

7. Получение ответов на вопросы (опционально)

Давай рассмотрим пайплайн более детально

Первое, что мы делаем, это согласовываем старт вычитки, тут все индивидуально, у некоторых, это задача, которая пришла в QA review, а для некоторых это команда от PMa или лида. Главное, это знать, что документ дописан и мы можем приступать к его тестам

Когда мы получили документ на руки, в ход идет второй шаг вычитки, ознакомление с документом.

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

Вычитка документа от лица “незаинтересованной стороны”

“Незаинтересованная сторона” - это любой специалист, не принимающий участие в непосредственной разработке продукта. Комьюнити менеджер / директор компании / ПМ или любой другой человек

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

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

2. Полнота описания и соответствие действительности. Любая документация должна содержать описание именно той функциональности, которая присутствует в приложении, и данное описание должно касаться абсолютно всей функциональности, а не только наиболее значимой.

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

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

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

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

7. Логика и согласованность

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

8. Соответствие правилам и стандартам компании: Проверьте, что требования соответствуют внутренним правилам и стандартам разработки в организации.

Вычитка документа от лица “Разработчика”

«Разработчик» - В данном контексте, это любой специалист, принимающий участие в непосредственной разработке продукта. Художник, разработчик, QA специалист и тд

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

2. Подтверждение ожидаемого результата

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

3. Осуществимость
   Насколько прописанные требования возможно реализовать

4. Наличие описания настроек по умолчанию

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

5. Актуальность описания

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

6. Достаточность описания
   Все ли описано, что необходимо для разработки

7. Наличие Арта \ звуков \ Анимации
   Эти ребята тоже хотят получить подробную информацию о том, что от них хочет ГД, желательно при проверке на это требование так же проверить наличие референсов или макетов

8. Требования к тестированию (Опционально)
   Обратите внимание на требования к тестированию, которые описывают, как будут проверяться и проверены соответствующие требования.

9. Практичность
   Удостоверьтесь, что требования выполнимы и осуществимы с учетом ограничений проекта.

Вычитка документации от лица QA

В рамках этого этапа подразумевается вычитка с использованием критического мышления

Какие требования тестируются:

1. Требования к автоматизации:
   Если проект предполагает автоматизированные тесты или процессы, удостоверьтесь, что требования определяют необходимость и область автоматизации.

2. Разрешение конфликтов:
   Если есть конфликтующие или неоднозначные требования, QA-специалист должен помочь команде разработки разрешить эти проблемы.

3. Тестирование производительности:
   Удостоверьтесь, что требования определяют критерии производительности и возможные нагрузочные тесты для проверки соответствия требованиям. (опционально)

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

5. Отладка и логирование:
   Проверьте, что требования предусматривают возможности для логирования функционала

6. Интероперабельность:
   Если продукт должен взаимодействовать с другими системами или программами, удостоверьтесь, что требования описывают, как именно будут взаимодействовать объекты.

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

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

Формирование запроса на читы

В рамках этого этапа, QA инженер формирует запрос на читы DEV команде.

Как это делается

1. Инженер смотрит, какой функционал уже покрыт читами

2. Какой функционал нужно покрыть читами

3. Выкидывает все читы, что команда не сможет реализовать

4. Оставшиеся запросы выносит аккуратным списком в отдельный блок снизу ГДД

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

Получение ответов на вопросы

В завершение вычитки, тестеры вычитывают ответы, на заданные вопросы. От QA требуется лишь убедиться, что все неточности будут учтены в финальном документе, который будет переписан с учетом заданных вопросов

Поздравляем, док протестирован!

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