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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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