Кажется, кто если не разработчики или пользователь может найти все недостатки продукта? Нужно просто запустить приложение на всех имеющихся устройствах, пройти все сценарии, нажать все кнопки во всех возможных сочетаниях. В этом случае исследование и тестирование сводится к бета-тестам — интенсивному использованию продукта командой перед выпуском на рынок.
И это распространенное заблуждение, последствия которого можно прочесть среди отзывов в сторах. Главный минус — неполное покрытие, поскольку некоторые случаи предусмотреть во время использования продукта командой практически невозможно.
Чтобы не было тоскливо и больно за бесцельно потраченное время, у роботов тестирование стартует вместе с проектом. Это помогает отловить нетипичные кейсы. Например, Google долго не признавал Крым частью РФ. Мы обнаружили это во время анализа требований, учли при разработке и уберегли абонентов Билайн от роуминга в отпуске, а саму компанию — от волны претензий.
В последние месяцы таких кейсов стало больше — из-за блокировок Роскомнадзора начали падать сервисы Google, в том числе геокодер, который используют многие приложения. Это и произошло во время тестирования. Сервисы, конечно, заработали, но приложение все же использует Яндекс.Карты — так сейчас надежнее.
Проверка идей
Тестирование продукта начинается на этапе проектирования — роботы-тестировщики проводят исследовательское тестирование, проверяют гипотезы, а после проверяют требования на полноту, понятность и непротиворечивость, устраняя дефекты на ранних этапах разработки.
Первая боль тестирования — коммуникации. Когда разработчики пишут одно, тестировщики проверяют другое, а часть багов приходится фиксить на продакшене. Все это звучит и выглядит забавно, но не для клиента.
Так с болью за бесцельно потерянное время, мы выработали и отладили процесс тестирования в привязке к разработке.
Все начинается с тест-дизайна:
- Все написанные требования проходят проверку командой разработчиков и тестировщиков
- После начинаем писать чек-листы для Mock-тестирования, и тест кейсы
- Все тест-кейсы проходят ревью
Мы прорабатываем все возможные сценарии и поведение продукта/системы и только потом тестируем и фиксируем все оплошности (если таковые имеются). И только после исследовательского тестирования и подготовки сценариев стартуют основные функциональные тесты. Цикл за циклом, фича за фичей переделывается до тех пор, пока она не станет идеальной.
Тест-алгоритм
Теперь у нас есть четкий алгоритм передачи сборок в тестирование и только после — в релиз.
- Как только фича готова, она передается в тестирование.
- После первого цикла тестов заводятся баги.
- Приоритезируем баги и решаем что берем в разработку для следующей итерации.
- Разработчики фиксят баги.
- Проверяем фиксы и тестируем фичу.
- Если опять вылезли баги, повторяем шаги 1-5.
- После того как фича протестирована, она готова попасть в список Release Candidat — сюда попадают протестированные функции.
- Весь протестированный функционал собирается в Релизной сборке.
- Сборка передается в отдел QA и попадает на инсталляционное тестирование, регрессионное тестирование и проверка на соответствие требованиям App Store и Google Play.
- QA отдел составляет отчет, и релиз отправляется в стор.
Чтобы оптимизировать само тестирование мы автоматизируем API, мобильные приложение работают со своим middleware — его тестируем в полной мере. Поскольку роботы часто работают с закрытой инфраструктурой банков и страховых компаний, у нас не всегда есть доступ к backend-системам заказчика, в таких случаях для тестирования сквозных сценариев мы пишем автотесты для API и иногда нагрузку.
Несмотря на любовь роботов к алгоритмам, иногда есть смысл в точечной автоматизации, тем более, у нас очень талантливые QA-инженеры. Им мы выдали больше сотни устройств. Сейчас тестировщики могут менять смартфоны и планшеты каждый день — запаса хватит месяца на четыре.
Мы не тестируем на эмуляторах — кто гарантирует, что в них нет багов? Да и у самих устройств есть масса отличий: различные версии операционных систем в сочетании с оболочками Android (например, Huawei и их EMIU), разрешение и диагональ экрана, поля экрана (есть весьма специфичные рамки) и иногда различия в железе. Эмуляторы, увы, не учитывают этих «неожиданных» особенностей
Последний взгляд
Когда приложение готово, баги исправлены, остается проверить продукт на соответствие особым требованиям сторов. Apple традиционно придерживается строгих правил в отношении приложений App Store — сама проверка может занять пару дней, а если сборку завернут, к планируемой дате релиза можно добавить еще дня 3-4. Google традиционно проще и быстрее, но это не означает, что требования можно не читать.
Как этого избежать? Тестировать UI/UX и накапливать экспертизу в области публикации приложений сторах. Например, если в приложении есть поп-ап акции, но на момент проверки она не вступила в силу, Store может завернуть сборку. Проверено роботами.
Ответственность за результат — хороший стимул и мотиватор. Инженеры по тестированию — последняя инстанция на пути к финальному релизу продукта, основной фильтр от всех багов и уязвимостей. Тем более, если подключается к работе не в последний момент.
В заключении процитирую «классика» QA Майкла Фритциуса (Michael Fritzius):
Если убедить менеджмент в необходимости QA невозможно, вооружитесь тем фактом, что успех требует отличного ПО. Если оно у вас есть, все остальное будет. Отличный отдел QA – это ключевой фактор отличного ПО.