Оставляя преднамеренные ошибки в коде для тестировщиков, чтобы найти

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

1. Непосредственно перед тем, как продукт перейдет в QA, команда разработчиков добавляет несколько случайных ошибок в случайных местах кода. Они должным образом сохраняют исходный рабочий код, чтобы убедиться, что эти ошибки не поставляются с конечным продуктом.
2. Тестеры также проинформированы об этом. Таким образом, они будут проверять, потому что они знают, что есть ошибки, и что их отсутствие может рассматриваться как признак некомпетентности.
3. Если найдена ошибка (преднамеренная или иная), о ней будет сообщено команде разработчиков для исправления. Затем команда разработчиков добавляет еще одну преднамеренную ошибку в соответствующий раздел кода непосредственно перед тем, как продукт попадает в QA второго уровня. Менеджер проекта говорит, что тестер должен думать как разработчик, и он / она должен ожидать новых ошибок в разделах, где были внесены изменения.

Ну, так оно и есть. Они говорят, что у этого подхода есть следующие преимущества.

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

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

Некоторые уточнения:

1. Они правильно создают резервную копию исходного кода в системе контроля версий.
2. Когда тестировщик обнаруживает преднамеренную ошибку, команда разработчиков просто игнорирует ее. Если тестировщик обнаруживает непреднамеренную (оригинальную) ошибку, команда разработчиков сначала проверяет, вызвана ли она какой-либо преднамеренной ошибкой. То есть команда разработчиков сначала пытается воспроизвести это на исходном рабочем коде и пытается исправить это, если они могут.
3. Просто игнорируйте проблемы взаимоотношений между QA и командой разработчиков. Я специально задавал этот вопрос программистам , а не на рабочем месте . Учтите, что между QA и командой разработчиков существует хорошая связь, и они работают вместе после рабочего дня. Менеджер проекта - хороший, старый джентльмен, который всегда готов поддержать обе команды (Godsend).

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

• Это QA не будет усердно работать, если они не знают, что их проверяют каждый день (что не может быть хорошим для морального состояния)

• Что не хватает непреднамеренных ошибок в программном обеспечении для QA, чтобы найти

• Задача этого QA - найти ошибки - это не так; это для обеспечения качества программного обеспечения производства

• То, что такая битва умов между разработкой и QA в некотором роде полезна для компании - это не так; все сотрудники должны работать вместе против конкурентов компании, а не друг против друга.

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

Чтобы расширить мое описание «работы QA:» QA определенно должен находить ошибки - и в коде, и в их тестовых наборах - как артефакт выполнения своей работы, но роль не должна быть определена как «вы должны найти ошибки «. Должно быть, «вы должны поддерживать наборы тестов в актуальном состоянии, чтобы учесть новые функции и обеспечить весь охват тестирования. Если это не приводит к обнаружению ошибок, то процедуры тестирования недостаточно сложны для продукта.

Ну, исходя из того, что я узнал:

1. Это не школа и не собеседование;
2. Тестеры не дети;
3. Это не игра;
4. Это пустая трата денег компании.

QA не только для того, чтобы находить ошибки, но и для того, чтобы беспокоиться о том, насколько интуитивно понятна система, какова кривая обучения для пользователя, удобство использования и доступность в целом. Например: « Уродлива ли система ?», «У пользователя дальтонизм, а материал красный и зеленый?» Они тоже должны жаловаться.

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

ТЛ; др

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

Плохая идея.

С точки зрения тестера: «Таким образом, они будут испытывать тяжело, потому что они знают, что есть ошибки, и их отсутствие может рассматриваться как их некомпетентность». По сути, разработчики заминируют код. Мало кто любит выполнять работу, которая в конечном итоге бессмысленна (потому что ошибки известны заранее), но все же влияет на их восприятие. Если есть материальные наказания за то, что не нашли мины-ловушки, тем более. И знаете ли вы, что тестеры процветают, обнаруживая ошибки? Это звучит как токсичная конфронтационная среда; QA должен быть доволен, если проверяемый код имеет высокое качество. Хотя, если они заплатили за ошибку ... http://thedailywtf.com/articles/The-Defect-Black-Market

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

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

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

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

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

