Тестовая документация Flashcards

Question

Правила написания тест кейсов

Answer 1

Все тест кейсы должны быть обезличенными(Не пишем "Нажимаем кнопку "Сохранить", а пишем "Кликнуть кнопку "Сохранить") Профессиональный слог должен наблюдаться при написании любой документации. Не должно быть каких-то приколюх/словечек для друзей-коллег и тд.(Не пишем "Приложение воркает ") Тест кейс должен быть описан так, чтобы любой другой тестировщик мог спокойно открыть этот тест кейс и без вашего объяснения пройти по всем шагам и чтобы у него это не вызывало трудностей Из правила №3 вытекает текущее правило: не ударяйтесь в крайность. Тестировщики знают как открывать инструменты для тестирования и куда нажимать по кнопкам, знают как открыть базу данных и как открыть текущий сайт и так далее, поэтому описываем с понимаем что основы тестирования ваш коллега знает Тест кейсы пишутся тогда, когда у сценария вашей проверки больше одного шага. Писать тест кейс "Проверить цвет кнопки" - пустая трата ресурсов. Лучше используйте чеклист Тест кейсы пишутся в зависимости от контекста проверки. Если у вас смоук, то тест кейс будет вероятно большим, но не будет нацелен на точечные проверки, а на общую работу какого-либо компонента. Мы не указываем конкретные тестовые данные в тест кейсе. Тест кейс - абстракная проверка, тестировщик сам придумает и сформирует тестовые данные(Не пишем "Отправить письмо пользователю Крис123"). Однако мы можем привести пример тестовых данных, где опишем как и где достать и получить самим эти тестовые данные, без использования упомянутых в примере ранне(никаких скриншотов, файлов, примеров и так далее) Ожидаемый результат указывается у КАЖДОГО шага проверки и соблюдается всем правилам По-хорошему кейс должен быть атомарным и не зависеть от предыдущего или последующего тест кейса 1 тест кейс = 1 проверка. Вы не можете в одном кейсе проверить все и сразу. Вы не можете в одном шаге тест кейса проверить все и сразу.

Answer 2

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

Answer 3

Управление тест-кейсами: Создание, хранение и поддержка актуальности тест-кейсов, включая их описание и условия выполнения. Выполнение тестов: Запуск тестов, как ручных, так и автоматизированных, и отслеживание их прогресса. Отчетность и анализ: Генерация отчетов о состоянии тестирования и качества программного обеспечения, анализ результатов для выявления трендов и областей для улучшения. Используется очень редко, чаще всего занимаются этим лиды. Интеграция с другими инструментами: Связь с системами управления проектами, инструментами автоматизации тестирования и другими системами для обмена данными и улучшения эффективности.

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

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

Answer 8

Бэклог – это список задач (issues), который используется для управления и планирования работы команды. В Jira бэклог представляет собой совокупность всех задач, которые необходимо выполнить для достижения целей проекта. Бэклог включает в себя задачи разного типа: истории, баги, задачи, эпики и другие. Основное предназначение бэклога – это организация и приоритизация работы команды продуктовым менеджеров. Обычно тут лежат таски и баги, которые мы воооообще никогда не будем делать или сделаем когда-нибудь.

Answer 9

