Home

Автор: Джеймс Бах (James Bach)
Оригинал статьи: https://www.satisfice.com/blog/archives/5290
Перевод: Ольга Алифанова

Рим был построен не за один день, но хватило всего шести дней, чтобы он по случайности сгорел дотла в 64 году нашей эры. Он был заново отстроен с учетом пожарной безопасности. А когда в 1903 году при пожаре в театре "Ирокез" в Чикаго погибло 502 человека, уже в 1904 году нормы пожарной безопасности повысились. Пожар на фабрике "Трайангл" в Нью-Йорке (146 погибших) привел к основанию Нью-Йоркского Бюро пожарной безопасности, а Национальная Ассоциация Пожарной Безопасности сейчас поддерживает несколько сотен различных норм и требований – и многие из них появились вследствие особо трагичных пожаров. Люди учатся на трагедиях.

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

Поэтому неудивительно, что в 2011 году на конференции STARWest Джеймс Уиттакер, тогда работавший в Google, объявил, что тестирование "мертво". Что? Тестирование мертво? Он вроде бы имел в виду, что тестировщики больше не нужны, так как их заменили автоматические проверки и автоматические обновления. Однако Уиттакер не был профессионалом тестирования. Представьте руководителя фабрики по производству шкафов, который, ни разу в жизни не смастерив шкаф, заявляет, что квалифицированное плотничество умерло. Звучало это примерно так же.

Судьба, казалось, подслушивала и была оскорблена – спустя пару недель ряд багов Google попал в новости: на CNN.com появилась статья с прискорбным заголовком "Неделя, когда Google реально облажался". Спустя еще несколько месяцев в Google Wallet была обнаружена серьезная проблема безопасности, затрагивающая всех пользователей. Репутация продолжала портиться.

Что это значит для тестирования? В конце концов, ни один процесс тестирования не гарантирует, что избавит от всех абсолютно багов. Другие процессы при этом тоже могут найти или предотвратить баги. Любители и фрилансеры могут их найти! Разработчики могут тестировать свой собственный код. Тот факт, что Google периодически конфузится из-за плохого качества ПО, не означает автоматом, что им нужно нанять больше тестировщиков. Может, им нужно нанять разработчиков получше, или получше их учить.

Очевидно тут одно: странно хвастать, как низко вы цените тестирование, ожидая при этом прощения от пользователей и (все чаще) правительства за нанесение ущерба обществу своими продуктами.

Что убьет тестирование?

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

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

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

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

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

В нашей отрасли действительно есть проблема с разрушением ожиданий, что все будет надежно работать всегда. Недавно я застрял снаружи собственного дома в холода и обнаружил, что мой Android-телефон не дает мне позвонить через сотовую сеть. Я перезагрузил телефон (что заняло несколько минут), но это не  помогло. Я подсоединился к WiFi и попытался позвонить через него, но получил странную ошибку о том, что я не зарегистрирован. До этого я звонил через WiFi из дома и поэтому точно знал, что этот способ работает. В итоге я запустил Skype и отправил сообщение сыну (это было сделано через WiFi, почему звонки-то не работали?). Эта штука предполагалась как телефон. Меня это раздражает, но не удивляет.

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

(С тех пор, как я это написал, я перешел на iPhone, с ним дела немного лучше).

3. Тестирование может умереть, если качество тестирования будет хронически плохим. К сожалению, смерть тестирования может быть самосбывающимся пророчеством. Люди, которые более склонны верить, что тестирование мертво (как ребята из Google), навряд ли будут посвящать себя изучению тестирования. Они просто не знают, как правильно тестировать – или же им просто все равно. Момент, когда менеджмент спросит себя, а зачем им вообще тестировщики – вопрос времени.

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

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

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

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

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

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

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

Мы с Майклом преподаем Rapid Software Testing – боевое искусство тестирования. Это захватывающе. Мы пытаемся показать людям, что их работа не должна быть отстоем. Мы кормим тестировщиков.

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