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

Любой сайт или приложение нуждаются в тестировании. Сделать это можно вручную или с помощью автотестов. А что лучше для бизнеса? Зависит от ситуации. Меня зовут Ксения, я тимлид команды тестировщиков в Fojin. Расскажу о разных вариантах с примерами из нашей ежедневной практики.

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

Кратко: что такое ручное и автоматизированное тестирование?

Из названий понятно, что автотестирование основано на работе специализированного ПО при минимальном вмешательстве человека, а мануальное (ручное) целиком полагается на QA-специалиста для написания и выполнения тестов.

Тестировщик цифровых продуктов / QA-инженер использует в работе много узконаправленных инструментов. Необходимость в этом не зависит от специализации. Например, у «ручников» может быть Postman, а у автотестировщиков – Selenium.

QA-специалист, особенно мануальный, не может обойтись и без «общеайтишных» сервисов. К примеру, мы в Fojin обычно используем Confluence для создания единой базы знаний и ClickUp для управления задачами по тестированию.

<p>Confluence: тестировщик расписал план и уже выполнил все тесты. А рядом можно найти ссылки на всевозможную документацию по проекту – очень удобно.</p>

Confluence: тестировщик расписал план и уже выполнил все тесты. А рядом можно найти ссылки на всевозможную документацию по проекту – очень удобно.

Какие проблемы решает тестирование цифрового продукта:

  • Ошибки в UX, которые усложняют навигацию по сайту или приложению;
  • Некорректное отображение элементов интерфейса при работе с разных устройств (ноутбук, смартфон и т.д.);
  • Баги, из-за которых продукт работает не так, как ожидалось;
  • Проблемы с производительностью, из-за которых продукт «тормозит» или не выполняет требуемое действие;
  • Неуспешная интеграция со сторонним сервисом (например, не работает оплата онлайн на сайте)
  • Проблемы с безопасностью данных, и многое другое.

Так какой же тип тестирования лучше для продукта?

На первый взгляд, специализированное ПО справится быстрее человека и точно не допустит ошибок в процессе. (Спойлер: это не всегда так.) А с другой стороны, ничто не сравнится с работой профессионала, без которого в любом случае не обойтись: даже автоматизированное тестирование предполагает, что нужно сначала написать тесты.

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

Чтобы проиллюстрировать эту мысль, далее приведем несколько примеров из практики QA-специалистов компании Fojin.

Когда лучше выбрать автоматизированное тестирование?

Ситуация 1

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

Кейс из нашей практики

Проект по созданию платформы-агрегатора, где мы настроили полноценные процессы тестирования и написали документацию с нуля. Явно не хватало автоматизированного тестирования, и мы предложили клиенту внедрить эту практику. Были проведены smoke-тесты и регрессионные тесты. Автоматизация позволила ускорить ряд процессов и на треть приблизить большой E2E-тест к завершению. В итоге удалось ускорить прогресс всей команды, улучшить качество продукта и приблизить дату релиза.

Ситуация 2

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

Кейс из нашей практики

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

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

Ситуация 3

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

Кейс из нашей практики

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

Ситуация 4

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

Кейс из нашей практики

Проект по тестированию банковского приложения длится уже более 3 лет, поскольку продукт имеет сложную логику, а также постоянно обновляется и эволюционирует. Частые релизы неизбежно сопровождаются проблемами и багами (например, в результате поломки интеграций). Всё это нужно выявить и устранить как можно оперативнее, иначе клиента ожидают большие потери – в том числе денежные. Поэтому автоматизированное тестирование тут незаменимо: с его помощью время на проверку всей системы сокращается в десятки раз.

Тестирование API с помощью инструмента Postman
Тестирование API с помощью инструмента Postman

Когда стоит использовать ручное тестирование?

Ситуация 1

Нужно полностью протестировать пользовательский интерфейс: оценить удобство и общее впечатление. Адекватно справиться с такой задачей может только человек. Отчет опытного мануального тестировщика можно использовать как обратную связь от потенциального пользователя.

Кейс из нашей практики

Установщик ПО проектировался с нуля командой аналитиков, дизайнеров и мануальных тестировщиков. Продукт предназначался для внутренних процессов, и вначале было неясно, как именно он должен функционировать, чтобы решать определенные задачи. При создании подробного флоу мы выявили несколько неудобных и непонятных пользователю UX-кейсов. Заметить все «узкие места» и неочевидные моменты способен только опытный специалист по мануальному тестированию. Во время и после реализации мы дополнительно провели юзабилити-тестирование. Получилось приложение с довольно сложным функционалом, но пользователь не испытывает трудностей благодаря понятному и удобному интерфейсу.

Ситуация 2

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

Кейс из нашей практики

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

В ручном тестировании важен опыт и доля творчества. «Ручник» полностью контролирует качество продукта на всех стадиях разработки и сопровождения.

Ситуация 3

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

Кейс из нашей практики

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

Воспроизвести проблему пользователей – задача как раз для специалиста по ручному тестированию.
Воспроизвести проблему пользователей – задача как раз для специалиста по ручному тестированию.

Ситуация 4

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

Кейс из нашей практики

Для сервиса потокового аудио была разработана веб-версия и мобильная версия под Android и iOS. Необходимо было проверить корректность работы с аппаратными средствами. Для полноценного ручного тестирования приходилось настраивать эмуляторы под множество версий операционных систем и моделей устройств. Использование эмулятора помогло избежать проблемы маленького парка устройств для тестирования и позволило всё покрыть тестами.

Ситуация 5

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

Кейс из нашей практики

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

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

А когда лучший подход – совмещать оба вида тестирования?

Ситуация

Требуется дополнительная ручная проверка для обнаружения ошибок, существование которых нельзя предугадать. Это дает QA-специалисту возможность задаваться вопросом: «А если пользователь сделает вот так, что будет?» и отклоняться от тестового сценария при необходимости.

Кейс из нашей практики

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

Успешное тестирование основано на повторениях и вариациях. С первым отлично справятся автотесты, а второе обеспечит программный тестировщик.

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

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

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

Чек-листы, чтобы правильно выбрать

Автоматизированное тестирование подходит, когда:

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

Ручное тестирование лучше, когда:

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

Совместить ручное и автоматизированное тестирование имеет смысл, когда:

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

Если у вас есть команда QA-специалистов, провести всестороннее тестирование будет не трудно. Но даже если внутренней команды нет, всегда можно отдать решение этой проблемы на аутсорс. Да, например, к нам.

Задать вопрос или договориться о созвоне: hello@fojin.tech

1414
Начать дискуссию