1. Критические функции системы: Основные бизнес-функции: Например, регистрация и авторизация пользователей, обработка платежей, создание и обработка заказов, которые жизненно важны для работы системы. Эти функции всегда должны быть включены в регрессионное тестирование, так как их сбой может серьезно повлиять на работу системы. 2. Функциональность, затронутая изменениями: Исправление дефектов: Все тест-кейсы, связанные с областями, где были исправлены баги, должны быть включены в регрессионное тестирование, чтобы убедиться, что исправление не повлияло на другие части системы. Новые функции: Включение тест-кейсов для областей, связанных с новыми функциями, чтобы убедиться, что они не нарушают существующий функционал. 3. Часто используемые сценарии: Основные сценарии использования: Тест-кейсы, которые проверяют наиболее часто используемые пути в системе, должны быть включены в регрессионное тестирование, так как их корректность важна для удовлетворенности пользователей. Сценарии высокого риска: Например, операции с деньгами, обработка конфиденциальных данных и другие критически важные сценарии. 4. Тесты, которые выявили дефекты в прошлом: Исторически проблемные области: Тест-кейсы, которые ранее выявляли дефекты, так как эти области могут оставаться уязвимыми для повторных ошибок. Дефекты, которые были исправлены: Тест-кейсы, которые связаны с недавно исправленными дефектами, чтобы убедиться, что дефект не возвращается. 5. Тесты, которые были написаны на прошлые фичи: Бывает такое, что могут собрать сборку без прошлого релиза (с прошлыми фичами), поэтому важно добавлять кейсы из прошлого релиза.

Answer 10

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

Answer 11

Тестирование требований — это важный этап процесса обеспечения качества, который помогает убедиться, что требования к программному обеспечению ясны, полны, реализуемы и тестируемы. Вот шаги, которые я обычно предпринимаю для тестирования требований: 1. Анализ требований: Понимание требований: Первым шагом является тщательное изучение всех предоставленных требований. Я уделяю особое внимание терминологии, определению границ системы и основным функциональным и нефункциональным требованиям. Выявление неясностей: В процессе анализа я ищу нечеткости, двусмысленности и противоречия в требованиях. Например, если требование описывает функцию, но не определяет, как она должна себя вести в определенных сценариях, это вызывает вопросы. Проверка полноты: Я проверяю, все ли основные аспекты системы описаны в требованиях. Полные требования включают в себя не только основную функциональность, но и исключительные случаи, граничные значения и нефункциональные требования, такие как производительность, безопасность и совместимость. 2. Проверка тестируемости требований: Определение критериев приемки: Я проверяю, можно ли разработать тест-кейсы на основе каждого требования. Если требование сложно протестировать (например, оно слишком общее или нет четких критериев приемки), я поднимаю этот вопрос на обсуждение с бизнес-аналитиками или заказчиком. Создание примеров использования: Для лучшего понимания и тестируемости требований я разрабатываю сценарии использования, которые иллюстрируют, как система будет работать в различных ситуациях. Это помогает определить, как требования будут воплощены в реальных условиях. 3. Верификация требований: Проверка на соответствие: Я сравниваю требования с бизнес-целями и задачами, чтобы убедиться, что они соответствуют нуждам заказчика и целям проекта. Анализ на противоречия: Я ищу противоречия между требованиями, например, если одно требование требует определенного поведения, а другое прямо противоположного. Проверка на дублирование: Я удостоверяюсь, что требования не дублируют друг друга, чтобы избежать путаницы и избыточности в разработке и тестировании. 4. Проверка на реализуемость: Оценка технической возможности: Я оцениваю, можно ли реализовать требования с учетом доступных технологий, инструментов и архитектуры системы. Если возникают сомнения в реализуемости какого-либо требования, я обсуждаю это с командой разработки. Оценка технической возможности: Я оцениваю, можно ли реализовать требования с учетом доступных технологий, инструментов и архитектуры системы. Если возникают сомнения в реализуемости какого-либо требования, я обсуждаю это с командой разработки. 5. Обратная связь и уточнение требований: Обратная связь с заинтересованными сторонами: Если я нахожу неясности или проблемы с требованиями, я взаимодействую с бизнес-аналитиками, заказчиками или командой разработки для их устранения. Этот процесс включает обсуждения, воркшопы и, при необходимости, переписывание или уточнение требований. Уточнение требований: На основе обсуждений требования могут быть уточнены, чтобы они стали ясными, полными и тестируемыми. 6. Создание трейсабилити матрицы: [ЧЕСТНО - НЕ ДЕЛАЮ] Связь требований и тестов: Я создаю трейсабилити матрицу, которая помогает отслеживать соответствие между требованиями и тест-кейсами. Это позволяет убедиться, что для каждого требования есть соответствующий тест-кейс и что все требования покрыты. 7. Разработка тест-кейсов на основе требований: Создание тест-кейсов: Я начинаю разрабатывать тест-кейсы, основываясь на требованиях. Если требование четко сформулировано и тестируемо, создание тест-кейса не вызывает трудностей. Проверка тест-кейсов: Я проверяю, что тест-кейсы действительно покрывают все аспекты требования и способны выявить возможные дефекты при их реализации.

