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

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

Тестирование проводят с целью найти программные ошибки (баги) до того, как их найдут пользователи.

Мы разрабатываем проекты по методологии SCRUM. Процесс тестирование на два этапа:

  • Тестирование в спринтах (во время разработки).
  • Тестирование по окончанию разработки (Финальная отладка).

В спринте вместе с разработчиками учувствует инженер по тестированию. Выделяется время на проверку написанного кода и исправление найденных ошибок. Проверять закрытые задача на спринтах - важно. Если вы начнете проверять проект только после окончания программирования (в нашей компании процесс длится 3-4 месяца), то обнаружите много ошибок. Закрытие которых может занять до 30-40% от времени разработки. Проверка закрытых участков во время спринта уменьшает этот процент.

Что такое финальная отладка?

Финальная отладка – это проверка всех элементов системы по окончанию разработки. Наша команда делает проекты с клиент-серверной архитектурой, где присутствуют разные элементы: back-end, frond-end, мобильные клиенты, API и т.д. Когда в конце проекта все сущности системы синхронизируются, могут возникнуть ошибки. Тестирование на этапе финальной отладки – ключевой процесс. Его задача выпустить рабочую системе, где все элементы работают согласно Технического задания.

Кто проводит тестирование и на каком этапе?

Тестирование проводит инженер по тестированию (далее QA). QA ответственный за качество выпускаемого продукта. Именно инженер по тестированию решает готов продукт к релизу или нет. В компании действуют стандарты тестирования мобильных приложений и веб-проектов.

  • Чтобы быть в курсе проекта инженер по тестированию участвует в стендапах (митинги, встречи) каждый день и демонстрациях проекта после окончания спринта.
  • В процессе спринта программист закрывает задачу и переводит ее на QA специалиста.
  • QA проверяет задачу и формирует описание проблем по ней.
  • QA сопровождает баг до его закрытия.

Для описания ошибок мы используем сервис bitbucket.org. Составляющие описания задачи:

  • Экран или страница
  • Версия операционной системы (ОС)
  • Устройство
  • Версия приложения
  • Версия браузера
  • Формат задачи (баг, задача, предложение).
  • Критичность бага (блокирующий, критический, мажорный (важный) или минорный (не важный)).
  • Скриншот, если он есть или другой прилагаемый материал (видео, файлы которые загружались на момент тестирования).
  • Пошаговое воспроизведение бага (подробно и с выводом что не так и как должно быть с ссылкой на техническое задание или дизайн).

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

Виды тестирования

В зависимости от задачи, QA специалист выбирает вид тестирования, инструменты и степень автоматизации. Это оформляется в виде плана тестирования.

Степень автоматизации: ручное тестирование, полуавтоматизированное тестирование, автоматизированное тестирование.

Типы тестирования: приемочное тестирование, дымовое тестирование, регрессионное тестирование, бета-тестирование.

QA выбирает цель тестирования:

  • Инсталляционное тестирование
  • Функциональное тестирование
  • Тестирование производительности (нагрузочное тестирование, тестирование стабильности, объемное тестирование)
  • Стресс-тестирование (тестирование на отказ и восстановление)
  • Юзабилити-тестирование
  • Тестирование интерфейса пользователя
  • Тестирование безопасности
  • Тестирование локализации
  • Тестирование совместимости
  • Тестирование данных и целостности базы данных

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

Перед началом тестирования QA готовит план тестирования, который включает в себя:

  • тестирование UI,
  • тестирование UX,
  • нагрузочное тестирования,
  • тестирование безопасности

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

Вот как этот выглядит:

Что мы проверяем для веб-проектов?

Юзабилити:

  • Сайт должен соответствовать дизайну и прототипу сайта.
  • На момент сдачи сайта каталог должен соответствовать тому, который есть в прототипе.
  • Замечания по удобству использования сайта.
  • Вещи, которые внедрили в проект, но они аномально нагружают систему.
  • Проверяется адаптивность сайта. Используется такие сервисы как http://ipadpeek.com/ и http://beta.screenqueri.es/
  • Скорость загрузки сайта на разных разрешениях.

Нагрузка:

  • Для нагрузочного тестирования используется сервис loadstorm.com
  • Нагрузочное тестирование API, проводится если на сайте используются внутренние или сторонние API.

Валидность:

  • Проверяем сайт на валидацию верстки, используем ресурс http://validator.w3.org/

Кроссбраузерность:

  • Проверяем сайт на всех поддерживаемых браузерах.

Безопасность:

  • Проверяем сайт на наличие вредоносного кода http://antivirus-alarm.ru/proverka/
  • Проверяем сайт на уязвимости http://find-xss.net/ делаем проверку сканерами sql инъекций, xss сканер и find-link

Скорость загрузки и работы сайта:

И другие параметры.

Что мы проверяем для мобильных приложений?

  • Юзабилити
  • Размер экрана
  • Ресурсы телефона (утечки памяти, энергопотребление)
  • Разрешения экрана и версии ОС (Версии ОС, экраны ретина/неретина, GPS, наличие камеры/отсутствие камеры и т.д.)
  • Реакция приложения на внешние прерывания
  • In-app purchases
  • Интернационализация (проверять в портретном и ландшафтном режимах)
  • Постоянная обратная связь с пользователем (реакция кнопок на нажатие, сообщения об ошибках)
  • Апдейты

Требования к составлению тест плана

Полный план тестирования QA готовит после окончания разработки на этапе подготовки к полному тестированию проекта. Документ должен описывать такие пункты:

  • Цель тестирования, описание задачи.
  • Описание составляющих системы.
  • Какие сущности будут протестированы в ходе теста.
  • Окружения, в котором находится тестируемый продукт.
  • Описание узких мест системы.
  • Порядок тестирования системы (список, что за чем нужно сделать).
  • Инструментарий и его назначение (название инструмента и как будем применять).
  • Оценка по затраченному времени (список пунктов с оценкой).
  • Типы и соотношения тестирования (список с оценкой в процентах).
  • Критерии приемки продукта (допустимые проблемы при которых продукт можно выпускать в релиз).

План по тестированию

План включает в себя такие пункты:

  • Элементы системы
  • Окружение
  • Тестовая документация
  • Принципы тестирования
  • Порядок проведения тестирования
  • Узкие места
  • Зависимость сущностей системы
  • Типы тестирования
  • Используемые инструменты
  • Оценка по времени
  • Критерии приемки продукта

Отчет по результатам тестирования

После проведения тестирования составляется отчет.

Работа с серверами для разработки приложения

На проекте есть 3 сервера:

  • Dev – на этом сервере проводится разработка приложения
  • Test – на этом сервере проходит тестирование приложения
  • Prod – на этом сервере делается релиз проекта, только когда он готов.

Разработчик работает и вносит правки на dev сервере. Инженер по тестированию проводит тестирование на test сервере.

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

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

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

Не хотите ждать или возникли дополнительные вопросы?

Мы всегда рады помочь. Звоните:

Москва: +7 (499) 348 28 56
Киев: +38 (044) 393 07 08
Днепропетровск: +38 (067) 787 07 08
>