Home

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи: http://thethinkingtester.blogspot.com/2018/01/testing-buttons.html
http://thethinkingtester.blogspot.com/2018/02/testing-back-buttons.html
Перевод: Ольга Алифанова

Про кнопки, как правило, легко забыть. Кнопка "Сохранить" настолько универсальна, что кажется, что она просто не может не сработать. Однако игнорирование тестирования кнопок на странице может привести к игнорированию багов. Недавно мне рассказали о тестировании функциональности существующей веб-страницы. Новая фича отлично работала, но команда забыла проверить кнопку "Удалить". Оказалось, что разработчики забыли добавить действие удаления, и кнопка делала ничего!

Вот о чем стоит помнить, тестируя кнопки!

1. Проверьте "счастливый сценарий" кнопки. Как правило, на кнопках есть сообщение, говорящее вам, что кнопка должна делать. Попробуйте это выполнить, и убедитесь, что кнопка делает то, что обещала! Действительно ли кнопка "Сохранить" сохранила ваши данные? Удалены ли они по кнопке "Удалить"? Очистила ли все кнопка "Очистить"? Запустился ли поиск по кнопке поиска? Отметим, что кнопка "Назад" тоже широко распространена, но эти кнопки достаточно коварны, и мы обсудим их позже.
2. Используйте кнопку не по назначению. К примеру, быстро нажмите на "Сохранить" дважды, добавляя данные. Не сохранилось ли две записи вместо одной? Не начинает ли кнопка странно себя вести, если вы нажали на нее дважды? Как насчет ситуации, когда вы быстро нажимаете на одну кнопку, а затем на другую? Один из самых забавных багов, который я находила, был баг с кнопкой обновления – она перерисовывала экран, и кнопка увеличивалась каждый раз, когда я на нее нажимала.
3. Находится ли кнопка там, где должна? Потратив много времени на тестирование приложения, легко привыкнуть к виду страницы и не обратить внимания на отсутствующие элементы. Подумайте о ваших пользовательских сценариях, изучая страницу. Что понадобится пользователю, чтобы сделать здесь что-то определенное? Пройдите по его сценарию, и в ходе этого обращайте внимание на кнопки.
4. Подумайте, в каких случаях кнопка активна, а в каких заблокирована. Имеет ли это смысл? К примеру, доступна ли кнопка "Сохранить" только тогда, когда заполнены все обязательные поля? Активируется ли кнопка "Очистить" только тогда, когда в поле внесены какие-то данные? Как вы узнаете, что кнопка активна? Можно ли судить об этом по ее внешнему виду? Не выглядит ли она активной, когда на самом деле заблокирована? Что будет, если нажать на заблокированную кнопку? Логичны ли правила активирования и блокировки кнопки?
5. И, наконец, попробуйте сломать ваши кнопки! К примеру, если у вас есть заблокированная кнопка "Сохранить" – скажем, не заполнено обязательное поле – можно ли отредактировать код страницы так, чтобы кнопка стала активной, и можно ли ее после этого использовать? Если на странице, согласно коду, есть скрытые кнопки, можно ли сделать их видимыми и активными? В лучшем случае такой баг – это досадная помеха, которая приведет к добавлению неверных данных в базу. В худшем случае это способ получить доступ к вашей системе. Представьте, что у вас есть кнопка, которая видима и доступна только тогда, когда пользователь входит с правами администратора. Если злоумышленник может заставить эту кнопку отобразиться и активироваться, он получит доступ к страницам и функциям, которого у него быть не должно. Ваш разработчик должен проверять права пользователя по клику на кнопке, чтобы не допустить использования кнопки тем, кто не должен быть способен нажимать на нее.

Если вы никогда не редактировали html веб-страницы во время тестирования, вот небольшая инструкция для Chrome:

1. Нажмите на многоточие в верхнем правом углу экрана, а затем выберите "Дополнительные инструменты" – "Инструменты разработчика". В правой стороне экрана появится новая панель.
2. Нажмите на кнопку, которую собираетесь тестировать, правой кнопкой, и выберите "Просмотреть код". В панели разработчика вы увидите подсвеченный html-код этой кнопки.
3. Нажмите на этот код правой клавишей и выберите "Редактировать как HTML". Появится окно с возможность редактирования текста.
4. Если видите текст вроде "'disabled'=disabled" – удалите его. Переключитесь с режима редактирования и проверьте, активна ли кнопка. Если активна, кликните по ней и посмотрите, что будет!
5. Чтобы найти скрытые кнопки, посмотрите в html в инструментах разработчика и поищите "button" через поиск.
6. Если вы нашли кнопку с пометкой "ng-hide", попробуйте поменять на "ng-show". Сможете ли вы заставить кнопку появиться на странице?

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

Тестирование кнопки "Назад"

Эта кнопка встречается так часто, что про нее легко забыть, тестируя приложения. Первое, что нужно знать, приступая к тестированию такой кнопки – это то, что они бывают разных типов. Две основные категории – это нативные кнопки и кнопки приложения.

Нативные кнопки – это кнопки, встроенные в браузер, мобильную операционную систему, и в мобильный телефон физически. На фотографии выше стрелочка "назад" – это кнопка Хрома. В Андроиде, как правило, есть кнопка "назад" внизу экрана, которую можно использовать в любом приложении. У iPhone эта кнопка находится наверху страницы.

Кнопки в приложении добавляются, когда дизайнер хочет сильнее контролировать пользовательскую навигацию. В примере выше кнопка "Home" используется для перехода на главную страницу W3Schools (тут стоит отметить, что W3Schools – отличный способ изучить HTML, CSS, JavaScript и многое другое - https://www.w3schools.com/default.asp).

Тестируя сайты и приложения, важно проверить поведение ВСЕХ кнопок "Назад", даже тех, которые добавлены не вашей командой. Первое, что стоит сделать – это подумать, куда эти кнопки должны вести. Это кажется очевидным, но иногда простой переход на предыдущую страницу – не самая удачная мысль. К примеру, пользователь редактирует свои данные на странице редактирования. Закончив редактировать и перейдя к сохраненной информации, пользователь не должен попадать на окно редактирования по кнопке "Назад" – он может решить, что ему нужно заново редактировать данные. Вместо этого лучше направлять его на страницу, которая была до страницы редактирования.

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

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

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

Можно также проверить, что кнопка "назад" активна и заблокирована в правильных ситуациях. Мы же не хотим, чтобы пользователь нажимал на активную кнопку "Назад", которая никуда не ведет?

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

Обсудить в форуме