Home

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

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

Тестировщикам, серьезно относящимся к тестированию, сложно объяснить окружающим, как это работает.

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

Мы не знаем, чего именно мы не знаем. Это, конечно, должно быть очевидным, но если мы чего-то не знаем, то понятия не имеем, как мало мы в этом понимаем, и наш опыт или отсутствие опыта могут завести нас не туда. "Водить машину легко! Просто включаешь передачу, и вперед!" Возможно, это отлично работает в вашем нынешнем контексте. А теперь предлагаю сесть за руль в Бангалоре.

Какое отношение это имеет к тестированию? А вот какое:

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

В мире разработки ПО есть поверье, что если все полны энтузиазма и действительно как следует стараются, то все будет хорошо. Если верить в это, нет необходимости искать глубокие, скрытые, редкие, плавающие, внезапные проблемы; достоинства людей магическим образом не позволяют таким проблемам появиться. Это, мягко говоря, крайне оптимистичный взгляд на риски. Все это здорово, если продукт не так уж и важен. Но если наш продукт значим, мы должны искать проблемы, а для намеренного поиска глубоких проблем неплохо бы иметь опытных тестировщиков!

Однако роль тестировщика не всегда приветствуется. Проблема в том, что для создания инновационного, сложного продукта требуется огромный запас оптимизма, установка "нет ничего невозможного". Однако, как мне как-то сказала моя подруга Фиона Чарльз, перефразируя Тома ДеМарко и Тима Листера – "В окружении, где все возможно, риск-менеджмент – уголовное преступление". Я бы больше сказал, в таком окружении даже признание риска – уголовное преступление.

В книге Waltzing With Bears ДеМарко и Листер пишут: "Прямой результат подхода "возможно все" – это обескураживание любого анализа, предполагающего, что возможно не все. Внедряя структуру риск-менеджмента, вы даете людям возможность думать негативно хотя бы иногда. Делающие это компании понимают, что негативное мышление – единственный способ не прохлопать риск в ходе развития проекта".

Отрицание риска хорошо показано в прекрасном документальном фильме General Magic, который рассказывает про команду разработки с таким же именем. В ранних 1990-х (!!) General Magic работали над устройством, которое по мощности, дизайну и амбициям было практически неотличимо от вышедшего 15 лет спустя iPhone.

Документальный фильм заслуживает просмотра. В одной из частей лидер проекта Марк Порат вспоминает, почему General Magic прогорели, даже не приблизившись к запуску. "Мы были бесстрашны и уверены, что все делаем правильно; вопрос "Могу ли я ошибаться" даже не вставал. Это то, что нужно, чтобы оторваться от Земли – неимоверный набор скорости, полученный благодаря подавлению мыслей о возможности неудачи".

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

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

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

Ложная и бессмысленная идея, что тестирование можно автоматизировать, ведет к разделению тестирования на "ручное" и "автоматизированное".

Слушайте сюда: ни один аспект разработки ПО (или любой другой социальной, когнитивной, интеллектуальной, критической, аналитической или исследовательской работы) так не делится. Не существует "ручных программистов". Не существует "автоматизированного исследования". Менеджеры не управляют проектами "вручную", и не существует "автоматизированного менеджмента". Врачи могут использовать очень мощные и сложные инструменты, но не существует "автоматизированных врачей", как и "ручных", и ни один доктор не позволит себя так категоризировать.

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

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

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

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

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

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

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

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

Вы сказали "ручное"? Возможно, вы говорите про исследовательскую работу, которая, как ни странно, отличается от вышеописанной эмпирической. Исследовательское в терминологии Rapid Software Testing означает агентское; кто или что отвечает за принятие решений в каждый момент времени. Об этом есть что почитать.

Погодите-ка… Почему эмпирическое и исследовательское тестирование – это разные вещи?

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

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

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

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

У "ручного тестирования" есть и другие измерения. Долгое время мы считали "спекулятивное тестирование" тем, что имеют в виду люди, говорящие о "ручном"; "что, если?" Мы противопоставляли его "демонстративному" тестированию, но потом рассудили, что демонстрация – это на самом деле вообще не тест. По крайней мере, она не имеет такого намерения. Чтобы действие стало тестированием, оно должно быть исходно спекулятивным.

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

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

Есть еще одна издержка, связанная с предыдущими. Она хорошо спрятана, и ее не осознают: ее можно назвать издержкой интерпретации или анализа. Достаточно крупный набор автоматизированных проверок непроницаем; в него нельзя вникнуть без затратного ревью. Эти зелененькие проверки вообще что-то делают? А кто его знает!

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

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

Тут есть еще нечто более странно: вместо того, чтобы учить тех, кто не технарь, программировать и получать прямой опыт взаимодействия с API, мы сажаем их перед GUI фронтэнда API. Опытные программисты пытаются автоматизировать интерфейс, и в то же самое время тестировщики без технических навыков используют Cypress, чтобы не взаимодействовать с API вообще! Опыт работы с API через Cypress колоссально отличается от опыта разработчика, использующего API.

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

Тестирование должно рассматриваться, как социальное, когнитивное, сконцентрированное на риске, критическое (во многих смыслах), аналитическое, исследовательское, профессиональное, эмпирическое, экспериментальное, научное, почетное искусство. А не как "ручное" и "автоматизированное". Давайте отправим эти ложные определения в длинный отпуск на необитаемый остров, пока они не помрут от безразличия.

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

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