Тестирование без документации

Представьте, что вы идете по канату без страховочной сетки внизу – вот на что похоже тестирование программного обеспечения без документированных требований. Страшно? Может быть, немного. Документированные требования служат дорожной картой как для разработчиков, так и для тестировщиков. Они определяют, что должно делать программное обеспечение, описывают ожидаемое поведение и закладывают основу для тестирования. Но что происходит, когда этот важнейший компонент отсутствует? Эта статья описывает системный подход, который позволит вам эффективно обеспечивать качество программного обеспечения даже при отсутствии подробно документированных требований.

Содержание:

Активно общайтесь

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

  1. Запланируйте регулярные встречи с заинтересованными сторонами для обсуждения особенностей и функциональности приложения.
  2. Используйте эти обсуждения для составления тестовых сценариев.
  3. Постоянно обновляйте свои знания и тестовые сценарии по мере развития проекта.

Используйте исследовательское тестирование

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

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

БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале Библиотека тестировщика

Используйте сессионное тестирование

Сессионное тестирование (SBTM) – это метод исследовательского тестирования, который предполагает непрерывные сессии тестирования. Считайте, что сессионное тестирование – это ваш GPS. Оно помогает вам планировать, выполнять и анализировать исследовательские тесты в заданных временных рамках, обеспечивая эффективное прохождение всех необходимых этапов. Это идеальный вариант для управления исследовательским тестированием и его документирования.

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

Разрабатывайте подход, ориентированный на пользователя

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

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

Вот простой пошаговый пример, иллюстрирующий, как это можно сделать для гипотетического приложения для повышения продуктивности:

Шаг 1: Разработка персонажей

Персонаж 1: «Стартапер Стив»

  1. Демографические данные: возраст 30 лет, основатель стартапа, технологически подкован.
  2. Потребности: Нужны эффективные инструменты для управления задачами и проектами команды, отслеживания прогресса и удаленного общения.
  3. Поведение: часто переключается между различными функциями, требует быстрого доступа к данным, использует приложение на нескольких устройствах (ноутбук и смартфон).

Персонаж 2: “Фрилансер Фиона”

  1. Демографические данные: возраст 26 лет, графический дизайнер-фрилансер, работает на дому.
  2. Потребности: Нужны простые функции для управления задачами и работы с расписанием, предпочитает интуитивно понятный дизайн без лишних сложностей.
  3. Поведение: Использует приложение в основном для управления личными проектами и соблюдения сроков, нуждается в интеграции с дизайнерскими инструментами и сервисами обмена файлами.

Шаг 2: Создание пользовательских сценариев

Сценарий для Стартапера Стива:

  • Задача: управлять новым проектом со своей командой.
  • Шаги:
  1. Войдите в приложение на его ноутбуке.
  2. Создайте новый проект, назначьте задания членам команды.
  3. Установите сроки и приоритеты для задач.
  4. Используйте чат для общения с членом команды по поводу конкретной задачи.
  5. Зайдите в обзор проекта, чтобы увидеть прогресс команды.
  • Пограничный случай: получение ошибки при попытке загрузить большой файл во время сеанса чата.

Сценарий для Фрилансера Фионы:

  • Задача: спланировать свою неделю с учетом всех проектов и сроков.
  • Шаги:
  1. Войдите в приложение на ее планшете.
  2. Добавьте новые задачи на неделю.
  3. Назначайте сроки и устанавливайте напоминания.
  4. Интегрируйте ее календарь, чтобы просматривать все задачи и встречи в одном месте.
  5. Поделитесь своим списком задач с клиентом для ознакомления.
  • Пограничный случай: приложение падает при попытке интегрировать внешний календарь.

Шаг 3: Используйте персонажей и сценарии для тестирования

Приоритеты и направления тестирования:

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

Задействуйте Agile-методологии

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

Согласно Agile:

  1. Объедините быстрые циклы тестирования с регулярными доработками.
  2. Включайте тестирование в ранние этапы разработки, чтобы выявить проблемы как можно раньше.
  3. Найдите время для регулярных ретроспектив, чтобы улучшать процессы.

Ведите полную документацию по контролю качества

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

  1. Разрабатывайте подробные тест-кейсы по результатам общения с разработчиками и другими заинтересованными сторонами.
  2. Включайте ожидаемые результаты и критерии прохождения в каждый тест-кейс, даже если они со временем меняются.
  3. Используйте TestCaseLab для хранения и управления тест-кейсами, обеспечивая доступность и возможность редактирования по мере необходимости.

Сохраняйте историю прохождения тестов

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

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

Перевод статьи «Art of Software Testing Without Documentation».

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *