Документация Flashcards
Что такое требование и для чего они нужны
описание того, какие функции и с соблюдением каких условий должно выполнять приложение в процессе решения полезной для пользователя задачи
Требования являются отправной точкой для для определения того, что будет проектироваться. Если в требованиях что-то не то, то и реализовано будет что-то не то. Чем позжно обнаружена ошибка в требованиях, тем дороже ее исправление
Для чего служат требования?
Позволяют понять ЧТО и с соблюдением каких условий система должна делать
Предоставляют возможность оценить масштаб изменений и управлять изменениями
Являются основой для управления плана проекта
Помогают предотвращать или разрешать конфликтные ситуации
Упрощают расстановку приоритетов в наборе задач
Позволяют объективно оценить степень прогресса в разработке проекта
Продуктная документация
План проекта - формальный документ, который определяет как проект будет реализован, как будет осуществляться мониторинг и контроль. Он может быть как достаточно простой, так и детально описанный документ. Также может состоять из нескольких вспомогательных документов
Тестовый план - Документ описывающий объем тестирования, подход, ресурсы и график запланированных тестовых действий. Он определяет функции, которые нужно тестировать, тестовые задачи, кто и какую задачу будет выполнять, насколько тестировщик будет независим, среда тестирования, используемые методы тестирования, критерии начала и завершения тестирования и риски, требующие планирования на случай непредвиденных обстоятельств.
Требования к программному продукту - описывает продукт, который будет создавать ваша компания. Эти требования должны чётко и недвусмысленно описывать назначение продукта, его функции, характеристики и поведение
Функциональные спецификации - документ, который в полной и точной форме определяет требования, дизайн, поведение и другие характеристики компонента или системы. Спецификации описывают ожидаемое поведение системы.
Архитектура и дизайн - описывает ее основные компоненты, их отношения (структуры) и то как они взаоимодействую друг с другом. Арихтектура служит планом для сисетмы
Тест кейсы и набор тест кейсов
Технические спецификации
Тестовый план
Документ описывающий объем тестирования, подход, ресурсы и график запланированных тестовых действий. Он определяет функции, которые нужно тестировать, тестовые задачи, кто и какую задачу будет выполнять, насколько тестировщик будет независим, среда тестирования, используемые методы тестирования, критерии начала и завершения тестирования и риски,
Проектная документация
Проектная документация включает в себя как продуктную документаци, так и еще ряд документов
Пользовательская и сопроводительная документация (например встроенная помощь, руководство по установке и использованию, лицензионные соглашения
Маркетинговая документация - используется как на начальных этапах (для уточнения сути и концепции продукта), так и на финальных стадиях (для продвижения продукта на рынке)
Уровни и типы требований
3 уровня
Бизнес требования - Цель ради которой разрабатывается продукт (зачем вообще нужен продукт, какая от него польза и как заказчик получит прибыль). Результатом выявления требований является общее видение проекта- документ как правило предствален простым текстом и таблицами.
Пользовательские требования - описывают какие задачи пользователь сможет выполнять с помощью продукта (реакция системы на действия пользователя, сценарии работы пользователя). Так как тут уже появляется описание поведения, требования могут быть использованы для оценки объема работ, стоимости проекта, времени разработки. Пользовательские требования оформляются в виде вариантов использования, пользовательских историй, пользовательских сценариев.
Уровень продуктных требований
Функциональные требования - описывают поведение системы, то есть ее действия (вычисления, преобразования, проверка, обработка и ид). Стоит понимать, что функциональные требования описывают не только, что системы должна делать, но и что не должна.
Нефункциональные требования - описывают свойства системы (удобство пользования, безопасность, надёжность и тд), которыми она должна обладать при реализации своего поведения.
Ограничения - факторы, ограничивающие выбор способов и средств реализации продукта
Требования к интерфейсам - особенности взаимодействия разрабатываемой системы с другими системами и операционной средой
Пример - Обмен данными между клиентской и серверной частями приложения при осуществлении фоновых AJAX-запросов должен быть реализован в формате JSON
Требования к данным - описывают структуры данных являющиеся неотъемлемой частью разрабатываемой системы. Часто сюда вносят описание базы данных и особенностей ее использования
Информация о кассовых транзацкиях за текущий месяц должна храниться в операционной таблице, а по завершении месяца переноситься в архивную.
Спецификация требований - описание всех требований уровня продукта.
Чек-лист
Некий список проверок, в котором указано, что будет тестироваться, результат и статус проверок
Что должно быть в хорошем чек-листе:
Версия сборки
Окружение в котором проводилось тестирование
Дата тестирования
Тестировщик, который проводил работу
Тип тестирование, описание того, что проверяется, результат
Идентификатор
Ссылка на обнаруженный баг
Тест-кейс
Описание шагов / Пошаговый сценарий
Здесь описывается процесс тестирования
В хорошем тест-кейсе должен быть
Заголовок Приоритет Идентификатор Environment Pre-condition (optional) - шаги, необходимые до выполнения тестирования. Например если требуется логин в систему. Мы его прописываем сюда, а не в степс ту репродьюс Ссылка на требование Название тестируемого модуля Описание шагов Результат проверок Ожидаемый результат
Что такое тест дизайн
Этап процесса тестирования, на котором проектируются и создаются тест кейсы
Баг репорт и его элементы
Баг репорт (Отчет о дефекте)
Атрибуты бага:
Заголовок - отвечает на три вопроса ЧТО (что происходит) ГДЕ (название модуля) И КОГДА (при каких условиях)
Пример - Login Page: The button sign in is displaced after clicking on it
Короткое описание проблемы
Тут же могу быть шаги воспроизведения бага (steps to reproduce - STR)
Прописывает фактический результать (Result)
Ожидаемый результат (Expected result)
Также нужно писать, почему вы решили, что ожидаемый результат должен быть таким. Должна быть ссылка, может на спек
Могут быть preconditions. Какие-то условия, например пишется, что у был создан юзер, с таким-то логином и паролем, который использовался для входа в систему для тестирования
Проект (Название проекта)
Компонент, в котором был обнаружен дефект
Версия билда, на котором был обнаружен баг
Серъезность (severity)
Приоритет - Порядко исправления багов High Medium Low Бывает в цифрах вместо хай мед и лоу
Статус
Автор (кто нашел баг)
Назначение (assigned to)
Окружение на котором обнаружен эффект. ОС, разрядность системы, браузер и тд
Еще бывают:
Окружение разработчика
Stage (Стабильная версия) - тут чаще всего работают тестировщики, здесь доводят приложение до стабильного состояния и переводят в прод.
Production - окружение для пользователей
Прикрепленный файл - Attachment
Если скриншот, нужно на нем делать уточнения
В видео лучше убирать лишние звуки, видео должно быть коротким
Серъезность бага (severity). Уровни
Серъезность (severity)
Blocker - ошибка, которая приводит программу в нерабочее состоянее, то есть с таким багом дальнешная работа с программмой невозможна
Critical - ключевой функционал программы не работает, либо обнаружено существенное отклонение от бизнес логики приложения, потеря пользовательских данных
Major - Серьезные ошибки, которые свидетельствую об отклонении от бизнес логики или нарушающие работу программы, но они не имеют критическое значение для работоспособности программы. Возможно есть обходной путь (workaround), позволяющий задействовать функцию другим способом
Minor - незначительный дефект, на нарушающий функционал приложения
Trivial - Баг, не влияющий на функционал, но может быть обнаружен визуально (например опечатка в тексте)
На разных проектах может отличаться
Жизненный цикл бага
New - Дефект найден
Open/Assigned/Active - Направлен на работу девелоперу
Отложен - Пока не нуждается в фиксе, исправление будет произведено в дальнейшем
Resolved или Отклонен (Fixed, Duplicate, Wontfix (вообще не будет фиксится), Worksforme, Incomplete (баг непонятен), Fixed indirectly (пофикшен баг фиксом другого бага) - Пофикшен, назначается на тестировщика, чтобы тот проверил, действительно ли исправлен баг
Verified (QA проверяет, что баг действительно исправлен)
Closed
Reopen - если опять появился, цикл после реопена повторяется
Verified (QA проверяет, что баг действительно исправлен)
