чит лист текстового поля
Самые простые и эффективные способы тестирования поля ввода текста
Любое текстовое поле в создаваемом программном обеспечении кажется таким простым и понятным функционалом, что процесс тестирования сводится к банальной проверке правильности его заполнения. Но, это только на первый взгляд.
Проверять правильность работы текстового поля нужно с особой тщательностью, ведь с его помощью можно очень быстро получить несанкционированный доступ к базе данных!
Процесс валидации текстовой формы при функциональном тестировании – это первая среди всех проверок, которая поможет предотвратить манипуляции с пользовательскими файлами и данными. Также это своего рода защита перед появлением в БД вредной информации.
Подобные вирусные файлы могут вызвать проблемы с функционированием веб-продукта как на стороне клиента, так и на стороне сервера. Ну и наконец, корректная валидация позволяет сразу же предотвратить атаки межсайтового скриптинга и вредоносных SQL-инъекций хакеров.
Основные типы проверки текстового поля
Проверять работоспособность текстового поля можно очень многими способами. Мы выделим наиболее важные проверки, которые QA-специалист должен выполнять в обязательном порядке при тестировании текстовых полей.
Тестирование форм без спецификации
Итак, представим, что необходимо проверить текстовое поле, о котором нет особой информации в спецификации на проекте.
В подобной ситуации можно выполнить следующие проверки:
Проверка полей на основе технической документации
Представим, что мы кое-что знаем о формах, знаем какие примерные значения можно вводить в форму, а также каковы ограничения в них установлены.
Тестирование поля с известными данными
Итак, что мы можем конкретного проверить:
Для всего вышеизложенного перечня проверок стоит выяснить, какие именно сообщения об ошибке отображаются и убедится в том, что все сообщения при валидной отправке тоже корректны.
Тестирование текстовых полей + автоматизация
Без автоматизации тестирования в данном случае тоже никак не обойтись.
Если тестировщик выполнил полный перечень ручных проверок, скорее всего нет надобности в автоматизации тестов. Более того, множество форм состоит из нескольких полей, а значит масса тестов для каждого по отдельности – это огромное количество потраченного времени на их выполнение.
Тем не менее, целесообразной будет автоматизация следующих пунктов:
Конечно же, это неполный перечень того, что можно тестировать при проверке форм. Но данный список можно использовать как базовый набор проверок, которые стоит в обязательном порядке выполнять при работе с текстовыми формами.
Тестировщик никогда не должен верить разработчику на слово, что все и так работает, и незачем лишний раз себя утруждать монотонными проверками. Ведь при нахождении клиентом технической уязвимости, спросят в первую очередь именно с проверяющего!
Чит лист текстового поля
Как я использовала чит-листы и узнала за день тестирования больше нового, чем за 3 прочитанные книги
Книги, к слову, тоже оказались полезными, но тут главный герой не книги, а чит-листы.
Как я их использовала — по большей части при тестировании незнакомых мне продуктов, потому что когда продукт тебе знаком, ты знаешь все “трещинки”, все поля ввода, ошибки, ямки в коде продукта и с каким выражением лица лучше данные вводить (но это не точно). Бывали случаи, когда чит-листы в моей команде применялись и на знакомых продуктах и, ребята, там столько всего находилось из разряда фантастики!
Как я использовала чит-листы? Внимайте, ребятки.
Шаг первый: гуглить чит-листы! А нагугленное бережно собирать себе в личную коллекцию на все случаи жизни: контрольные списки интерфейса, проверки числовых полей, проверки текстовых полей, email и даже можно разжиться парой листиков по тестированию безопасности.
Шаг второй: хватит это терпеть! Я прыгала из документа в документ, чит-лист один, чит-лист другой, “крутится-вертится шар голубой!” Часть проверок повторялась, я решила — хватит это терпеть!
Шаг третий: пиши, сокращай! Я решила, что нужно оптимизировать это безобразие и сгруппировала проверки в табличку по типам, так стало намного удобнее — каждая вкладка моей таблицы отвечала за тестирование какого-то определенного типа поля, число, текст, а рядом с каждой проверкой стоял статус — прошло или не прошло.
Кому-то сильно интересно сейчас, почему я пою хвалебные оды такому простому инструменту? Чего же в них такого хорошего, в чит-листах? А вот чего:
Агеева Нина, тренер ПОИНТ
П.С. Вот такие классные штуки делают студенты нашего первого потока ПОИНТ
Как мы тестируем frontend (html-верстку). Чек-лист
Меня зовут Павел, я со-основатель 100UP (разработка сайтов и рекламное агентство в одном лице). Мы занимаемся дизайном и разработкой технически сложных веб-проектов. В основном это e-commerce и b2b-порталы (личные кабинеты дилеров, производителей и др.).
В этой статье мы бы хотели поделиться своим опытом как мы в своей команде тестируем html-верстку, так как качественная верстка является неотъемлемой частью успешного запуска проекта.
Есть масса примеров, когда компании в спешке с желанием как можно скорее представить новый сайт клиентам, решали, что не стоит тратить “лишнее” время на качественное тестирование, выпускали очень “сырой” проект. Конечно, для простых корпоративных сайтов упущенная прибыль минимальна при запуске проекта с кривой версткой, а вот для коммерческих проектов стоимость ошибок слишком высока, особенно для интернет-магазинов, когда посетитель не может подобрать товар или даже оформить заказ.
1. Два вида тестирования: ручное и автоматизированное. Автоматизация: юнит-тесты и интеграционные тесты.
2. Чек-лист по тестированию верстки: что в себя включает проверка; проверяемые параметры.
3. В каких браузерах и на каких устройствах мы тестируем.
4. Разработка сайта и тестирование. Схема.
5. Сервисы, которые используются для тестирования верстки сайта.
Тестирование верстки сайта осуществляется двумя способами — вручную и с помощью автоматизированных тестов.
Для того, чтобы выполнить ручное тестирование, разработчику и тестировщику необходимо “пройтись” по всем пунктам разработанного заранее чек-листа (представлен в пункте статьи №2).
Преимущество ручного тестирование заключается в его “гибкости” и детальности. Тестировщик может увидеть сценарии, которые не прописаны в скрипте, и тут же протестировать их. Однако есть и существенный минус — приходится все “делать своими руками”, а это значит, что затрачивается значительное количество времени. Сократить время проверки помогает автоматическое тестирование.
Автоматическое тестирование осуществляется с помощью тестов, которые пишутся разработчиками, для выполнения повторяющихся монотонных действий, а также для поиска неочевидных ошибок. Разработчик один раз пишет тест, затем в последующем использует его для проверки похожих компонентов на разных сайтах.
Самые низкоуровневые (простые) тесты — это юнит-тесты. В широком смысле юнит-тесты — это код, который тестирует юниты (части) кода: функции, модули и классы. В рамках frontend-разработки юнит-тесты — это тесты javascript. Обычно каждый javascript-компонент сайта имеет большое количество мелких юнит-тестов. Каждый такой тест проверяет только одно взаимодействие с тестируемым компонентом.
Основным преимуществом юнит-тестов является их независимость от других частей приложения — часто корректировки в скрипты можно вносить точечно, не изменяя весь код теста. Кроме того эти тесты небольшие, и во многих случаях их написание не занимает много времени.
Для написания и воспроизведения юнит-тестов мы используем фреймворк jest. Тесты производятся в виртуальной среде, где взаимодействие с сервером эмулируется.
Кроме юнит-тестов также для автоматического тестирование верстки мы используем приемочные тесты или интеграционные тесты. В интеграционных тестах производится тестирование как и целых компонентов, так и взаимодействие разных компонентов друг с другом. Такие тесты позволяют проверить, как frontend будет вести себя на готовом сайте на CMS-движке. В первую очередь данными тестами проверяется взаимодействие различных javascript-компонентов между собой.
Приемочные тесты в отличие от юнит-тестов не проверяют мельчайшие детали компонентов, а тестируют их основные функции. Внутри этих тестов мы пытаемся максимально имитировать действия пользователей: тесты нажимают кнопки, ждут отклика, заполняют поля, переходят по ссылкам.
Для написания приемочных тестов мы используем Selenium.
Кроме того к автоматическим тестам мы относим мониторинг сайта и логирование javascript-ошибок, найденных при взаимодействии с этим сайтом. На наших сайтах мы логируем javascript-ошибки с помощью Sentry.
Данный чек-лист постоянно нами обновляется и каждый его пункт содержит описание, которое мы решили не вставлять в эту статью, так как она была получилась “километровая”. Актуальный чек-лист с комментариями можно посмотреть на нашем сайте.
Мы пришли к тому, что проверяемые параметры можно разделить на несколько групп:
1. Соответствие макету
2. Работа в разных окружениях
3. Проверка на разных разрешениях экрана (проверка десктопной и адаптивных версий)
вторник, 7 июля 2015 г.
Буквы в телефоне — баг?
Покупала я тут недавно сертификат на «Ужин в темноте».
Выбираешь сертификат, нажимаешь «Заказать» — отображается корзина.
Проверяешь, все ли правильно, нажимаешь «Оформить заказ».
И видишь такую формочку
Имя короткое, ввожу его, глядя на клавиатуру, не поднимая глаз — «Ольга». И автоматом нажимаю «Enter». Оу, зеленая галочка появилась, чудненько.
Начинаю набирать телефон и смотрю на экран — смогу ли я ввести свой номер как мне удобно или тут маска ввода зашита?
Поясню, мой номер выглядит примерно так: 8 (926) 22-33-456.
Именно так я его и помню, так всегда и называю, когда просят мой номер. И когда меня просят его проверить и называют 8 (926) 223-34-56, это немного коробит. Непривычно, приходится в уме прикидывать, он или не он.
Поле ввода может быть простым текстом, может быть маской. Так что я смотрю на экран, что мне покажется там?
Минуточку! Какая галочка? Я еще ничего не ввела!
Почему один символ считаем корректным вводом?
Во мне тут же проснулся тестировщик и попробовал ввести одну букву — тоже работает!
Нет уж, давайте разберемся.
Откуда у меня диссонанс — я работаю с данными. Мы умеем проверять качество введенных данных и по Дадате моя картина мира:
Но давайте посмотрим с точки зрения простого пользователя. Мы не любим запретов, они нас бесят. Ведь зачем все эти ограничения? Чтобы типа помочь «не ошибиться». Но вот только если мне помощь не нужна, я найду способ ее обойти. Вот, допустим, телефон. Ах, вы мне запретили вводить что-то кроме маски? Ну и звоните по общему телефону в нашу компанию, перебьетесь без добавочного.
В Дадате была форма с вводом имени и номером телефона. А куда писать доп инфо? В телефон! Так и пишем: «8 800 2223344, звонить после 11:00» или «8 (495) 222-33-44, доб 4455, звонить до 18:00». Сможем мы перезвонить человеку? Сможем! И не нужны никакие маски. И не нужно ограничивать возможности ввода.
Но как же так? А вдруг пользователь ошибется и введет 10 или 12 цифр вместо 11? И не заметит! О ужас и кошмар, мы ему не перезвоним, пользователь обидится и затаит кровную месть. Встречный вопрос — а если он введет 11 цифр, но ошибется в одной? Все равно ведь мы этому пользователю не дозвонимся, а как система такую ошибку найдет?
В случае же ввода телефона в «Ужине в темноте» бага нет. У них есть несколько полей. Я могу ввести только свое имя и адрес доставки и не оставлять телефон и email. Им он и не нужен, это нужно мне, если я хочу, чтобы курьер мне отзвонился. А если не хочу, то и ничего и не ввожу или пытаюсь обмануть лишние проверки.
Конечно, в таком случае можно вообще не рисовать восклицательные знаки и не требовать заполнять поля, в которые можно просто везде нулей понаставить. Было бы лучше убрать знаки и подписать каждое поле, зачем мне, пользователю, нужно его заполнять, Но не «выводить ошибку, если поле заполнено неправильно». Как-то так 🙂
Где брать идеи для тестов (подборка полезных ссылок)
Вот выдали нам (тестировщикам) функционал и сказали:
А с чего начать? Для новичка это может быть целой проблемой. Особенно когда нет подробного ТЗ. Поэтому я решила создать эту подборку, где можно поискать вдохновение!
Где брать идеи
Статьи
Они обычно называются классы эквивалентности для. или чек-лист для. или чит-лист для. или как-то так. Вот вам мои подборки:
Это еще не конец! в этой статье Michael Hunter рассказывает про разные методы ввода, файлы, сетевое соединение, сообщения об ошибках, доступность, меню
Юлия Iuliia. Схемы транслитерации если ваша система что-то транслитерирует, то будет полезно.
Чит-листы в Ситечке
В системе Ситечко есть чит-листы, это как раз шаблоны для переиспользования (подробнее можно почитать тут).
Чтобы их увидеть, нужно:
Ну и всё, дальше уже выбираете нужный вам.
Работы студентов
Я собираю хорошие работы студентов своей школы для начинающих в конфлюенсе в открытом доступе (ссылка доступна без авторизации). Эти работы помогают другим студентам:
Плагины для автозаполнения полей
Например, тот же Bug Mugnet. Установили плагин, ставим курсор на любое поле ввода, и вдохновляемся. Вот, например, подборка для валидных емейл-адресов:
Исследовательские туры
Туры из книги James A. Whittaker это когда ты выбираешь какой-то один тур, засекаешь время, и выполняешь задачи тура. Фишка в том, что в каждом туре подробно рассказано, что именно тебе нужно делать.
Они помогают находить баги. Но и мысли для тестирования тоже подкидывают. В какую сторону думать, что проверять можно найти там вдохновение!
Если у вас есть другие полезные ссылки на чек-листы и идеи для тестирования, скидывайте в комментарии!
PS больше полезных статей ищите в моем блоге по метке полезное. А полезные видео на моем youtube-канале