Home

Автор: Кейт Полк (Kate Paulk)
Оригинал статьи
Перевод: Ольга Алифанова

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

Ниже – десять распространенных и наиболее ошибочных причин не нанимать тестировщиков.

1. Только ленивые разработчики пишут баги / Наличие тестировщиков приводит к лени разработчиков

Это печальное верование обязано своим возникновением идее о возможности создания ПО без багов, без вложения миллионов, и за приемлемое время. Создать ПО без единого бага, конечно, можно, но оно будет или крайне тривиальным (на ум сразу приходит"Hello World" или школьные домашние задания по программированию), или вся команда должна затратить неимоверное количество времени на отлавливание и искоренение последних багов перед релизом.

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

2. У нас есть юнит-тесты / кто угодно в команде может это протестировать

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

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

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

3. Это веб-приложение – исправим на проде

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

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

К тому же исправления на проде из-за жалоб пользователей означают, что пользователи это увидели. Давнее исследование гласит, что только 4% пользователей уведомят вас о наличии проблемы. На каждого сообщившего о проблеме приходится минимум 24 человека, столкнувшихся с ней. Они могут рассказать друзьям и родственникам, как ужасно ваше приложение, и почему не стоит тратить на него время. Хотя исследование было опубликовано в далеком 1971 году, процент сообщающих бизнесу о проблемах пользователей вряд ли сильно изменился – однако сейчас те 24 человека, которые не сообщили вам о проблеме, говорят о ней друзьям в социальных сетях. Плохие новости могут стать вирусными и разрушить вашу репутацию.

С этой точки зрения профессионалы тестирования – это страховка от потери репутации.

4. Можно использовать стажеров или новичков.

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

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

Другая проблема со стажерами и новобранцами, далекими от тестирования, в том, что обычно они не владеют доменными бизнес-знаниями. Мало шансов, что они осознают, что им нужен доменный эксперт для объяснения, как должны работать наиболее сложные аспекты системы.

5. Протестировать может бизнес-аналитик / команда документирования / техническая поддержка

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

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

6. Пользователи проверят это за нас / у нас есть бета-программа

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

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

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

7. У нас нет времени / ресурсов для тестирования

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

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

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

8. Хороший квалифицированный тестировщик уйдет из тестирования

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

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

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

9. Мы не можем позволить себе найм тестировщиков

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

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

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

10. Тестировщики находят чересчур много багов

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

Большинство людей любит знать о проблемах и путях их решений заранее, если это возможно. Сколько раз вы жаловались, что застряли в пробке из-за дорожных работ, о которых не предупредили перед последним возможным для объезда поворотом? Лично я бухтел об этом неоднократно. Куда лучше сообщить людям о проблемах, которые вы не исправили, вместе с информацией об исправленных, чем ждать, пока они наткнуться на них, и извиняться.

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

Работа тестировщиков важна

Интернет переполнен информацией о компаниях и правительствах, пострадавших или разрушенных из-за недостаточного или отсутствующего тестирования. Компании вроде Knight Capital Group и Peak Hosting обанкротились из-за багов. В случае с Knight Capital Group разрушение прибыльного бизнеса заняло менее часа.

Бизнес принимает решения на основании издержек, рисков и потенциальной выгоды. Если существует риск потенциального банкротства, вопрос надо переформулировать – "Можете ли вы позволить себе не нанимать опытных тестировщиков?"

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