Андрей Сильчук, Delivery Manager, Head of DataArt’s R&D Center Odessa.
С вами моя ежемесячная рубрика «Поясняю за АЙТИ». Признаю, грешен — замечен во лжи. И это ж надо, на первой же строчке статьи. Говорят, рубрика не ежемесячная, раз апрельского выпуска не было! Да, к сожалению, ребята, в связи с карантином и происходящими вокруг него событиями руки до статьи так и не дошли. Но это ничего, сегодня мы компенсируем опоздание с лихвой. Мы поговорим об одной особенности процесса тестирования, которую я лично заметил, еще будучи практикующим QA инженером. Поверьте мне как человеку, имеющему более 10 лет опыта в IT, главе крупного R&D-центра, деливери менеджеру, удачно сдавшему огромное количество проектов, эта особенность — тема интересная и тонкая.
Мы с вами знаем, что QA достаточно молодая дисциплина. Но все-таки сколько ей лет? Двадцать? Тридцать? Может быть, 40 лет? Не все знают, что еще сам Ньютон выдал ставшую крылатой латинскую фразу: “Insperata accidit magis saepe, quam qua speres”, что в принципе можно перевести как «Только знающий точку назначения, да дойдет». Давайте немного порассуждаем о ней. О чем она говорит? Я в ней вижу ни что иное, как размышления человека об ожидаемом результате. Но так ли это важно? Начнем с простого: не зная, чего же вы, собственно, хотите, невозможно определить, есть ли в системе дефект или все идет как надо. Не так ли? Ну а если продукт не удовлетворят заказчика и конечного пользователя, ни он сам, ни компания, его создавшая, просто не выживут. Именно поэтому expected result, на самом деле, важнейшая составляющая процесса тестирования.
Я продолжил поиски истины и наткнулся на интересную «Теорему Тенымероет — Йоката».
Открыта она в 1995 году и математически доказывает значение наличия ожидаемого результата. Постулат прост: наличие Ожидаемого результата помогает уменьшить количество ложных расчетов на 97,3 % и ускоряет работу в 4,45 раза вне зависимости от сферы деятельности. Это утверждение было сформулировано и доказано совместными усилиями греческого и китайского математиков, и в целом я склонен доверять этим цифрам. Согласно метрик моих реальных проектов, могу заявить со всей ответственностью, что в начале тестирования, когда мы имеем слабое представление о системе, количество релевантных дефектов будет заведомо меньше, чем в дальнейшем, когда мы в ее поведении хорошенько покопаемся. Приведу и пару примеров из истории.
В 1973 году телохранитель президента Никсона почувствовал себя крайне плохо, после того как попытался на лодке добраться к президенту через залив. Врачи сказали, что молодой и крепкий мужчина не выживет, и просто изолировали его. Однако один медбрат сумел его спасти. Каким же образом он излечил его недуг? Все просто, этот работник медицинской сферы, порывшись в информационном поле, установил, что симптомы подходят под ожидаемое поведение больного при одной крайне редкой в тех широтах болезни. Это позволило быстро предложить верное лечение. А вот еще один пример.
В 1874 году в одном из полицейских участков Шотландии младший офицер взял в заложники брата своего капитана и собирался его застрелить. Пацан выжил. Все благодаря тому, что капитан сам вызвался вести переговоры, зная, чего ожидать от подчиненного. Ему было известно, что на учебных стрельбах тот всегда уводил револьвер чуть влево. Ожидаемый результат — пуля после его выстрела в любой ситуации попадает чуть левее намеченной цели. Когда он освобождал брата, то велел ему, убегая, прыгнуть вправо, благодаря чему пуля ушла в молоко.
Наконец, последний пример. В 2006 году маленькая девочка выжила при пожаре в воинской части, в котором погибли десятки мужчин. Как, спросите вы? Все просто, продукты горения поднимаются вверх, и девочка, будучи ниже ростом, чем другие жертвы, единственная смогла продержаться до приезда пожарных. Если бы все в воинской части помнили об ожидаемом поведении угарного газа, возможно, жертв было бы гораздо меньше или не было вовсе. Кто знает?
Теперь время небольшого откровения. Своим заявлением о десятилетнем опыте и экспертизе в вопросах тестирования я сам сформировал для вас ожидаемый результат последующих рассуждений. Вы же не думали, что такой профессиональный парень несет полную отсебятину, к тому же, так уверенно, с именами, датами и указанием локаций. Вряд ли многие из вас сразу полезли проверять факты, о которых я говорил, даже если отдельные детали и вызвали сомнения. Именно так мы попадаем в ловушку ложных ожиданий.
Теперь по порядку. Начнем с фразы Ньютона, которая, на самом деле, переводится как: «Неожиданное случается чаще ожидаемого». Да и произнес ее вовсе не Ньютон, а Галилей (во всяком случае, ему ее приписывают). Дальше больше. Вы еще со мной или уже проверяете остальные высказывания? Прочитайте название теоремы «Тенымероет — Йоката». Наоборот и получите «А такой теоремы нет». Портреты ученых — первые картинки, выданные поиском Google по запросам «греческий математик» и «китайский математик», соответственно. Я даже не знаю, кто эти ребята. Возможно, вы споткнулись на фамилии Йоката, подумав, что математик, скорее всего, японец. Но навело ли это на мысль проверить факт существования теоремы? Или вы просто довольно усмехнулись, подумав: «Да, этот парень опытный тестировщик, но как востоковед я сильнее»?
Описанные мной исторические примеры составлены из картинок, найденных по теме “The History of Computers Documentary 2018”, сюжетов “Game of Thrones”, щепотки воображения и частичной правды. Первый случай про лодку и болезнь списан с эпизода исцеления Джораха от серой хвори Сэмом. История про заложника — перенесенная в иные обстоятельства сцена, где Джон пытается спасти Рикона. Пожар я просто выдумал, но постарался придать эпизоду научную подоплеку.
Думаете это все? Тогда посмотрите на иллюстрации. Они ведь не имеют ничего общего с этими историями! Но кто обратил на это внимание? Если вы удивились, поздравляю — готов биться об заклад, вы попали в число немногих. Человеческий мозг устроен так, что сам достроит логические связи даже там, где их нет. Мозг естественным образом работал на ожидаемый результат, используя крупицы правдивой информации, случайные картинки, уверенную подачу и т. д. Правда же заключается в том, что expected result содержит в себе четыре аспекта: психологический, авторитетный, групповой и системный. Теперь немного подробнее о каждом.
Психологический аспект легко объяснить одной картинкой:
Вы видите надпись, и мозг сам выстраивает ожидаемый результат. Где “гостиница” становится продолжением ряда, определенно связанного с “дрессировкой собак”, хотя и несколько выбивается из него. Вы уверены, что речь идет о передержке. Но может быть, человек рекламируют уникальный отель, где вы можете вволю гладить дрессированных им собак? Или просто рассказывает втором бизнесе? Кто знает.
Авторитетный аспект. Я уже говорил, что в начале статьи, опираясь на свой опыт, сформировал ложные ожидания и настроил вас на некритическое отношение к своим словам. Так и в реальных проектах ваши более синьорные и уверенные в себе коллеги могут сформировать образ истины в последней инстанции.
Групповой аспект заключается в том, что новому человеку в проекте проще пойти на поводу у сплоченной команды, чем обратить общее внимание на явный недочет. Если все как один утверждают, что «оно отродясь так работало и так сложилось исторически», сомнения хочется отправить в дальний угол. Даже если в начале разговора вы были уверены в ошибке так же, как в любви своей мамы.
Последний аспект, который я выделил — системный. Опыт ваших прежних проектов заранее формирует ожидаемые результаты для тех или иных ситуаций. Но ведь, согласитесь, есть и нюансы? Именно в них чаще скрывается суть, и благодаря какой-то мелочи реальный результат оказаться обратным вашим ожиданиям, к которым вас подталкивает собственная экспертиза.
Какой телефон считать эталоном? У большинства из вас всплывет мысль: «Да это то же iPhone!». Потому что это самая распиаренная марка и она у всех на слуху. Не так уж важно, насколько это утверждение верно, давайте просто подумаем о куче других крутых девайсов, представленных на рынке. По каким параметрам вы сравнивали их с тем, который первым пришел на ум?
Давайте напоследок вспомним известный случай, имевший место 25 сентября 1983 года. Он давно превратился в байку, но предыстория у нее все равно остается правдивой. В тот момент мы все едва не погибли (даже те, чьи родители еще не были знакомы или вообще не родились). На главный советский компьютер поступает сообщение о запуске ядерной ракеты с американской базы. Через минуту его дополняет информация о втором, третьем, четвертом и пятом запусках. Дежурный офицер, по регламенту, должен принять решение об ответных мерах и отправить всего одно короткое сообщение руководству страны. Ядерный удар по США со стороны Советов — единственный ожидаемый результат в сложившейся ситуации. Однако Станислав Евграфович Петров, проанализировав ситуацию, определяет, что техника дала сбой и тревога ложная. Судный день откладывается на неопределенный срок.
К чему это я? Да к тому, что ожидаемый результат может даже самым опытным из нас указать неверное направление. Что тогда делать, и зачем я тут распинаюсь? У меня нет серебряной пули, но есть непрошенный совет — с достаточной периодической частотой проводите на вашем проекте «день тестирования наобум». Берите области системы, в которые вы раньше глубоко не погружались, где, например, оунером был ваш коллега, отдавайте ему свою и вместе проводите ad hoc тестирование. Это может не дать неожиданного результата раз, другой, третий и даже пятый. Но поверьте, и сейчас я говорю абсолютно серьезно, иногда это помогает найти критические дефекты. Такие, которым вы сами будете удивляться: «Как это мы раньше их не замечали?!»
Такая практика — очень крутая инвестиция, которую можно грамотно подать не только своим же менеджерам, но и заказчику. Вы уже ушли проверять ожидаемые результаты? Почему вы еще здесь?!
В статье были использованы фотографии:
Константинос Даскалакис
Чжан Ийтан Мо Цзунцзянь
ENIAC-J. Prester Eckert em primeiro plano, e John W. Mauchly ao centro (SILVA 2006a)