Автоматизированное тестирование — это одна из самых обсуждаемых тем среди инженеров по контролю качества. Новые системы тестирования программного обеспечения появляются постоянно, и каждый новый фреймворк получает титул лучшего.
Однако автоматизированное тестирование основывается на предположении, что программа используется так, как это задумали разработчики. Если полагаться только на автоматические тесты, то вскоре в коде появятся ошибки, и в то же время вы получите слабое представление о качестве интерфейса приложения.
Что касается ручного тестирования, то ему уделяют всё меньше внимания, поскольку такой процесс изнуряет сотрудников, а на роль исполнителя подойдет только специалист с особым складом ума. Однако «ручные» тесты отнюдь не уступают автоматизированным. Дело здесь в том, что подходы обладают разными областями применимости, поэтому сегодня мы рассмотрим некоторые достоинства и недостатки каждого решения.
/ фото verkeorg CC
По мнению Сары Фитжи (Sarah Fittje), инженера контроля качества в компании Project A Ventures, если тест подразумевает выполнение большого числа повторяющихся задач, то его имеет смысл автоматизировать. Классический пример — регрессионное тестирование, позволяющее обнаружить серьёзные баги, поэтому его важно регулярно проводить в полном объеме до запуска конечного продукта (кстати, если вам интересно, можете почитать руководство для QA-специалистов от Сары, его вы можете найти по ссылке).
При этом не стоит думать, что настройка автоматических тестов позволит серьезно сэкономить. Написание и поддержка написанных скриптов требует определенных навыков в области QA, которыми обладают не все тестировщики, следовательно, компании придется платить своим специалистам больше (однако штат тестировщиков все же удастся сократить).
Также стоит отметить, что достаточно сложно внедрять автоматизированные тесты для большого приложения с большим функционалом – так вы рискуете потерять видение общей картины и не сможете покрыть тестами весь функционал. Однако настраивая систему автоматизированного тестирования с первых дней проекта, вы получаете возможность ускорить циклы контроля качества и наладить последовательную проверку работы приложения.
Однако важно понимать, что автоматизированное тестирование не сможет помочь в определении недостатков внешнего вида интерфейса и качества взаимодействия пользователя с продуктом. Рассмотрим направления для применения автоматизации:
Этот тип тестирования нацелен на проверку front-end-части приложения. Без помощи автоматизации очень трудно учесть все возможные комбинации взаимодействия пользователя с интерфейсом в веб-браузерах, мобильных устройствах и прочих системах (важно понимать, что такой тест не сможет оценить UX, как было отмечено выше).
С помощью этого типа тестирования разработчики находят баги, вызванные улучшениями функций приложения. Под давлением частых обновлений разработчикам приходится трудиться в бешеном ритме и иногда идти на компромиссы, чем непременно пользуются баги, «закрадываясь» в код программного обеспечения. Вручную отследить недочеты каждого релиза достаточно проблематично.
Это тестирование для проверки выполнения функциональных требований, то есть работает ли приложение в соответствии с ожиданиями. Определяется, насколько точно реализуются задуманные функции, проводится анализ на соответствие стандартам, оценивается защищённость решения. На повторение функционального тестирования уходит много времени, даже при небольшом изменении в приложении, поэтому выполнять все действия «руками» может быть накладно.
Автоматизированное тестирование помогает добиться высокого качества, но на данный момент оно ещё не заменило ручные тесты полностью. Это связано с тем, что пользователи могут совершать абсолютно неожиданные действия, которые сложно учесть в автоматических тестах.
Пока пользователь привыкает к приложению, он способен ошибаться, не завершать нужные шаги, вводить неожиданные значения и так далее. Пользователи знают гораздо меньше о вашем продукте, но в итоге именно они будут им пользоваться. Поэтому клиентское одобрение — самый ценный индикатор качества интерфейса.
Когда для оценки работы программы ключевую роль начинают играть поведенческие особенности человека и интуиция, то стоит обратить внимание на ручное тестирование — здесь важнее поставить себя на место пользователя. Тестировщик может подходить творчески к процессу проверки функциональности: придумывать неожиданные идеи, имитировать необычные варианты использования — это помогает раскрыть критические ошибки, которые «не заметит» автоматизированное тестирование.
Пара юзкейсов ручного тестирования:
Это тестирование служит для проверки удобства использования приложения с точки зрения пользователя. Такую расплывчатую по своим целям задачу компьютер решить не может — машине нужны четкие формулировки.
Разовое тестирование, направленное на проверку одного аспекта программы. Для такого типа тестирования нет формально определённых правил, оно проводится импровизационно — тестировщик может использовать любые доступные средства для поиска багов. Фактически ad hoc тесты – это попытка «угадать» возможную ошибку.
Как мы отметили выше, разные типы тестирования обладают разными сферами применимости. Автоматические тесты не заменят ручные, но они могут быть использованы для экономии рабочего времени при отработке больших однообразных наборов действий. Ручное же тестирование выполняется долго, но без него не обойтись, если вы хотите добиться высокого качества продукта. На данный момент только комбинация этих подходов способна обеспечить высокие стандарты по отношению к функциональности и удобству использования продукта.
В качестве примера такого подхода Сара Фитжи приводит процесс тестирования онлайн-магазина natue, когда после успешного внедрения новых функций в тестовом проекте, QA-команда запускала автоматизированное регрессионное тестирование.
«Пока выполнялась автоматизированная проверка, мы одновременно проводили ручное тестирование новых функций, учитывая промежуточные результаты регрессионного теста, – рассказывает Сара. – Если во время ручного или автоматизированного тестирования обнаруживались баги, то они исправлялись, а тесты запускались заново». Если же все проходило успешно, то команда Сары повторяла проверку уже перед самим запуском финальной версии.
Еще один пример приводит Стивен Аллен (Steven Allen), инженер компании TestGrid.io. Он говорит, что в iOS полноценное автоматизированное тестирование долгое время было недоступно. Несколько лет назад Apple начали выпускать инструменты для автоматизации, но они пока что не совершенны. Поэтому использовать только средства автоматизации не получается – приходится прибегать к ручному тестированию.
Разработчики автоматизируют тесты, чтобы работать эффективнее и успевать больше, но нельзя описать скриптами все возможные варианты использования приложения и учесть все ошибки. Некоторые вещи очень легко пропустить – например, если на экране входа появилось лишнее поле ввода пользовательского имени, но при этом всё остальное работает правильно.
«Очень сложно написать идеальный код для автоматических тестов, – говорит Джозеф Миллар (Joseph Millar), специалист отдела контроля качества компании Lucid Software. – Если разработчик допустит ошибку в скриптах, он рискует пропустить большой пласт ошибок, тогда как при ручном тестировании эти недочеты, скорее всего, будут обнаружены. Поэтому так важно использовать оба метода при разработке приложений. Один для экономии времени, второй для «шлифовки».
P.S. Наши другие материалы: Дайджест об облаках, сетевых технологиях и разработке сервисов.
Однако автоматизированное тестирование основывается на предположении, что программа используется так, как это задумали разработчики. Если полагаться только на автоматические тесты, то вскоре в коде появятся ошибки, и в то же время вы получите слабое представление о качестве интерфейса приложения.
Что касается ручного тестирования, то ему уделяют всё меньше внимания, поскольку такой процесс изнуряет сотрудников, а на роль исполнителя подойдет только специалист с особым складом ума. Однако «ручные» тесты отнюдь не уступают автоматизированным. Дело здесь в том, что подходы обладают разными областями применимости, поэтому сегодня мы рассмотрим некоторые достоинства и недостатки каждого решения.
/ фото verkeorg CC
Автоматизированное тестирование
По мнению Сары Фитжи (Sarah Fittje), инженера контроля качества в компании Project A Ventures, если тест подразумевает выполнение большого числа повторяющихся задач, то его имеет смысл автоматизировать. Классический пример — регрессионное тестирование, позволяющее обнаружить серьёзные баги, поэтому его важно регулярно проводить в полном объеме до запуска конечного продукта (кстати, если вам интересно, можете почитать руководство для QA-специалистов от Сары, его вы можете найти по ссылке).
При этом не стоит думать, что настройка автоматических тестов позволит серьезно сэкономить. Написание и поддержка написанных скриптов требует определенных навыков в области QA, которыми обладают не все тестировщики, следовательно, компании придется платить своим специалистам больше (однако штат тестировщиков все же удастся сократить).
Также стоит отметить, что достаточно сложно внедрять автоматизированные тесты для большого приложения с большим функционалом – так вы рискуете потерять видение общей картины и не сможете покрыть тестами весь функционал. Однако настраивая систему автоматизированного тестирования с первых дней проекта, вы получаете возможность ускорить циклы контроля качества и наладить последовательную проверку работы приложения.
Однако важно понимать, что автоматизированное тестирование не сможет помочь в определении недостатков внешнего вида интерфейса и качества взаимодействия пользователя с продуктом. Рассмотрим направления для применения автоматизации:
Тестирование графического интерфейса
Этот тип тестирования нацелен на проверку front-end-части приложения. Без помощи автоматизации очень трудно учесть все возможные комбинации взаимодействия пользователя с интерфейсом в веб-браузерах, мобильных устройствах и прочих системах (важно понимать, что такой тест не сможет оценить UX, как было отмечено выше).
Регрессионное тестирование
С помощью этого типа тестирования разработчики находят баги, вызванные улучшениями функций приложения. Под давлением частых обновлений разработчикам приходится трудиться в бешеном ритме и иногда идти на компромиссы, чем непременно пользуются баги, «закрадываясь» в код программного обеспечения. Вручную отследить недочеты каждого релиза достаточно проблематично.
Функциональное тестирование
Это тестирование для проверки выполнения функциональных требований, то есть работает ли приложение в соответствии с ожиданиями. Определяется, насколько точно реализуются задуманные функции, проводится анализ на соответствие стандартам, оценивается защищённость решения. На повторение функционального тестирования уходит много времени, даже при небольшом изменении в приложении, поэтому выполнять все действия «руками» может быть накладно.
Ручное тестирование
Автоматизированное тестирование помогает добиться высокого качества, но на данный момент оно ещё не заменило ручные тесты полностью. Это связано с тем, что пользователи могут совершать абсолютно неожиданные действия, которые сложно учесть в автоматических тестах.
Пока пользователь привыкает к приложению, он способен ошибаться, не завершать нужные шаги, вводить неожиданные значения и так далее. Пользователи знают гораздо меньше о вашем продукте, но в итоге именно они будут им пользоваться. Поэтому клиентское одобрение — самый ценный индикатор качества интерфейса.
Когда для оценки работы программы ключевую роль начинают играть поведенческие особенности человека и интуиция, то стоит обратить внимание на ручное тестирование — здесь важнее поставить себя на место пользователя. Тестировщик может подходить творчески к процессу проверки функциональности: придумывать неожиданные идеи, имитировать необычные варианты использования — это помогает раскрыть критические ошибки, которые «не заметит» автоматизированное тестирование.
Пара юзкейсов ручного тестирования:
Юзабилити-тестирование
Это тестирование служит для проверки удобства использования приложения с точки зрения пользователя. Такую расплывчатую по своим целям задачу компьютер решить не может — машине нужны четкие формулировки.
Ad hoc тестирование
Разовое тестирование, направленное на проверку одного аспекта программы. Для такого типа тестирования нет формально определённых правил, оно проводится импровизационно — тестировщик может использовать любые доступные средства для поиска багов. Фактически ad hoc тесты – это попытка «угадать» возможную ошибку.
Комбинированный вариант
Как мы отметили выше, разные типы тестирования обладают разными сферами применимости. Автоматические тесты не заменят ручные, но они могут быть использованы для экономии рабочего времени при отработке больших однообразных наборов действий. Ручное же тестирование выполняется долго, но без него не обойтись, если вы хотите добиться высокого качества продукта. На данный момент только комбинация этих подходов способна обеспечить высокие стандарты по отношению к функциональности и удобству использования продукта.
В качестве примера такого подхода Сара Фитжи приводит процесс тестирования онлайн-магазина natue, когда после успешного внедрения новых функций в тестовом проекте, QA-команда запускала автоматизированное регрессионное тестирование.
«Пока выполнялась автоматизированная проверка, мы одновременно проводили ручное тестирование новых функций, учитывая промежуточные результаты регрессионного теста, – рассказывает Сара. – Если во время ручного или автоматизированного тестирования обнаруживались баги, то они исправлялись, а тесты запускались заново». Если же все проходило успешно, то команда Сары повторяла проверку уже перед самим запуском финальной версии.
Еще один пример приводит Стивен Аллен (Steven Allen), инженер компании TestGrid.io. Он говорит, что в iOS полноценное автоматизированное тестирование долгое время было недоступно. Несколько лет назад Apple начали выпускать инструменты для автоматизации, но они пока что не совершенны. Поэтому использовать только средства автоматизации не получается – приходится прибегать к ручному тестированию.
Разработчики автоматизируют тесты, чтобы работать эффективнее и успевать больше, но нельзя описать скриптами все возможные варианты использования приложения и учесть все ошибки. Некоторые вещи очень легко пропустить – например, если на экране входа появилось лишнее поле ввода пользовательского имени, но при этом всё остальное работает правильно.
«Очень сложно написать идеальный код для автоматических тестов, – говорит Джозеф Миллар (Joseph Millar), специалист отдела контроля качества компании Lucid Software. – Если разработчик допустит ошибку в скриптах, он рискует пропустить большой пласт ошибок, тогда как при ручном тестировании эти недочеты, скорее всего, будут обнаружены. Поэтому так важно использовать оба метода при разработке приложений. Один для экономии времени, второй для «шлифовки».
P.S. Наши другие материалы: Дайджест об облаках, сетевых технологиях и разработке сервисов.
Поделиться с друзьями
Комментарии (9)
vit1251
06.10.2016 17:41+1«Это связано с тем, что пользователи могут совершать абсолютно неожиданные действия, которые сложно учесть в автоматических тестах.»
В автоматических тестах можно реализовать любые действия и даже самые неожиданные. Я вижу тут просто предположение, что автоматические тесты пишут по плохой спецификации (учитываются только позитивные сценарии), а в противовес ставите тестирование не по спецификации ручным QA.
Это заблуждение идет из того что спецификацию на тестирование пишет не квалифицированный тест дизайнер не понимающий всех аспектов тестирования программного обеспечения. Каждый уважающий себя тест дизайнер знает о существовании негативных тестов и отлично справляются с набрасыванием тестовых планов для ручников и автоматизаторов по негативным сценариям.
Galangetan
Не могу с вами согласиться.
Вы пишите «Это связано с тем, что пользователи могут совершать абсолютно неожиданные действия, которые сложно учесть в автоматических тестах.» почему так? По-моему как раз таки в автоматизированных тестах неожиданные действия учесть легче.
«Тестировщик может подходить творчески к процессу проверки функциональности: придумывать неожиданные идеи, имитировать необычные варианты использования — это помогает раскрыть критические ошибки, которые «не заметит» автоматизированное тестирование.» — опять не понимаю, почему это автоматизированное тестирование не заметит? Можете обосновать?
tundrawolf_kiba
Потому, что автоматизированное тестирование может заметить только то некорректное поведение приложение, которое было предположено заранее, а человек может обратить внимание и на другие вещи во время проведения тестирования. Я представляю как автоматизировать позитивные сценарии(и то, в определенных пределах), но как учесть, а затем автоматизировать все возможные негативные сценарии — я, если честно, не очень представляю.
ivan19631224
> Как и отсутствие на смартфоне пакета из…
А отсутствие самого смартфона, наверное, уже нечто совершенно неукладывающееся в голове, практически неприличное.
tundrawolf_kiba
Все верно. Проблема только в том, что все возможные пути возникновения ошибки — не покрыть, я даже выделил сверху этот момент. Автоматизация весьма полезна, особенно в тех же регрессионных тестах, она позволяет значительно сократить рутину. Просто она — не панацея, и не заменит ручное тестирование полностью — т.к. программа не способна заметить какое-либо отклонение от правильного поведения — не предусмотренное заранее.
miwa
То, что панацеи не существует — это не оспаривается. Я другое не могу понять. Давайте на примере.
Есть у нас в программе возможность, например, создать пользователя. Для этого надо:
1. Запустить программу (открыть сайт в браузере, запусть линк с рабочего стола или бинарник)
2. Авторизоваться
2.1 Ввести имя пользователя в поле usernname
2.2. Ввести пароль в поле password
2.3 Нажать кнопку «ОК»
4. Нажать кнопку btnusers
5. Ввести новое имя пользователя в поле newuser
6. Ввести новый пароль в поле newpassword
7. Ввести еще что-то в поле somefield
8. Нажать кнопку «ОК».
В результате этого в базе данных должна появиться запись с новосозданным именем и, например, хешем нововведенного пароля. Если запись создана — тест прошел успешно, если запись не создана — тест провален.
При этом тест будет провален во всем многообразии случаев — и при переполнении места на сервере БД, и при недоступности БД, и при срабатывании множества проверок по пути начиная от авторизации. В смысле, какая бы ошибка по пути не произошла — все равно в базе данных не будет записи о свежесозданном пользователе и робот сигнализует об ошибке. А с причинами возникновения конкретной ошибки уже будет разбираться человек.
В чем я неправ?
tundrawolf_kiba
В том, что вы описали только один тесткейс. Большинство тесткейсов можно автоматизировать, да. Но разговор о том, что машина увидит только то, что уже покрыто тесткейсами, а ручной тестировщик способен обратить внимание на некорректное поведение даже если оно не было заранее спрогнозировано и на него нет тесткейса.
Pakos
..., если честно, не очень представляю
а приходится, потому как их значительно больше. Особенно когда система состоит из нескольких модулях, соединённых сетью, где скорость передачи «прибежать и набрать то же в другом месте» выше, как и надёжность. потому да, фейлы тоже надо воспроизводить и получать на них реакцию. Когда тестировщик делает что-то вручную, то потом можно это включить и в автоматизированный тест. По крайней мере у нас на это табу нет (хотя автоматизированных тестов крайне мало, что вызывает боль и желание с этим бороться).
tundrawolf_kiba
Используйте абстракцию в виде BDD, это позволит часть труда переложить на ручных тестировщиков, пусть пишут тесткейсы сразу в этом формате. И для ревью разработчиками и и аналиттиками опять же проще