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

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

.
Ретроспективные уроки исследовательского тестирования: искусство тестирования
05.09.2019 00:00

Автор: Виктор Славчев (Viktor Slavchev)
Оригинал статьи
Перевод: Ольга Алифанова

Если вы регулярно следите за моим блогом – хотя я нерегулярно пишу – или слышали мои выступления, то, возможно, слышали, как я говорю нечто вроде "Тестирование похоже на науку" или "Наука тестирования". Это звучит веско и броско, но я пока что видел немного хороших объяснений, почему это так. Я этого тоже не объяснял, поэтому в том есть и моя вина.

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

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

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

Итак,…

Почему тестирование похоже на науку?

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

Другой аспект тестирования, похожий на науку – это способ демонстрации наших находок.

Один из основных принципов тестирования – это мысль Эдсгера Дейкстры, которую, я надеюсь, все слышали хотя бы однажды:

"Тестирование программ может доказать присутствие багов, но не может доказать их отсутствие!"

- Эдсгер В. Дейкстра.

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

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

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

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

Сила эксперимента

Тестирование – это игра в "данетку", как и наука.

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

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

Приведу примеры. Представьте, что вы исследователь и хотите выяснить, будет ли ускорение свободно падающего предмета в атмосфере Земли постоянной величиной, или же переменной, меняющейся в зависимости от каких-то условий (будем игнорировать тот факт, что мы это знаем). Вы не можете просто пойти и спросить у гравитации – "эй, гравитация, твоя скорость постоянна или переменчива?" Честно говоря, это отличный вопрос, но он останется без ответа. Вам придется провести эксперимент, чтобы найти этот ответ.

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

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

Демонстрируемость

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

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

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

Схожим образом, в тестировании мы можем наблюдать за множеством таких "обществ", спекулирующих фактами, доказательства которых с треском проваливаются:

  • Общество поклонников тест-кейсов
  • Общество "Автоматизируй все"
  • Общество "AI заменит тестировщиков"
  • Общество формального тестирования
  • Общество зрелых моделей и стандартов
  • Общество ерунды про личные качества.

Их всегда можно заметить по ряду значимых признаков:

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

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

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

Как работает тестирование?

Вот небольшая схема, объясняющая, как тестирование работает:

 

Давайте рассмотрим гипотетическую ситуацию – у нас есть поле, формат которого нам нужно очень конкретно проверять – скажем, SSID или ИНН.

Вот как эта модель будет работать на примере типичного теста:

  1. У этого поля очень специфичная валидация формата, обычно верифицируемая регулярным выражением или каким-то иным образом. Каждый символ значим, так как иногда нужно проверять последнюю цифру. Поэтому добавление символов должно спровоцировать ошибку формата (я сделал наблюдение).
  2. Что будет, если этот добавленный символ – пробел? Мы можем добавить его случайно или при вставке скопированного (подумал об интересных вопросах).
  3. За это нельзя карать – как сказано выше, это непреднамеренная ошибка. Лучшее, что мы можем сделать – это обрезать пробелы. Зачастую разработчики забывают о такой вероятности, и пробелы вызовут ошибку в поле (Гипотеза).
  4. Я могу протестировать и доказать это, просто добавив пробел в начале, конце или где угодно еще в строке (Тестирование гипотезы).
  5. На основании результата, если выявлена проблема, я могу задаться вопросом, нет ли подобной проблемы в других полях, потому что они используют тот же способ обработки текста (Разработка теории), и так далее.

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

И шокирующая новость…

Я – гребаный лжец…

Ну, как минимум, отчасти, потому что это не просто модель работы тестирования – это модель научного метода. Это не просто способ проведения тестирования – этим способом проводятся научные эксперименты.

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

Ловушка: подтверждение против опровержения

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

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

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

Важно помнить, что в случае тестирования игра в подтверждение может привести к катастрофе. Спросите джуниор-тестировщика, в чем цель тестирования, и вы получите ответ вроде "Доказать, что продукт работает как ожидается". Это именно то, чего мы пытаемся избежать. Если мы будем только о том, как он должен работать, мы сами закроем себе глаза на все способы, при которых он может не сработать, или не должен работать, или будет работать плохо.

Что еще важнее – даже если мы откроем 99 способов показать, как он может работать, мы не сможем с уверенностью сказать, что он на самом деле работает, если в реальности существует один случай, когда он работать не будет.

"Наука должна начинаться с мифов и критики мифов".

- Карл Поппер.

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

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

Это также связано с теорией вышепроцитированного Карла Поппера об опровергаемости, которая звучит примерно так:

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

- Карл Поппер.

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

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

До новых встреч!

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