Answer 12

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

Answer 13

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

Answer 14

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

Answer 15

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

Answer 16

На некоторых проектах я писала в комментариях к задаче ЧТО БЫЛО ПРОТЕСТИРОВАНО. Выглядело следующим образом: Я протестировала задачу, перевел статус задачи в "Ready to regress", и написал комментарий: ПРОТЕСТИРОВАНО Окружения проверки: iPhone 15 pro max, version17.5.1; iPhone 11 version 17; Pixel 6 Android 16 При тестировании был задействован набор тест-кейсов *ссылка на набор тест кейсов*. Были проверены интеграции между Микросервисами 1,2,3 и верстка на разных устройствах. Требование S1723 - ВЫПОЛНЕНО Требование S1724 - ВЫПОЛНЕНО Требование S1725 - ВЫПОЛНЕНО Задача готова к регрессионному тестированию И ССЫЛКА НА ТЕСТОВЫЙ ПРОГОН, ГДЕ СОЗДАЕТСЯ ОТЧЕТ О ТЕСТИРОВАНИИ. (его можно создать в тмс)

Answer 17

Заказчик: Основной источник требований, так как именно заказчик определяет бизнес-цели и задачи, которые должно решать программное обеспечение. Клиенты: Пользователи, которые будут использовать продукт, также могут предоставлять требования, основанные на их ожиданиях и потребностях. Конечные пользователи: Люди, которые будут непосредственно взаимодействовать с системой. Их опыт и ожидания являются ключевыми для определения пользовательского интерфейса и функциональности. Суперпользователи или продвинутые пользователи: Опытные пользователи, которые могут предложить более детализированные и специфические требования, основанные на глубоком знании процессов и задач. Бизнес-аналитики собирают и анализируют требования, связывая потребности бизнеса с возможностями и ограничениями системы. Они помогают формализовать требования и уточнить их в контексте бизнес-целей. Менеджеры проекта: Обеспечивают, чтобы требования соответствовали стратегическим целям проекта, бюджетным и временным ограничениям. Владельцы продукта (Product Owners): Задают приоритеты и определяют, какие функции и требования являются наиболее важными для выпуска. Исследования рынка и конкурентов могут выявить требования, основанные на рыночных тенденциях, ожиданиях пользователей и особенностях конкурирующих продуктов. Юридические требования: Законы и нормативные акты, такие как GDPR для защиты данных, накладывают ограничения и требования, которым должна соответствовать система. Отраслевые стандарты: Стандарты, принятые в определенной отрасли (например, HIPAA в здравоохранении), также являются важным источником требований. Разработчики: Могут предоставлять технические требования, определяя, какие технологии, архитектура и подходы следует использовать для реализации функциональности. Команда поддержки: Их опыт работы с пользователями и поддержкой продукта может выявить важные требования к стабильности, поддерживаемости и расширяемости системы. QA-инженеры: Могут предоставлять требования, связанные с тестированием, качеством и критериями приемки программного обеспечения. Существующие системы: Анализ существующих систем, которые заменяются или интегрируются с новой системой, может выявить важные функциональные и нефункциональные требования. Техническая документация: Документация по существующему программному обеспечению или компонентам может служить источником требований, особенно если требуется поддержка обратной совместимости.

Answer 18

