Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Лучшие вакансии

.
Предвзятость в тестировании
19.08.2015 10:50

Оригинальная публикация: http://testsheepnz.blogspot.ru/2015/07/confirmation-bias-in-testing.html

Автор: блогер и тестировщик TestSheep

Перевод: Ольга Алифанова для Software-testing.RU

Концепцию предвзятости я понимал смутно, пока не прошел курс Джеймса Баха "RST". Смысл понятия в том, что зачастую мы видим то, что наш мозг, наша психика хотят видеть, а не то, что существует на самом деле.

В целом, такая профессия, как тестировщик, существует именно благодаря предвзятому отношению.

Представим разработчика, создающего страницу регистрации для нового приложения.  Он регистрирует нового пользователя, вводя свое имя, почту, дату рождения, и получает сообщение "Добро пожаловать, Стюарт Кук!"."Все работает", заключает разработчик, и переходит к следующей интригующей задаче.

Можем ли мы сказать, что регистрация была протестирована? Разработчик ввел данные, увидел то, что и хотел увидеть - приветствие системы - и убедился, что все работает как надо.

Все мы попадались на эту удочку не раз (я, по крайней мере, попадался) - один тест ничего не доказывает. Осознание, что мы склонны делать вывод "все работает", исходя из одного-единственного подтверждения - ключевой момент курса "Быстрое тестирование".

Ввести данные и получить сообщение "Привет, Стюарт" - неплохой старт.  Но до финиша еще далеко.

Вдруг это просто сообщение?  Что, если учетная запись не была создана?  Мы можем проверить базу данных, или попробовать войти в систему, чтобы убедиться, что учетную запись можно использовать.  Если разработчик еще не создал страницу авторизации, придется ограничиться базой данных.  Вы же собирались ее проверить, правда?

А если мы зарегистрируемся как Вася - мы тоже получим сообщение "Привет, Стюарт"? Мелочь, а неприятно.
Что, если поля регистрации будут принимать значения любой длины? А если мы введем туда полную ерунду - удастся ли создать учетку?

 

Эвристики для тестирования формы регистрации можно посмотреть в моих статьях "Назад к основам".

Иногда про нас, тестировщиков, говорят, что с нами тяжело и сложно иметь дело.

Когда Стюарт, наш программист, регистрируется под своим именем, он говорит "Все работает" и переходит к другой задаче.

Когда к тестированию приступаем мы, мы должны сказать "У нас есть некоторая уверенность, что если ввести похожие данные, то при этом сценарии система будет работать как задумано".

Не слишком ли мы осторожничаем?  Ряд участников процесса разработки почувствует себя неуютно от таких заключений.

 Давайте поразмышляем, почему я предпочитаю именно такую формулировку.

"Если ввести похожие данные":

Данные, которые мы ввели - это фамилия, имя и отчество определенной длины на определенном языке, конкретная дата рождения и определенной сложности пароль.  Если мы введем данные, которые:

  • Включают символы других языков
  • Гораздо длиннее / короче
  • Значительно отличаются от первоначальных (например, дата рождения)
  • Имеют кардинально иную структуру (например, пароль),

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

Все согласны? Идем дальше.

"при этом сценарии система будет работать, как задумано"

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

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

"Есть некоторая уверенность"

Странновато звучит, правда?  Вы уверены или нет?  Если вы успешно создали учетную запись для Стюарта Кука, вы же можете с уверенностью заявить, что при предоставлении аналогичной информации вы создадите такую же учетную запись?

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

Ладно, давайте предположим, что вы удалили созданную учетную запись Стюарта сразу после создания.  Можем ли мы теперь быть уверены, что сможем снова ее создать?

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

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

Как бороться с предвзятостью?

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

Используйте мою формулировку, приведенную выше:
"У меня есть некоторая уверенность, что если ввести похожие данные, то при этом сценарии система будет работать как задумано".

Во-вторых, пробуйте различные сценарии, старайтесь покрыть своими тестами все возможные сценарии системы.

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

Увы, мы никогда не сможем быть уверенными на 100%, что "все работает" - всегда придется соблюдать баланс между попытками перебрать все возможные варианты данных, получить все возможные результаты, и временем, выделенным на тестирование.

Хорошее тестирование - это мудрый выбор сценариев, основанный на возможностях системы и собственном опыте, который позволяет изловить потенциальные дефекты.

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