Должны ли разработчики отвечать за тесты, отличные от юнит-тестов, и если да, то какие из них наиболее распространены?

35

В настоящее время я работаю над довольно крупным проектом, и я использовал JUnit и EasyMock для довольно обширного функционального тестирования модулей. Теперь мне интересно, о каких других видах тестирования мне следует беспокоиться. Как разработчик, я должен беспокоиться о таких вещах, как функциональность или регрессионное тестирование? Есть ли хороший способ интегрировать их в инструменты, такие как Maven / Ant / Gradle? Они лучше подходят для тестера или бакалавра? Есть ли другие полезные виды тестирования, которые мне не хватает?

Джеки
источник
2
Несмотря на то, что на практике это упрощенно, масштабируйте до тех пор, пока это разрешено в вашей среде, оставаясь на практике разговорным, а не изолированным, как это обычно бывает. Воспринимайте команду «конец в конец» как нечто большее, чем сегрегацию и больше как набор навыков, каждая команда представляет различные наборы навыков, которые следует использовать для достижения полного успеха. Команда должна нести ответственность за успех которых необходимы испытания для достижения. То, как они решаются в отношении реализации, - это просто детали реализации, основанные на наборе навыков.
Аарон Макивер
1
Ответ на этот вопрос также будет зависеть от уровня квалификации других членов команды. Например, в команде, где QA не обладает сильными навыками программирования, разработчики могут сделать больше, чем в команде, где QA может написать свои собственные тесты.
Неонтапир
Хороший критерий - насколько автоматизированы тесты. Программисты умеют автоматизировать вещи с помощью кода.
Rwong

Ответы:

44

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

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

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

Итог: вы должны нести ответственность за доставку высококачественного кода. Если это означает, что вам нужно написать некоторые функциональные или регрессионные тесты, сделайте это.

Брайан Оукли
источник
Я полностью согласен с частью кода высокого качества. Я имел в виду больше хорошего и хорошего кода. Например, изменения, которые в вашей перспективе считаются «свободными от ошибок», имеют отрицательную производительность где-то еще. Лучший пример, который я могу придумать, - это то, что требование не проверено должным образом на нагрузку. Таким образом, мой код вызывает проблемы с нагрузкой на сервер, даже если он «не содержит ошибок» (хорошо, так что можно поспорить, что это не так, но приколите меня). PS Я думаю, что ваша часть доверия является ключевой здесь.
Джеки
10
Вы несете ответственность за предоставление кода без дефектов. Ответственность за построение того, о чем просили, лежит на разработчике . Дефекты могут возникать и возникать из-за плохо собранных / интерпретированных требований, проблем окружающей среды в данном развертывании, конфликтов в ОС и т. Д. Если анализ основных причин не выполняется для каждого дефекта, бездефектный код для бизнеса означает, что они ожидают это делать то, что ожидает пользователь, и все, что меньше, является дефектом. Нереально предполагать, что разработчик может оставаться вовлеченным на протяжении всего SDLC, чтобы просто повысить доверие; это не будет масштабироваться.
Аарон Макивер
2
«Тестирование программы может быть очень эффективным способом показать наличие ошибок, но безнадежно неадекватно, чтобы показать их отсутствие». - Эдсгер В. Дейкстра, «Смиренный программист» (лекция премии Тьюринга), 1972.
Джон Р. Штром
1
«Вы несете ответственность за предоставление кода без дефектов». это сказочная страна. Вы можете предоставить то, что требует область, но крайние случаи и интерпретации бизнес-логики делают ваше заявление невозможным для выполнения. Как вы думаете, почему у каждой основной версии программного обеспечения есть выпуски, исправления и т. Д. Потому что мы все несовершенны, включая бизнес-логику.
Джейсон Себринг
4
Будут ли счастливы все, кто не согласен с первым предложением этого ответа, если Брайан сформулирует это так: «Ваша цель - создать код без дефектов»?
Carson63000
13

Это может помочь вам:

Agile тестирование квадрантов

Q1 написаны разработчиками.

Q2 автоматизированы разработчиками и написаны в сотрудничестве с бизнесом и / или тестерами.

foobarcode
источник
Разработчики также часто участвуют в тестировании Q4.
Неонтапир
Связанный файл больше не может быть найден.
Душан Рихновский
3

Есть ли другие полезные виды тестирования, которые мне не хватает?

