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

267

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

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

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

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

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

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

  1. Они правильно создают резервную копию исходного кода в системе контроля версий.
  2. Когда тестировщик обнаруживает преднамеренную ошибку, команда разработчиков просто игнорирует ее. Если тестировщик обнаруживает непреднамеренную (оригинальную) ошибку, команда разработчиков сначала проверяет, вызвана ли она какой-либо преднамеренной ошибкой. То есть команда разработчиков сначала пытается воспроизвести это на исходном рабочем коде и пытается исправить это, если они могут.
  3. Просто игнорируйте проблемы взаимоотношений между QA и командой разработчиков. Я специально задавал этот вопрос программистам , а не на рабочем месте . Учтите, что между QA и командой разработчиков существует хорошая связь, и они работают вместе после рабочего дня. Менеджер проекта - хороший, старый джентльмен, который всегда готов поддержать обе команды (Godsend).
Krishnabhadra
источник
59
«Тест должен думать как разработчик» ... интересно. Я бы подумал, что очевидно, что тестер должен думать не как разработчик, а как пользователь.
Триларион,
12
Что произойдет, если намеренно введенная ошибка закрывает другую ошибку, которую могли найти тестеры, если бы эта намеренная ошибка не была введена? Например, предположим, что кусок кода имеет проблему с забором и что команда разработчиков не знает об этой ошибке. Программист решает вставить в это место преднамеренную ошибку. Теперь в коде есть ошибка двойного забора. Предположим, что тестеры обнаружат ошибку, но не увидят, что это ошибка двойного забора. Congrats! Тестеры обнаружили введенную ошибку. Исходный код будет восстановлен, чтобы содержать исходную ошибку забора. К сожалению!
Дэвид Хаммен,
20
Я КС. Я бы предпочел найти настоящие ошибки, спасибо. Я бы ушел из этой компании, как будто она в огне. Никто не может (намеренно) тратить мое время.
Арджун Шанкар
7
«Мы не делаем это в нашей фирме, но один из моих друзей говорит, что его технический директор попросил каждого менеджера по продукту добавлять дополнительные функции в начале каждого цикла разработки функций ...»
Марко,
3
Я подозреваю, что добавление преднамеренных ошибок создает риск. Что если преднамеренная ошибка на самом деле исправляет что-то непреднамеренное? О положительном побочном эффекте не сообщается, код удаляется, и через QA появляется реальная ошибка. По своей природе эти «преднамеренные ошибки» в последнюю минуту будут плохо рассмотрены, в противном случае ошибки тратят слишком много времени на разработку.
Джодрелл

Ответы:

462

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

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

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

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

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

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


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

Джеймс Маклеод
источник
17
Задача этого QA - найти ошибки - это не так; Это для обеспечения качества программного обеспечения. Это требует некоторого разъяснения. Выделение и устранение ошибок является одним из важных процессов при поставке качественного программного обеспечения.
Кришнабхадра
21
На самом деле, во многих компаниях работа QA заключается в поиске ошибок, и если в продукт были добавлены новые функции, а QA только что запускает тестовый набор, который не показывает никаких ошибок, я лично не буду доверять этому тестовому набору и ожидаю, что это будет неполным.
Док Браун
8
Я согласен, за исключением последнего пункта. Наличие состязательного подхода между QA и развитием (и бизнесом) в значительной степени неизбежно. У каждой группы есть свои желания и опыт. Как компания, они должны сбалансироваться, чтобы хорошо работать. По моему опыту, «хорошая игра» просто приводит к тому, что группы не настаивают на своей повестке дня, что приводит к стагнации или дисбалансу. Лучшие компании, которые я видел, были те, где развитие, контроль качества и деловая сторона настаивали на своих потребностях, но действовали как проверка для других, приводя к компромиссу в отношении лучшего баланса для компании.
Теластин
42
Я хотел бы добавить еще один момент: преднамеренная ошибка может скрыть истинную ошибку, которая появилась бы, если бы преднамеренная ошибка не остановила процесс (например, выбрасывая исключение).
nkoniishvt
30
Если бы я был специалистом по обеспечению качества и обнаружил, что трачу впустую свое время на изучение и документирование преднамеренно введенных ошибок, я бы нашел новую работу.
Кик
209

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

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

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

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

