Путь к надёжности: как QA инженеру действовать в нестандартных ситуациях

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

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

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

Ситуация 1 – Новые баги

Пришёл фикс бага на тестирование, ты его тестируешь основной баг пофикшен, но ты находишь два-три других бага, которых раньше не было. Что делать, какой статус ставить основному багу, куда деть новые?

• Первым делом в такой ситуации стоит отметить, что появились новые баги. Лучше создать отдельные задачи с типом issue, а не писать баги в комментарии.

• После этого, в зависимости от серьёзности текущего и новых багов принимаете решения, это зависит от процессов принятых в вашей компании, но вот возможные пути решения:

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

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

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

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

Ситуация 2 – Не баг, а фича

Вы принесли баг разработчику, он настаивает на том, что это не баг, потому что сделал это специально.

• Первым делом сравните ожидаемый результат с требованиями по задаче.

• Если требований нет, то стоит уточнить правильное поведение у менеджера продукта, либо UI/UX дизайнера, в зависимости от того в какой логике проблема.

• Даже если в требованиях написано, что это не баг, можно с ними не согласиться по объективным причинам. Например, у конкурентов другое поведение, или такое поведение кажется нелогичным или противоречит бизнес-логике приложения. В таких случаях выносите этот вопрос на обсуждение с менеджером продукта.

Помните, что баги встречаются не только в коде, но и в документации и в дизайне.

Ситуация 3 – Запрос доступа к камере

В приложение калькулятора внедряют сканер формул, и поэтому на тестирование принесли задачу, что теперь на старте приложения будет запрашиваться доступ к камере.

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

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

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

  • Android Request runtime permissions | Android Developers

  • iOS Privacy | Apple Developer Documentation 

• Даже если менеджер продукта принял риски и говорит релизить в таком виде, надо удостоверится, что проведут или предложить провести A/B тестирование, чтобы снизить вероятное негативное влияние новой функциональности или убедиться, что его не будет.

Ситуация 4 – Опасные разрешения

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

• Разрешение на установку приложений для Google Play считается чувствительным, и нужно соответствовать особым критериям, чтобы можно было его добавить. Без этого приложение с таким разрешением не допустят до релиза. 

  • Не пропускайте и другие чувствительные доступы которые добавляются в приложение. О чувствительных разрешениях и требованиях для них читайте тут Permissions and APIs that Access Sensitive Information — Play Console Help

  • В iOS такого разрешения нет, однако, стоит изучить политику Apple по другим чувствительным разрешениям тоже  Protecting the User’s Privacy | Apple Developer Documentation 

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

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

Ситуация 5 – Завтра релиз, а ничего не готово

У вашего мобильного приложения релиз послезавтра, а уже через четыре дня запуск, который нельзя отложить. Функциональность в приложении готова к тестированию, но бэкэнд успевает закончить поддержку уже только после релиза — что сделать, чтобы запуск состоялся успешно?

• Тут вспоминайте о моках, протестируйте функциональность, подменяя ответы запросов через сниффер трафика.

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

• Перед запуском фичи, как бэкэнд будет готов, перепроверьте, что новая функциональность работает как ожидается.

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

Ситуация 6 – Не запрашивай лишнего

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

• Не закрывайте глаза на проблемы производительности, особенно, если у вас высоконагруженное приложение, лишние запросы ведут к потенциальным проблемам на бэкенде и производительности приложения.

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

• Если присутствуют сомнения в серьёзности бага ставьте её выше, чем хотите. Лучше ошибиться в большую сторону и подсветить проблему. Понизить приоритет можно всегда, а вот упустить серьёзный баг дороже.

Общие рекомендации и выводы

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

• Ищите компромисс между качеством продукта и задачами бизнеса, ваша задача найти и указать на проблемы, нельзя взять и сказать “я не буду тестировать без бэкенда и точка”.

• Не оставляйте не заведённых багов. Изменить приоритет или вовсе отклонить баг можно в любой момент, а незначительный, на первый взгляд, баг может скрывать серьёзные проблемы. 

• Знайте и изучайте гайдлайны платформ, замечайте если какие-то места в приложении их нарушают, даже если сейчас ваше приложение прошло ревью в следующий раз может не пройти.

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

Делитесь интересными и сложными ситуациями из вашего опыта и предлагайте другие решения для этих проблем. Жду ваших комментариев!

Спасибо что дочитали! Давайте оставаться на связи: можете писать мне в linkedin и подписывайтесь в телеграмм t.me/LilBugHunters