;
Александр Александров

Окей, гуру! Требования – зачем они?

30.04.2021 1208
IBS Training Center Telegram
Подписывайтесь на наш канал в Telegram:
больше материалов экспертов, анонсы бесплатных вебинаров и задачки для IT-специалистов
Подписаться

Казалось бы, требования – область ответственности аналитиков, а не тестировщиков.

Но давайте по порядку.

Как проверять тестирование требований?

Хорошо известны «требования к требованиям» – полнота, однозначность. Непротиворечивость, эффективность, тестируемость и др. Я называю такие «требования к требованиям» мантрами, поскольку далеко не всегда понятно, как их надежно проверить.

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

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

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

Требования и тестирование без тестовых сценариев и/или без тестировщиков

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

Новый подход – тестирование с помощью аналитиков. Заметим, однако, что тестирование вообще и тест-дизайн в частности – это своя инженерная область со своими правилами и технологиями. Если аналитик не владеет инженерией тестирования, он не сможет провести тестирование на требуемом уровне и в требуемые сроки. А если он владеет этой инженерией, то он и есть тестировщик (правда, такое бывает ну очень редко).

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

Требования и тестирование в проектах сопровождения

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

Требования и изменения

Выше мы упоминали о построении матрицы покрытия требований тестовыми сценариями. Поскольку изменения могут быть (и реально возникают) во всех проектах, построение и актуализация матрицы покрытия – обязательная активность процесса тестирования.

Матрица покрытия позволяет оперативно получать ответы на следующие вопросы:

  • Какими тестовыми сценариями проверяется конкретное требование?

  • Какие требования проверяет конкретный тестовый сценарий?

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

Риски тестирования, связанные с требованиями

Наиболее частыми рисками тестирования, обусловленными несовершенством требований, являются:

  • Низкое качество требований к моменту начала тестирования, не позволяющие разработать и применить качественные тестовые сценарии

  • Позднее начало активностей по тестированию, не позволяющее уложиться в сроки и бюджет тестирования

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

  • Пренебрежение матрицей покрытия требований тестовыми сценариями (например, пропуск части требований обнаруживается случайно)


Изучить, как правильно тестировщику работать с требованиями, и глубже погрузиться в тему вы можете на наших курсах!

Тестирование ПО


Расскажи друзьям:

Как не пропустить самое интересное?
Подписывайтесь на наш ежемесячный дайджест!
Спасибо.
Вы подписаны на ежемесячный дайджест.
Пользователь только что записался на курс ""
Спасибо!
Форма отправлена успешно.