ТЛ; др

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

искра
источник
26
+1 Полностью согласен со всеми 4 пунктами, особенно с первым. Конкурентный подход, который приносят так много новых разработчиков, часто отражает их предыдущие 15 лет обучения - чрезвычайно конкурентную среду - в отличие от рабочего места, где сотрудничество было бы лучшим подходом.
Майкл Даррант
1
Очень предпочитаю этот ответ верхнему ответу.
Pharap
1
«QA предназначен не только для поиска ошибок, но и [...]» - я просто хочу сказать, что во многих местах термины «тестирование программного обеспечения» и «обеспечение качества» используются взаимозаменяемо. Да, это плохо. Там, где я работал, у нас был сотрудник, который использовал штат - на каждом собрании отдела контроля качества - здесь мы занимаемся не проверкой качества, а контролем качества. (Она имела в виду это как критику нашего отдела контроля качества.)
Марио
1. Это школа. Каждый день - школьный день. Если вы работаете в инженерной дисциплине, но не хотите учиться каждый день, вам следует уйти из моего офиса. Это также интервью. Производительность должна измеряться каждый день, чтобы убедиться, что отдел получает деньги. 2. Если моя карьера меня чему-то научила, так это то, что у QA есть умственные способности 14 лет. Они дети и должны управляться как стадо овец.
Gusdor
1. Это не школа в том смысле, что люди могут сотрудничать и не конкурировать друг с другом за оценки, нет такой вещи, как копирование вашей работы, поскольку задачи должны выполняться только один раз, и не стыдно просить помощи у коллеги. И 2. Если ваш QA настолько плох, ваша проблема в HR, и это те, кто должен выйти из офиса.
SparK
99

Плохая идея.

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

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

Джулия Хейворд
источник
32
Если они платят за ошибку, то это
BЈовић
12
"заинтересован, чтобы найти ошибки, которые вы знаете, есть" Отличная точка. Если организация делает это, это, вероятно, означает, что кто-то вдыхает шею людей, отвечающих за обеспечение качества, чтобы убедиться, что они обнаружили посаженные ошибки, так что это будет их главным приоритетом. Что, если они соберутся и скажут, скажем: «Привет, почти все ошибки в том, что не удается сохранить одно поле на экране редактирования с кучей данных» (или что-то в этом роде). Затем они потратят непомерное количество времени на поиск одного типа ошибок и увеличат вероятность того, что они пропустят другие типы ошибок.
Джей
Первое, что мне пришло в
Дэн Нили,
10
> Реальные жучки выходят за дверь. Я делал большие тесты. Вы начинаете с тезиса, что (нетривиальный) код всегда имеет ошибки. QA - это герои, которые находят их раньше, чем покупатель. Ошибки всегда есть. Если вы вводите искусственные ошибки, вы теряете время, которое вы могли бы потратить на поиск настоящих ошибок; Время на тестирование ограничено, вы снижаете качество, добавляя ненужную работу.
RedSonja
58

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Скотт Уитлок
источник
1
Комментарии не для расширенного обсуждения; этот разговор был перенесен в чат .
Яннис
Всем привет. Обсуждение становилось слишком длинным для комментариев. Как вы можете видеть из моего предыдущего (автоматического) комментария, я переместил все комментарии в отдельную комнату чата . Если вы хотите продолжить обсуждение ответа, пожалуйста, сделайте это в этом чате, а не здесь. Благодарю.
Яннис
3
Описанный подход может иногда использоваться для тестирования QA , а не как постоянный процесс.
Герлос
30

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

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

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

Ложка
источник
28

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

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

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

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

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

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

Роджер Роуланд
источник
1
Мне нравится идея обратной связи по питанию!
jxramos
23

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

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

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

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

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

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

