Хабрахабр

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

Всем привет!

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

Что делать?

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

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

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

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

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

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

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

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

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

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

ЧаВо

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

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

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

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

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

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

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

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

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