Home

Автор: Мария Кедемо (Maria Kedemo)
Оригинал статьи
Перевод: Ольга Алифанова

Я часто слышу, что люди говорят о тестировании, как о валидации и верификации требований. Но тестирование – это намного более широкое понятие.

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

Согласно Оксфордскому словарю,

Верификация – это "Убедиться или продемонстрировать, что (нечто) верно, точно или оправдано".

Валидация – это "проверить или доказать валидность или точность чего-то".

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

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

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

Когда наш мозг нацелен на верификацию, мы забываем задавать вопросы:

Что, если…? Что еще? Что будет, когда…? Для кого это? Почему это так спроектировано? Когда это можно применить? Можно ли использовать эту функцию иначе, чем ожидается? Какова ее ценность? Для кого?

Бросая вызов тестируемому продукту или системе, вы узнаете много нового. Избежав искажения подтверждения, вы повысите шанс нахождения багов/дефектов, которые не должны найти пользователи. В худших случаях эти баги будут стоить кучу денег вашей компании.

Но надо же убедиться в соответствии требованиям!

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

Тестирование требует множества источников информации. Письменные требования – всего лишь один из источников, дающий тест-анализу информацию для принятия решения, что тестировать. Если мы хотим, чтобы продукты и ПО стали лучше, нужно выйти за рамки проверок. Так как мы не можем протестировать все, нам надо знать, что важнее всего тестировать. На это решение влияет множество параметров, и это еще один необходимый тестировщику навык. И тут-то многие и выбирают слишком узкий подход, выбирая верификацию вместо тестирования. Вместо этого вы можете сфокусироваться на риске. Что самое худшее может произойти? Что, если мы не сможем перейти к оплате? Вместо проверки нескольких конкретных сценариев будьте креативными и исследуйте эти сценарии с разных сторон.

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

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

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

Забудем про верификацию и начнем тестировать!

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

Рикард Эдгрен, Записная книжка тест-дизайнера

Джеймс Бах, "Тестирование VS проверки"

Майкл Болтон, "Тестирование без карты"

Анна-Мария Шарре, "Как тестировщику не стать обманутым"

Обсудить в форуме