Schwern
источник
Это был бы единственный способ сбора любых значимых данных. Но количество времени и усилий, которые потребуются для определения надлежащих тестовых случаев, чтобы получить значимые результаты, разрушит любой бюджет и график. И даже если бы вам дали бюджет и график, вам пришлось бы преодолеть препятствие, гарантирующее, что у вас есть квалифицированные специалисты, которые достаточно хорошо разбираются в статистике и программном обеспечении, чтобы иметь возможность определить надлежащий набор тестов. Я не думаю, что вы получите все это в одном проекте. Таким образом, в реальной жизни лучшее, что может сделать этот метод, - получить ошибочные, если не вводящие в заблуждение цифры.
Данк
1
Инъекции SQL является хорошим , чтобы сделать это для, как вы можете просто выбрать п операторов SQL в случайном порядке , чтобы «сломать»
Ян
1
Большая проблема заключается в том, что преднамеренные ошибки, как правило, будут сильно отличаться от проблем, которые вы получаете естественным путем - вы можете просто обучать свой QA думать, как программисты. Это в значительной степени разрушает весь смысл QA - иметь POV ближе к клиенту, чем к коду. Огромной частью QA является проверка работоспособности в отношении вещей, которые разработчики считают интуитивными (либо из-за незнания о незнании пользователей, либо из-за близости к коду, времени, потраченного на пользовательский интерфейс и т. Д.). Преднамеренные ошибки не являются хорошо распределенным образцом.
Луаан
20

Плохая идея.

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

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

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

Майкл Даррант
источник
7
Моя жена провела тестирование в течение 8 лет и просто уехала в dev - в основном из-за таких проблем с доверием. Это просто оскорбительно для тестера.
Брайан Бетчер
19

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

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

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

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

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

сойка
источник
Этот пункт о спецификации в "Два" является отличной аналогией.
Kyralessa
14

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

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

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

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

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

back2dos
источник
5
Если бы вы оставили это первое предложение, я получил бы +1, потому что все остальное хорошо :) Это просто ужасная идея, плохое - преуменьшение. Самый простой способ обеспечить подотчетность QA - отслеживать количество ошибок, попадающих в поле. Это само по себе позволит достичь ВСЕ, что заявляемый способ является его преимуществами.
Данк
@Dunk: Отслеживание этого числа не улучшит вашу команду автоматически, так же, как ведение счета в спорте не делает вас лучшим спортсменом, каким вы могли бы быть. На самом деле спортсмены тренируются , то есть выполняют искусственные задания, чтобы повысить свою производительность контролируемым образом, что мало чем отличается от того, что предлагается здесь. Если у вас нет идеи, как заставить людей улучшить это число, оно не имеет большой ценности.
back2dos
Я не утверждаю, что это что-то улучшит. Я только утверждаю, что он выполнит все, что будет достигнуто методом «вставки ложных ошибок», но без затрат и потраченного времени. Что он будет делать, так это дать указание, если через QA проходит слишком много дефектов. Если определено, что это так, то либо процесс, либо люди должны быть переоценены. Метод «ложная ошибка» не предоставляет больше информации, чем это, но на самом деле он предоставляет менее полезную информацию. Таким образом, ваши затраты выше за меньшую выгоду, используя метод «ложная ошибка». Как я уже сказал, ужасная идея.
Данк
@Dunk Тогда вы не правильно прочитали вопрос. Это говорит о том, что этот метод повышает моральный дух, а также основательность. Также количество ошибок, которые делают это через QA, не может надежно измерить эффективность команды QA. Это в равной степени зависит от того, сколько ошибок вносят разработчики. Если они начинают использовать TDD, и в выпуске внезапно уменьшается количество дефектов, что это говорит о тестерах? Ничего.
back2dos
@Dunk В отличие от этого, «ложная ошибка» на самом деле дает вам больше информации, исходя из предположения, что сложность их поиска не колеблется беспорядочно (что можно упорядочить). Поскольку вы знаете, сколько существует искусственных дефектов, вы можете точно сказать , какой процент из них был обнаружен в QA. Таким образом, вы получаете дополнительную информацию о том, насколько эффективен контроль качества при обнаружении искусственных дефектов. И это число, безусловно, больше связано с их общей эффективностью, чем тот, который вы предложили.
back2dos
9

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

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

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

в

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

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

Джеймс Мишра
источник
7

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

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

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

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

