СоХабр закрыт.

С 13.05.2019 изменения постов больше не отслеживаются, и новые посты не сохраняются.

| сохранено

H Что вам необходимо знать, выбирая: ручное или автоматическое тестирование в черновиках Tutorial

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



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

Ручное тестирование программного обеспечения


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

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

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

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

В общем, автоматизированное тестирование не имеет смысла для маленьких, и краткосрочных проектов, поскольку первоначальные расходы слишком высоки. Кроме того, если вы тестируете вещи, которые требуют человеческого понимания (human touch), такие как юзабилити (usability), то тестировщик-человек будет гораздо лучше. Тестировщикам, которые имеют мало опыта в тестировании, рекомендуется начинать именно с ручного тестирования, и, как только они осознают, что такое тестовое покрытие и оценивание рисков, им следует приступать к автоматизированному тестированию.

Автоматизированное тестирование


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

По словам Джона Овербо, ведущего senior SDEТ в Microsoft, автоматизированные инструменты тестирования имеет смысл использовать, только когда затраты на их приобретение, создание, и поддержку меньше, чем выгода, которую они приносят.

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

Ричард Фенхель, технический директор в компании «Black Marble» объясняет значение использования автоматизированных средств: «Использование авторизированного тестирования, сделало цикл обратной связи короче, так как мы больше не ограничены неудобствами SharePoint. Это не удалило потребность в тестировании, как части цикла разработки ПО полностью, но большая часть проверок, в частности, для веб-частей, стала намного легче.»

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

Есть много мнений, какой вид тестирования сделать основным в Вашем проекте. Убедитесь, что Вы принимаете обоснованное и хорошо информированное решение, что лучше удовлетворит конкретные потребности Вашего проекта.

Оригинал тут.

комментарии (12)

0
lolmaus ,  
Автор что-нибудь слышал про Behavior-Driven Development?
0
Pompeius_Magnus ,  
Автор статьи или автор перевода?
0
vit1251 ,  
Я слышал. Более того даже предлагал начальству начинать его использовать.
Очень интересный на мой взгляд подход. А что Вас конкретно интересует в BDD?
+1
sectus ,  
-1. Не ясно что именно хотел сказать автор, не ясно зачем это перевёл переводчик.
0
Pompeius_Magnus ,  
несколько общих слов об автоматическом и ручном тестировании.
0
kovyl ,  
А какой в них смысл, если нет конкретики?
0
vit1251 ,  
Статья не для технических специалистов, а для начинающих руководителей пришедших не из разработки.
Короче для самозванцев в нашей священной отрасли. А те кто работает в ИТ и так все это понимает потому что работает в ИТ.
Честно говоря ни стал трогать и минусовать, но и полезной статью не нашел — нажал на мнимую кнопку равнодушия.
0
kovyl ,  
А этим гражданам я бы посоветовал читать не абстрактные сопли, а ту же самую техническую литературу. Конкретные приемы и технологии. Конкретные сценарии, fail- и success-stories.
0
imanushin ,  
Тут тонкий момент. Дело в том, что в статье сказано много полуочевидный вещей, а главное — мало доказательств. Приведены фразы каких-то людей в каких-то проектах, однако это фразы, не более того.

Ричард Фенхель, технический директор в компании «Black Marble»

Я думаю, все знают, кто это такой? И, кстати, в оригинальной статье даже нет ссылки на интервью, что позволяет усомниться в истинности фразы.

Если говорить про автоматизацию, то скорее можно было бы посоветовать записать планируемые затраты в виде таблички: какой релиз, сколько пишем автотестов, сколько делаем ручных, какое ожидаемое количество ненайденных багов (а они всегда будут), покрытие и т.д. В этом случае можно более-менее оценивать окупаемость инвестиций, необходимость автотестов (например, мы в проекте как-то раз заметили, что юнит тесты ни разу не нашли ни одной баги, однако время на их написание было потрачено немалое, следовательно прибыль от них за 3-4 года отрицательная). Просто в этом случае аналитика получается более сложная.
+2
kovyl ,  
>> Автоматизированное тестирование программного обеспечения использует автоматизированные средства для выполнения тестов.

/me вспомнил университетские лекции и прослезился от ностальгии.
+1
rmpl ,  
Напомнило:
Я муравьед. Я ем муравьев. Когда я вижу муравья — я его ем. Когда я не вижу муравья — я его не ем. Если ты муравей — я тебя съем. Если ты не муравей — я тебя не буду есть.
0
iAlex ,  
офтопик: О сколько теплых и приятных воспоминаний напомнил iBook G4…