Незадолго до поступления в школу Flatiron я работал в технологическом стартапе, специализирующемся на IoT (Интернете вещей), в качестве операционного менеджера. Я работал в очень маленькой команде, поэтому мне неизбежно приходилось носить много шляп. Я тесно сотрудничал с командой веб-разработчиков и выполнял контроль качества (QA) на веб-сайте и в мобильных приложениях. Процесс контроля качества был одной из задач, которые мне больше всего нравились в этой работе, и, хотя он выполнялся очень неформально, он многому научил меня в процессе разработки продукта и этапах веб-разработки.
Когда дело доходит до контроля качества веб-сайта или приложения, необходимо учитывать несколько моментов:
Соответствует ли дизайн вашего веб-сайта стилю вашего бренда и вашей аудитории?
Хотелось бы думать, что это само собой разумеется, но никогда нельзя быть слишком осторожным. При разработке приложения оно должно отражать индивидуальность вашего бренда, от выбора шрифта до цветовой схемы и общего внешнего вида.
Если ваше приложение ориентировано на более молодую аудиторию, у вас, вероятно, будет более красочный, яркий цвет. схема. Если вы представляете люксовый бренд, вы не будете использовать шрифт Comic Sans (и действительно, независимо от вашего рынка, вам не следует использовать Comic Sans).
Ваш веб-сайт/веб-приложение не содержит опечаток?
Это кажется довольно простым, но я всегда удивляюсь, когда посещаю веб-сайт или использую приложение с опечатками и грамматическими ошибками. Если в приложении есть несоответствия, одним из распространенных, которые я отметил, является несоответствие с заглавными буквами. Не существует жесткого правила для использования заглавных букв, но как только вы используете конкретное правило, придерживайтесь его! Если вы используете Заглавный регистр (где каждое слово начинается с заглавной буквы, как в названии книги) для заголовка, все ваши заголовки должны использовать заглавный регистр.
Одна практика, которую я использую, — это набирать текст в текстовом процессоре и использовать проверку орфографии перед его размещением на веб-странице.
Доступен ли ваш веб-сайт/веб-приложение?
В одной из своих первых историй, которую я опубликовал, я выделил несколько способов сделать ваш сайт более доступным. Это не было всеобъемлющим, и есть несколько других аспектов, которые следует учитывать. Вопросы, которые следует учитывать, включают: доступно ли ваше веб-приложение для людей с ограниченными возможностями? Доступна ли ваша цветовая схема для людей с цветовой слепотой? Достаточно ли велик размер вашего шрифта для чтения (или на вашем сайте есть возможность увеличить размер шрифта)? Могут ли элементы на веб-странице быть прочитаны программой чтения с экрана? Есть ли у вас много мигающих элементов, которые могут вызвать у кого-то эпилепсию?
Более подробную информацию о том, как сделать свой сайт более доступным, можно найти здесь.
Есть ли четкая последовательность событий?
Перед тем, как создать приложение, я стараюсь составить как можно более полный список пользовательских случаев. Затем я использую эти случаи, чтобы выяснить, какие элементы должны быть доступны на каждой странице, и создаю каркасы. Я всегда хочу убедиться, что поток событий плавный и логичный для пользователя. Должен ли пользователь быть направлен на свою панель управления или на другую страницу при входе в систему? Если пользователь просматривает определенную страницу при входе в систему, перенаправляются ли они на эту страницу или куда-то еще? Тестирование этого процесса может помочь выявить элементы, которые могли быть пропущены.
Все ваши ссылки работают?
В процессе прохождения всех возможных потоков событий, которые может принять пользователь, важно щелкнуть каждую из ваших ссылок, чтобы убедиться, что 1) ссылка правильно связана (а не только текст с другим стилем) и ведет к альтернативному местоположение и 2) ссылка указывает на правильную конечную точку. Вы ожидаете, что ссылка Flatiron School приведет вас на веб-сайт Flatiron School, а не на веб-сайт Dev Bootcamp (RIP).
Правильно ли работают ваши формы и уведомления?
Если ваше приложение включает формы, важно протестировать их, используя различные типы ответов. Некоторые из вещей, которые вы должны тестировать, включают:
- Форма отправляется правильно?
- Есть ли проверка полей ввода? Если да, то работают ли они нормально?
- Правильно ли отформатирован входной ответ в базе данных?
- Существуют ли какие-либо последующие действия, вызванные отправкой формы (например, отправляет ли форма электронное письмо при отправке и т. д.)? Если да, то правильно ли выполняется это действие?
Если ваша форма отправляет электронное письмо при ее выполнении, важно протестировать использование действительных адресов электронной почты, чтобы вы могли убедиться, что электронное письмо отправлено правильно и в нужном формате. Если ваше приложение отправляет электронные письма, текстовые или push-уведомления, также лучше протестировать их.
Ваш веб-сайт/веб-приложение работает на разных устройствах и в разных браузерах?
К сожалению, не все браузеры или устройства работают одинаково. И если вы специально не создаете свое приложение для одной платформы и не сообщаете об этом своим пользователям, вы должны убедиться, что все, кто обращается к вашему сайту, имеют одинаковый пользовательский интерфейс. Если у вас есть функция, которая работает только на iOS, а не на Android, вы отталкиваете огромную часть своей потенциальной потребительской базы. Поскольку не существует универсальных стандартов дизайна для устройств Android, лучше протестировать несколько самых популярных моделей. И как бы мы ни любили придираться к Internet Explorer, все еще есть люди, которые его используют. Они должны иметь доступ к вашему сайту и иметь те же возможности, что и ваши пользователи Google Chrome или Mozilla Firefox.
Существуют замечательные сервисы, такие как Amazon’s AWS Device Farm, которые позволяют тестировать ваше приложение на разных платформах и устройствах.
Соответствует ли ваш веб-сайт/веб-приложение требованиям законодательства?
Коммерческие веб-сайты должны иметь политику конфиденциальности, «которая раскрывает некоторые или все способы, которыми сторона собирает, использует, раскрывает и управляет данными клиента или клиента». Хотя это и не требуется по закону, рекомендуется, чтобы веб-сайты также включали условия обслуживания.
Кроме того, существуют особые требования к электронным письмам, отправляемым бизнесом в соответствии с Законом о CAN-SPAM. Если ваше приложение отправляет электронные письма, вы соблюдаете определенные требования, в том числе:
- Не используйте ложную или вводящую в заблуждение информацию заголовка.
- Не используйте вводящие в заблуждение темы.
- Идентифицируйте сообщение как рекламу.
- Сообщите получателям, где вы находитесь.
- Сообщите получателям, как отказаться от получения писем от вас в будущем.
- Немедленно выполняйте запросы на отказ.
- Следите за тем, что другие делают от вашего имени.
Безопасен ли ваш сайт/приложение?
Если ваш веб-сайт или приложение содержит элемент электронной коммерции или использует конфиденциальную информацию, например финансовую или социальную информацию, вы должны обеспечить безопасность своего сайта. Безопасность также следует принимать во внимание в зависимости от вашей пользовательской базы, например. несовершеннолетние, пережившие жестокое обращение/нападение и т. д.
Я нашел ошибку! Что мне делать?
Если бы это был ваш дом, ответ мог бы быть сжечь его дотла.
В идеале вы работали с гибким рабочим процессом и выполняли спринты с тестированием каждой новой функции. Если вы этого не сделали, и вы ждали, пока ваше приложение будет полностью создано, чтобы протестировать его, вы можете почувствовать необходимость перейти в режим полного уничтожения этих ошибок. Однако это не конец света. Если многие ваши ошибки связаны с одной функцией, вы можете рассмотреть возможность отката и исключения этой функции до тех пор, пока в ней не будет ошибок, прежде чем запускать ее в производство.
Когда вы найдете ошибки, запишите их! Вы можете использовать систему управления проектами, такую как Pivotal Tracker, или вы можете использовать обычную ручку на бумаге. Важно, чтобы вы документировали именно то, что вы сделали, чтобы найти эту ошибку, чтобы ее можно было воспроизвести, чтобы найти точное место ошибки.
Понятно, что после столь долгой работы над проектом начинаешь пропускать мелкие ошибки, потому что у тебя есть конкретное представление о том, как что-то должно происходить. Это отличная идея, чтобы кто-то еще провел некоторые тесты для вас, а также для свежего взгляда.
Выполнение QA научило меня некоторым действительно полезным навыкам. Во-первых, я научился разбивать «общую картину» продукта на более мелкие наборы готовых функций. Во-вторых, я научился разрабатывать функции и поток с использованием пользовательских случаев. В-третьих, я научился говорить о своем коде вслух. Третий урок оказался невероятно полезным, особенно сейчас, когда я создаю свои собственные проекты. Даже если я занимаюсь парным программированием с кем-то или на собеседовании и не знаю, что делать дальше, я знаю, как рассказать о своих ожиданиях и мыслях, чтобы помочь мне достичь цели.
