Проект близок к завершению. Время начинать тестирование. Какие методы возможны к концу цикла разработки?

Question

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

Какова будет рекомендуемая стратегия тестирования продукта на этом этапе, кроме юзабилити-тестирования? Это обычно точка, в которой вы застряли с ожидаемым ручным выводом / фактическим выходом?

Answer 1

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

Answer 2

Если у вас есть на это бюджет, приобретите комплект автоматизации тестирования. HP / Mercury QuickTest является лидером в этой области, но стоит очень дорого. Идея заключается в том, что вы записываете тестовые случаи, такие как макросы, используя графический интерфейс пользователя. Вы заполняете входные данные в форме (web, .net, swing, практически любой GUI), движок запоминает имена элементов формы. Затем вы можете проверить ожидаемый вывод в GUI и в БД. Затем вы можете подключить таблицу или электронную таблицу с различными входными данными теста, включая недопустимые случаи, когда он потерпит неудачу, и, если хотите, запустить его через сотни сценариев. После записи тестов вы также можете редактировать сгенерированные скрипты, чтобы настроить их. В конце концов, он создает для вас аккуратный отчет, показывающий, что именно не удалось.

Существуют также некоторые дешевые и бесплатные наборы средств для автоматизации тестирования графического интерфейса, которые выполняют практически те же функции, но с меньшим количеством функций. В целом, чем дороже комплект, тем меньше ручной настройки. Проверьте этот список: http://www.testingfaqs.org/t-gui.html

Answer 3

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

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

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

Answer 4

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

Я бы порекомендовал проверку кода кем-то / людьми, которые знают (или могут разработать) функциональную спецификацию продукта.

Экстремальный, пуристский способ состоит в том, чтобы сказать, что, поскольку он «был полностью свободен для всех без какого-либо тестирования», поэтому нельзя доверять ни одному из них: ни существующему тестированию, ни коду Ни разработчики, ни процесс разработки, ни управление, ничего о проекте. Кроме того, тестирование не повышает качество программного обеспечения (качество должно быть встроенным, частью процесса разработки). Единственный способ получить качественный продукт - это создать качественный продукт; у этого продукта не было качества в его сборке, и поэтому нужно восстановить его:

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

Но проверка кода (и исправление дефектов, обнаруженных при проверке кода) может быть быстрее. Это было бы в дополнение к функциональному тестированию.

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

Вам также понадобится:

• Либо:
  • Знание функциональной спецификации (и нефункциональной спецификации)
  • Разработчики и / или QA люди с подсказкой
• Или:
  • Небольшой, простой продукт
  • Пациент, прощающий конечных пользователей
  • Постоянная техническая поддержка после доставки продукта

Answer 5

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