<style>.lazy{display:none}</style>Как тестировщику работать с плохими требованиями

Как тестировщику работать с плохими требованиями

Плохо сформулированные требования могут усложнить процесс создания и тестирования ПО и привести к неудовлетворительному результату. Анализ требований к продукту является отправной точкой жизненного цикла тестирования ПО — чётко сформулированные требования помогают повысить качество продукта и избежать множества ошибок.

Как плохие, неполные и противоречивые требования создают проблемы:

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

  • Как бы вы сообщили о сбое системы, если нет определения того, какое поведение системы считается корректным?
  • Как донести до клиента, что время загрузки главной страницы в 100 секунд неприемлемо, если нет соответствующих требований к производительности?

2. Неполные требования — для описания такой ситуации отлично подходит фраза «знать что-то частично опаснее, чем не знать вообще»‎.

Попытка интерпретации неполного требования и его реализация — это большой риск, например:

  • Как бы вы подтвердили, что всплывающее окно с результатами поиска, работает надлежащим образом, если единственным требованием было «результаты поиска должны быть корректными»? При этом вам не известно, какие критерии должны учитываться при поиске.
  • Как бы вы интерпретировали следующее требование «необходимо создать кнопку “забыли пароль?”, чтобы облегчить пользователю восстановление или замену забытого пароля»? Не зная точных требований, тестировщик проверит эту кнопку исходя из собственных представлений, что может привести к конфликту с заказчиком.

3. Противоречивые требования — если попросить кого-то сделать две разные вещи одновременно, он просто запутается.

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

Методы работы с плохими требованиями

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

Метод №1. Исследовать и учиться.

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

Метод №2. Использовать опыт.

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

Метод №3. Обратитесь к Wireframe.

Каркасы веб-сайта или схема страницы (Wireframe) — это своего рода визуальные требования, позволяющие найти мелкие детали, которые могут быть очень полезны для создания ожидаемого вида продукта или приложения. Использование таких схем помогает более точно осветить аспекты тестирования. Для работы со схемами страницы можно воспользоваться Balsamiq Wireframes.

Метод № 4. Обсуждение с коллегами.

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

Метод №5. Уточнение у заказчика.

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

Заключение

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

Перевод статьи «How to Deal With Bad Requirements as a Tester».

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

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