Есть приемочное тестирование, для которого я бы порекомендовал фреймворки в стиле BDD, использующие язык Gherkin: JBehave (Java), Cucumber (Ruby), Behat (PHP) и т. Д. Этот тип тестирования имеет некоторые преимущества перед модульными тестами:

  • Тесты легко читаются не разработчиками, поэтому вы можете показать их клиентам
  • Тесты четко описывают бизнес-процессы, не вдаваясь в детали реализации (я не имею в виду, что реализация не важна - она, безусловно, есть - но лучше, когда вы отделяете бизнес-требования от самого кода)
  • Тесты делают то, что пользователи будут делать с помощью вашего приложения
  • Их легче написать (ИМХО, может зависеть от языка и структуры): без насмешек, меньше технических деталей
scriptin
источник
3

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

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

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

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

Пабло ласкано
источник
2

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

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

Но это работа команды, а не только вашей.

nunomvbarreiro
источник
1

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

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

m3th0dman
источник
1

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

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

Если ваш вопрос полезен для отслеживания ошибок, мне нравятся bugzilla, google docs, zendesk или basecamp с точки зрения систем связи.

Джейсон Себринг
источник
1

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

Одним из вопросов является эффективное использование времени разработчиков.

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

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

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

Steve314
источник
0

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

Хонус Вагнер
источник
Я думаю, что я пытаюсь достичь того, что считается эффективным "молотком".
Джеки
Это определенно субъективно. Я бы сказал, что любой тип теста применим к вашему проекту (конечно, не все типы тестов применимы ко всем проектам). Вот достойный список: softwaretestinghelp.com/types-of-software-testing . Конечно, то, что вы делаете сами и от чего отказываетесь, зависит от вашего времени, ресурсов и способностей. Например, вы не сможете выполнить приемочное тестирование, поскольку существуют определенные правила, которым должен следовать только пользователь. Короче говоря, делайте все, что возможно, за то время, которое у вас есть.
Хонус Вагнер
Для моих проектов, которые в основном являются веб, я обычно пытаюсь охватить юнит, функциональность, удобство использования, регрессию, производительность, несмотря ни на что. Если у меня есть время, я выбираю «Белый ящик», «Стресс», «Совместимость», даже «Принятие», если знаю достаточно. Мой общий стиль кодирования чрезвычайно ориентирован на производительность, поэтому я снижаю свой приоритет. Ничто из этого не означает, что QA не найдет что-то неправильное ни в одном из этих типов тестов, это просто означает, что они найдут меньше и сделают намного более легкий раунд 2.
Хонус Вагнер
0

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

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

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

Мишель Кэннон
источник
1
Единственная проблема, с которой я сталкиваюсь, заключается в том, что между разработчиками и группой тестирования должна быть определенная степень изоляции, в противном случае группа разработчиков будет заражена мнением разработчика "код работает". QA и разработчики преследуют противоположные цели; разработчик пытается заставить его работать, в то время как команда QA пытается сломать его, и разработчик не всегда имеет лучший взгляд на актуальность теста.
Роберт Харви
Я не согласен на сто процентов, но с другой стороны, в последнее время я был связан с мобильными приложениями, и я думаю, что они требуют уровня интеграции, немного превышающего традиционный. Обратите внимание, я использую термин интеграция. может быть изоляция, но обе команды должны рассмотреть и внести свой вклад в контрольные примеры. Маловероятно, что разработчики будут иметь доступ ко всем необходимым ресурсам тестирования для проведения надлежащего тестирования, также маловероятно, что тестировщики будут иметь знания для разработки тестовых примеров для чего-то более продвинутого, чем потоковое видео по сотовым сетям. слишком много изоляции = проблемы.
Мишель Кэннон
Кроме того, я думаю, что чем более вертикальным будет рынок и более специализированным, тем больше интеграции между командами. на самом деле каждый должен перейти на фазу тестирования с понятием, что код работает в некоторых тестируемых условиях, но, скорее всего, имеет недостатки, чем нет
Мишель Кэннон
Кажется, что это работает, команда тестирования создает документ варианта использования, используя функциональную спецификацию. Команда разработчиков рассматривает документ по применению на основе технических и функциональных спецификаций и при необходимости добавляет кейсы. Команда тестирования разрабатывает сценарии тестирования из вариантов использования. Разработка тестового обзора тестовых случаев. Конечно, отнимает много времени, но лучше, чем тестирование на этапе развертывания или производства.
Мишель Кэннон