Зачем тестировать веб-продукты

Содержание

1. Что такое тестирование сервиса
2. Для чего тестируют веб-продукты
3. Семь принципов тестирования
4. Разница в тестировании сайта, приложения, интерфейса и сервиса
5. Функциональное тестирование
6. Нефункциональное тестирование
7. Методы проверки
8. Инструменты тестирования
9. Этапы тестирования
10. Ошибки
11. Что происходит после релиза и зачем продолжать тестирование
12. Подведем итоги

Что такое тестирование сервиса

• поиск несоответствий между фактическим и ожидаемым поведением ПО;
• проверка качества системы, которая проводится на ограниченном наборе тестов.

• верификацию — подтверждение того, что требования выполнены верно. Мы должны ответить на вопрос: «Делаем ли мы продукт правильно?».
• валидацию — соответствует ли ПО своему прямому назначению. Здесь спрашиваем себя «Делаем ли мы правильный продукт?».

С какой целью проводится тестирование сайта

Выявление багов

Обеспечение безопасности

Улучшение пользовательского опыта

Соответствие ожиданиям

Семь принципов тестирования

• Тестирование показывает наличие дефектов, но не их отсутствие. Диагностика сокращает количество ошибок, скрытых в ПО, но обнаружение и устранение проблем не гарантирует, что продукт будет на 100% безошибочным. 
• Исчерпывающее тестирование — невозможно. Нельзя учесть все сценарии, способы и комбинации тестовых окружений в одном продукте.
• Раннее тестирование экономит время и деньги. Чем раньше начнется проверка, тем дешевле обойдется исправление багов.
• Скопление ошибок. Часто ошибки не распределяются равномерно, они сконцентрированы в небольшом количестве модулей. В данном случае работает принцип Парето — 80% всех дефектов находятся в 20% модулей. 
• Парадокс пестицида. Если запускать одни и те же тесты по кругу, они перестают находить новые ошибки. Нужно пересматривать сценарии и включать разные испытания системы, желательно с привлечением других QA-специалистов. 
• Диагностика зависит от контекста. Например, проверка сайта e-commerce отличается от исследования мобильного приложения. Для каждого типа продукта применяют разные подходы и методологии.
• Заблуждение об отсутствии ошибок. Поиск и устранение дефектов не помогут, если созданная система непригодна для использования и не отвечает потребностям и требованиям пользователя.

Разница в тестировании сайта, приложения, интерфейса и сервиса

Тестирование контентных сайтов и проектов на конструкторах

Тестирование мобильных приложений

Тестирование интерфейса сайта

Тестирование личного кабинета

Тестирование интернет-магазина

Тестирование сервисов

• На старте анализируем требования, изучаем логичность системы и ищем несоответствия.
• После проектирования тестируем пользовательские сценарии, прототипы и макеты, архитектуру базы данных.
• Создаем тест-план и готовим тестовую документацию.
• Затем проверяем функциональные, нефункциональные требования и верстку.
• После исправления багов проводим повторную диагностику — тестирование изменений. Мы проверяем, что внесенные правки действительно решили проблему.
• В конце пишем отчет по итогам тестирования.

Функциональное тестирование сайта

• корректную работу ссылок и форм;
• успешность авторизации;
• добавление обратной связи;
• оформление заказа с первого раза;
• удаление товаров из корзины;
• возможность редактирования данных в кабинете и многое другое.

Нефункциональное тестирование сайта

Производительность (Performance Testing)

• Нагрузочное тестирование (Load Testing) — моделирование ситуаций во время плановой, повышенной нагрузки в течении определенного времени. Используется для определения узких мест в системе.
• Стресс-тестирование (Stress Testing) — оценка поведения системы в стрессовых ситуациях и быстроты ее восстановления. Используется для определения пиковых нагрузок, которые способна выдержать система.
• Стабильность или надежность (Stability or Reliability Testing) — проверка устойчивости ПО в течение длительного времени к сбоям. 

Юзабилити (Usability testing)

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

Безопасность (Security and Access Control Testing)

• Исключение SQL-инъекций. Один из способов взлома сайта, когда в запрос внедряют SQL-код и получают доступ к данным.
• По истечении сеанса пользователю нужно повторно авторизоваться в системе.
• Обозначение ролей с индивидуальным набором прав для всех пользователей. Это особенно актуально для корпоративных порталов, доступных как для клиентов, так и для сотрудников компании.
• Проверка открытых конфиденциальных данных.
• Тест сторонних интеграций и уязвимых файлов.
• Поиск лазеек в функционале и другое.

