Действительно ли ручное тестирование QA мертво? [закрытый]

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

Нет

И если нет, то почему?

Нет все технологии / тесты подходят для автоматизации.

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

Нет!

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

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

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

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

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

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

Joel on Software говорит "Почему QA" гораздо красноречивее, чем я - http://www.joelonsoftware.com/items/2010/01/26.html

И Kohana2 всего лишь php index.php controller/method/param1/param2/etc

Кохана был создан для запуска на CLI, а также веб.

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

# For bash
set -o noglob

# For csh/tcsh
set noglob

# Now that noglob is set, you can safely use *
calc 3 * 3

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

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

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

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

№

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

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

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

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

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

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