Косвенные требования — это требования, которые не описывают конкретную функциональность системы, а скорее определяют условия, ограничения или характеристики, которые должны быть выполнены, чтобы система соответствовала ожиданиям пользователей и бизнес-целям. Эти требования часто касаются нефункциональных аспектов, таких как производительность, безопасность, удобство использования и масштабируемость. Производительность: "Система должна обрабатывать не менее 1000 запросов в секунду при нагрузке на сервере с процессором не ниже Intel Xeon и 16 ГБ оперативной памяти." "Время отклика системы на пользовательские запросы не должно превышать 2 секунд при одновременном доступе до 100 пользователей." Масштабируемость: "Система должна поддерживать возможность горизонтального масштабирования для обеспечения стабильной работы при увеличении количества пользователей." "Система должна быть способна масштабироваться до 10 000 одновременных пользователей без значительного снижения производительности." Надежность: "Система должна обеспечивать безотказную работу с коэффициентом готовности не ниже 99,9% в течение месяца." "Система должна обеспечивать безотказную работу с коэффициентом готовности не ниже 99,9% в течение месяца." Удобство использования (Usability): "Интерфейс системы должен быть интуитивно понятным, обеспечивая выполнение ключевых задач в не более чем трех кликах." "Система должна поддерживать доступность для пользователей с ограниченными возможностями в соответствии со стандартами WCAG 2.1." Безопасность: "Система должна обеспечивать шифрование всех данных, передаваемых между клиентом и сервером, с использованием SSL/TLS." "Система должна предоставлять возможность многофакторной аутентификации для всех пользователей." Совместимость: "Система должна корректно работать в последних двух версиях браузеров Chrome, Firefox, Safari и Edge." "Система должна поддерживать работу на операционных системах Windows, macOS и Linux." Мобильность: "Система должна быть оптимизирована для работы на мобильных устройствах с экранами различных размеров, обеспечивая удобство использования и функциональность, сопоставимую с десктопной версией." "Приложение должно корректно отображаться и функционировать на устройствах с операционными системами Android и iOS." Модульность и поддерживаемость: "Код системы должен быть структурированным и модульным, что позволит легко вносить изменения и добавлять новые функции без необходимости значительной переработки существующего кода." "Система должна быть построена с учетом принципов SOLID, чтобы облегчить поддержку и расширение функциональности в будущем." Локализация и интернационализация: "Мобильное приложение должно быть оптимизировано для минимального энергопотребления, обеспечивая работу без значительного влияния на время работы устройства от батареи." "Серверная часть системы должна минимизировать использование ресурсов, чтобы сократить эксплуатационные расходы и снизить нагрузку на оборудование." Лицензирование и правовые требования: "Система должна соответствовать требованиям GDPR для защиты персональных данных пользователей из Европейского Союза." "Программное обеспечение должно использовать только лицензированные библиотеки и компоненты, совместимые с условиями лицензирования проекта." Документация: "Система должна поставляться с полной и актуальной технической документацией, включая API-спецификации, схемы базы данных и руководство по установке." "Документация должна быть доступна на нескольких языках, чтобы обеспечить ее использование в различных регионах." Экономичность: "Система должна быть разработана с учетом минимизации затрат на инфраструктуру и эксплуатацию, обеспечивая максимально эффективное использование серверных ресурсов." "Процесс развертывания системы должен быть автоматизирован для снижения расходов на техническую поддержку."

Answer 19

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

Answer 20

Функциональное требование — это заявление о том, как должна вести себя система. Он определяет, что система должна делать, чтобы удовлетворить потребности или ожидания пользователя. Функциональные требования можно рассматривать как функции, которые обнаруживает пользователь. Они отличаются от нефункциональных требований, которые определяют, как система должна работать внутри (например, производительность, безопасность и т. д.). Функциональные требования состоят из двух частей: функции и поведения. Функция — это то, что делает система (например, «рассчитать налог с продаж»). Поведение определяется тем, как это делает система (например, «Система должна рассчитать налог с продаж путем умножения покупной цены на налоговую ставку»).

