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

Компания имеет небольшие команды разработчиков в нескольких странах.
В течение нескольких лет она успешно выпускает программный продукт (клиент в MS Visual Studio 2008 C ++, C # и сервер на Java), основанный на математической и межотраслевой инженерии.фундаментальные научные (и высокотехнологичные) исследования.
Разработка программного обеспечения не основана на TDD (разработка через тестирование), здесь нет модульных тестов, а также отдела обеспечения качества и т. д.

ЭтоКомпания инициирует введение группы обеспечения качества (отдел и, ну, в общем, практика / политика обеспечения качества) из 2-3 человек.

Первоочередные задачи - установить (автоматизированные) методы тестирования GUI и API.

Является ли внедрение модульного (или имитационного) тестирования или TDD (разработка через тестирование) необходимым и обязательным для успеха QA?

Обновление:
Хранилище базы данных - MS SQL Server.

Обновление2:
Спасибо всем, кроме того, что я отправил http://testing.stackexchange.com/questions/791/what-are-in-qa-besides-testing

Я понимаю, что постфактум юнит-тесты (или, скорее, имитация), вероятно, должны бытьвключены для повторяющихся ошибок, но должны ли они быть первой проблемой, чтобы ввести?
Каковы возможные проблемы первоочередности и их заказы?Должны ли постфактумные юнит-тесты вводиться разработчиками или «тестерами»?

Может ли контроль качества быть эффективным без юнит- (фиктивного) тестирования вообще?

Update3:
Спасибо за комментарий, что TDD не является модульным тестированием, я начал читать:

Спросили после прочтения:

Ответы [ 5 ]

9 голосов
/ 03 декабря 2010

Как указано в комментарии выше, TDD - это не то же самое, что модульное тестирование.

Мой совет:

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

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

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

Ответы:

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

5 голосов
/ 06 декабря 2010

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

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

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

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

2 голосов
/ 05 декабря 2010

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

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

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

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

1 голос
/ 04 декабря 2010

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

0 голосов

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

Они отвечают на вопросы Черный ящик против белого ящика Тестирование
Ответ от cschol говорит:

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

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

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

Genn answers :

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

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

Обновление:
Ну, может быть, я не сделалсформулируйте вопрос хорошо, но меня действительно смутил термин «создание группы контроля качества», который также был обвинен в использовании модульных тестов.
Мне кажется, я нашел свой ответ в [1], где приводится сравнительная таблица задач по SDE / T или SDET (Инженер по разработке программного обеспечения в тестировании или инженер по разработке программного обеспечения в тестировании) и STE (инженер по тестированию программного обеспечения).
Термин отдел обеспечения качества (или инженеры по качеству программного обеспечения) не должен был использоваться.
Это скорее отдел тестирования программного обеспечения илиОтдел разработки программного обеспечения

[1]
"Как мы тестируем программное обеспечение в M"icrosoft "
, Алан Пейдж, Кен Джонстон, БиДжей Роллисон. ОПУБЛИКОВАНО Microsoft Press. Отдел корпорации Microsoft One Microsoft Way Редмонд, Вашингтон. 98052-6399 Авторское право © 2009, Корпорация Microsoft.

...