Тестируй, властвуй, побеждай. Или как протестировать сайт перед передачей заказчику и не облажаться

Привет, висичане! Собрать сайт – две трети всего дела. Его нужно еще хорошенько протестировать вдоль и поперек, чтобы у заказчика были только слезки радости от полученного результата. В этой статье я расскажу вам про подход, который мы в Div Block Studio используем к тестированию сайтов. Хоть мы и используем Webflow, актуально будет всем, кто разрабатывает сайты.

Представьте картину: вы молодец, сделали классный сайт, у вас все выглядит прекрасно, но вот у вашего клиента - ультраширик, и на сафари поехала верстка, или не работает какая-то фича. Не прикольно, согласитесь. Первое впечатление такое себе.

Поэтому, чтобы максимально уберечь себя от таких моментов, и деливерить максимально законченный продукт – уделяйте достаточное время для тестирования. Не зря же QA-инженеры хлебушек кушают 🙂 (а некоторые даже с икрой).

Ремарка: Даже протестировав все вдоль и поперек на багу все равно наткнуться можно, ибо все мы человеки, да и не все обладают зоопарком всех возможных устройств. Поэтому, перед стартом проекта сообщите клиенту, что если будут баги – вы в течение определенного срока (2-3 недели) после старта будете устранять их бесплатно. Все будут довольны. Ну, кроме вас, если багов будет много.

Так вот, у нас QA процесс выглядит так:

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

Мы используем приложение Responsively для проверки как сайт выглядит на разных устройствах одновременно. Просто открываем приложение, вставляем ссылку сайта, выбираем на каких девайсах тестить, и проходимся по каждой странице делая заметки о косяках.

Такой подход практически исключает вероятность каких-то критичных визуальных проблем. Практически, потому-что сложновато представить как выглядит сайт на 32х дюймовом экране, когда у вас ноут. И то, что выглядит круто на ноуте, будет смотреться огроменным или слишком мелким на больших экранах.

Этот тип тестирования обычно проводится совместно с тестированием функциональности и адаптивности, и означает, что мы тестируем сайт в самых популярных браузерах (мы обычно обходимся Хромом и Сафари). Мы используем как сами браузеры, так и инструмент Browserstack для тестирования на старых версиях браузеров при необходимости.

В качестве опционального тестирования (когда клиенту важна скорость загрузки и параметры performance) мы также проводим тестирование производительности, включающее использование таких инструментов как Google Lighthouse, GTmetrix или DebugBear, чтобы убедиться, что мы оптимизировали все, что можно, чтобы сайт загружался максимально быстро.

После всех этих манипуляций, мы передаем сайт на аккаунт клиента и помогаем настроить доменное имя, аналитику и дополнительные интеграции при необходимости (Hubspot, Gsheet, Airtable, GTM, Hotjar и тд).

Понравилась статья? Подписывайся на мой бложик тут, на VC, или в телеграм, где я по большей части рассказываю про no-code, публикую новости, и делюсь моментами из жизни студии.

Посмотреть другие мои статьи можно тут 👇