Answer 21

1. Руководства пользователя (User Guides): Руководство пользователя: Основной документ, который описывает, как использовать программное обеспечение, его функциональные возможности, интерфейс и основные операции. Краткое руководство (Quick Start Guide): Краткая инструкция, предназначенная для быстрого начала работы с программным продуктом. Включает основные шаги по установке и начальной настройке. Руководство по решению проблем (Troubleshooting Guide): Документ, помогающий пользователям самостоятельно решать распространенные проблемы и ошибки, возникающие при работе с программным обеспечением. 2. Документация по установке и настройке (Installation and Configuration Guides): Руководство по установке (Installation Guide): Подробное описание процесса установки программного обеспечения, включая системные требования, подготовку среды, шаги по установке и проверку успешности установки. Руководство по настройке (Configuration Guide): Инструкции по настройке программного обеспечения после его установки, включая параметры конфигурации, оптимизацию производительности и интеграцию с другими системами. 3. Техническая документация (Technical Documentation): Документация по API (API Documentation): Подробное описание интерфейсов программирования приложений (API), предоставляемых программным продуктом, включая описание методов, параметров, возвращаемых значений и примеры использования. Руководство по интеграции (Integration Guide): Документ, описывающий, как интегрировать программное обеспечение с другими системами и сервисами, включая необходимые шаги, настройки и примеры кода. Руководство по разработке (Developer Guide): Документ для разработчиков, описывающий, как использовать программное обеспечение в процессе разработки, включая примеры использования API, SDK и других инструментов. 4. Документация по обслуживанию и поддержке (Maintenance and Support Documentation): Руководство по обслуживанию (Maintenance Guide): Инструкции по регулярному обслуживанию программного обеспечения, включая обновление, мониторинг состояния, резервное копирование и восстановление данных. Документация по поддержке (Support Documentation): Описание процедур поддержки, включая контактную информацию, процедуры эскалации, типичные проблемы и их решения. 5. Лицензионные соглашения и правовая документация (Licensing and Legal Documentation): Лицензионное соглашение с конечным пользователем (EULA - End User License Agreement): Документ, который определяет условия использования программного обеспечения конечными пользователями. Политика конфиденциальности (Privacy Policy): Документ, описывающий, как собираются, используются и защищаются персональные данные пользователей. Условия использования (Terms of Service): Документ, описывающий условия использования сервиса или программного продукта, включая права и обязанности пользователя и поставщика. 6. Документация по релизам (Release Notes): Заметки о выпуске (Release Notes): Документ, описывающий изменения, исправления и новые функции в каждой новой версии программного обеспечения. Включает информацию о добавленных функциях, исправленных ошибках и известных проблемах. Документация по версии (Version Documentation): Описание особенностей конкретной версии программного обеспечения, включая изменения по сравнению с предыдущими версиями и особенности обновления. 7. Обучающие материалы и документация по обучению (Training and Educational Materials): Руководства по обучению (Training Manuals): Материалы, предназначенные для обучения пользователей и администраторов работе с программным обеспечением. Могут включать учебные пособия, пошаговые инструкции и упражнения. Примеры и учебные кейсы (Tutorials and Case Studies): Документация, которая предоставляет примеры использования программного обеспечения в реальных ситуациях, а также учебные примеры и практические задания. 8. Документация по требованиям (Requirements Documentation): Документ с требованиями (Requirements Document): Подробное описание функциональных и нефункциональных требований, предъявляемых к программному обеспечению. Этот документ может использоваться внешними стейкхолдерами для оценки соответствия программного продукта их потребностям.

Answer 22

