Тестирование документации к программным продуктам
Перечень качеств, на которые можно ориентироваться при тестировании документации:
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. Адаптированность к наименее возможной квалификации пользователей
Не всегда люди задаются вопросом о том, как функционирует программа, им важен результат. И стоит учитывать, что продукт могут использовать разные пользователи. Например, системному администратору, имеющую высокую квалификацию, может потребоваться показать на пальцах результаты работы с использованием продукта директору. А директор может заглянуть в документацию, если показанные результаты очень важны в рамках его деятельности. Тут стоит как можно меньше использовать сложные технические термины, для понимания которых придется открывать интернет. Домохозяйке не обязательно знать как функционирует микроволновая печь, но ей важно знать, что в ней можно варить и не следует помещать внутрь металлические предметы. Также домохозяйке, в отличие от ученого, следует знать, что не стоит помещать яйца в микроволновку.
Кому нужна качественная документация
Часто замечаю, что мало кто обращает на качество документации. Действительно, кому она приносит выгоду и какую? Подозреваю, что многие команды при разработке программных продуктов создают документацию лишь потому, что задачу по созданию документации поставили вышестоящие лица. И понижение приоритета обеспечения качества документации обусловлено тем, что нет возможности подсчитать в цифрах выгоду, которую это дает. К сожалению, я не могу представить такую статистику в цифрах.
Выгоду от наличия документации можно сравнить с выгодой создания дополнительной инфраструктуры при постройке жилья. С одной стороны, при продаже главную роль играет площадь жилья: цена назначается за квадрат. Но если присмотреться — цена в некоторых домах значительно превосходит цену в других. И обусловлено это в первую очередь окружающей инфраструктурой (стоянки, лифты, газоны, и т.д.).
Наличие качественной документации дает плюсы: пользователи не стремятся отказаться от продукта, снижается нагрузка на техподдержку, внутри команды разработки возникает меньше вопросов о том, как должен функционировать продукт, легче его продавать.
Тестирование документации
Документация– это еще одна составляющая программного продукта любой уважающей себя организации, занимающейся разработкой программного обеспечения. Но не все организации уделяют достаточное количество времени разработке стоящей документации. Очень часто нам приходится иметь дело с толковым программным продуктом и невзрачным, непонятным и беспомощным документным сопровождением.
Попробуем собрать воедино критерии тестирования, образующие квинтэссенцию качественной документации. Думаю, будет справедливым, если мы опустим такое всем понятное правило, как грамматика, так как не в ней одной таится успешный релиз.
В целом, документация создается для возможности грамотно и без паники найти выход или решение из любой возникшей проблемной ситуации человеку из самым низким знанием принципов разработки программного обеспечения. От этого принципа необходимо отталкиваться, продумывая содержание и структуру наших мануалов.
• Полнота и соответствие действительности. Любая документация должна содержать описание именно той функциональности, которая присутствует в приложении. И данное описание должно касаться абсолютно всей функциональности, а не только наиболее значимой.
• Навигация. И не просто навигация, а удобная навигация. У пользователя никогда не должно возникать проблем с поиском необходимой ему информации. Древовидная структура файлов, закладки и прочее должны быть на видном месте сразу, как пользователь открывает документ. Алфавитный указатель, поиск – должно присутствовать все, что поможет найти решение или описание проблемы.
• Из пункта выше вытекает структурированность документации. Все документы должны находится в полном порядке, по разделам. Также, текст должен быть с четкой структурой, чтобы можно было в любой момент вспомнить, где остановился или понять, в каком абзаце содержится именно та информация, которая нам необходима.
• Инструкции должны присутствовать везде. Даже при выполнении абсолютно одинаковых манипуляций с программой необходимо пошаговое описание действий во всех случаях. Это может быть как прямое повторение инструкций, так и ссылка на уже существующие.
• Термины и их значение. В любой документации может использоваться масса терминов, аббревиатур и сокращений. Каждый из них должен иметь свое значение и расшифровку.
• Доступность пользователю. Документация должна быть максимально понятной для любой целевой аудитории.
• Если документация создана и для иностранных пользователей,то необходимо привлечение специалистов данного лингвистического сектора, вплоть до носителей языка.
Основные принципы тестирования требований
Существует еще много требований к составлению и тестированию документации. Сегодня мы рассмотрели основные положения. Но главное правило, которое поможет нам – это умение ставить себя на место пользователя, попавшего в определенную проблемную ситуацию.
Свойства качественных требований
В процессе тестирования требований проверяется их соответствие определённому набору свойств:
Техники тестирования требований
Тестирование документации и требований относится к разряду нефункционального тестирования (non-functional testing). Основные техники такого тестирования в контексте требований таковы:
Для запоминания: аналог беглого просмотра — это ситуация, когда вы в школе с одноклассниками проверяли перед сдачей сочинения друг друга, чтобы найти описки и ошибки.
Для запоминания: аналог технического просмотра — это ситуация, когда некий договор визирует юридический отдел, бухгалтерия и т.д.
Для запоминания: аналог формальной инспекции — это ситуация генеральной уборки квартиры (включая содержимое всех шкафов, холодильника, кладовки и т.д.).
Тестовая документация и анализ требований
В преддверии старта курса «Game QA Engineer» публикуем текстовую расшифровку онлайн-интенсива, который провела Надежда Чертовских — руководитель отдела QA в компании BeresnevGames и преподаватель OTUS.
Цели интенсива:
познакомиться с основными видами тестовой документации;
проанализировать документ от game-дизайнера;
попрактиковать составление чек-листа.
Для начала давайте обсудим такой животрепещущий вопрос: почему сегодня на курсе «тестировщик игр» мы обсуждаем документацию?
Как тестировщик, который целый день только в игры играет и сообщает разработчикам об обнаруженных ошибках, связан с документацией? Какая вообще работа у тестировщика игры? Какие у тестировщика могут быть документы?
Существует распространённое заблуждение, что тестировщик игр целый день только и делает, что в игры играет. Но на самом деле это не так. Тестировщик в геймдеве точно такой же тестировщик, как и в любой другой сфере, и работает точно по такому же принципу, но продукт у него не web-страничка, не application на операционной системе, а игра (мобильная, консольная, десктопная).
Тестирование может быть автоматизированным и ручным
На интенсиве мы поговорим в целом об артефактах тестирования, с которыми работает тестировщик:
План тестирования (Test Plan)
Тест-кейс (Test Case)
Баг-репорт (Bug Report)
Отчёт о тестировании (Test Report)
Из этого мы можем сделать вывод, что тестировщик не только читает требования, которые подготовили к продукту, но и сам генерирует документы.
В ходе интенсива мы более подробно поговорили о 6 типах документов, которые перечислили выше, обсудили, какие из них полезные, какие используются чаще, какие меньше и составили чек-лист по требованиям.
План тестирования
План тестирование (далее ПТ) или тест-план – это большой документ, который чаще всего описывает весь объем работ по тестированию проекта либо части проекта (например, релиза или предрелизного билда). ПТ описывает, что будет тестироваться, в какие сроки, какими инструментами, какая команда, обязанности и ответственности каждого члена команды. Также часто в ПТ включается стратегия тестирования, график релизов на несколько ближайших спринтов. В зависимости от команды бывает разная степень детализации ПТ и его могут делать разные люди в команде. В каких-то компаниях ПТ делает менеджер, в каких-то middle-тестировщик, либо senior-тестировщик, либо тимлид отдела тестирования.
Всё, что мы далее обсудим по документам, которые генерирует тестировщик, может отличаться от компании к компании, от команды к команде. В зависимости от команды и компании форм-фактор всех документов может быть либо уже обговорён и установлен, либо, если вы приходите первым QA специалистом на проект, то вы сами устанавливаете, как удобно вам.
Форм-фактор у тест-плана может быть разный (схема, интеллектуальная карта и т.д.) и зависит от того, как команде будет удобнее взаимодействовать с документами.
Чаще всего ПТ требуется именно для людей, которые принимают решения по проекту, чтобы они поняли, что в следующий момент мы делаем: релизим билд или нужно подвинуть сроки, добавить к тестированию, убавить к каким-то другим срокам. И лучше всего не делать ПТ огромным, чтобы человек, который будет его читать, смог осилить весь объём. Если посмотреть примеры тест-планов в интернете — часто это одностраничная схема, чтобы все в общем и целом понимали, какой объем тестирование предстоит. Обычно план тестирования делается до начала тестирования и до момента релиза.
Таким образом План тестирования:
описывает стратегию тестирования, цели, график, оценку, результаты, а также ресурсы необходимые для тестирования;
имеет разную степень детализации;
имеет разный форм-фактор;
составляется не более, чем на 2-х страницах;
составляется до начала тестирования.
Пример тест-плана с сайта с сайта www.guru99.com
Тест-кейс
Тест-кейс можно сравнить с рецептом — это последовательность шагов, которые приводят к какому-то результату. Тест-кейс лучше не делать избыточным. Тестировщики чаще всего хорошо знают свой проект, поэтому досконально писать тест-кейс нет необходимости. Тест-кейс должен быть краткий и понятный, так чтобы другой тестировщик, либо другой специалист в команде смог быстро пройти по нему и проверить, что все происходит так, как нужно.
Тест-кейсы можно формировать в последовательный сценарий, чтобы проверить, как игрок пройдет по этому функционалу от начала до конца.
Тест-кейсы можно группировать в смысловые блоки.
Например, если в игре запускается какой-то ивент, формируется набор тест-кейсов для проверки этого ивента.
Тест-кейсы лучше писать по требованиям гейм-дизайнерского документа. Но, если функционал уже готов, а требований тест-кейсов по нему не написано, можно написать уже по факту. Лишним не будет.
Составляющие тест-кейса:
идентификатор (уникальный номер, по которому вы сможете найти этот тест-кейс и на него сослаться);
название сценария (какое-то краткое, но ёмкое);
ссылка на требования ГДД;
предусловия (опционально, если они требуются для тест-кейса);
фактический результат (опционально).
Пример тест-кейса
Чек-лист
Чек-листы можно сравнить со списком покупок, который мы формируем на проверку. Например, чек-лист на Smoke-тест, чтобы проверить, что игра запускается и весь функционал, который должен в игре отрабатывать отрабатывает, иконка приложения соответствует иконке нашего приложения. Также чек-лист может быть составлен на регрессионное тестирование и даже на тестирование требований.
Чек-листы чаще всего составляются без детализации и их можно скомпоновать в наборы и проверять тоже для любого функционала либо нового, либо регрессионного.
Чек-листы лучше сразу писать по требованиям (геймдизайнерскому документу) перед стартом тестирования функционала или по итогу.
Небольшой пример из игры нашей студии: есть поле для ввода имени питомца и есть несколько условий на этом поле: имя питомца должно состоять из более чем 2 символов и только в этом случае кнопка из серой неактивной станет зеленой активной и можно будет питомца наименовать. Мы начинаем формировать чек-лист к этому полю если количество символов больше 2 то кнопка принять становится активное, если меньше 2 не активно. Первые 2 пункта чек-листа, которые можно проверить.
На скриншоте мы видим, как игрок из Китая захотел назвать питомца очень коротким ёмким именем и, к сожалению, не смог это сделать и обращался в тех. поддержку. В результате ему пришлось выдумывать более длинное имя.
Ссылка на mindmap чек-лист для мобильной игры:
Баг-репорт
Баг-репорт оформляется, когда баг уже локализован и его можно повторить. Если баг плавающий, нужно пытаться его повторить или занести в систему, где фиксируются баги, как плавающий баг. Ключевой момент, что баг можно повторить и воспроизвести, только тогда его заносят в систему с багами, где хранятся баг-репорты. Если создать и оформить какой-то баг, и разработчик не сможет его воспроизвести, то тут появится множество вопросов.
Поэтому лучше всего сразу проверить на нескольких устройствах, если это возможно и посмотреть на разных операционных системах, на разных разрешениях экрана, то есть максимально локализовать проблему.
В баг-репорте обязательно должны быть:
Подробное описание проблемы – что, где, когда случилось.
Важность дефекта, который указывает тестировщик, а уже приоритет по исправлению этой ошибки указывает менеджер либо команда из разработчиков.
Условия воспроизведения – версия игры, версия операционной системы и другие уникальные условия, которые могут помочь разработчику быстро найти баг, устранить и передать задачу на тестинг.
Алгоритм воспроизведения – пошаговые предусловия предусловия, которые необходимы для воспроизведения бага.
Доказательства – скрины, видео, логи с устройств.
Скриншоты из разных систем, в которых баг-репорт можно вести. В разных компаниях в разных командах условия могут быть абсолютно разные, и где хранятся баг репорты — также зависит от компании.
Отчет о тестировании
Отчет о тестировании пишется, когда функционал уж проверен и релиз либо предрелиз показывает итог проделанной работы.
Отчет о тестировании может быть представлен как текст, таблица, график или диаграмма, если это позволяет инструмент.
Составляющая отчёта о тестировании:
Кто тестировал (состав команды).
Когда тестировал (даты проведения тестов).
Как тестировал (процесс тестирования, описание применяемых методов и технологий).
Какие возникли проблемы и как решились.
Инструкция
Инструкцию можно писать до, во время или после тестирования. Инструкцию никогда не поздно написать. Это помогает как новичкам, так и коллегам, которые работают в одной команде. С помощью инструкции можно быстро сориентироваться в проекте.
Например, вышел новый функционал. Лучше написать инструкцию, как этот функционал проверить, как переключаться, если проверка нового функционала подразумевает переключение между версиями или предусматривает какой-то сложный алгоритм проверки. Это экономит время на объяснения, когда требуется делегировать задачу либо в команду пришел новый человек и нужно его обучить.
Также инструкция помогает выгрузить старое и не потерять. Скорость выпуска релизов в геймдеве довольно высокая и часто есть необходимость вернуться к старому функционалу, который ранее уже тестировался, но прошло какое-то время и тестируется новый функционал, а нужно вернуться к проверке того старого. Поэтому лучше всего, чтобы было прописано, как тестировать, где тестировать, что и куда переключать. Лучше всего все в картинках, гифках или видео. Сегодня современные инструменты всё это позволяют сделать быстро и без проблем. Также ели есть возможность сохранять какие-то состояния проекта, состояния продукта, то лучше где-то всё это фиксировать и выкладывать в общем доступе.
Инструкции лучше писать сразу. Это позволяет избежать множество проблем в дальнейшем.
Где хранить:
Google Docs, Google Sheets
Zephyr, Test Management for Jira
Геймдизайнерский документ (ГДД, диздок)
В геймдизайнерском документе гейм-дизайнер пишет требования к продукту или к отдельному функционалу.
Детализация у геймдизайнерского документа может быть разная. Форм-фактор также может быть разным.
Существует несколько способов проверки требований к игре: по принципу Что? Где? Когда? или по принципу проверки на полноту, однозначность, непротиворечивость, тестируемость, необходимость, осуществимость.
После того как геймдизайнерский документ готов лучше всего, если его прочитают и вместе обсудят специалист по тестированию, разработчик и сам гейм-дизайнер.
Тестировщику в этом случае следует задавать следующие вопросы: не противоречит ли те требования, которые гейм-дизайнер написал, функционалу, который сейчас есть, не будут ли нововведения противоречить наративу, функциям и механикам, которые есть в игре сейчас.
Требования геймдизайнерского документы должны пониматься всеми однозначно, что исключает какого-либо двоякого толкования.
Важно смотреть на полноту содержания: все ли условия предусмотрены, все ли сценарии, которые могут возникнуть у игрока в связи с новым функционалом продуманы.
Разработчик смотрит на возможность реализации ГДД.
Также необходимо продумать, как новый функционал будет тестироваться, после того как разработчик его реализует.
Практическая часть интенсива. Мы попробуем сформировать чек-лист и вопросов гейм-дизайнеру по новому продукту на основе ГДД.
На картинке мы видим 3 скрина игры.
скрин – изображение и кнопка Play, при нажатии на которую, мы попадаем в игровой mod
скрин – на старте есть какое-то количество жизней и шагов
скрин – при проигрыше попадаем на экран проигрыша, где написано итоговое количество набранных за игру баллов и кнопка сыграть ещё.
Итоги интенсива:
Узнали, какие бывают виды документации у тестировщика игр.
Обсудили зачем тот или иной документ нужен.
Попрактиковались в создании чек-листа.
Список материалов для самостоятельного изучения:
