Уроки ретроспективного анализа: наука о тестировании

Уроки ретроспективного анализа: наука о тестировании

Mr. Slavchev

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

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

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


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

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

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

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

«Тестирование программ можно использовать для того, чтобы показать наличие ошибок, но никогда — чтобы показать их отсутствие!»
Эдсгер Дейсктра

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

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

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

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


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

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

Представьте себе темную комнату, в ней есть объект, и вы должны его угадать. Для этого вы можете задавать только вопросы, на которые будут даны ответы «да» или «нет», например: «он большой?» или «это кошка», или «это квадрат»? Вам нужно будет задать много вопросов, чтобы угадать объект. Но, что более важно, если вы достаточно умны, вы попытаетесь задавать последовательные вопросы, основываясь на информации, которую вы получаете от ответов, чтобы с каждым разом быть все ближе к разгадке.

Я знаю, что вы собираетесь здесь сказать: «Это не честно. Я могу задавать гораздо более сложные вопросы, более прямые и целенаправленные. Мне не нужно следовать этому дурацкому правилу с ответами "да/нет"». И это правда, но это не работает в науке, и не работает в тестировании.

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

Точно так же, когда мы тестируем форму кредитной карты и хотим выявить все проблемы, которые могут существенно повлиять на наших клиентов, мы не можем просто подойти и спросить форму: «Привет, форма, какие у тебя серьезные проблемы? Ты можешь их продемонстрировать?». Это звучит как отличный вопрос, и на самом деле это именно то, что нас интересует, но мы не получим никакого ответа, просто потому что это так не работает.

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


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

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

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

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

Точно так же при тестировании мы можем наблюдать множество таких «обществ», которые спекулируют фактами, которые им совершенно не удается доказать, например:

  • Общество «Автоматизировать все»
  • ИИ заменяет общество тестирования
  • Общество формального тестирования
  • Общество зрелых моделей и стандартов
  • Общество софт-скилов и т.д.


Их всегда можно определить по нескольким важным факторам:

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

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

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


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

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

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

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

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

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

Теперь большое открытие...


Я чертов лжец...

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

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


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

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

Тот факт, что у нас есть проверяемые предсказания, неизбежно заставит нас искать эксперимент, чтобы доказать это предсказание, вопрос в том, достаточно ли оно хорошее?

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

Важно, что в случае тестирования, игра в подтверждения может привести к катастрофе. Спросите у начинающего тестировщика, какова цель тестирования, и вы получите ответ типа: «Доказать, что продукт работает (как ожидалось)». Это именно то, чего мы пытаемся избежать. Если мы только подумаем, как это должно работать, мы можем ослепить себя от всех способов, которыми это может не работать, или не должно работать.

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


«Наука должна начинаться с мифов и с критики мифов»
Карл Поппер


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

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

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

«Я требую, чтобы логическая форма [теории] была такой, чтобы ее можно было выделить с помощью эмпирических тестов в отрицательном смысле: эмпирическая научная система должна быть опровергнута опытом»
Карл Поппер


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

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


Переведено командой QApedia. Подписывайтесь на наш канал.


Report Page