Comments 11
Не могу с вами согласиться.
Вы пишите «Это связано с тем, что пользователи могут совершать абсолютно неожиданные действия, которые сложно учесть в автоматических тестах.» почему так? По-моему как раз таки в автоматизированных тестах неожиданные действия учесть легче.
«Тестировщик может подходить творчески к процессу проверки функциональности: придумывать неожиданные идеи, имитировать необычные варианты использования — это помогает раскрыть критические ошибки, которые «не заметит» автоматизированное тестирование.» — опять не понимаю, почему это автоматизированное тестирование не заметит? Можете обосновать?
Вы пишите «Это связано с тем, что пользователи могут совершать абсолютно неожиданные действия, которые сложно учесть в автоматических тестах.» почему так? По-моему как раз таки в автоматизированных тестах неожиданные действия учесть легче.
«Тестировщик может подходить творчески к процессу проверки функциональности: придумывать неожиданные идеи, имитировать необычные варианты использования — это помогает раскрыть критические ошибки, которые «не заметит» автоматизированное тестирование.» — опять не понимаю, почему это автоматизированное тестирование не заметит? Можете обосновать?
Потому, что автоматизированное тестирование может заметить только то некорректное поведение приложение, которое было предположено заранее, а человек может обратить внимание и на другие вещи во время проведения тестирования. Я представляю как автоматизировать позитивные сценарии(и то, в определенных пределах), но как учесть, а затем автоматизировать все возможные негативные сценарии — я, если честно, не очень представляю.
Кхм. Объясните мне, пожалуйста, как неспециалисту. Я пишу тест, который запускает приложение, выполняет в нем ряд действий — нажимает кнопки, заполняет поля ввода и т.д. — и ожидает какой-то результат. Например, запись в базе данных. Соответственно, если запись в базе не появилась, значит что-то пошло не так, тест провален. Разве нет?
Напоминаю, я неспециалист поэтому просьба не пинать ногами, если глупость спросил.
Напоминаю, я неспециалист поэтому просьба не пинать ногами, если глупость спросил.
Все верно. Проблема только в том, что все возможные пути возникновения ошибки — не покрыть, я даже выделил сверху этот момент. Автоматизация весьма полезна, особенно в тех же регрессионных тестах, она позволяет значительно сократить рутину. Просто она — не панацея, и не заменит ручное тестирование полностью — т.к. программа не способна заметить какое-либо отклонение от правильного поведения — не предусмотренное заранее.
То, что панацеи не существует — это не оспаривается. Я другое не могу понять. Давайте на примере.
Есть у нас в программе возможность, например, создать пользователя. Для этого надо:
1. Запустить программу (открыть сайт в браузере, запусть линк с рабочего стола или бинарник)
2. Авторизоваться
2.1 Ввести имя пользователя в поле usernname
2.2. Ввести пароль в поле password
2.3 Нажать кнопку «ОК»
4. Нажать кнопку btnusers
5. Ввести новое имя пользователя в поле newuser
6. Ввести новый пароль в поле newpassword
7. Ввести еще что-то в поле somefield
8. Нажать кнопку «ОК».
В результате этого в базе данных должна появиться запись с новосозданным именем и, например, хешем нововведенного пароля. Если запись создана — тест прошел успешно, если запись не создана — тест провален.
При этом тест будет провален во всем многообразии случаев — и при переполнении места на сервере БД, и при недоступности БД, и при срабатывании множества проверок по пути начиная от авторизации. В смысле, какая бы ошибка по пути не произошла — все равно в базе данных не будет записи о свежесозданном пользователе и робот сигнализует об ошибке. А с причинами возникновения конкретной ошибки уже будет разбираться человек.
В чем я неправ?
Есть у нас в программе возможность, например, создать пользователя. Для этого надо:
1. Запустить программу (открыть сайт в браузере, запусть линк с рабочего стола или бинарник)
2. Авторизоваться
2.1 Ввести имя пользователя в поле usernname
2.2. Ввести пароль в поле password
2.3 Нажать кнопку «ОК»
4. Нажать кнопку btnusers
5. Ввести новое имя пользователя в поле newuser
6. Ввести новый пароль в поле newpassword
7. Ввести еще что-то в поле somefield
8. Нажать кнопку «ОК».
В результате этого в базе данных должна появиться запись с новосозданным именем и, например, хешем нововведенного пароля. Если запись создана — тест прошел успешно, если запись не создана — тест провален.
При этом тест будет провален во всем многообразии случаев — и при переполнении места на сервере БД, и при недоступности БД, и при срабатывании множества проверок по пути начиная от авторизации. В смысле, какая бы ошибка по пути не произошла — все равно в базе данных не будет записи о свежесозданном пользователе и робот сигнализует об ошибке. А с причинами возникновения конкретной ошибки уже будет разбираться человек.
В чем я неправ?
В том, что вы описали только один тесткейс. Большинство тесткейсов можно автоматизировать, да. Но разговор о том, что машина увидит только то, что уже покрыто тесткейсами, а ручной тестировщик способен обратить внимание на некорректное поведение даже если оно не было заранее спрогнозировано и на него нет тесткейса.
..., если честно, не очень представляю
а приходится, потому как их значительно больше. Особенно когда система состоит из нескольких модулях, соединённых сетью, где скорость передачи «прибежать и набрать то же в другом месте» выше, как и надёжность. потому да, фейлы тоже надо воспроизводить и получать на них реакцию. Когда тестировщик делает что-то вручную, то потом можно это включить и в автоматизированный тест. По крайней мере у нас на это табу нет (хотя автоматизированных тестов крайне мало, что вызывает боль и желание с этим бороться).
а приходится, потому как их значительно больше. Особенно когда система состоит из нескольких модулях, соединённых сетью, где скорость передачи «прибежать и набрать то же в другом месте» выше, как и надёжность. потому да, фейлы тоже надо воспроизводить и получать на них реакцию. Когда тестировщик делает что-то вручную, то потом можно это включить и в автоматизированный тест. По крайней мере у нас на это табу нет (хотя автоматизированных тестов крайне мало, что вызывает боль и желание с этим бороться).
Приведу простой пример. Диалоговое окно со списком чего-то, не важно чего. Над списком в этом окне лэйбл — полужирная надпись, скажем «Выберите документ из списка». Однажды кто-то что-то накодил и надпись перестала отображаться. Совсем. Как вы планируете это автотестировать?
Я думаю автор таким образом отнёсся к сложности тестированию фронтэнда содержащего много js + ajax + socket. Модно, но писать фронтэнд тяжелей.
Там разные ветки логики заполнения формы и вводимых данных. Причём на самом фронтэнде.
Но самое важное, нужно учитывать разный ответ в случае неудач, которые не всегда обрабатываются на фронтэнде. А именно они являются основой для автоматического тестирования.
Легче «посадить попку и заставить клевать».
Бекэнд тестируется быстро и автоматически, а вот то что сейчас творится на фронтэнде — это ужас.
Но с вами согласен.
Там разные ветки логики заполнения формы и вводимых данных. Причём на самом фронтэнде.
Но самое важное, нужно учитывать разный ответ в случае неудач, которые не всегда обрабатываются на фронтэнде. А именно они являются основой для автоматического тестирования.
Легче «посадить попку и заставить клевать».
Бекэнд тестируется быстро и автоматически, а вот то что сейчас творится на фронтэнде — это ужас.
Но с вами согласен.
«Это связано с тем, что пользователи могут совершать абсолютно неожиданные действия, которые сложно учесть в автоматических тестах.»
В автоматических тестах можно реализовать любые действия и даже самые неожиданные. Я вижу тут просто предположение, что автоматические тесты пишут по плохой спецификации (учитываются только позитивные сценарии), а в противовес ставите тестирование не по спецификации ручным QA.
Это заблуждение идет из того что спецификацию на тестирование пишет не квалифицированный тест дизайнер не понимающий всех аспектов тестирования программного обеспечения. Каждый уважающий себя тест дизайнер знает о существовании негативных тестов и отлично справляются с набрасыванием тестовых планов для ручников и автоматизаторов по негативным сценариям.
В автоматических тестах можно реализовать любые действия и даже самые неожиданные. Я вижу тут просто предположение, что автоматические тесты пишут по плохой спецификации (учитываются только позитивные сценарии), а в противовес ставите тестирование не по спецификации ручным QA.
Это заблуждение идет из того что спецификацию на тестирование пишет не квалифицированный тест дизайнер не понимающий всех аспектов тестирования программного обеспечения. Каждый уважающий себя тест дизайнер знает о существовании негативных тестов и отлично справляются с набрасыванием тестовых планов для ручников и автоматизаторов по негативным сценариям.
Sign up to leave a comment.
Вручную или автоматически: Пара слов о тестировании приложений