Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

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

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

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

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

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

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

Создание множества результатов работы машины может казаться кому-то чудесной идеей, но машина агностична – ей все равно, хорош результат или плох. Даже при использовании сложного инструментария критическая оценка результатов займет куда больше времени, чем производство этих результатов. Это вежливый вариант закона Брандолини («на опровержение всякой чуши нужно куда больше сил, чем на ее создание» - прим. пер.)

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

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

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