Юнит-тестирование инженером QA

Question

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

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

Как вы думаете, это плохая идея освободить разработчика от написания юнит-тестов таким образом?

Answer 1

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

Answer 2

Существует небольшая, но важная разница между намерениями модульных тестов и тестов QA: Тестирование QA подтверждает функциональность; модульное тестирование подтверждает проект . То есть внешний вид контрастирует с внутренним видом продукта.

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

Следовательно, совершенно естественно, что разработчики, а не сотрудники QA, пишут юнит-тесты.

Answer 3

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

Bad:

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

Хорошо:

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

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

Answer 4

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

Может быть, вы слышали о TDD ? «Test Driven Development» - действительно хорошая практика для разработки. Его основная цель - разработка модульных тестов перед написанием реального кода (что странно, когда мы начинаем использовать TDD, я признаю) ...

Answer 5

Да.

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

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

Answer 6

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

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

В своем вопросе вы сказали, что у вас был один человек, выполняющий юнит-тестирование. Хорошее модульное тестирование требует больших усилий в зависимости от требуемого покрытия тестами. Это где-то от 50% до 100% уровня усилий команды разработчиков. Один человек, тестирующий много кода разработчиков, будет полностью ошеломлен.

Answer 7

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

Однако для того, чтобы пройти модульное тестирование, код должен быть тестируемым; что он может сделать, если код, который он получает, не тестируется? Переписать это? Рефакторинг это? Без юнит-тестов?

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

Answer 8

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

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

Answer 9

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

С другой стороны, я считаю, что QA должно оставаться как можно ближе к юнит-тестированию. QA нуждается в хороших отношениях с разработчиком и пытается понять дизайн кода. Зачем? Когда разработчик пишет модульные тесты, основное внимание по-прежнему уделяется разработке, а не тестированию. Вы не можете доверять (не в плохом смысле) разработчику, чтобы он придумал лучшие тестовые случаи и что у него есть хорошее освещение. Поскольку QA специализируется на тестировании, может быть хорошей идеей держать QA и dev как можно ближе во время модульного тестирования.

Answer 10

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

Проводит ли специалист по QA реорганизацию кода, чтобы сделать его тестируемым?

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