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

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

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

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

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

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

Некоторые пояснения:

  1. Они правильно резервируют исходный код в исходном элементе управления.
  2. Когда тестер обнаруживает преднамеренную ошибку, команда разработчиков просто игнорирует ее. Если тестировщик обнаруживает непреднамеренную (оригинальную) ошибку, команда разработчиков сначала проверяет, вызвана ли она какой-либо из умышленных ошибок. То есть команда разработчиков сначала пытается воспроизвести это в исходном рабочем коде и пытается исправить ее, если они могут.
  3. Просто игнорируйте проблемы взаимоотношений между QA и командой разработчиков. Я специально задал этот вопрос на Программисты , а не на Рабочее место . Подумайте, что между QA и командой разработчиков существует хорошая взаимопонимания, и они отправляются вместе после рабочего дня. Менеджер проекта - хороший, старый джентльмен, который всегда готов поддержать обе команды (Godsend).
260 голосов | спросил Krishnabhadra 28 Jpm1000000pmWed, 28 Jan 2015 13:56:26 +030015 2015, 13:56:26

21 ответ


454

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

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

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

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

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

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


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

ответил James McLeod 28 Jpm1000000pmWed, 28 Jan 2015 14:18:57 +030015 2015, 14:18:57
204

Хорошо, основываясь на том, что я узнал:

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

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

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

TL; др

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

ответил SparK 28 Jpm1000000pmWed, 28 Jan 2015 14:35:40 +030015 2015, 14:35:40
96

Плохая идея.

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

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

ответил Julia Hayward 28 Jpm1000000pmWed, 28 Jan 2015 14:26:21 +030015 2015, 14:26:21
56

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

  

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

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

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

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

ответил Paddy 28 Jpm1000000pmWed, 28 Jan 2015 18:53:34 +030015 2015, 18:53:34
50

Edit

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

Редактировать конец

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

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

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

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

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

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

ответил Scott Whitlock 28 Jpm1000000pmWed, 28 Jan 2015 15:29:17 +030015 2015, 15:29:17
28

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

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

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

ответил The Spooniest 29 Jpm1000000pmThu, 29 Jan 2015 15:16:33 +030015 2015, 15:16:33
27

Лично мне не нравится этот подход.

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

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

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

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

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

ответил Roger Rowland 28 Jpm1000000pmWed, 28 Jan 2015 18:01:04 +030015 2015, 18:01:04
23

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

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

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

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

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

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

ответил Schwern 29 Jam1000000amThu, 29 Jan 2015 06:52:56 +030015 2015, 06:52:56
20

Плохая идея.

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

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

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

ответил Michael Durrant 28 Jpm1000000pmWed, 28 Jan 2015 15:49:07 +030015 2015, 15:49:07
19

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

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

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

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

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

ответил Jay 28 Jpm1000000pmWed, 28 Jan 2015 21:33:46 +030015 2015, 21:33:46
14

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

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

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

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

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

ответил back2dos 28 Jpm1000000pmWed, 28 Jan 2015 16:09:04 +030015 2015, 16:09:04
9

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

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

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

в

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

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

ответил James Mishra 30 Jpm1000000pmFri, 30 Jan 2015 16:44:11 +030015 2015, 16:44:11
7

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

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

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

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

ответил Tom Au 28 Jpm1000000pmWed, 28 Jan 2015 17:40:57 +030015 2015, 17:40:57
7

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

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

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

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

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

ответил JeffO 28 Jpm1000000pmWed, 28 Jan 2015 18:25:29 +030015 2015, 18:25:29
7

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

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

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

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

ответил yoniLavi 29 Jam1000000amThu, 29 Jan 2015 04:18:04 +030015 2015, 04:18:04
4

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

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

ответил Chris Pratt 30 Jpm1000000pmFri, 30 Jan 2015 22:28:00 +030015 2015, 22:28:00
2

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

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

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

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

ответил Dominic Cronin 30 Jam1000000amFri, 30 Jan 2015 01:19:55 +030015 2015, 01:19:55
2

Одна вещь, о которой еще никто не упомянул: тестирование мутаций .

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

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

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

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

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

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

ответил MathematicalOrchid 17 PMpFri, 17 Apr 2015 16:27:49 +030027Friday 2015, 16:27:49
1

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

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

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

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

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

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

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

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

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

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

ответил Christian Hujer 2 FebruaryEurope/MoscowbMon, 02 Feb 2015 14:23:02 +0300000000pmMon, 02 Feb 2015 14:23:02 +030015 2015, 14:23:02
1

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

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


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


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

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


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

ответил DevSolar 4 FebruaryEurope/MoscowbWed, 04 Feb 2015 15:46:43 +0300000000pmWed, 04 Feb 2015 15:46:43 +030015 2015, 15:46:43
0

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

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

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

ответил Alexander 30 Jpm1000000pmFri, 30 Jan 2015 15:43:57 +030015 2015, 15:43:57

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132