Ручное тестирование QA мертвое?

Question

Могу ли я автоматизировать все типы тестов (модульное тестирование, ... и т. Д.), Чтобы мне не требовалась команда QA для проведения ручного тестирования? А если нет, то почему?

Answer 1

Я бы подвел итог так:

• Автоматизированные тесты предназначены для поиска проблем, о которых вы знаете (неверный код).

• Ручные тесты предназначены для поиска проблем, о которых вы не знаете (неправильный дизайн / технические характеристики).

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

Answer 2

Тестирование черного ящика никогда не пройдет, пока люди используют ваш продукт. Ничто не заменит человеческой способности распознавать «что-то странное».

Answer 3

номер

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

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

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

Answer 4

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

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

Answer 5

Одной из причин опыта работы с Vista было предположительно то, что MSFT сократила количество «простых людей» тестеров в пользу программистов-тестеров, которые писали сценарии.

Конечно, скрипты не замечали таких вещей, как широкий спектр различных тем, когда вы углублялись в панель управления, или диалоговые окна оценки копий или другие «незначительные» графические функции, которые делали весь продукт дерьмовым

Answer 6

Ручной QA, более известный как Blackbox QA, далеко не мертв.

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

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

Самая важная причина для Blackbox QA заключается в том, что в вашей организации вы получаете надежных адвокатов. Многие из этих специалистов по обеспечению качества (включая меня) имеют более творческий опыт, чем опыт программирования. Хотя некоторые могут думать, что это неудача, это люди, которых не волнует, как работает код - они заботятся о том, как работает продукт. Они проводят время, думая как клиент, а не разработчик; «О, мой почти мертвый iPod закончил синхронизацию, это означает, что я могу закрыть свой ноутбук и просто дать ему зарядиться. Ага, а потом я просто вытащу его, когда моя машина спит (даже если я воспроизводил музыку с нее на мой компьютер) и все будет хорошо. "

Разработчики и тестеры знают, как должен работать продукт, и все применяют продукт в соответствии со спецификацией. Хорошая работа тестера - использовать продукт небрежно, чтобы избежать неприятностей. Снимайте USB-диск с компьютера во время копирования данных, вы с ума сошли?!? Конечно, это действительно глупая идея. Но люди делают это все время. И хороший специалист по обеспечению качества сделает это, чтобы убедиться, что вытягивание жесткого диска не разрушит всю систему. Или отключите Wi-Fi при загрузке фильма или синхронизируйте музыку при покупке нового контента, а затем одновременно измените пароль учетной записи и адрес электронной почты. Или установите ОС на MP3-плеер и попытайтесь загрузиться с него, затем извлеките плеер из системы, пока он загружается с устройства (да, я сделал это и обнаружил в нем действительно хорошую ошибку).

Джоэл из «Программного обеспечения» говорит «Почему QA» гораздо красноречивее, чем я - http://www.joelonsoftware.com/items/2010/01/26.html

Answer 7

Абсолютно нет.Автоматизированные тесты - это код.Они могут иметь собственные ошибки, которые будут маскировать ошибки в AUT.Кроме того, ни один автоматизированный тест не может задать вопрос «Что делать, если я это сделаю?» Или сделать обоснованное предположение о том, где ошибки наиболее вероятны.Автоматизированного поискового тестирования не существует.

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

Answer 8

Нет!

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

Answer 9

[По моему опыту использования как Ручной, так и Автоматизации]

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

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

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

Answer 10

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

Опыт пользователя и проблемы с интерфейсом могут быть выявлены только при ручном тестировании.

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

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