Казалось бы, требования – область ответственности аналитиков, а не тестировщиков.
Но давайте по порядку.
Как проверять тестирование требований?
Хорошо известны «требования к требованиям» – полнота, однозначность. Непротиворечивость, эффективность, тестируемость и др. Я называю такие «требования к требованиям» мантрами, поскольку далеко не всегда понятно, как их надежно проверить.
Однако для тестирования любой дефект требований – это переделка тестовых сценариев, тестовых данных, автоматизированных скриптов, повторное тестирование. Поэтому экспертиза тестирования более других экспертиз заинтересована в проверке этих мантр.
Мы считаем, что эффективный способ проверки – это раннее проектирование тестовых сценариев. Может быть, даже не тестовых сценариев, а тестовых условий или идей тестов – набора высокоуровневых задумок того, что и зачем (но не как) планируется тестировать.
И параллельно начинать строить визуализация связи тестовых сценариев и требований и требований (где и что проверяется), которые в дальнейшем будут преобразованы в полноценную матрицу покрытия.
Требования и тестирование без тестовых сценариев и/или без тестировщиков
Раньше считалось, что программисты могу успешно тестировать собственный код (имеется в виду не только модульное тестирование) и поэтому никакие тестировщики не нужны. Потом все поняли, что это не так, но идея обойтись без тестировщиков не пропала.
Новый подход – тестирование с помощью аналитиков. Заметим, однако, что тестирование вообще и тест-дизайн в частности – это своя инженерная область со своими правилами и технологиями. Если аналитик не владеет инженерией тестирования, он не сможет провести тестирование на требуемом уровне и в требуемые сроки. А если он владеет этой инженерией, то он и есть тестировщик (правда, такое бывает ну очень редко).
Наконец, вспомним про дефекты требований, в нахождении которых крайне заинтересованы тестировщики. Что же, аналитики будут искать их сами у себя? Напоминает ситуацию с программистами, тестирующими собственный код. Успех такого мероприятия сомнителен.
Требования и тестирование в проектах сопровождения
Особенность проектов сопровождения, в частности. в том, что небольшие требования вызывают небольшие правки кода, но могут потребовать больших объемов тестирования. Типичные примеры – добавление поля, рефакторинг кода и др. Это означает, что все принятые пропорции в части соотношения числа программистов и тестировщиков, или трудозатрат на разработку и тестирование могут быть нарушены. И здесь на первый план выходит адекватная и обоснованная оценка трудозатрат на тестирование, которую умеют проводить только тестировщики.
Требования и изменения
Выше мы упоминали о построении матрицы покрытия требований тестовыми сценариями. Поскольку изменения могут быть (и реально возникают) во всех проектах, построение и актуализация матрицы покрытия – обязательная активность процесса тестирования.
Матрица покрытия позволяет оперативно получать ответы на следующие вопросы:
-
Какими тестовыми сценариями проверяется конкретное требование?
-
Какие требования проверяет конкретный тестовый сценарий?
Потребность в ответе на первый вопрос возникает при оценке трудозатрат на тестирование изменения требования. Потребность в ответе на второй вопрос возникает при оценке критичности дефекта, найденного посредством прогона тестового сценария.
Риски тестирования, связанные с требованиямиНаиболее частыми рисками тестирования, обусловленными несовершенством требований, являются:
-
Низкое качество требований к моменту начала тестирования, не позволяющие разработать и применить качественные тестовые сценарии
-
Позднее начало активностей по тестированию, не позволяющее уложиться в сроки и бюджет тестирования
-
Отсутствие или несвоевременное проведение качественного ревью требований, не позволяющее выполнить все активности тестирования с требуемым качеством
-
Пренебрежение матрицей покрытия требований тестовыми сценариями (например, пропуск части требований обнаруживается случайно)
Изучить, как правильно тестировщику работать с требованиями, и глубже погрузиться в тему вы можете на наших курсах!
Тестирование ПО