Качество сборки: как работает QA в 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 – это ключевой фактор отличного ПО.