Тестирование сайтов и приложений: разбираем реальные примеры
Любой сайт или приложение нуждаются в тестировании. Сделать это можно вручную или с помощью автотестов. А что лучше для бизнеса? Зависит от ситуации. Меня зовут Ксения, я тимлид команды тестировщиков в Fojin. Расскажу о разных вариантах с примерами из нашей ежедневной практики.
Кратко: что такое ручное и автоматизированное тестирование?
Из названий понятно, что автотестирование основано на работе специализированного ПО при минимальном вмешательстве человека, а мануальное (ручное) целиком полагается на QA-специалиста для написания и выполнения тестов.
Тестировщик цифровых продуктов / QA-инженер использует в работе много узконаправленных инструментов. Необходимость в этом не зависит от специализации. Например, у «ручников» может быть Postman, а у автотестировщиков – Selenium.
QA-специалист, особенно мануальный, не может обойтись и без «общеайтишных» сервисов. К примеру, мы в Fojin обычно используем Confluence для создания единой базы знаний и ClickUp для управления задачами по тестированию.
Confluence: тестировщик расписал план и уже выполнил все тесты. А рядом можно найти ссылки на всевозможную документацию по проекту – очень удобно.
Какие проблемы решает тестирование цифрового продукта:
- Ошибки в UX, которые усложняют навигацию по сайту или приложению;
- Некорректное отображение элементов интерфейса при работе с разных устройств (ноутбук, смартфон и т.д.);
- Баги, из-за которых продукт работает не так, как ожидалось;
- Проблемы с производительностью, из-за которых продукт «тормозит» или не выполняет требуемое действие;
- Неуспешная интеграция со сторонним сервисом (например, не работает оплата онлайн на сайте)
- Проблемы с безопасностью данных, и многое другое.
Так какой же тип тестирования лучше для продукта?
На первый взгляд, специализированное ПО справится быстрее человека и точно не допустит ошибок в процессе. (Спойлер: это не всегда так.) А с другой стороны, ничто не сравнится с работой профессионала, без которого в любом случае не обойтись: даже автоматизированное тестирование предполагает, что нужно сначала написать тесты.
На самом деле однозначного ответа на вопрос нет, потому что необходимо прежде всего изучить конкретный проект и его особенности.
Чтобы проиллюстрировать эту мысль, далее приведем несколько примеров из практики QA-специалистов компании Fojin.
Когда лучше выбрать автоматизированное тестирование?
Ситуация 1
Приложение большое, и тестировать его вручную – долго и дорого для бизнеса. Автотестирование чаще всего используется именно на сложных и крупных проектах.
Кейс из нашей практики
Проект по созданию платформы-агрегатора, где мы настроили полноценные процессы тестирования и написали документацию с нуля. Явно не хватало автоматизированного тестирования, и мы предложили клиенту внедрить эту практику. Были проведены smoke-тесты и регрессионные тесты. Автоматизация позволила ускорить ряд процессов и на треть приблизить большой E2E-тест к завершению. В итоге удалось ускорить прогресс всей команды, улучшить качество продукта и приблизить дату релиза.
Ситуация 2
Приложение сложное, и функционал регулярно обновляется. В этом случае требуется регулярно проводить регрессионное тестирование – чтобы обнаружить баги, которые возникли в уже протестированном коде после обновлений.
Кейс из нашей практики
Приложение для аренды и продажи строительных инструментов имело очень много различных функций, пользовательских путей и сценариев. Автотесты помогали в каждом спринте находить баги и поддерживать в актуальном состоянии информацию о стабильности системы.
Автотесты найдут проблемы, которые может не заметить ручной тестировщик.
Ситуация 3
Необходимо оценить, как система справляется с высокой нагрузкой. Для этого моделируется большое количество пользователей/продуктов, и затем проводится нагрузочное тестирование.
Кейс из нашей практики
Та же платформа-агрегатор, где все процессы тестирования были выстроены нами с нуля. Мы предложили заказчику и успешно внедрили автоматизацию. В первую очередь это помогло с нагрузочным тестированием, т.к. появилась возможность совершать все рутинные действия за пару секунд через API. Это ускорило процесс и освободило время для сложных задач.
Ситуация 4
Проект большой, и планируется развивать его несколько лет. Целесообразно уменьшать ручной труд тестировщиков программного обеспечения и постепенно внедрять автоматизацию. Тестовые сценарии пишутся один раз, а затем используются повторно.
Кейс из нашей практики
Проект по тестированию банковского приложения длится уже более 3 лет, поскольку продукт имеет сложную логику, а также постоянно обновляется и эволюционирует. Частые релизы неизбежно сопровождаются проблемами и багами (например, в результате поломки интеграций). Всё это нужно выявить и устранить как можно оперативнее, иначе клиента ожидают большие потери – в том числе денежные. Поэтому автоматизированное тестирование тут незаменимо: с его помощью время на проверку всей системы сокращается в десятки раз.
Когда стоит использовать ручное тестирование?
Ситуация 1
Нужно полностью протестировать пользовательский интерфейс: оценить удобство и общее впечатление. Адекватно справиться с такой задачей может только человек. Отчет опытного мануального тестировщика можно использовать как обратную связь от потенциального пользователя.
Кейс из нашей практики
Установщик ПО проектировался с нуля командой аналитиков, дизайнеров и мануальных тестировщиков. Продукт предназначался для внутренних процессов, и вначале было неясно, как именно он должен функционировать, чтобы решать определенные задачи. При создании подробного флоу мы выявили несколько неудобных и непонятных пользователю UX-кейсов. Заметить все «узкие места» и неочевидные моменты способен только опытный специалист по мануальному тестированию. Во время и после реализации мы дополнительно провели юзабилити-тестирование. Получилось приложение с довольно сложным функционалом, но пользователь не испытывает трудностей благодаря понятному и удобному интерфейсу.
Ситуация 2
Автоматизированное тестирование по какой-либо причине невозможно или просто нецелесообразно. На начальных этапах разработки происходят частые изменения, тестирование которых вручную – намного удобнее и быстрее для команды, а также дешевле для заказчика.
Кейс из нашей практики
В процессе разработки приложения для E-commerce долгое время не было стабильно работающей сборки, что не позволяло начать проектирование и разработку автотестов. Также была проблема с развертыванием тестового стенда, на котором могли бы прогоняться автотесты. Поэтому мануальный QA-специалист успешно тестировал все сборки на локальном устройстве и находил все баги, даже в очень сырой версии продукта.
В ручном тестировании важен опыт и доля творчества. «Ручник» полностью контролирует качество продукта на всех стадиях разработки и сопровождения.
Ситуация 3
Пользователи сайта или приложения столкнулись с технической проблемой и сообщили в службу поддержки. Используя информацию о проблеме, тестировщики смогут воспроизвести ее и подробно описать для разработчиков, а те уже найдут оптимальное и быстрое решение.
Кейс из нашей практики
Посетители интернет-магазина регулярно жаловались на техническую проблему в процессе оформления заказа. Мы провели серию тестов (запросы к базе данных, совместимость расширений и т.д.) и смогли воспроизвести проблему с оформлением заказа и ошибкой тайм-аута. Затем наши разработчики успешно всё пофиксили. Жалобы от пользователей перестали поступать.
Ситуация 4
Важно проверить работу приложения на разных видах устройств и операционных систем. Ручное тестирование можно успешно проводить даже на таких устройствах, для которых не предусмотрены автотесты: фитнес-браслеты, датчики движения и т.п.
Кейс из нашей практики
Для сервиса потокового аудио была разработана веб-версия и мобильная версия под Android и iOS. Необходимо было проверить корректность работы с аппаратными средствами. Для полноценного ручного тестирования приходилось настраивать эмуляторы под множество версий операционных систем и моделей устройств. Использование эмулятора помогло избежать проблемы маленького парка устройств для тестирования и позволило всё покрыть тестами.
Ситуация 5
Проект небольшой и отличается простым функционалом либо имеет ограниченный бюджет. Там, где не подразумевается сложная логика оплаты, расчетов, вычислений и алгоритмов, не всегда рационально использование автотестов.
Кейс из нашей практики
Для небольшого фермерского приложения, с маленьким бюджетом и небольшой командой разработки, идеально подошла роль мануального тестировщика. Два специалиста по ручному тестированию отлично справились с работой и вывели продукт в релиз.
Мануальный инженер-тестировщик всегда в гуще событий на небольшом проекте, знает все актуальные доработки функционала, сроки релиза и другие детали, а значит, может быстрее реагировать на изменения.
А когда лучший подход – совмещать оба вида тестирования?
Ситуация
Требуется дополнительная ручная проверка для обнаружения ошибок, существование которых нельзя предугадать. Это дает QA-специалисту возможность задаваться вопросом: «А если пользователь сделает вот так, что будет?» и отклоняться от тестового сценария при необходимости.
Кейс из нашей практики
Упомянутое выше банковское приложение – хороший пример тестирования программного обеспечения, когда невозможно обойтись только одним видом специалистов. Мануальные тестировщики на этом проекте создают тестовые сценарии, проверяют новый функционал и решают задачи, которые невозможно автоматизировать. Автотесты ежедневно мониторят состояние сервисов и компонентов фронтенда, а перед каждым релизом помогают покрыть тестами большее число тест-кейсов, и значит, повысить скорость и качество проверки.
Успешное тестирование основано на повторениях и вариациях. С первым отлично справятся автотесты, а второе обеспечит программный тестировщик.
Ежедневные прогоны автотестов позволяют быстро выявить непредвиденные баги системы. Мануальный тестировщик программного обеспечения может обнаружить баги аналитики, найти несостыковки в макетах дизайна и неудобные UX для пользователя, а также предложить продуктовые улучшения.
Если на проекте есть ресурсы для работы ручного и автоматизированного тестировщика – это идеальный вариант. Специалисты будут дополнять друг друга, решать нетривиальные вопросы, помогать в решении любых задач по тестированию. В общем, работа будет максимально эффективной, а количество багов на проде станет минимальным.
Чек-листы, чтобы правильно выбрать
Автоматизированное тестирование подходит, когда:
- Продукт имеет сложную логику;
- В процессе разработки часто вносятся изменения;
- Требуется глубокое тестирование каждой фичи с возможностью настройки запусков тестов;
- Продукт подразумевает много пользователей, и нужен большой регрессионный набор тестов перед релизом;
- Вы планируете добавлять новый функционал или полностью обновлять продукт.
Ручное тестирование лучше, когда:
- Нужно проверить пользовательский интерфейс на логичность и удобство;
- Продукт подразумевает использование на разных устройствах и типах операционных систем;
- У проекта небольшой бюджет, относительно короткий срок разработки и несложная логика, так что за всем удобно следить вручную;
- Требуется быстро воспроизвести несложный баг, о котором сообщили пользователи;
- Вы подозреваете, что автотесты допустили ошибку, и хотите перепроверить важный функционал вручную.
Совместить ручное и автоматизированное тестирование имеет смысл, когда:
- Приложение имеет сложную логику, может использоваться на разных устройствах, включает в себя что-то нетипичное и новаторское, и так далее;
- Проекту уже больше года, и имеются далеко идущие планы по его развитию.
Если у вас есть команда QA-специалистов, провести всестороннее тестирование будет не трудно. Но даже если внутренней команды нет, всегда можно отдать решение этой проблемы на аутсорс. Да, например, к нам.
Задать вопрос или договориться о созвоне: hello@fojin.tech