3. Я полагаю, что это просто научит ваших тестеров думать так же, как ваши разработчики (то есть, как Том добавил бы ошибку здесь), что, вероятно, снизит вероятность обнаружения ошибок, о которых Том не думал.

редактировать

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

Конец Править

Есть веская причина проверить, действительно ли ваше тестирование / проверка работает. Позвольте мне привести пример с производства, но принцип тот же.

Обычно при подаче материала через машину устройство подачи может не проталкивать материал достаточно далеко. Это называется «короткой подачей», и для предотвращения этого мы могли бы установить «датчик короткой подачи» (обычно датчик типа сквозной балки, который заблокирован материалом). Этот датчик обнаруживает конец материала, когда он достигает полной длины подачи. В определенный момент цикла машины мы проверяем, что датчик заблокирован, и останавливаем машину, если проверка не удалась.

Теперь вам нужно подумать о том, как сам тест может провалиться. Например, некоторая грязь или другой мусор могут заблокировать датчик, и он всегда будет сообщать «ОК» и никогда не останавливать машину. Кроме того, характер датчика заключается в том, что приемник включается, когда луч попадает на него, поэтому в зависимости от типа установленного датчика электрически вы получаете вход «ВКЛ», когда датчик не заблокирован . Это означает, что в случае обрыва кабеля, потери питания на этом датчике или сбоя входа логика вашей программы будет показывать «ВЫКЛ», а это будет означать «заблокирован» или «ОК».

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

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

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

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

• Это демонстрирует принципиальное отсутствие понимания концепции обеспечения качества . Тестеры не должны думать как разработчики: они должны думать как конечные пользователи. Основная причина наличия команд QA заключается в том, что разработчики по своей природе слишком близки к коду; QA должен поддерживать достаточное расстояние от кода, чтобы они могли поймать то, что пропустили разработчики.
• Это пустая трата усилий QA . Предполагая, что эти ошибки не являются тривиальными - смотрите ниже, когда они есть - это означает, что QA тратит время и ресурсы на изучение уже известных вещей, когда они могли бы тратить эти усилия на поиск того, что неизвестно.
• Это пустая трата усилий разработчика . Чтобы люди, отвечающие за обеспечение качества, могли поймать эти нетривиальные ошибки, разработчики должны сначала написать их. Это требует еще больших усилий, затраченных не только на кодирование ошибок, но также с учетом требований к программному обеспечению и дизайна.
• Это подвергает производство ненужному риску . Это только вопрос времени, когда изменения не будут объединены должным образом.
• Если это не делает выше, то это бессмысленно . Если все известные ошибки тривиальны, то они не поймают некачественных работников: они поймают только людей, которые вообще не работают. Есть лучшие способы сделать это.
• Это отравляет рабочую среду . Ваши тестеры QA являются профессионалами. Им следует доверять, чтобы они были профессиональными, пока не будет реальной причины подозревать обратное. Когда есть основания подозревать , в противном случае, должно быть надлежащее расследование вместо этих интеллектуальных игр. Все остальное убивает мораль.

Шутки в сторону. Даже если паранойя премьер-министра окажется обоснованной в данном конкретном случае, это не тот, кто имеет каких-либо бизнес-тестеров.

Лично мне не по себе от такого подхода.

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

Любые изменения кода (преднамеренные или иные) могут привести к побочным эффектам. Эти побочные эффекты могут быть хорошо обнаружены во время тестирования, но это может не быть очевидным (даже для разработчика, который установил ошибку), какова основная причина. Это не кажется «безопасным», если вы знаете, что я имею в виду (я говорю здесь изнутри).

