в описании теста упомянуто поле ввода которого нет на экране тестируемого приложения ваши действия
В описании теста упомянуто поле ввода которого нет на экране тестируемого приложения ваши действия
Что пишут в блогах
В этом видео я показал как можно визуализировать покрытие автоматическими тестами для GraphQL api с помощью инструмента Reqover.
Cегодня хочу поговорить с вами на тему комьюнити для тестировщиков.
Как и в любой сфере, среди тестировщиков существует куча различных комьюнити. Раньше они организовывались в скайпе.
Забываю похвастаться статусом книги.
Онлайн-тренинги
Конференции
Heisenbug 2021 Moscow
Большая техническая конференция для тестировщиков
5-7 октября 2021, онлайн
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова
Текстовое поле в приложении кажется таким обычным делом, однако это одна из наиболее важных вещей, которую мы можем протестировать. Почему? Потому что текстовые поля дают доступ к приложению и его базе данных. Валидация текстового поля – это то, что предотвращает появление в базе плохих данных. Эти данные могут вызвать разнообразные проблемы для пользователей и разработчиков. Валидация также предотвращает атаки межсайтового скриптинга и SQL-инъекции.
Тестировать текстовое поле можно миллионами способов, и я коснусь этих способов в статье. Для начала давайте представим, что мы тестируем текстовое поле, не имея никакой информации о том, что оно делает:
Затем давайте предположим, что мы что-то знаем о том, что должно вводиться в это поле, и каковы ограничения для данных:
Для всех вышеописанных тестов выясните, какое сообщение об ошибке вы должны получать, и убедитесь, что получаете правильное сообщение.
И, наконец, нужно подумать об автоматизации. Если вы тщательно протестировали ваше поле вручную, то, возможно, нет необходимости автоматизировать все ваши тесты. Более того, большинство форм имеют более одного поля ввода, и куча тестов для каждого отдельного поля – это куча потраченного времени на прогон. Вот несколько советов, что можно автоматизировать:
Это не исчерпывающий список, а просто способ подтолкнуть вас к размышлениям о большом количестве тестов, которые можно прогнать, тестируя единственное поле. Не верьте на слово, что разработчик, создававший поле, добавил нужную валидацию, проверьте ее сами! Как-то раз я тестировала поле ввода даты, у которого было ограничение на год – он не мог быть меньше 1900 или больше, чем текущий год. Я получала нужное сообщение об ошибке, вводя 1880, но даты 1300 года легко принимались!
Как тестировать поле ввода информации
Всем доброго времени суток. Помогите неопытному тестировщику составить собственный список на что надо проверять поле ввода информации. Уверен, что у всех опытных тестировщиков, есть такой список. Поделитесь если не жалко.
Сам я ничего кроме самых простых типо (ввести одни пробелы, не вводить текст, ввесть HTML, SQL, JS, сложную комбинацию символов, ну и ещё нескольких не замослыватых пунктов не нашёл).
Всем доброго времени суток. Помогите неопытному тестировщику составить собственный список на что надо проверять поле ввода информации. Уверен, что у всех опытных тестировщиков, есть такой список. Поделитесь если не жалко.
Сам я ничего кроме самых простых типо (ввести одни пробелы, не вводить текст, ввесть HTML, SQL, JS, сложную комбинацию символов, ну и ещё нескольких не замослыватых пунктов не нашёл).
вобщем многое зависит от того что за поле вообще.
+ проверка на ограничение поля
+ проверка работы кнопок Del, BackSpace, Tab, вперед,назад,Enter, Ctrl+V (вставка текста больших размеров..) в данном поле + проверка в разных браузерах (IE,FF,Chrome,Opera..)
+ проверка снятия ограничений наложенных на поле (размер, ограничение на какието символы), ввод невалидных данных, сохранение изменений.
Всем доброго времени суток. Помогите неопытному тестировщику составить собственный список на что надо проверять поле ввода информации. Уверен, что у всех опытных тестировщиков, есть такой список. Поделитесь если не жалко.
Сам я ничего кроме самых простых типо (ввести одни пробелы, не вводить текст, ввесть HTML, SQL, JS, сложную комбинацию символов, ну и ещё нескольких не замослыватых пунктов не нашёл).
Пятничная задачка для тестировщиков
В сети набирает популярность ссылка, пройдя по которой участнику предоставляется возможность протестировать поле ввода. Пройти тест можно по ссылке. На сайте написано, что нужно найти все проверки для поля ввода.
Identify all the test required for the scenario bellow. Based on the data you input in the First Name field the tests will be evaluated.
What not to test: different browsers, extremely big requests, «nasty words». Do not use automation tools. The server will cut access at over 30 requests per second per IP.
The user has to fill in the required data in order to get access, as a standard user in forum.
Only the First Name field can be tested right now. The field has a max length of 30.
Что нужно сделать
Найдите все проверки для сценария описаного ниже. Основываясь на данных введеных вами в поле First Name проверки будут оценены. Что не нужно тестировать: разные браузеры, очень большие запросы, «плохие слова». Не используйте инструменты автоматизации. Сервер будет закрывать доступ при превышении лимита в 30 запросов в секунду с одного IP адреса.
Задание
Пользователь должен ввести нужные данные чтобы получить доступ на форум, как обычный пользователь. Только First Name пригодно для тестирования на текущий момент. Максимальный длина поля 30 символов.
От себя хочу добавить, не зацикливайтесь только на самом поле, мыслите шире.
Ну и как тестировщик, я нашел еще один баг. После того как вы найдете все 18 проверок, каждая последующая попытка отправить данные на проверку будет увеличивать счетчик пользователей которые прошли задание на 1. То есть, можно заниматься накрутками.
Чек-лист для тестирования числового поля
При тестировании встречаются как интересные задачки с замудреной логикой, так и простые, вроде проверки простой строки или числового поля. Для простых полей можно один раз написать чек-лист проверок, а потом переиспользовать, лишь немного меняя под «своё» поле.
Сегодня мы разберем чек-лист для числового поля. Сначала я напишу общий чек-лист, потом пройдемся по каждому пункту и разберемся, зачем он нужен, а в конце напишем чек-лист по этому шаблону.
Итак, у нас есть некое поле, куда нужно вводить число. Например, поле «возраст» при регистрации:
При этом на сайте нельзя регистрироваться до 18 лет, есть запрещённый контент.
Какие проверки тут можно провести:
Корректные значения
Представьте, что у вас буквально 5 минут на проверку функционала. И вы успеваете провести только первые несколько тестов из чек-листа. А чек-лист у вас:
Для поля с возрастом какие у нас будут корректные значения? Все, что выше 18 лет:
Тут надо понимать, что мы выбираем какое-то ОДНО значение. Просто каждый раз разное, для избежания эффекта пестицида.
Также важно понимать, что у нас может быть не одно корректное значение. Это когда у нас есть несколько диапазонов, и разные условия на каждом.
Например, тот же возраст:
Или если у нас идет расчет страховки в зависимости от стажа вождения:
Каждый раз берем разные значения, но в этом пункте смысл один — взять корректные значения из ТЗ.
Некорректные значения
Тут есть разные варианты. Что значит некорректное значение?
— А что будет, если мы возьмем значение из «неправильного» диапазона? Что, если мне меньше 18 лет? Ну, скажем, 10.
Потом внимательно смотрим на выбранный интервал:
— Хммммм, но ведь возраст не может быть меньше 0. То есть у нас есть логическая граница, разделяющая два разных класса эквивалентности:
— Если у нас есть некая логическая граница снизу, должна быть и сверху. Какой максимально возможный возраст у регистрирующихся на нашем сайте? Скорее всего, это около 55-65 лет, потому что более старшее поколение не любит компьютеры. Но можно заложить и условные 100-110 лет долгожителей.
Получаем еще один интервал с неявной границей. Но в любом случае, значения 25 и 145 будут различаться — одно реалистичное, а другое нет. Значит, стоит его тоже попробовать!
А дальше снова эффект пестицида. Один раз берем 145, а другой — 6666666.
Тут мы можем столкнуться с тем, что в поле нельзя ввести больше 2-3 символов. Разработчик перестраховался «от дурака». Это не повод опускать руки и отказываться от своей проверки. Потому что скорее всего разработчик просто установил maxlength на поле, а он легко обходится!
Граничные значения
Граничные значения отделяют один интервал от другого. Их обязательно надо тестировать. Потому что именно на границах чаще всего встречаются баги. Почему? Да потому что попадают в оба диапазона, или не попадают ни в один.
В нашем примере в ТЗ есть условие «регистрация только для лиц старше 18 лет». Это значит, что разработчик должен сделать в коде программы логику вида:
Чек-лист тестирования WEB приложений
Привет! После публикации статьи «Чек-лист тестирования мобильных приложений», поступило большое количество сообщений про такой же чек-лист, только для WEB приложений. Чтобы ответить на этот вопрос была подготовлена универсальная шпаргалка, которую можно использовать при тестировании практически любого WEB приложения.
В данный чек-лист вошли только общие характеристики. Естественно, в тестируемом приложении может быть функциональность, для которой нужно применять отдельный подход и создать отдельные сценарии. То же самое верно для производительности, удобства использования, безопасности и прочего тестирования, которое необходимо вашему приложению.
Чек-лист для тестирования WEB приложений состоит из шести разделов:
Функциональное тестирование
В данном пункте нам важно убедиться, что наш продукт соответствует нужной функциональной спецификации, упомянутой в документации по разработке.
Что проверяем?
Интеграционное тестирование
Интеграционное тестирование проводится для того, чтобы убедиться, что ваше приложение совместимо со сторонними сервисами.
Что проверяем?
Тестирование безопасности
Данная проверка нацелена на поиск недостатков и пробелов с точки зрения безопасности нашего приложения.
Что проверяем?
Тестирование локализации и глобализации
Тестирование интернационализации/глобализации WEB приложения включает тестирование приложения для различных местоположений, форматов дат, чисел и валют. Тестирование локализации включает тестирование WEB приложения с локализованными строками, изображениями и рабочими процессами для определенного региона.
Что проверяем?
Тестирование удобства использования
Тестирование удобства использования подразумевает проверку навигации, контента, другая информация для пользователя.
Что проверяем?
Кросс-платформенное тестирование
Кросс-платформенное тестирование проводится, чтобы убедиться, что ваше приложение совместимо с другими браузерами, различными оболочками, аппаратным обеспечением устройства.