Привет, я занимаюсь тестированием с 2020 года, вырос со стажёра до старшего инженера по тестированию и пережил многое, от единственного тестировщика в команде до стрессовых ситуаций, где каждая минута на счету. И труднее приходилось в ситуациях, где даже не подозреваешь, что действуешь неправильно.
Сегодня я разберу 6 кейсов, с которыми время от времени сталкивается каждый QA, которые на первый взгляд кажутся не сложными, но потом становится ясно, что они приводят к неожиданным проблемам, незнание которых может сильно осложнить тестирование, а в худшем случае привести к проблемам релиза.
! Некоторые ситуации описаны в специфическом для мобильного тестирования ключе, не будет проблемой переложить эти кейсы на ваши рабочие процессы, но считаю, стоит сразу предупредить.
Ситуация 1 – Новые баги
Пришёл фикс бага на тестирование, ты его тестируешь основной баг пофикшен, но ты находишь два-три других бага, которых раньше не было. Что делать, какой статус ставить основному багу, куда деть новые?
Первым делом в такой ситуации стоит отметить, что появились новые баги. Лучше создать отдельные задачи с типом issue, а не писать баги в комментарии.
После этого, в зависимости от серьёзности текущего и новых багов принимаете решения, это зависит от процессов принятых в вашей компании, но вот возможные пути решения:
Помните, деградация продукта нежелательна, и в скорее всего изначальный баг стоит переоткрыть.
Допустимо принять текущие исправления, а фикс новых багов перенести на следующий релиз, если у изначального бага высокая серьёзность и приоритет, а новые ошибки минорны.
Иногда случаются ситуации, когда фикс одного бага приводит к другому, такое происходит при интеграции с внешними системами - в таких случаях приходится решать, какая из проблем меньше влияет на пользователей и не фиксить её. Не забудьте также оповестить о проблеме разработчиков внешней системы или поднять обсуждение о необходимости собственного решения.
Везде, при решениях ориентируйтесь на процессы в компании и на ответственность, которую можете единолично принять, скорее всего для принятия окончательного решения необходимо будет обсудить это с менеджером продукта и лидом тестирования.
Ситуация 2 – Не баг, а фича
Вы принесли баг разработчику, он настаивает на том, что это не баг, потому что сделал это специально.
Первым делом сравните ожидаемый результат с требованиями по задаче.
Если требований нет, то стоит уточнить правильное поведение у менеджера продукта, либо UI/UX дизайнера, в зависимости от того в какой логике проблема.
Даже если в требованиях написано, что это не баг, можно с ними не согласиться по объективным причинам. Например, у конкурентов другое поведение, или такое поведение кажется нелогичным или противоречит бизнес-логике приложения. В таких случаях выносите этот вопрос на обсуждение с менеджером продукта.
Помните, что баги встречаются не только в коде, но и в документации и в дизайне.
Ситуация 3 – Запрос доступа к камере
В приложение калькулятора внедряют сканер формул, и поэтому на тестирование принесли задачу, что теперь на старте приложения будет запрашиваться доступ к камере.
QA должен не только тестировать задачи, но и обеспечивать качество, а качество это также пользовательский опыт. Нужно как минимум показать риски такого решения, что скорее всего пользователи закроют и удалят наше приложение, увидев такой запрос на старте.
Вторым шагом предложите правильное решение - перенести запрос доступа к месту активации функциональности, так как такой запрос будет понятным и ожидаемым пользователем, чем запрос на старте приложения.
В гайдлайнах магазинов приложений существует требование, объяснять пользователю перед запросом для чего нужен конкретный запрос или сам запрос должен происходить в понятном контексте, если такого пояснения нет, то приложение скорее всего не допустят к релизу магазином приложений.
Даже если менеджер продукта принял риски и говорит релизить в таком виде, надо удостоверится, что проведут или предложить провести 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