1. Техническая документация: Архитектурная документация: Описание архитектуры системы, включая диаграммы, используемые технологии, структуры данных, и взаимодействия между компонентами. Технические спецификации: Подробное описание требований к системе с технической точки зрения, включая API, базы данных, протоколы и другие технические детали. Документация по API: Описание интерфейсов прикладного программирования (API), предоставляемых системой, включая спецификации методов, параметры, форматы данных и примеры использования. Кодовая документация: Комментарии и описания, встроенные в исходный код, которые объясняют структуру и логику кода, включая описание функций, классов и методов. [Нужно только разрабам] 2. Документация по тестированию: Тест-план: Основной документ, описывающий стратегию, объем, ресурсы, график и критерии завершения тестирования. Тестовые сценарии (Test Scenarios): Высокоуровневые описания функциональности или процессов, которые будут тестироваться. [Не видела ни разу] Тест-кейсы: Подробные описания шагов, входных данных, ожидаемых результатов и фактических результатов для тестирования конкретных аспектов системы. Чек-листы: Списки задач или элементов, которые нужно проверить в процессе тестирования. Тестовые данные: Наборы данных, используемые для выполнения тестов, включая как валидные, так и невалидные данные. Тестовые окружения: Документация, описывающая конфигурацию среды тестирования, включая используемые аппаратные и программные средства. Отчеты о тестировании: Документы, представляющие результаты тестирования, включая пройденные и проваленные тесты, обнаруженные дефекты и их статус. 3. Документация по управлению проектом: Требования (Requirements): Описание функциональных и нефункциональных требований к системе, собранных от заказчиков и стейкхолдеров. Спецификация требований (SRS - Software Requirements Specification): Детализированное описание всех требований к системе, включая функциональные и нефункциональные требования. План управления проектом: Описание процессов управления проектом, графиков, задач и ответственных лиц. [Не видела ни разу] Риски и планы их минимизации: Документация, описывающая возможные риски, связанные с проектом, и планы по их смягчению. Отчеты о ходе выполнения: Регулярные отчеты о текущем статусе проекта, включая выполнение задач, выявленные проблемы и достигнутые цели. 4. Документация по релизам и развертыванию: План релиза: Описание процессов и шагов, необходимых для подготовки и выпуска новой версии продукта, включая даты релизов, список функциональности и исправлений. Документация по развертыванию: Инструкции по развертыванию приложения в различных средах (например, в тестовой, продакшн), включая настройку серверов, баз данных и других компонентов. Руководства по миграции данных: Документы, описывающие процесс миграции данных при обновлении системы или переходе на новую платформу. [Нужно только разрабам] 5. Документация по обеспечению качества (QA Documentation): Стандарты и процессы тестирования: Описание стандартов качества, используемых методов тестирования и процедур. Чек-листы по проверке качества: Списки критериев, которые необходимо проверить для обеспечения соответствия продукта стандартам качества. Документы по проверке соответствия: Отчеты и результаты проверок на соответствие внутренним и внешним стандартам, нормам и требованиям. 6. Обучающая и справочная документация: Руководства пользователя: Внутренние руководства, предназначенные для сотрудников, включающие инструкции по использованию инструментов, систем и процессов. Обучающие материалы: Документы и презентации для обучения сотрудников новым процессам, инструментам или технологиям.

Answer 23

Разница между чек-листом и тест-кейсом Уровень детализации: Чек-лист: Краткие пункты для проверки. Тест-кейс: Подробное описание шагов и ожидаемых результатов. Цель: Чек-лист: Быстрая проверка ключевых функций или требований. Тест-кейс: Тщательная и детализированная проверка конкретных сценариев использования. Использование: Чек-лист: Используется для высокоуровневого тестирования, когда не требуется детальное руководство. Тест-кейс: Используется для точного тестирования, особенно когда важно соблюдение конкретных шагов. Гибкость: Чек-лист: Гибкий и легко адаптируемый, подходит для ситуаций, где требуется быстрая проверка. Тест-кейс: Строгий и менее гибкий, но обеспечивает высокий уровень точности и повторяемости.