Когда автоматизация должна начаться? [закрытый]

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

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

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

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

Общие усилия по тестированию для ручного тестирования увеличатся с увеличением квадрат размера программы: из-за повторного тестирования и повторного тестирования.

Если вы не будете автоматизировать, вы не сможете проводить регулярное полное регрессионное тестирование.

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

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

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

Моя причина автоматизации тестирования заключается в том, что это означает, что я могу получать последовательную, повторяемую и своевременную обратную связь о том, что то, что я только что сделал, правильно.

Ручное тестирование также имеет свое место, но трудно быть настолько уверенным, что оно охватывает все должным образом, и, конечно же, не делает это так быстро, как автоматическое тестирование.

Например, частью одного из моих проектов является алгоритм оптимизации, который использует некоторые эвристики для обхода пространства поиска в поисках хороших решений. Сейчас существует около 40 различных эвристик, которые можно использовать по отдельности или в различных комбинациях, и каждая встреча с клиентом, похоже, включает добавление новой эвристики или расширение существующей. Мне нужно быть абсолютно уверенным, что ни одна из этих работ для одного клиента не вызовет регрессии для другого клиента, что включает запуск алгоритма в нескольких сотнях различных случаев и проверку того, что результат (не хуже, чем) был раньше.

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

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

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

По моему опыту, вам нужно начать тестирование примерно за 2 часа до того момента, когда вы внезапно поймете, что вам следовало начать тестирование 2 часа назад:)

Вы автоматизируете, потому что нажатие "go" и ожидание результатов 10 минут означает, что ваш тестировщик может выполнять другую полезную работу в течение этих 10 минут вместо того, чтобы присматривать за приложением. .

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

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

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

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

Можете ли вы назвать мне причины, по которым вы должны автоматизировать, даже если у вас есть ручные тестеры?

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