Connect with us

Статьи

Качество сборки: как работает QA в Redmadrobot

Как оценить, насколько хорош продукт, отловить все баги и уязвимости? Зачем тестировщики, когда еще нет кода, и причем здесь Крым — рассказывает руководитель отдела QA Redmadrobot Марина Куликова.

Redmadrobot

Опубликовано

/

     
     

Кажется, кто если не разработчики или пользователь может найти все недостатки продукта? Нужно просто запустить приложение на всех имеющихся устройствах, пройти все сценарии, нажать все кнопки во всех возможных сочетаниях. В этом случае исследование и тестирование сводится к бета-тестам — интенсивному использованию продукта командой перед выпуском на рынок.

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

Чтобы не было тоскливо и больно за бесцельно потраченное время, у роботов тестирование стартует вместе с проектом. Это помогает отловить нетипичные кейсы. Например, Google долго не признавал Крым частью РФ. Мы обнаружили это во время анализа требований, учли при разработке и уберегли абонентов Билайн от роуминга в отпуске, а саму компанию — от волны претензий.

В последние месяцы таких кейсов стало больше — из-за блокировок Роскомнадзора начали падать сервисы Google, в том числе геокодер, который используют многие приложения. Это и произошло во время тестирования. Сервисы, конечно, заработали, но приложение все же использует Яндекс.Карты — так сейчас надежнее.

Проверка идей

Тестирование продукта начинается на этапе проектирования — роботы-тестировщики проводят исследовательское тестирование, проверяют гипотезы, а после проверяют требования на полноту, понятность и непротиворечивость, устраняя дефекты на ранних этапах разработки.

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

Так с болью за бесцельно потерянное время, мы выработали и отладили процесс тестирования в привязке к разработке.

Все начинается с тест-дизайна:

  1. Все написанные требования проходят проверку командой разработчиков и тестировщиков
  2. После начинаем писать чек-листы для Mock-тестирования, и тест кейсы
  3. Все тест-кейсы проходят ревью

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

Тест-алгоритм

Теперь у нас есть четкий алгоритм передачи сборок в тестирование и только после — в релиз.

  1. Как только фича готова, она передается в тестирование.
  2. После первого цикла тестов заводятся баги.
  3. Приоритезируем баги и решаем что берем в разработку для следующей итерации.
  4. Разработчики фиксят баги.
  5. Проверяем фиксы и тестируем фичу.
  6. Если опять вылезли баги, повторяем шаги 1-5.
  7. После того как фича протестирована, она готова попасть в список Release Candidat — сюда попадают протестированные функции.
  8. Весь протестированный функционал собирается в Релизной сборке.
  9. Сборка передается в отдел QA и попадает на инсталляционное тестирование, регрессионное тестирование и проверка на соответствие требованиям App Store и Google Play.
  10. QA отдел составляет отчет, и релиз отправляется в стор.

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

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

Мы не тестируем на эмуляторах — кто гарантирует, что в них нет багов? Да и у самих устройств есть масса отличий: различные версии операционных систем в сочетании с оболочками Android (например, Huawei и их EMIU), разрешение и диагональ экрана, поля экрана (есть весьма специфичные рамки) и иногда различия в железе. Эмуляторы, увы, не учитывают этих «неожиданных» особенностей

Последний взгляд

Когда приложение готово, баги исправлены, остается проверить продукт на соответствие особым требованиям сторов. Apple традиционно придерживается строгих правил в отношении приложений App Store — сама проверка может занять пару дней, а если сборку завернут, к планируемой дате релиза можно добавить еще дня 3-4. Google традиционно проще и быстрее, но это не означает, что требования можно не читать.

Как этого избежать? Тестировать UI/UX и накапливать экспертизу в области публикации приложений сторах. Например, если в приложении есть поп-ап акции, но на момент проверки она не вступила в силу, Store может завернуть сборку. Проверено роботами.

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

В заключении процитирую «классика» QA Майкла Фритциуса (Michael Fritzius):

Если убедить менеджмент в необходимости QA невозможно, вооружитесь тем фактом, что успех требует отличного ПО. Если оно у вас есть, все остальное будет. Отличный отдел QA – это ключевой фактор отличного ПО.

Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.