Зачем позволять / не позволять разработчикам тестировать свою работу

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

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

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

Разработчики обычно работают с мышлением разработчика «как заставить это работать?» , Хороший тестер думает о том, "как это сломать?" - совсем другое мышление. Модульное тестирование и TDD действительно учат разработчиков менять шляпы в некоторой степени, но вы не должны на это полагаться. Более того, как отметили другие, всегда существует вероятность недопонимания требований. Поэтому окончательные приемочные испытания должны проводиться кем-то, кто находится как можно ближе к клиенту .

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

Разработчику будет трудно отстраниться от мышления «как это работает», а не «как это должно работать».

Из-за этого лучше привлечь кого-то с высокой степенью объективности для тестирования программы, например, QA или Test Engineers.

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

Разработчики ДОЛЖНЫ проверить свою работу. Это подразумеваемая ответственность.

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

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

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

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

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

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

Поработав с командой QA и без нее, я могу вам сказать, что на 100% ценю работу, которую они выполняют, и скажу, что они являются ценной частью команды разработчиков программного обеспечения. Когда у вас есть команда QA, это значительно облегчает выпуск вашего кода, потому что вы знаете, что он был тщательно протестирован, и это означает, что вы будете получать менее 3 часов звонков.

Разработчики должны тестировать свой собственный код.

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

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

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

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

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

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

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

Как разработчик, вы несете ответственность за свой собственный код, вы должны проверить его. Does the feature work as expected?Если ответ - да, все готово.

Почему бы вам не сделать тест-кейсы?

1. Вы субъективны , так как найденные ошибки написаны вами (или вашими коллегами).
2. Вы слишком дорого обходитесь компании для проведения кейс-тестов. (Я надеюсь).

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

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

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

Если вы ДЕЙСТВИТЕЛЬНО не хотите нанимать QA, попросите разработчиков написать тестовый код для других разработчиков. Это хороший первый шаг - вскоре вы увидите, что разработчики запрашивают ресурсы QA, потому что большую часть своего времени они тратят на тестирование чужого кода на наличие проблем, в дополнение к CR.

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

Методы и навыки тестирования тоже очень разные.

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

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

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

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

Следующий шаг - работа QAs, чтобы выяснить, что разработчики не видят, когда мы пишем код. Разработчик думает на более высоком уровне, но пользователь может не думать на том же уровне. Когда разработчик тестирует свою часть и ему нужно ввести какой-то текст в текстовое поле, он всегда может ввести полную строку, думая, что пользователь также сделает это. Может быть, пользователь тоже может это сделать, но случайным образом, когда он вводит в текст специальный символ, такой как% & $ ^, и это нарушает работу приложения, это плохо выглядит для конечного пользователя. Разработчик не может и не будет думать обо всех возможностях, которые могут возникнуть, потому что он не обучен так мыслить. Когда дело доходит до QA (тестера), они всегда думают о том, что может сделать пользователь, чтобы взломать это приложение и попробовать все глупости в книге, а не о глупых пользователях, но мы не должны ничего оставлять на волю случая.

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

Наконец, мы должны пройти UAT (User Acceptance Test), чтобы увидеть, соответствует ли то, что мы сделали, ожидаемым. Как правило, хотя требования проходят через BA, последний человек может не совсем точно знать, как он выглядит, и он / она может подумать, что это не то, что они ожидали, или они могут захотеть добавить что-то еще, чтобы он выглядел лучше, или по какой-то причине они могут отказаться от целая часть, поскольку они думают, что часть не пойдет с уже доступной функциональностью.

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

Комментарии выше поднимают большие моменты.

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

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

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

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

Программист при тестировании увидит текстовое поле с надписью «Количество» и введет «1». Затем опытный программист проведет дополнительный тест со значением «2».

Пользователь увидит текстовое поле с надписью «Количество» и введет «~~ unicorns ROX !!! ~~». Опытный пользователь также попробует "-12 1/2".

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

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

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

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

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

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

Он проверяется кем-то, кто не знаком с кодом, нравится вам это или нет. Вопрос в том, хотите ли вы, чтобы кто-то был вашим клиентом.

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

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

• Другие тестовые покрытия достаточно ... Существуют юнит-тесты, существует и используется среда интеграционных тестов, было выполнено тестирование пользовательского интерфейса, предварительное тестирование и т. Д. И т. Д. Тогда окончательный тест является менее строгим критерием приемлемости, чем финальный ». пробежать
• Существует набор тестовых примеров, написанных профессиональным SQA / Tester, которым кто-то (разработчик) может / должен явно следовать
• В противном случае риск отказа функции / продукта / модуля был снижен до низкого уровня (пусть профессионал проверит зоны высокого риска, а «новичок» - более низкий риск)
• Реальность бизнес-ситуации такова, что выпуск продукта с потенциальными дефектами лучше, чем задержка выпуска
• Разработчик, о котором идет речь, на самом деле тоже очень квалифицированный тестировщик и способен мысленно менять роли
• Это изменение представляет собой исправление ошибки, сделанное разработчиком в полевых условиях, когда сайт клиента закрывается или иным образом теряет доход из-за отключения системы (исправление, которое будет возвращено в офис и протестировано / выпущено в контролируемой версии как можно скорее). )

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

• Что-нибудь еще

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

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

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

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

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

Пора ИТ-индустрии перейти к более профессиональному подходу и внедрить процедуры для предотвращения тестирования вашего собственного кода.

• Каждый должен тестировать - тестовый код Develpers, функциональность теста QA'ers, обмен сообщениями о маркетинге. Таким образом, все придерживаются одной и той же философии и языка при тестировании, что является залогом успеха.

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

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

• Когда что-нибудь останавливается в производстве, делайте две вещи:

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

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

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

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