Кто должен писать тесты?

Ответ 1

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

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

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

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

Обновление

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

• некоторые люди могут не захотеть писать модульные тесты;
• Некоторые люди могут не знать, как писать хорошие модульные тесты, что может подорвать преимущества этого, и это может быть использовано как "доказательство", что тестирование устройства плохое;
• организация не может заставить людей работать вместе, а имеет четкие обязанности, такие как код кодеров, тест тестеров и т.д., которые могут заставить кого-то тестировать единицы;
• некоторые люди могут быть наняты для написания модульных тестов, поэтому, если эта роль не изменена, это противоречит написанию модульных тестов по вашему коду;
• может быть очень маленькая организация, которая может подразумевать неявное, что каждый делает немного всего;
• организация в целом не признает преимущества модульного тестирования, а скорее кода как-быструю, как возможно, и-дело-с-проблемами-позже,
• кто прилагает усилия для проведения модульного тестирования? Это один человек? Разработчики? Управление?
• может ли организация самостоятельно решить, кто выполняет модульное тестирование?

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

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

Ответ 2

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

Существуют различные типы тестирования:

• Тестирование устройств
• Тестирование интеграции
• Функциональное тестирование
• Нефункциональное тестирование - стресс, проникновение и многие другие типы.
• Тестирование приёма пользователей

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

Функциональное тестирование (системные функции как состояния спецификации) должно выполняться отдельной командой QA.

Нефункциональное тестирование может выполняться командой QA или архитектором/технологическим лидером.

UAT (система подходит для цели) должна выполняться клиентом.

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

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

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

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

Ответ 3

С TDD разработчик (прочитайте программиста или пару) должен написать тесты.

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

С BDD/ATDD должен быть задействован QA/PO.

BDD (Разработка с учетом поведения) и ATDD (тесты, основанные на приемочных испытаниях) обычно пишутся на менее гранулированном уровне. Лучшие тесты написаны с учетом заинтересованности. Таким образом, лучшие люди, чтобы написать это QA (Quality Assurance), POs (владельцы продуктов) или BAs (бизнес-аналитики). Чтобы не сказать, что разработчик не может их написать, вам просто нужно вступить в эту роль.

Красота работы в парах заключается в том, что, если ваша пара пишет тесты, есть автоматическая проверка работоспособности тестов по мере их написания.

Ответ 4

Неформальная политика в моей команде разработчиков

Каждый делает все.

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

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

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