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

- 192.0.2.0/24 (TEST-NET-1)
- 198.51.100.0/24 (TEST-NET-2)
- 203.0.113.0/24 (TEST-NET-3)

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

Подробнее: https://www.rfc-editor.org/rfc/rfc5737.html

Подобное есть и для IPv6: https://www.rfc-editor.org/rfc/rfc3849 Конкретно рекомендуется использовать 2001:DB8::/32. И желательно использовать именно этот диапазон, а не, к примеру, задепрекейченный https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml 0200::/7. Потому что на 0200::/7, который как бы никто не должен использовать ни для чего, сидит сеть Yggdrasil. И это было осознанное решение авторов: https://yggdrasil-network.github.io/faq.html

Домены описаны в https://www.rfc-editor.org/rfc/rfc2606. Там вы встретите и example.com, и .invalid.

Сейчас на Мобиусе был технический доклад, который был на удивление интересным. Но всю дорогу в голове была мысль: "в этом сценарии подошли бы плейлисты, это просто очевидно и на поверхности".

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

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

Да что с вами не так?! Ваш подход к разработке выглядит как та картинка "рандомная херня вперёд".

Если сто тысяч обезьян будут тыкать в клавиши печатной машинки, он случайно могут написать произведения Шекспира. А вы, случайно, попробуете то, что очевидно и рекомендовано.

Страшная новость: троян Хамелеон может обходить андроидную биометрию. А я сижу, такой, и не могу предположить даже, как это можно сделать. Срочно полез читать: https://www.threatfabric.com/blogs/android-banking-trojan-chameleon-is-back-in-action?utm_content=276256774&utm_medium=social&utm_source=linkedin&hss_channel=lcp-28590268

И знаете как? Да никак. Троян, используя Accessibility API нажимает кнопку use pin на экране биометрии. Потому что не может его пройти и принудительно сваливает на другой тип. Ну а то, что если у трояна есть доступ к accessibility api, то можно сушить вёсла - это вообще не новость.

Итого мы имеем просто ЕЩЁ ОДНОГО трояна, использующего тоже, что и примерно несколько сотен тысяч (миллионов?) других.

Димоооооооонд! https://laime-info.ru/catalog/hard-cheeses/parmezan-gold-40-srokom-sozrevaniya-12-mesyaczev

Официальный сайт, как я понимаю.

Отдельно обратите внимание на URL. Покликайте по стрелкам и следите за адресом.

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

Дважды это для вас, если вы ограничиваете длину пароля сверху.

https://text.tchncs.de/umnik/o-paroliakh-i-parol-nykh-frazakh для любителей федивёрса и лёгких страниц (страница весит меньше 400кб)

https://myachinqa.blogspot.com/2024/01/blog-post.html для любителей блогспота (страница весит почти 4Мб)

Впрочем, ничего нового

Прочитал историю успеха одного юноши, который в 19 устроился в фирму (важно - крупная фирма на несколько тысяч сотрудников, а не стартап), а в 21 он уже синьёр.

И вспомнил вот тот вопрос, который процитировал.

Лично для себя за это время я определил такое описание синьёра.

Это сотрудник, который может заменить _любого_ другого человека в команде (имеется в виду в его профильной области, конечно: в нашем случае тестировщик заменяет тестировщика) практически мгновенно. Его не нужно будет обучать - он сразу готов.
При необходимости, этот синьёр в одиночку может заменить ВСЕХ ДРУГИХ членов команды (для небольших команд, на 3-5 тестировщиков) одновременно и никто не заметит, что все остальные исчезли. Сам синьёр, конечно, начнёт лысеть, у него будет дёргаться глаз и трястись руки и так лучше не издеваться над людьми, но такое возможно.

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

Синьёр может поменять направление проекта за пару недель и снова сохранит все описанные выше фичи. То есть сейчас он в мобилочках, а завтра его закинули в веб (или наоборот) и вот он уже в новом направлении всё тот же синьёр и может заменить всех тестировщиков разом в одиночку.

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

В UiAtomator 2.3 исправили несколько проблем, из-за которых я и начал писать свой фреймворк автотестов. Кажется, скоро смогу отказаться от него (ура!).

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

- Поддержали отправку события нажатий нескольких кнопок. Я использовал это в первую очередь для снятия скриншотов ПОЛЬЗОВАТЕЛЬСКИМ способом.

- Теперь правильно будят устройство - через отправку кей эвентов. Если вам приходится писать автотесты на вот тех офигенных телефонах, где на кнопку Power навесили вызов ассистента, вы меня поймёте

- Уменьшили интервал полинга в 10 раз. Надо сказать, радикально. Я уменьшал в 5 раз

- Поддержали матчинг многострочных текстов и описаний https://android-review.googlesource.com/c/platform/frameworks/support/+/2283416

- Наконец вытянули UiDevice#executeShellCommand наружу

- Исправлен NPE для UiDevice#dumpWindowHierarchy

- Для UiObject2#scrollUntil добавили retry

- Уменьшили скорость скроллинга. Надеюсь, уменьшили правильно. Потому что мне приходилось опытным путём подбирать steps у скрола, чтобы всё работало нормально

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

Написал статью о том, что в RuStore лежит настоящий, но неправильный Signal. И что RuStore имеет прям детскую болезнь: он не понимает архитектуру процессора, на котором работает.

Лёгкая версия статьи (в килобайтах, в смысле): https://text.tchncs.de/umnik/rustore-i-podderzhka-raznykh-arkhitektur

Она же, но на блогспоте: https://myachinqa.blogspot.com/2024/03/rustore.html

Вакансию мечты нашёл.

Требования:
- Релевантные для задач проекта
- Опыт в тестировании от 5 лет

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

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

В RuStore отломили открытие экрана нужного приложения через стандартный вызов схемой market

adb shell am start -a android.intent.action.VIEW -d 'market://details?id=ru.dublgis.dgismobile'

Если в системе более одного маркета, нужно выбрать РуСтор. Он должен открыть экран нужного приложения (2GIS), но не сделает этого.

https://developer.android.com/reference/android/app/admin/DevicePolicyManager потеряли закрывающий </i>. Так что до самого Summary всё написано курсивом

Не баг. Пока пишу тест, увидел, что есть приложение с таким вот именем пакета. Представлено и в Gplay, и в F-droid: https://github.com/Semper-Viventem/MetaRadar

Попросил cloud.ru (часть Сбера, как я понимаю) удалить мою учётку. ТП ответили, что удалили, всё в порядке. Это было месяца два назад или больше.
Сейчас проверяю. Регистрируюсь на телефон - говорят, что такой есть. Восстанавливаю пароль по телефону - на моё мыло (то есть оно тоже известно) падает ссылка для установки нового пароля. Прохожу по ссылке - 403: пользователь заблокирован.

Сбер не понимает разницы между удалить учётную запись и заблокировать её.

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

Сегодня получил разрешение на его публикацию, так что вот, прикладываю. 6 страниц в PDF.

Мне будет интересно, с чем согласны, с чем не согласны, а где я вообще нафиг пошёл.

Разумеется, есть некоторая специфика, связанная с именно нашими проектами и нашим багтрекером, но прям таких вещей мало. Старался писать более-менее универсально