Методы проверки

Черный ящик

Белый ящик

Серый ящик

Инструменты тестирования

Снифферы

Диагностика API

Тестирование UX/UI

Логи и мониторинг

Эмуляторы устройств

Проверка производительности

Тестирование достоверности данных

Этапы тестирования веб-проектов: сайт, приложение, сервис

Анализ требований и матрица тестового покрытия

Тестовая документация

План тестирования

• учитываем требования;
• описываем стратегию, цели, результаты и ресурсы для тестирования;
• обращаем внимание на детали проекта; 
• записываем критерии входа и выхода — запуск и завершение тестов;
• указываем компоненты, на которые будем обращать внимание;
• кто будет в команде.

Тест-кейс 

Чек-лист 

Юзкейс

Процесс тестирования

• Водопадная модель (Waterfall). QA-специалист начинает анализировать уже разработанный продукт.
• Гибкая модель (Agile, Scrum, Kanban). QA-специалист совместно с командой работает по спринтам (короткие циклы для решения задач). 

• Заголовок — суть проблемы.
• Шаги воспроизведения — что сделали, чтобы найти баг.
• Ожидаемый результат — какой итог хотели увидеть на самом деле.
• Фактический результат — что видим, когда случилась ошибка.
• Окружение — браузер, ОС, тестовая среда.

Отладка кода

• В работе — ошибка находится в процессе исправления.
• Дубликат (Duplicate) — баг встречается дважды или существует два и более дефекта из-за появления одной проблемы.
• Отклонен (Rejected) — с точки зрения разработчика ошибка не оказывает влияния на систему и не требует дальнейшего рассмотрения.
• Отсрочен (Deferred) — баг исправят в последующих версиях системы, потому что у него низкий приоритет или он не приведет к значительным сбоям на данном этапе разработки.
• Не является багом (Not a bug). Например, изменения в дизайне сайта по желанию заказчика.
• Исправлен (Fixed) — в код внесли изменения и устранили дефект.

Отчетность

• Документ с результатами, в котором ссылаемся на критерии входа и выхода и указываем процент выполнения. 
• Матрица трассировки требований. В ней прописываем задачи, чтобы посмотреть, все ли тесты были выполнены.
• Отчеты из Test Management System. Дашборд, на котором видно, какой процент тестов был выполнен, что не удалось проверить и сколько времени ушло на диагностику.

• Высокий — сильное влияние на процессы, требуется срочно внести правки.
• Средний — ошибки, которые нужно решить на следующем этапе.
• Низкий — мелкие недочеты.
• Блокирующий, который мешает дальнейшей диагностике.

Ошибки

• Логика. Наша команда находит недочеты в требованиях, что помогает улучшить процесс разработки и снизить количество багов в коде. Мы также обращаем внимание на логические ошибки на этапе проектирования, чтобы убедиться, что сайт будет правильно работать, даже если посетитель использует его нестандартным образом.
• Верстка и адаптивность. Когда клиент приходит с готовой разработкой, мы часто сталкиваемся с проблемой: страница корректно отображается на компьютере, но на смартфоне адаптивность не работает. Мы проводим тщательную проверку, чтобы сайт выглядел хорошо на различных устройствах.
• Кроссплатформенность. Возникают ситуации, когда сайт в одном браузере выглядит, как и было задумано, а в другом что-то идет не так: съезжает контент или не работает анимация. Мы стараемся обнаружить и устранить эти различия.

Что происходит после релиза и зачем продолжать тестирование

• Поиск реальных багов. Некоторые ошибки становятся заметны только при реальном использовании. Тестирование помогает быстро их найти и исправить.
• Проверка нагрузки. После запуска приложения можно столкнуться с наплывом пользователей. Нагрузочное тестирование показывает, справляется ли система с высокой посещаемостью.
• Защита данных. Регулярное тестирование безопасности помогает предотвратить утечки данных и кибератаки.
• Улучшение удобства. Настоящие пользователи могут вести себя иначе, чем предполагалось. Анализ их поведения помогает доработать интерфейс и повысить комфорт работы с продуктом.
• Тестирование обновлений. Любое изменение — новая функция или исправление ошибки — требует проверки. Это снижает риск появления новых проблем.

Подведем итоги