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

1. Vysor

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

2. Flipper

Это архитектурная платформа, сейчас у неё есть много полезных плагинов. Например, логи, инспектор слоёв экрана, инспектор сети, профайлер. По сути, он заменяет андроид студию, xcode, снифферы. Возможно, найдёте для себя ещё полезные плагины.

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

3. Airdroid

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

4. Ios snapshot test-case и Shot

Это два инструмента, но они похожи. Один для андроида и второй для иоса. Суть у них простая. Вы делаете эталонные скриншоты и потом запускаете тест на сравнение.

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

5. И последний в списке Flashlight.

Это профайлер. Меряем нагрузку на процессор и оперативную память, смотрим FPS. На мой взгляд, приятнее, чем стандартные в студии и xcode. Но суть у всех профайлеров одинаковая.

Если кто-то знает ещё инструменты, будет интересно послушать.🦄

Что такое GraphQL в мобильках.
GraphQL — это язык запросов для API, разработанный Meta. Он предоставляет полное описание API и дает возможность запрашивать именно то, что им нужно.
Особенность такой системы:
- Серверы GraphQL находятся между клиентом и серверными службами.
- Возможно соединить несколько запросов REST в один запрос.
- Сервер GraphQL организует ресурсы в виде графа.
- Поддерживаются запросы, мутации (изменений данных) и подписки ( уведомления об изменениях схемы).

Если нужно попроще, то REST - это когда запросы едут в персональном авто, а в GraphQL едем в автобусе.

Пример работы запроса есть в картинке.

#интервью #читлист

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

Очень удобно, есть примеры ответов, в том числе и на ситуационные кейсы.

Сохраняйте в копилку!

​​📑 REST API vs GraphQL: в чём между ними разница

"Сегодня в среде разработчиков часто продвигают GraphQL в качестве замены REST, хотя обе технологии можно использовать одновременно. В этой статье Анастасия Иванова, технический писатель платформы МТС Exolve (входит в экосистему МТС), рассмотрит интерфейсы подробнее, чтобы понять, как выбрать подходящее решение под каждый конкретный проект. Подробности — под катом."

Читать статью

Когда разработчик не может воспроизвести баг

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

Что делать, если после тестирования на проде нашлись баги? 🪲🐞

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

1️⃣ Стоит разделить чувство вины и ответственность. Не нужно себя винить и сомневаться в своей компетентности. Это не продуктивно и точно никак не поможет вам в работе. Ошибки допускают все. Как минимум, кроме вас их допустили разработчики, и они вылились в дефекты, которые не были обнаружены в ходе тестирования.

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

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

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

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

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