Кроме того, тестер будет тратить много времени на тестирование кода, который фактически не будет выпущен. По моему мнению, после того, как намеренные ошибки будут удалены, следует в любом случае провести повторную проверку. Вот и весь смысл тестирования. Что - то меняется, что - нибудь , и вы повторно проверить все . Хорошо, я знаю, что на практике такого никогда не бывает, но это и есть регрессионное тестирование.

Так что, в целом, не убежден.

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

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

В простейшем случае, допустим, вы заполняете 100 ошибок, и они представляют полный диапазон реальных ошибок (я знаю, вряд ли, но я упрощаю). Вы не говорите QA, что делаете это, чтобы не испортить эксперимент. В конце процесса QA скажем, что они нашли 60 из 100 отобранных ошибок (и других реальных ошибок). Теперь вы знаете, что QA находит 60% ошибок.

Вы можете расширить это, посчитав количество обнаруженных реальных ошибок и применив коэффициент поддельных ошибок. В нашем примере, если QA обнаружило 200 реальных ошибок, вы можете заключить, что они нашли только 60% из них, поэтому осталось 133.

Конечно, это только общая оценка с огромными барами ошибок. Писать реалистичные, репрезентативные ошибки сложно. Ошибки, которые вы пишете, вероятно, будут легче найти в QA, потому что разработчики обучены не писать ошибок. Может быть лучше имитировать класс ошибок, таких как ошибки «один за другим», ошибки Unicode, переполнения буфера и так далее.

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

Это показатель , и его не следует использовать как инструмент управления мотивацией.

Плохая идея.

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

Такое мышление сочетается с тем, что QE являются только ручными тестировщиками и не мотивированы для понимания реального тестируемого кода.

Я старший QE, и это знакомая проблема в большинстве организаций, в которых я работал.

Я бы сказал, плохая идея.

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

Второе: он посылает тестерам четкое сообщение о том, что программисты и / или руководство считают, что они не выполняют свою работу и должны рассматриваться как дети. Я не могу себе представить, что это хорошо для морального состояния. Как программист, если мне давали двусмысленные или противоречивые спецификации для программы, и мне приходилось тратить кучу времени на их разъяснение, а затем, потратив часы или дни, мой босс сказал мне: «О, да, я намеренно сделал противоречивые заявления в спецификации, чтобы удостовериться, что вы действительно их читаете », думаю, я был бы очень раздражен. Если бы это происходило регулярно, этого вполне могло бы заставить меня искать другую работу.

В реальной жизни все, кроме самых тривиальных изменений кода, будут иметь ошибки. У меня никогда не было проблем с успокоением тестеров, потому что первый набросок кода, который им давали, был на 100% идеальным. Мне приходилось иметь дело с ленивыми тестировщиками, которые не выполняют адекватную работу, но они этого не понимали, потому что программисты были настолько совершенны. Лучший специалист по тестированию, с которым я когда-либо работал, однажды сказал мне, что в новом выпуске программного обеспечения он поставил перед собой личную цель - найти 100 ошибок. Хорошо, то, является ли 100 реалистичным числом, зависит от того, насколько велик продукт и насколько велики изменения, но в нашем случае ему почти всегда удавалось достичь этой цели. Иногда ему приходилось растягивать вещи, например, называть неправильно написанное слово в сообщении «ошибкой», но эй, это нужно было исправить.

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

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

1. Сделайте так, чтобы QA отчитывалось за качество любым возможным способом. Например, поддерживая их ответственность также. Это повысит их мотивацию, чтобы убедиться, что поставляемая продукция имеет более высокое качество. Всегда требуется меньше усилий, чтобы самостоятельно обнаружить неадекватность (ошибка, явно отсутствующая функция, нелогичное поведение), а затем попытаться понять, что пытается объяснить ваш расстроенный пользователь. А возложение части этой ответственности даже на разработчиков может повысить их мотивацию, чтобы помочь QA сделать свою работу как можно лучше.

