Содержание
Что такое тестирование сервиса
Тестирование — это:
- поиск несоответствий между фактическим и ожидаемым поведением ПО;
- проверка качества системы, которая проводится на ограниченном наборе тестов.
Веб-продукт проверяют на:
- верификацию — подтверждение того, что требования выполнены верно. Мы должны ответить на вопрос: «Делаем ли мы продукт правильно?».
- валидацию — соответствует ли ПО своему прямому назначению. Здесь спрашиваем себя «Делаем ли мы правильный продукт?».
При этом валидация — более весомый критерий, потому что удобство пользователя всегда на первом месте. Иногда мы намеренно отклоняемся от требований верификации, чтобы по валидации сервис получился максимально полезным и выполнял поставленные задачи. Однако все решения предварительно согласовываются с заказчиком.
Если говорить просто, тестирование сравнивает изначальные условия с фактическим результатом. А также подсвечивает моменты, из-за которых мы можем отклониться от ТЗ и внести корректировки, если это улучшит продукт.
Проверку проводят QA-специалисты, которые моделируют различные ситуации и анализируют поведение ПО в пользовательских сценариях и стрессовых условиях. Например, перед сезоном распродаж на «Черную пятницу» нужно оценить, как сервис справляется с нагрузкой из-за повышенного трафика и смогут ли пользователи без проблем заказывать товары в интернет-магазине.
Также тестирование показывает, насколько продукт логичен и удобен в использовании. Если что-то работает не так, как было задумано, аудитория будет отказываться от ресурса в пользу конкурентов. А если альтернативы нет — раздражаться от багов и неудобных сценариев, что приведет к снижению качества сервиса и продаж.
С какой целью проводится тестирование сайта
Иногда тестированием пренебрегают из-за сжатых сроков либо считают, что простые сайты не нуждаются в проверке. В Атвинте тестирование является обязательным этапом разработки. В результате наши клиенты получают веб-продукт с корректно работающим функционалом.
Рассмотрим один из наших кейсов. Клиника «Энергетик» обратилась к нам за обновлением сайта, чтобы создать цифровой имидж медучреждения. Ранее мы разрабатывали для клиента мобильное приложение, которое помогло выделить клинику среди конкурентов и снизить нагрузку на колл-центр.
На сайте было необходимо сделать интеграцию с 1С для передачи данных. Помимо проверки на корректность и безопасность конфиденциальной информации пациентов, нам нужно было убедиться, что система сможет передавать и обрабатывать большое количество информации. Для этого мы разработали методику нагрузочного тестирования, прописали сценарии пользователей и ожидаемые результаты.
Команда QA-отдела выяснила, что 1C не справляется с ожидаемым потоком аудитории — и дала рекомендации по увеличению мощностей и настройке ПО.
Рассмотрим ключевые преимущества тестирования, благодаря которым получается качественный продукт.
Выявление багов
Тестирование помогает находить недочеты и ошибки, из-за которых бизнес теряет деньги и клиентов.
К примеру, может выясниться что кнопка «Оплатить» перестала отправлять запрос на backend или интеграция по API с платежным сервисом работает некорректно. Значит, клиенты, находящиеся на последнем шаге покупки, не смогут совершить действие и заказ сорвется.
Обнаружение бага предотвратит потерю клиентов и обеспечит бесперебойную работу приложения
Обеспечение безопасности
Тестирование нужно для проверки уязвимых мест, если в сервисе хранятся личные данные пользователей или конфиденциальная информация о компании. Это поможет избежать утечки информации и создать репутацию надежного бренда, который заботится о цифровой гигиене и безопасности пользователей.
Специалисты проверяют надежность кода и обработку данных, от которых зависит стабильность работы продукта.
Улучшение пользовательского опыта
Чтобы пользовательский опыт был положительным, нужно оптимизировать интерфейс, проверить скорость загрузки страницы и корректное отображение контента. К примеру, если адаптивная верстка выполнена не для всех основных типов устройств — аудитории будет сложно взаимодействовать с сервисом и она уйдет к конкурентам.
Соответствие ожиданиям
На выходе должен получиться продукт, придуманный на старте — со всеми необходимыми функциями, которые работают корректно. Тестирование помогает сравнить план с фактом и оценить соответствие исходным требованиям.
Разработка сложных сервисов не обходится без ошибок — тот, кто говорит, что делает все сразу идеально, скорее всего, приукрашивает. К тестированию нужно подходить тщательно: погрузиться в проект, изучить техническое задание, разобраться в бизнес-процессах компании и в том, как продукт будет использовать аудитория. Если этого не сделать, можно пропустить недочеты и получить сервис, который не отвечает ожиданиям.
Влад Гусельников
Руководитель QA-отдела
Digital-агентство Атвинта
Семь принципов тестирования
Рассмотрим ключевые принципы проверки веб-продукта:
- Тестирование показывает наличие дефектов, но не их отсутствие. Диагностика сокращает количество ошибок, скрытых в ПО, но обнаружение и устранение проблем не гарантирует, что продукт будет на 100% безошибочным.
- Исчерпывающее тестирование — невозможно. Нельзя учесть все сценарии, способы и комбинации тестовых окружений в одном продукте.
- Раннее тестирование экономит время и деньги. Чем раньше начнется проверка, тем дешевле обойдется исправление багов.
- Скопление ошибок. Часто ошибки не распределяются равномерно, они сконцентрированы в небольшом количестве модулей. В данном случае работает принцип Парето — 80% всех дефектов находятся в 20% модулей.
- Парадокс пестицида. Если запускать одни и те же тесты по кругу, они перестают находить новые ошибки. Нужно пересматривать сценарии и включать разные испытания системы, желательно с привлечением других QA-специалистов.
- Диагностика зависит от контекста. Например, проверка сайта e-commerce отличается от исследования мобильного приложения. Для каждого типа продукта применяют разные подходы и методологии.
- Заблуждение об отсутствии ошибок. Поиск и устранение дефектов не помогут, если созданная система непригодна для использования и не отвечает потребностям и требованиям пользователя.
Разница в тестировании сайта, приложения, интерфейса и сервиса
Рассмотрим отличия в подходах к тестированию веб-продуктов в Атвинте.
Тестирование контентных сайтов и проектов на конструкторах
Во время тестирования мы уделяем внимание базовому функционалу, корректной работе форм, безопасности передачи данных и удобству использования. А также проверяем соответствие дизайна заданным требованиям, кроссбраузерность и адаптивность. QA-инженерам нужно убедиться, что посетителю будет легко ориентироваться на сайте и взаимодействовать с ним.
Тестирование мобильных приложений
Тестируя мобильные приложения мы углубляемся в исследование интерфейса, проверяем совместимость с различными устройствами и операционными системами — Android и iOS. Также изучаем функциональность, уровень безопасности и оцениваем производительность ресурсов.
Тестирование интерфейса сайта
При тестировании интерфейсов анализируем пользовательский опыт, проверяем корректность бизнес-логики и возможные сценарии поведения.
Тестирование личного кабинета
В работе с личными кабинетами мы смотрим на безопасность, юзабилити и функциональность. Тестируем возможности авторизации, восстановления пароля и корректное взаимодействие с персональными данными пользователей.
Тестирование интернет-магазина
Помимо диагностики, которую запускаем для сайтов, приложений и личных кабинетов, мы проводим еще несколько ключевых проверок. Тестируем производительность, API и интеграции, безопасность платежей и личных данных, процесс оформления заказов, корректность отображения цен и наличие товаров.
Тестирование сервисов
Когда речь идет о сложных продуктах, которые не закрываются коробочными решениями, тестирование адаптируется к уникальным требованиям системы, повышенной безопасности и проверке максимальной нагрузки.
Один из таких сервисов — образовательная платформа SMITUP, которую мы разработали для одноименной онлайн-школы. Система помогла масштабировать EdTech-бизнес и объединить процесс обучения в одном пространстве.
На платформе SMITUP мы тестируем масштабные компоненты, проверяем корректную работу сервиса в браузерах и на устройствах, а также наличие багов. После исправления дефектов QA-специалист полностью проверяет сервис, чтобы исключить появление ошибок в других местах.
Наш подход помогает обеспечить положительный опыт с системой, так как в нее заходят пользователи с разных гаджетов и браузеров. Плюс ученики разбросаны по всей России, и сервисом пользуются в том числе ребята из деревень, где интернет может быть слабым.
На платформе уже более 20 000 пользователей, внутри нее запущено 250 курсов. Наш продукт помог заказчику расширить предметную линейку в 4 раза. SMITUP — одна из лучших образовательных площадок в России, на конкурсе Tagline Awards она получила бронзу в номинации «Лучший личный кабинет».
У любого проекта есть определенные задачи и потребности, поэтому мы готовим индивидуальный набор тестов для каждого сервиса.
Наш QA-отдел в Атвинте использует несколько видов и методов тестирования для разных веб-продуктов. На каждом этапе разработки специалисты проводят исследования:
- На старте анализируем требования, изучаем логичность системы и ищем несоответствия.
- После проектирования тестируем пользовательские сценарии, прототипы и макеты, архитектуру базы данных.
- Создаем тест-план и готовим тестовую документацию.
- Затем проверяем функциональные, нефункциональные требования и верстку.
- После исправления багов проводим повторную диагностику — тестирование изменений. Мы проверяем, что внесенные правки действительно решили проблему.
- В конце пишем отчет по итогам тестирования.
Далее подробно рассмотрим виды и методы диагностики.
Функциональное тестирование сайта
Направлен на проверку корректности работы функций и возможностей веб-продукта — делает ли приложение то, что вы запланировали на старте. Наши QA-специалисты тестируют:
- корректную работу ссылок и форм;
- успешность авторизации;
- добавление обратной связи;
- оформление заказа с первого раза;
- удаление товаров из корзины;
- возможность редактирования данных в кабинете и многое другое.
Мы проводим позитивное и негативное тестирование. В первом случае оцениваем сценарий, который был прописан в плане — как ресурс должен работать. Во втором — проверяем различные ситуации, когда пользователь может пойти другим путем или попытаться сломать систему.
К примеру, для крупного металлургического холдинга мы разрабатываем платформу, куда сотрудники и руководители вносят предложения по оптимизации ресурсов на производстве.
Каждая инициатива и ее реализация оценивается с экономической точки зрения. Результаты автоматически подгружаются в отчеты и дашборды. QA-специалисты тестируют корректность формул, расчетов, добавление данных в диаграммы и возможность анализа метрик по периодам, чтобы пользователи могли сравнивать эффективность по каждому предложению, направлению (например, «Закупки» или «Логистика») и по всем компаниям холдинга.
Чтобы исключить бесконтрольное добавление инициатив — мы настроили и проверили роли для всех сотрудников. Когда пользователь вносит предложение, администратор проверяет его корректность, а затем одобряет или отклоняет заявку.
Нефункциональное тестирование сайта
Используется для оценки производительности, надежности и удобства использования продукта. Результат тестирования помогает снизить риски и выяснить, как платформа реагирует на нетипичные ситуации. В зависимости от требований проекта мы проводим ряд тестов.
Производительность (Performance Testing)
Нужен для определения и устранения узких мест производительности в ПО. Мы запускаем следующие тесты:
- Нагрузочное тестирование (Load Testing) — моделирование ситуаций во время плановой, повышенной нагрузки в течении определенного времени. Используется для определения узких мест в системе.
- Стресс-тестирование (Stress Testing) — оценка поведения системы в стрессовых ситуациях и быстроты ее восстановления. Используется для определения пиковых нагрузок, которые способна выдержать система.
- Стабильность или надежность (Stability or Reliability Testing) — проверка устойчивости ПО в течение длительного времени к сбоям.
Юзабилити (Usability testing)
Оценивает удобство взаимодействия с веб-продуктом и пользовательский опыт. Параметры тестирования юзабилити:
- Понимание функционала приложения или сайта.
- Доступность для каждого посетителя.
- Быстрый отклик ПО.
- Дизайн не создает негативных впечатлений и не мешает работе с функционалом.
- Простая навигация и понятный онбординг. Отсутствуют длинные шаги для совершения целевых действий — легко найти иконку корзины и номер телефона компании, разобраться в разделах приложения.
- Обработка ошибок. Если какая-то страница отсутствует или человек введет некорректный запрос — ПО покажет сообщение о проблеме и предложит пользователю выход из ситуации.
Безопасность (Security and Access Control Testing)
Исследует устойчивость к различным видам атак и обеспечивает защиту конфиденциальной информации от утечки. Чаще используется для веб-продуктов, в которых хранятся личные данные клиентов и документы компании.
Наша команда из QA-отдела проверяет уязвимые места, которые могут повлиять на безопасность ПО и репутацию бренда.
- Исключение SQL-инъекций. Один из способов взлома сайта, когда в запрос внедряют SQL-код и получают доступ к данным.
- По истечении сеанса пользователю нужно повторно авторизоваться в системе.
- Обозначение ролей с индивидуальным набором прав для всех пользователей. Это особенно актуально для корпоративных порталов, доступных как для клиентов, так и для сотрудников компании.
- Проверка открытых конфиденциальных данных.
- Тест сторонних интеграций и уязвимых файлов.
- Поиск лазеек в функционале и другое.
Методы проверки
Мы применяем методы, основанные на нашем опыте со сложными и узконаправленными сервисами. Это уникальные разработки тестовой документации, которые помогают снижать риски для бизнеса и создавать качественные веб-продукты.
Конечно, мы основываемся на базовых методах тестирования ПО.
Черный ящик
Black box testing — подход, в котором у тестировщика нет доступа к исходному коду веб-продукта и его внутренней архитектуре. Для достижения целей мы фокусируемся на внешней проверке входящих данных, получении ответов от приложения и сравнении фактических результатов с ожидаемыми, а также делаем упор на улучшение UX и UI для конечного потребителя.
Белый ящик
White box testing же представляет собой открытую систему с доступом к исходному коду и структуре. Основной упор делается на улучшение внутреннего качества веб-продукта. Этот метод позволяет провести более детальные тесты и обнаружить скрытые баги и недочеты в логике работы ресурса.
Серый ящик
Grey box testing — смешанный подход, который сочетает в себе элементы черного и белого ящиков. QA-специалист не имеет прямого доступа к коду, но у него есть описание алгоритма, архитектуры, API, что позволяет разрабатывать более целенаправленные тесты.
Инструменты тестирования
Наш QA-отдел обладает всем необходимым инструментарием для тестирования сайтов, приложений и сервисов.
Снифферы
Применяем анализаторы трафика — такие, как Charles Proxy, Proxyman и Fiddler Classic — для проверки http-запросов, кодов ответов и реакции ресурса. На практике это означает, что мы изучаем запросы и отслеживаем ответы сервера.
Диагностика API
Для проверки API мы используем Postman и Insomnia. Эти инструменты позволяют эффективно оценить взаимодействие различных компонентов и сервисов между собой.
Тестирование UX/UI
Изучаем пользовательский опыт и дизайн с использованием Figma и Pixel Perfect. Они помогают спрогнозировать, насколько удобным и приятным будет взаимодействие с продуктом для конечного пользователя.
Логи и мониторинг
Для анализа логов и информации применяем Devtools, Kibana и Sentry. Это позволяет выявлять и отслеживать возможные проблемы и неисправности в системе.
Эмуляторы устройств
Для анализа мобильных приложений используем эмуляторы — такие, как Android Studio и Xcode. С их помощью проверяется работа ресурсов на различных устройствах и операционных системах.
Проверка производительности
Запуск диагностики производительности осуществляется через JMeter. Мы оцениваем, насколько эффективно и быстро работает веб-продукт при различных нагрузках.
Тестирование достоверности данных
Для проверки корректности данных мы используем инструменты для работы с СУБД: SQL, DataGrip, Beekeeper Studio и phpMyAdmin. Мы должны убедиться, что данные хранятся и обрабатываются корректно.
Этапы тестирования веб-проектов: сайт, приложение, сервис
Анализ требований и матрица тестового покрытия
На старте работы над проектом мы проводим анализ требований, выясняем пожелания заказчика и цели веб-продукта. Создаем матрицу тестового покрытия, где указываем, какие функции и элементы будем проверять. Записываем функциональные и нефункциональные критерии.
Каждый тест автоматически заносится в общие результаты. Это позволяет нам оценить, на сколько процентов выполнена работа: какое количество элементов было проверено и сколько багов обнаружено.
Пример матрицы тестового покрытияУже на этом этапе мы начинаем тестирование: изучаем логику и структуру системы, а также проверяем наличие несостыковок. Если есть проблема, предлагаем пути решения — и за счет этого помогаем ускорить процесс разработки, сэкономить бюджет компании и на выходе создать полезный и качественный веб-продукт.
Тестовая документация
Тестовая документация включает в себя различные документы и схемы, которые помогают проводить диагностику и фиксировать каждый шаг. После анализа требований создаем план тестирования.
План тестирования
Тест-план — это документ, в котором описан объем работ по диагностике. При подготовке тест-плана мы:
- учитываем требования;
- описываем стратегию, цели, результаты и ресурсы для тестирования;
- обращаем внимание на детали проекта;
- записываем критерии входа и выхода — запуск и завершение тестов;
- указываем компоненты, на которые будем обращать внимание;
- кто будет в команде.
После этого приступаем к разработке тестовой документации.
Тест-кейс
Test Case — это алгоритмы действий для проверки работы программы: кнопки, поля ввода, формы.
Мы управляем тестами и анализируем результаты в Test Management System (TMS). Внутри прописываем, что нужно сделать на подготовительном этапе, как провести проверку и что ожидать на выходе. Если факт не соответствует плану — анализируем ситуацию и составляем отчет об ошибке (баг-репорт).
Тест-кейсы создаются для элементов, требующих частых проверок в каждой версии продукта, и для тестов, которые недостаточно покрыть только одним чек-листом.
Чек-лист
Checklist значительно проще и короче, если сравнивать его с тест-кейсами. В чек-лист добавляют компоненты, которые необходимо проверить, но без конкретных шагов. Поэтому QA-специалисты могут использовать разные данные и пути проверки, чтобы находить новые дефекты.
В каждом чек-листе ведем подсчет процента запущенных, успешных, проваленных и заблокированных тестов, которые изначально фиксируются в матрице тестового покрытия.
Юзкейс
Use case — это сценарии взаимодействия пользователя с системой и ее ответные действия. Например, пользователь заполняет данные, а приложение сохраняет их.
Юзкейсы делают в виде текстовых документов и блок-схем. Последний вариант более понятен и удобен для структурирования сложных сценариев.
Процесс тестирования
Этапы тестирования зависят от выбранной методологии разработки ПО, в основном это:
- Водопадная модель (Waterfall). QA-специалист начинает анализировать уже разработанный продукт.
- Гибкая модель (Agile, Scrum, Kanban). QA-специалист совместно с командой работает по спринтам (короткие циклы для решения задач).
Мы проверяем позитивные и негативные сценарии, стремясь найти максимальное количество дефектов и зафиксировать ошибки в баг-репорте. Оформление документа зависит от проекта, но есть обязательные поля:
- Заголовок — суть проблемы.
- Шаги воспроизведения — что сделали, чтобы найти баг.
- Ожидаемый результат — какой итог хотели увидеть на самом деле.
- Фактический результат — что видим, когда случилась ошибка.
- Окружение — браузер, ОС, тестовая среда.
Отладка кода
Чтобы правильно понять и описать дефекты, каждому из них мы присваиваем определенные статусы. Это называется жизненным циклом бага (Bug Life Cycle) — стадии с начала существования ошибки до ее полного разрешения.
QA-отдел обнаруживает дефект, заводит его в баг-трекер. Затем указывают статус ошибки — «Новый», назначают программиста и в ходе проверки прописывают комментарии.
- В работе — ошибка находится в процессе исправления.
- Дубликат (Duplicate) — баг встречается дважды или существует два и более дефекта из-за появления одной проблемы.
- Отклонен (Rejected) — с точки зрения разработчика ошибка не оказывает влияния на систему и не требует дальнейшего рассмотрения.
- Отсрочен (Deferred) — баг исправят в последующих версиях системы, потому что у него низкий приоритет или он не приведет к значительным сбоям на данном этапе разработки.
- Не является багом (Not a bug). Например, изменения в дизайне сайта по желанию заказчика.
- Исправлен (Fixed) — в код внесли изменения и устранили дефект.
Разработчик возвращает работу для ретеста со статусом «Исправлен». Если проблема устранена, специалисты оставляют соответствующие комментарии: «Проверен» (Verified) и «Закрыт» (Closed).
Если дефект появляется снова, задачу переоткрывают (Reopen) — и цикл проверки повторяется.
Отчетность
Отчетность включает следующие материалы:
- Документ с результатами, в котором ссылаемся на критерии входа и выхода и указываем процент выполнения.
- Матрица трассировки требований. В ней прописываем задачи, чтобы посмотреть, все ли тесты были выполнены.
- Отчеты из Test Management System. Дашборд, на котором видно, какой процент тестов был выполнен, что не удалось проверить и сколько времени ушло на диагностику.
Мы всегда подтверждаем актуальность системы — на любом этапе тестирования можно увидеть ее готовность, количество ошибок и классификацию багов.
Дефекты оцениваем по приоритетам:
- Высокий — сильное влияние на процессы, требуется срочно внести правки.
- Средний — ошибки, которые нужно решить на следующем этапе.
- Низкий — мелкие недочеты.
- Блокирующий, который мешает дальнейшей диагностике.
Ошибки
Перечислим типичные дефекты, которые встречаются практически во всех системах:
- Логика. Наша команда находит недочеты в требованиях, что помогает улучшить процесс разработки и снизить количество багов в коде. Мы также обращаем внимание на логические ошибки на этапе проектирования, чтобы убедиться, что сайт будет правильно работать, даже если посетитель использует его нестандартным образом.
- Верстка и адаптивность. Когда клиент приходит с готовой разработкой, мы часто сталкиваемся с проблемой: страница корректно отображается на компьютере, но на смартфоне адаптивность не работает. Мы проводим тщательную проверку, чтобы сайт выглядел хорошо на различных устройствах.
- Кроссплатформенность. Возникают ситуации, когда сайт в одном браузере выглядит, как и было задумано, а в другом что-то идет не так: съезжает контент или не работает анимация. Мы стараемся обнаружить и устранить эти различия.
Подведем итоги
Тестирование является важной составляющей в разработке любых веб-продуктов. Оно обеспечивает высокое качество и надежность программы. Используя разные подходы, инструменты и документацию, QA-специалисты помогают улучшать функционал сервисов и предотвращают серьезные проблемы в их работе.
Проверка веб-продуктов влияет на улучшение пользовательского опыта и финансовые показатели бизнеса. Если не проводить тестирование, можно столкнуться с убытками из-за некачественного сервиса: потеря клиентов, снижение репутации и дополнительные затраты на исправление ПО. Диагностика является неотъемлемой частью разработки и помогает защитить от подобных рисков, и обеспечить развитие компании.
