Хабрахабр

[Из песочницы] Заметка для фронтендеров: что проверить перед тестированием

Всем привет!

Недавно наша команда писала большую фичу. Так сложилось, что я из той самой службы контроля качества. Она напомнит на что стоит обратить внимание перед передачей задачи в тестирование.
Немного порефлексировав, решил создать такую вот статью-шпаргалку для фронтендеров.

Было бы в высшей степени непрофессионально передавать на контроль качества заведомо дефектный код. Когда вы передаете окончательную версию продукта в службу контроля качества, вы должны рассчитывать на то, что контроль не выявит никаких проблем. Любой, в качестве которого вы не уверены! А какой код является заведомо дефектным?

Как стать профессионалом разработки ПО»
Роберт С. «Идеальный программист. Мартин

Верстать по прототипам.

И иногда проще сделать по-своему, чем следовать прототипу. Так бывает, что дизайнеры — это прекрасные эльфы с высокой башни, и «они так видят». И если кажется, что нарисовано что-то странное — всегда можно обсудить. Но обычно эти ребята на нашей стороне, и рисуя, они держат голове (или на бумаге) какие-то аргументы почему сделано так, в чём ценность.

Очень, очень, очень стрёмно видеть свежие прототипы, что не сходятся со свежей задачей. Если что-то невозможно (читай очень дорого) сделать — так и надо сказать.

Прототип слева.
Найди N отличий.

Всё хорошо, когда информация на сайте статична и неизменна. Можно посмотреть в паре браузеров и нескольких разрешениях. Это позволит сразу же найти явные проблемы и поправить их до тестирования.

Но всё меняется, когда есть они — инпуты.

В них крайне необходимо вводить всякое:

  • Много текста.
  • Разный текст: буквы, цифры, спецсимволы и т.д.
  • Мало текста. Можно ли ничего не вводить и как это потом будет выглядеть?
  • Текст не того формата или невалидный текст.
  • На десерт: большие строки вообще без пробелов.
  • Пробелы: лидирующие и замыкающие.

Скрытый текст

Типичный фронтендер может задаться вопросом: а много текста — это сколько? На это есть у меня ответ: столько, сколько влезет в инпут. Нет ограничений на длину? Можно ввести 10-20 тыс. знаков и посмотреть на результат. Может ваш бэкенд не готов к таким объёмам? На минуточку, 20 тыс. знаков — это вот столько:


A4, Times New Roman, 12 кегль, межстрочный — 1.

Про лидирующие и замыкающие пробелы.

У меня был опыт, когда приложение падало из-за наличия пробела в конце логина. Они не нужны в 99% случаев, кроме, быть может, только для паролей, но это неточно. Так что: тримьте пробелы! Он остался после копирования строки из почты.

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

Проверяем всё то же самое:

  • Большие тексты, с пробелами или же без оных.
  • Тексты с переносами строк, абзацами. Иногда вставляю стихи для этого.
  • Минимальный набор данных. Всё ли остаётся на месте, когда ничего или почти ничего нет?
  • Отображение не всех полей от сложной сущности. Они могут быть пустыми.

Под катом, немного живых примеров.

Скрытый текст

Порой нельзя просто взять и ввести что хочется — срабатывают валидации.

Что делать?

Т.е. Смотрим список валидаций и по каждой из них делаем проверки, что она ругается. ограничения на длину, запрещённые символы, маска ввода — вот это всё надо проверить и убедиться, что оно работает.

Хинт: текст можно вводить ещё и копированием.

Я понимаю, первая реакция какая-то такая.

Но если нет, то увы. Вам повезло, если пользователей этого дивного браузера у вас немного. Придётся посмотреть на свою работу сквозь призму альтернативного восприятия.

Тут почти как с IE, только не больно.

В противном случае придётся сделать две вещи: Если у вас на проекте не собираются никакие пользовательские метрики, то всё хорошо.

  • Навесить все метрики на требуемые действия. В моём опыте информация о метриках приходила или из аналитики, или фронтендеры сами были в курсе.
  • Проверить, что на действия отправляются нужные метрики с нужными данными. Хотя бы выводить в консоль в дев-режиме.

Я коротко рассказал о том, на что стоит обратить внимание при работе с фронтом. Эти несколько проверок позволят на выходе получать существенно более качественный продукт.

Поэтому в конце ещё раз краткое содержание: Хочется отметить, что статья будет полезна если у вас и вовсе нет тестировщика.

  • Верстать по прототипам.
  • Вводить разнообразные данные: много, мало, в_одно_слово, не вводить.
  • Тримить пробелы.
  • Проверять валидации.
  • IE.
  • Не забыть метрики.

ЧаВо

В: Тестировщики всё найдут!
О: Не всё. Тестировщики — это вам не HEPA-фильтр, а люди. И если на этапе разработки кто-то не сделал свою часть работы, то она никуда не девается, а просто переходит кому-то другому.

Значит с этим будут работать другие люди, тратить не только время, но и свои силы. Наверстали, но не посмотрели? И за валом таких проблем могут быть пропущены более серьёзные вещи. Человек устаёт, глаз замыливается, усталость накапливается.

Доделывать нормально всё равно придётся. Также не стоит забывать, что любая игра задачами в пинг-понг только накладывает дополнительные расходы времени. Но раннее обнаружение проблем ускоряет весь процесс разработки.

Спасибо за внимание.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть