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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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