Том Ау
источник
1
Я думаю, что есть хорошие стороны в этом. Лучше найти ошибку, ДО того, как она выйдет в дикую природу, и я лучше нажму на свой внутренний QA (за что им все-таки платят?), Чем на внешние атаки. Охота на ошибки - это часть, и до тех пор, пока этот вид тестирования выполняется правильно, я не понимаю, почему он не может быть ценным.
WernerCD
1
Копия «оригинала» не может быть безошибочной и также по определению не проверена (потому что код был изменен для добавления ошибок).
Роджер Роуланд,
1
По моему опыту, жуки не являются изолированными животными и не сидят одни. Программное обеспечение является частью системы, и ошибки - преднамеренные или нет - влияют на систему . Если, конечно, мы не говорим о тривиальных частях программного обеспечения.
Роджер Роуланд,
18
Существует нулевое доказательство того, что этот метод найдет еще 1 дополнительную ошибку помимо намеренно вставленных ошибок. Нет никаких доказательств того, что это заставит QA работать усерднее, чтобы находить ошибки. Они могут попробовать меньше. Кроме того, поскольку вы потратили весь цикл выполнения процедуры приемочного тестирования во время тестирования намеренно неработающего кода (наш полномасштабный тест занимает 3 недели), теперь вам нужно повторно выполнить тест с действительным кодом, который будет развернут, поскольку Версия не является той же сборкой, поэтому ее тесты практически бесполезны для проверки «реальной» сборки.
Данк
6
Я предполагаю, что Паттон имел в виду, что вы должны проводить строгие тренировки и полевые учения в мирное время. Аналогия будет состоять в том, чтобы иметь строгие классы в ИТ-школе или после обучения. Я почти уверен, что Паттон не имел в виду, что офицерам следует дать указание стрелять в их собственные войска сзади, чтобы держать войска в напряжении!
Джей
7

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

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

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

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

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

JeffO
источник
Определенно согласен с этим, что приводит к появлению проблем, требующих внимания.
Адам Джонс
@AdamJohns - Вы никогда не узнаете наверняка, если не попробуете это проверить. Есть лучшие способы, так что это было бы почти последним средством для меня.
JeffO
7

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

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

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

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

yoniLavi
источник
4
Вместо того, чтобы разработчики «внедряли» ошибки в код, их время было бы гораздо лучше определять, как эти ошибки могли попасть в систему с самого начала, а затем исправлять код, чтобы эти ошибки не возникали или обрабатывались должным образом. программное обеспечение Цель разработки проекта не в том, чтобы протестировать систему обеспечения качества, а в том, чтобы создать работоспособную надежную и работающую систему, которая делает то, что ее пользователи хотят.
Данк
4

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

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

Крис Пратт
источник
2

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

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

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

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

Доминик Кронин
источник
2

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

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

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

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

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

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

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

MathematicalOrchid
источник
1

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

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

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

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

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

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

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

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

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

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

Кристиан Худжер
источник
1

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

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


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


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

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


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

DevSolar
источник
1
Это круговой аргумент. Вы говорите, что «заполнять ошибки в тестовой сборке неправильно, потому что разработчики не должны делать сборку с известным ошибочным кодом».
Доминик Кронин
@DominicCronin: Ничего особенного в этом нет. Все, что попадает в хранилище, должно быть наилучшего качества. Там есть целый ряд причин - исключение искусственного изменения строк кода - одна из них (в отношении svn blame и подобных функций репозитория). Опасность «забывания», чтобы снова устранить ошибку. Проблема в том, что тестеры в основном могли искать то, что было «посеяно», просматривая журнал изменений репозитория. Множество других причин, практически без пользы для противовеса. Но у меня заканчивается пространство, и в любом случае идея заключалась в том, чтобы представить одну , короткую причину.
DevSolar
@DominicCronin: Или, иначе говоря - там может быть случай , чтобы сделать для «затравки» ошибки, но линия должна быть притянута задолго до совершения , что в репо. А с другой стороны, в то время как имеющие «затравка» код для тестирования может иметь одну или две вещи для него, вы должны только когда - либо проверить покончила код. Две идеи - каждая из которых уже спорна сама по себе - просто никак не связаны между собой.
DevSolar
0

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

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

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

Александр
источник
2
кажется, это не дает ничего существенного по сравнению с замечаниями, сделанными и объясненными в предыдущих 16 ответах
комнат