Home

Автор: Джеймс Бах (James Bach)
Оригинал статьи
Перевод: Ольга Алифанова

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

Пост написан Стефаном Шмидтом. Он говорит, что у него за плечами более сорока лет разработки. У меня их столько же (1 января 2024 стукнул 41 год, годовщина моего первого рабочего дня в Dale Disharoon, Inc. Моим первым проектом было создание игры Hey Diddle Diddle для Apple II и С64). Возможно, разница между нами в том, что я всю свою карьеру занимался именно тестированием, а он говорит, что «пишет тесты» в ходе разработки. Между написанием тестов, предполагаю, он пишет код продукта, а это не тестирование. То есть он в лучшем случае поверхностно знаком с нашей отраслью.

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

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

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

Шмидт неоднократно пишет о «написании тестов». Это говорит мне о том, что он рассматривает тестирование, как механический процесс проверки результатов работы функций, не более того. А что насчет тест-стратегии, тест-дизайна, и тестирования, охватывающего весь пользовательский опыт? Думаю, глаза мистера Шмидта стекленеют, когда опытные тестировщики хотят обсудить основные эвристики, структуры и навыки тестирования. Откуда я это знаю? Потому что люди, с интересом изучающие тестирование и размышляющие о нем, понимают, что этот процесс нельзя закодировать; они знают, что проверки результатов вывода – это не цель и не душа тестирования. Люди, любящие тестировать, знают, что самые важные баги не найдет никакой код. Хотите доказательств? Последите за тем, как находятся баги, и сами это увидите. Доказательства вокруг вас. Просто откройте глаза! Я смотрю на это десятилетиями.

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

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

Рекомендация: никогда не используйте фразу «написать тест». Написать можно процедуру, но тест – не процедура, тест – это творчество. Можно сказать «Я создал тест», «спроектировал тест», «написал тест-процедуру» или даже «написал код теста». Эти фразы не подразумевают, что тестирование – алгоритмизированная деятельность.

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

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