Может ли QA быть эффективным без модульного тестирования (TDD)?

Ответ 1

Как указано в комментарии выше, TDD не совпадает с тестированием модуля.

Мой совет:

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

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

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

Ответы:

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

Ответ 2

Проблема с именами Test-driven development и unit-testing заключается в том, что они подразумевают, что они касаются тестирования программного обеспечения. Они не. TDD и модульное тестирование составляют дизайн, и они являются ответственностью разработчиков.

Роль аналитика QA по-прежнему имеет первостепенное значение для любой команды, занимающейся TDD, и это будет долгим, долгим временем, прежде чем вы окажетесь вне работы в качестве добросовестного QA!

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

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

Ответ 3

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

Если вы пытаетесь модифицировать тесты в существующем приложении,

• начать с автоматизации сценариев ядра как приемочных тестов GUI (я предполагаю, что ваше приложение не тестируется под кожей, потому что оно было спроектировано таким образом. Если бы это было так, тогда API тесты быстрее и проще писать).
• После того, как у вас есть поведение приложения, связанное с некоторыми тестами (защитная сетка), вы можете приступить к рефакторингу, который вам не нравится. Попросите разработчиков согласиться с тем, что весь новый код должен быть проверен с помощью модульных тестов.
• Если у вас есть период ожидания, и вы решили использовать его для улучшения охвата тестирования: найдите основные компоненты, используемые в большинстве частот, и , чтобы они были покрыты пакетом unit test. Проведите свой путь извне. (Не делайте ошибку, когда QA пишете пост-факто единичные тесты для (существующего/нового) кода, о которых они мало что знают.) Тестирование модулей /TDD не является чем-то вы можете забрать за неделю, особенно в среде устаревшего кода.

Со временем внесите TDD в цикл разработки. Это гарантирует, что ошибки, которые могут быть обнаружены на более низких уровнях, действительно пойманы, и у QA есть время, чтобы протестировать ad-hoc, удобство использования, производительность и т.д.

Ответ 4

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

Ответ 5

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

Они жалуются на вопрос Black box vs White box Testing
Ответ cschol сообщает:

• "Тестирование White Box равно Программному обеспечению Unit Test. Разработчик или тестер уровня развития (например, другой разработчик) гарантирует, что написанный им код работает должным образом в соответствии с подробными требованиями к уровню, прежде чем интегрировать его в систему.

  Тестирование Black Box равно Тестирование интеграции. Тестер гарантирует, что система работает в соответствии с требованиями на функциональном уровне.

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

Генн отвечает:

• "Тщательный unit test будет ловить дефекты на стадии разработки, а не после того, как программное обеспечение будет интегрировано в систему. Тест черного ящика на уровне системы обеспечит правильное поведение всех модулей программного обеспечения при объединении. A unit test in этап разработки не поймал бы эти недостатки, поскольку модули обычно разрабатываются независимо друг от друга"

Итак, домен QA - это черный ящик или интеграционное тестирование. Тестирование белого ящика или модульное тестирование - это область разработчиков/разработки.
Даже высококвалифицированные тестеры-программисты не могут писать модульные тесты или разрабатывать a-la-TDD вместо разработчиков.

Обновление:
Ну, может быть, я не сформулировал вопрос хорошо, но меня действительно смутило понятие создания группы QA, которое также было обвинено в жгутах unit test.
Я думаю, что нашел свой ответ в [1], который дает сравнительную таблицу задач SDE/T или SDET (инженером по разработке программного обеспечения в тесте или инженером по разработке программного обеспечения в тесте) и STE (инженером по тестированию SW).
Термин QA-отдел (или Software Quality Engineers) не должен использоваться.
Это скорее Software Test Engineering Dept или Software Design Dept

[1]
"Как мы тестируем программное обеспечение в Microsoft"
Алан Пейдж, Кен Джонстон, Бь Роллисон ОПУБЛИКОВАНО Microsoft Press Отдел Microsoft Corporation Один Microsoft Way Redmond, Вашингтон 98052-6399 Copyright © 2009 Microsoft Corporation ISBN: 9780735624252