2. Имейте несколько команд QA, которые могут конкурировать. Вы должны найти разумную метрику, конечно. Определенно не только количество вопросов. Фактор серьезности дефекта или деловой ценности (как определено заинтересованными сторонами) предложенных улучшений должен помочь.

Трудно сказать, достаточно ли хорош QA. В долгосрочной перспективе легче и, возможно, даже лучше найти способы, которыми QA «когда-либо улучшается».

Тем не менее, есть одна проблема, о которой следует знать, если вы вводите преднамеренные ошибки: откуда вы знаете, что «правильный» код вообще когда-либо был правильным? После второго QA вы удаляете все преднамеренные ошибки, которые не были обнаружены. Нет никакого способа узнать, что вы не просто заменяете их кодом, который нарушен другим способом, или что вы не разрешаете нарушенное поведение, которое раньше было недоступно (преувеличенный пример: некоторые диалоги не открывались из-за преднамеренной ошибки, но сам диалог не работает - вы просто не узнаете, потому что тестеры его не увидели).

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

Это называется мутационным тестированием . Идея состоит в том, чтобы использовать программное обеспечение для автоматизации создания небольших изменений в исходном коде (называемых мутантами). Изменения предназначены для создания различного поведения, например, мы могли бы изменить

if x < 10:
    print "X is small!"

в

# we flipped the inequality operator
if x > 10:
    print "X is small!"

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

Мне нравится эта идея. Это был генерал Паттон, который сказал: «Чем больше вы потеете в мире, тем меньше вы истекаете кровью на войне».

Ввод преднамеренных ошибок "пустая трата времени" тестеров. Но это также заставляет их работать усерднее, а это означает, что они также будут лучше выполнять поиск непреднамеренных ошибок. (И у вас есть копия «оригинала», так что вам не придется жить с тем, что вы сделали.)

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

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

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

Положительный результат - команда QA усердно работает над поиском ошибок. Кто знает, может быть, они считают это проблемой. Это дружеская игра. Или они просто делают, потому что за ними наблюдают (Эффект Хоторна?).

Отрицательный результат - они могут не работать усерднее и все равно найти ошибку. QA считает это мелким и враждебным. Так что теперь они переходят к поиску гипер-ошибок и возвращают всевозможные мелкие проблемы. Этот шрифт не отображается должным образом, когда я делаю снимок экрана и конвертирую его в PDF и просматриваю его с 500%.

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

Мы все могли бы согласиться, что это не будет работать 90% времени. Это не очень хорошо для остальных 10%. Проверьте вещи для себя. Довольны ли клиенты выпуском, в котором есть преднамеренные ошибки в коде? Влияет ли это на моральный дух работников и производительность труда в других областях? Увеличить оборот? Вы говорите нам.

Исходя из мира, в котором разработчики должны сами писать и запускать тесты, этот «тестовый» «QA» бункер, на который вы ссылаетесь, пугает и смущает меня, поэтому я постараюсь ответить с этой точки зрения. Кроме того, квалифицированные инженеры по обеспечению качества, с моей точки зрения (как это хорошо описано в ответе @ SparK), должны сосредоточиться на более широких вопросах обеспечения того, чтобы программное обеспечение полностью удовлетворяло истории пользователей и имело общее «качество» (в отношении домен, для которого предназначено программное обеспечение), вместо поиска ошибок.

Меня привлекло упоминание @ JamesMcleod о «инъекции дефекта» в комментариях к вопросу. Я на самом деле считаю, что если разработчики думают, как они могут вносить ошибки в систему, это отличная идея для углубленного изучения концепции защиты. Ни одной ошибки не должно быть достаточно, чтобы остановить всю систему неконтролируемым образом (без четкой регистрации действий), вызвать повреждение данных или само по себе выявить уязвимость безопасности.

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

