Почему тестирование — важный этап в разработке любого проекта и что на нём делают тестировщики

Спойлер: не просто тыкаются в экранах! Привет, это Лиза из Лиги А. Мы разрабатываем проекты для студий, агентств и продуктовых команд. Работаем с разными форматами — от простых страничек до сложных сервисов. Расскажем, почему тестирование нельзя пропускать, а тестировщиков — всегда брать на проект.

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

С написанием статьи нам помогла Катя, старший тестировщик Лиги с 2020 года. Поэтому вместе с ней расскажем, почему тестирование — важный этап в разработке проекта и как именно он проходит, во всех деталях.

Небольшое погружение в контекст

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

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

Что важно знать тестировщику на старте

В момент запуска проекта, после того, как менеджер узнал всю информацию от клиента, команда собирается на совместное внутреннее обсуждение и разбор материалов. Так, они больше погружаются в проект и его логику, синхронизируются проще говоря.

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

В общем, тестировщик изучает материалы, чтобы в будущем правильно протестировать проект и найти баги. Он глубоко погружается в механику и изучает возможные пользовательские сценарии. А разработчик в это время пишет код.

Между написанием кода и тестированием на проект подключается тимлид, чтобы провести код-ревью, но сейчас не будем погружаться в этот процесс, расскажем об этом в следующей статье)

Наконец, готовый проект переходит на проверку к тестировщику. Давайте узнаем поглубже, что же там происходит.

К нам приходят для реализации разных типов веб-проектов: лендингов, админок, интернет-магазинов, корпоративных порталов. Главной нашей задачей является создать качественный продукт, который в будущем удобно и просто поддерживать. Поэтому мы используем ручное (и очень душное 🤌🏻) тестирование — вручную проверяем проект на несоответствие требованиям. Делаем это руками с помощью сервисов и внутреннего чек-листа.

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

Например, приложение Сбербанка, которое с каждым годом развивается и наполняется разными фичами. Его можно назвать проектом-долгосроком.

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

Корнер-кейс — особый случай тестового сценария, который проверяет редко встречающиеся или граничные условия функционала программы.

Если на корнер-кейс наткнётся пользователь, то не сможет пройти по сценарию и завершить покупку, если он находился, к примеру, в интернет-магазине. В результате, бизнес не получит деньги сейчас и потеряет ещё больше в будущем. А мог бы заранее вложиться в качественное тестирование сайта, на этапе разработки.

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

А что за чек-листы и как их использовать?

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

Визуальная часть

Смотрим на вёрстку, адаптив, сверяем с дизайн-макетами и проверяем висячие предлоги. Проверяем написание знака рубля, чтобы был такой — ₽.

Функциональная часть

Проверяем UI-kit на наличие ошибок, проверяем микроанимации, скорость загрузки интерактивных элементов, переполняемость блоков и элементов на странице.

Кроссбраузерность + кроссплатформенность

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

Обычно такое тестирование мы проводим с помощью Xcode — симулятора, где как раз можно посмотреть проект на разных устройствах Apple. Плюс BrowserStack — позволяет запустить вашу страничку на внушительном количестве браузеров под Linux, Windows и MacOs.

Соответствие веб-стандартам

Смотрим на валидность разметки, смотрим на иерархию заголовков.

Соответствие техническому заданию клиента

Ну, тут всё должно быть так, как в ТЗ :)

Доступность

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

И это только малая часть того, что тестировщик должен проверить. Напишите в комментарии, если хотите получить версию нашего чек-листа, поделимся 👇🏻

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

Проект будет ломаться по логике, а какие-то кнопки могут совсем не отрабатывать свои состояния и быть пустыми. Раз уж мы заговорили про кнопки — если не протестировать кроссбраузерность, они будут отличаться на iOS и в Safari. А то, что проверили только на Mac, может отличается от Chrome.

Кроссбраузерное тестирование — процесс тестирования проекта на разных платформах и браузерах. Важно проверять на Mac, в Chrome, Safari и Firefox.

Какие проекты могут обойтись без тестирования?

Мы придерживаемся того, что никакие) Всё-таки, любой проект требует проверки, пусть это даже маленькая правка от клиента.

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

Как мы относимся к тестированию со стороны агентства

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

Где-то 5 лет мы собирали данные по затратам часов каждого специалиста на его работу на проекте, чтобы с уверенностью сказать — на тестирование надо закладывать 15-20% от общего количества часов разработки всего проекта.

Приходите к нам за качественным тестированием. Кроме него подберём технологии, соберём подходящую команду и реализуем проект. Пишите нам на почту или мне в телеграм — @gingerliza.

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