Модульные тесты QA Engineer

Да.

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

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

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

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

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

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

Плохо:

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

Хорошо:

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

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

Есть тонкое, но важное различие между целью модульных тестов и тестов QA: QA-тестирование подтверждает функциональность; модульное тестирование подтверждает дизайн. То есть внешний вид противопоставлен внутреннему виду продукта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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