Связанная опция - это использование флагов функций, чтобы преднамеренно отключить функции в определенных компонентах, чтобы проверить, как другие компоненты справляются с этим. Я также хотел бы настоятельно рекомендовать прочитать бесплатную книгу / статью «Обучение от первых респондентов: когда ваши системы должны работать», в которой описывается такое обширное тестирование программной инфраструктуры, которое будет использоваться командой Обамы для выборов 2012 года.

Как уже говорили другие, задача QA - не искать только ошибки. Я бы пошел дальше и сказал, что это не их работа, технически. Разработчики должны нести ответственность за сохранение своего кода без ошибок. Наборы тестов должны быть запущены до того, как новый код когда-либо будет зафиксирован, и, если наборы тестов не пройдены, то он никогда не должен делать это в QA. Преднамеренное внесение ошибок означает, что вы определенно не можете пройти тесты, так почему ваш код идет в QA?

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

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

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

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

Тем не менее, знания - это сила, и без этой техники у вас будет еще меньше представления о качестве вашей кодовой базы. Если вы можете реализовать это с уважением и по правильным причинам, я бы сказал: «Почему бы и нет?»

Еще никто не упомянул: тестирование на мутацию .

Именно здесь автоматизированный инструмент берет ваш исходный код и намеренно вставляет в него ошибки. (Например, удалите случайно выбранный оператор, измените И на ИЛИ или что-то еще.) Затем он запускает ваш полный набор тестов и проверяет, пройдены ли тесты.

Если все тесты пройдены, то есть две возможности:

• То, что было изменено, ничего не делает. Другими словами, у вас есть мертвый код.
• Изменение внесло ошибку, которую ваш тестовый набор не улавливает. Вам нужно больше тестов.

Обратите внимание, что, в отличие от вашего предложения, все, что я описал выше, автоматизировано . Вы не тратите время разработчиков, вставляя бессмысленные ошибки вручную. И вы не тратите время тестировщиков на поиск известных ошибок. Единственное, что вы используете, это машинное время, которое намного дешевле. (Машины не устают делать один и тот же тест 20 000 раз. Люди перестают заботиться через некоторое время!)

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

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

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

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

Затем вы можете намеренно нарушить производственный код, чтобы проверить, работают ли тесты.

Есть несколько уровней, на которых это возможно:

• Разработчик, который только что провел рефакторинг какого-либо модульного теста, может нарушить производственный код, чтобы убедиться, что модульный тест все еще находит то, что должен найти.
• Тестер, который только что провел рефакторинг какого-либо приемочного теста, может нарушить производственный код, чтобы убедиться, что приемочный тест все еще проверяет то, что он должен проверять.
• Если интерфейс является стабильным и достаточно надежным (т. Е. Основанным на протоколах), компания может захотеть сохранить набор известных неисправных версий продукта и запустить их тестирование для регрессионного тестирования теста.

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

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

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

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

Концепция преднамеренного введения ошибок в производственный код называется саботажем , а введенная ошибка называется диверсантом .

Тестировщик, который не берет код для тестирования непосредственно из хранилища, делает это неправильно. (1)

Разработчик , который проверки в заведомо ошибочном коде в хранилище делает это неправильно. (2)

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

(1) Потому что вам нужно документировать, какую версию вы тестировали. Вы можете проверить версию, помеченную хешем Git или номером ревизии SVN, а «код, который дал мне Джо», - нет.

(2) Потому что вы просто этого не сделаете, за пределами тестового драйвера, который ожидает сбой.

Это попытка по кратчайшей возможной причине «шага лифта», которая должна иметь непосредственное значение как для разработчиков, так и для тестеров и менеджмента.

Я рекомендую против преднамеренного внедрения ошибок в КАЖДУЮ сборку, которую вы отправляете в QA.

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

Если они находят больше нерабочих ошибок в крайнем случае, чем вы записали, то, конечно, не ваш QA нуждается в надзоре ... ;-)