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

Всем привет!

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

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

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


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

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

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

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


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

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

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

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


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

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


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

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

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

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

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


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

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


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

Что делать?

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

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


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

aivj9nh6lanlfkicgvwtiwlinka.jpeg

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


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

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

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


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

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

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


ЧаВо


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

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

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

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

© Habrahabr.ru