Привет, Хабр!
Это вторая часть статьи о Kafka (первая тут). Давайте продолжим разбираться.
Итак, часто тестирование сводится к эмуляции работы сервиса и наблюдением за топиками кафки. Для этого необходимо подключиться к кластеру кафки с теми же правами доступа, что и у вашего сервиса либо сервиса, с которым у вас интеграция (креды для кластера обычно подсказывают коллеги-разработчики, девопсы, тестировщики)...
Статья для начинающих QA посвящена распространенной проблеме рутинных задач в тестировании (дейли, отчеты, анализ требований, регресс, воспроизведение багов, подготовка данных, коммуникация). Автор с юмором описывает эти ситуации и предлагает практические решения, подкрепленные ссылками на книги по управлению проектами и тестированию. Советы включают автоматизацию, оптимизацию процессов, развитие, делегирование и поиск смысла в работе.
Для мобильных приложений, отображающих критичные данные хорошей практикой будет запретить делать снимки и запись экрана в областях отображающих конфиденциальную информацию. Иначе злоумышленники могут получить доступ к паролям или карточным данным при помощи вредоносного ПО, которое, например, делает записи экрана или скриншоты.
В этой статье мы рассмотрим способы защиты мобильных приложений от снятия критичной информации. Хотя в интернете можно найти материалы на эту тему, многие из них либо недостаточно подробны, либо устарели.
Привет! Я — Таня Рашидова, QA тимлид в KODE. Я думала, что все тестировщики уже давно внедрили AI в свою повседневную работу. Но недавно выяснила, что многие либо не пробовали, либо попробовали, запутались, не получили вау-результата и забросили. Раз уж я уже объяснила, как использую AI в работе нескольким коллегам, решила оформить опыт в статью. Может, кому-то из вас она сэкономит время и силы.
Привет! Меня зовут Дима Баранов, я занимаюсь мобильной автоматизацией в Битрикс24. Мы разрабатываем и поддерживаем приложения для огромной пользовательской базы, и без мобильных автотестов тут не обойтись. Сегодня я расскажу, как мы решили одну из самых неприятных (из интересных) проблем в автоматизации iOS-приложений — работу с системными запросами разрешений. Сами события возникли еще год назад, но хочется об этом рассказать. Если вы сталкивались с тем, что тесты падают из-за неожиданно появляющихся системных диалогов — эта статья может вам помочь.
Всем привет! Меня зовут Ира, я руковожу отделом тестирования мобильной платформы в Ozon Tech. Наш отдел занимается разработкой инструментов для автоматизации тестирования мобильных приложений Ozon и тестированием внутренних библиотек.
До того как прийти в компанию, я занималась мобильной разработкой и знаю, какие вопросы задают разработчикам на собеседованиях. Про многопоточность разработчика точно спросят, но у QA-инженеров про работу процессов и потоков в мобильных приложениях мы, как правило, не спрашиваем. На мой взгляд, в этом имеет смысл разобраться, чтобы эффективно взаимодействовать с разработчиками и говорить с ними на одном языке.
В этой статье расскажу о том, как приложение работает «под капотом», что такое многопоточность, какие потоки бывают, и какие ошибки, связанные с реализацией многопоточности, могут возникать в приложении.
Тестирование кода, особенно в сложных системах, зачастую затруднено из-за зависимости от реальных баз данных, внешних сервисов или действий пользователей. Чтобы упростить тестирование, используют заглушки — это упрощенные версии реальных компонентов, которые помогают проверить работу системы без необходимости запускать всё "по-настоящему".
Всем привет! Попарное тестирование (pairwise testing) - одна из самых распространённых техник тест дизайна. Уверена, вы уже про неё читали в книгах, сертификациях, статьях…
В этой статье хочу рассказать о том, на чём основана данная техника, почему она так распространена, пояснить принцип, разобрать примеры и инструменты, которые помогают автоматизировать процесс тест дизайна.
Привет, Хабр! С вами снова Ольга Султанова, руководитель отдела тестирования Рунити. В этот раз расскажу, как мы автоматизировали рутинные задачи в нашем отделе с помощью собственного бота, сократили работу над почти десятью мелкими задачами, сосредоточились на более важных делах и стали регулярно отмечать дни рождения в команде. А еще подсветим проблемы. Статья будет полезна, прежде всего, тимлидам, тестировщикам и разработчикам. Подробности под катом.
Ещё несколько лет назад любое приложение, установленное на устройство с Android, могло без разрешений видеть все остальные приложения.
В 2022 году, с выпуском Android 11, Google удалила этот доступ для разработчиков приложений. Согласно новой политике видимости пакетов, приложения должны видеть другие приложения только в том случае, если те необходимы для их базовой функциональности. Кроме того, разработчики должны явным образом объявлять эти приложения в обязательном для всех приложений Android файле конфигурации AndroidManifest.xml.
В крайних случаях, например, для диспетчеров файлов, браузеров и антивирусов Google предоставляет исключение в виде разрешения QUERY_ALL_PACKAGES, которое позволяет видеть все установленные приложения.
На своём основном телефоне я не пользуюсь Android, но у меня есть запасной, и мне стало очень любопытно, какие приложения индийских компаний содержат проверки других установленных мной приложений.
Я скачал несколько десятков пришедших мне в голову приложений и начал изучать их файлы манифестов. Они ведь наверняка будут уважать мою конфиденциальность и запрашивать только те приложения, которые необходимы для их базовой функциональности?
Собеседование — это не только способ проверить кандидата, но и возможность для интервьюера прокачать свои навыки, расширить кругозор и повлиять на состав команды. Если выстроить процесс правильно, то можно превратить собеседование из рутины в интересную и полезную задачу.
Меня зовут Сергей Лебедев, я QA Lead в Яндекс Лавке. И сегодня я расскажу как подготовиться к интервью, если у вас мало или совсем нет опыта в найме и отборе кандидатов. Какие вопросы задавать, как анализировать ответы кандидатов и принимать взвешенные решения, чтобы собеседование проходило комфортно и эффективно для всех участников.
Неприятная ситуация: продукт проходит тщательную проверку на всех этапах разработки, а после релиза всё равно возникают неожиданные ошибки… А ведь это происходит, потому что тестирования на ранних стадиях (shift-left testing, «влево») не всегда достаточно, чтобы гарантировать стабильность продукта. Поэтому важно учитывать и тестирование в продакшене (shift-right testing, «вправо»).
В этой статье решил разобрать оба подхода и рассказать, в чём преимущества каждого из методов, какие проблемы они решают, а какие нет, и как их комбинировать.
Я люблю историю развития компьютерной индустрии. На днях мне попался к чтению цикл статей «Удивительный и забытый Palm», в которых рассказывалось, как Palm, Inc. удалось создать класс устройств на новой мобильной ОС — Palm OS, которые сначала захватили 80% рынка карманных компьютеров, а после ушли в забвение из-за принятия некоторых неверных решений и скорого прихода iOS/Android.
Однако тот цикл был посвящён в первую очередь самим устройствам и операционной системе. Меня же особо привлекла ссылка на «Zen of Palm» — брошюру, содержащую философию и руководство компании Palm по разработке приложений для устройств на Palm OS.
Авторы исследовали, как должны работать КПК, чтобы пользователям было удобно ими пользоваться. Концепции, лежащие в данном документе, не теряют своей актуальности, и даже наоборот — о многих из них забыли как разработчики приложений, так и производители смартфонов. Руководство направлено на создателей приложений, которые привыкли разрабатывать большие программы, и рассказывает, как уместить большие возможности и удобство в компактные устройства.
Удивительно, как столь проработанный документ почти не имеет упоминаний в современном интернете, особенно в его русскоязычной части. Текст, который вы прочитаете ниже, является несколько вольным переводом этого документа — с сокращением многочисленно повторяющихся или малозначимых тезисов, а также с добавлением описания тех возможностей, которые не были указаны в изначальном тексте, и о которых не знает сегодняшний читатель.
Всем привет!
В этой серии из нескольких статей мы разберемся, что делать тестировщику на проекте с кафкой (как впервые, так и имея какой-то опыт). Здесь я не буду говорить о брокерах и zookeeper-ах, о том, как развернуть кафку. Но мы разберемся, как её настроить и как с её помощью тестировать ваши микросервисы.
Начнём с «базы» (точнее, теории).
Apache Kafka — распределённый программный брокер сообщений с открытым исходным кодом, разрабатываемый в рамках фонда Apache на языках Java и Scala.
Меня зовут Александр Чекунков, я — Android‑разработчик в СБЕРе. Занимаюсь разработкой CSI‑опросов в мобильном приложении «СберБанк Онлайн».
Во многих крупных компаниях написание unit‑тестов является ключевым этапом при разработке нового функционала. Тесты позволяют выявлять ошибки на ранних стадиях, служат своего рода документацией, помогая другим разработчикам быстрее понять, как должен работать тестируемый компонент системы. Также, в отдельных случаях, тесты помогают выявить и минимизировать зависимости между частями кода, что упрощает его поддержку и развитие.
Но для того чтобы получить максимальную пользу от unit‑тестов, важно писать их правильно. В этой статье мы обсудим best practices, применяемые командой СБЕРа для написания тестов, и рассмотрим подходы для повышения их эффективности.
Как использовать в тестировании ИИ? Как тестировать сам ИИ? И главное: как не завязнуть в излишнем хайпе вокруг ИИ, а совершенствоваться и в «нехайповых» темах вроде безопасности или нагрузки?
Мы уже много лет проводим конференцию по тестированию Heisenbug. Если посмотреть, как менялась программа с годами, получится срез актуальных для индустрии вопросов, который постепенно изменялся со временем. Например, можно проследить, как с определённого момента среди тем появилось название Playwright, и никуда уже не делось (вот и в этот раз встретится).
В апреле проведём конференцию снова. Те, кто размышляют над посещением, могут из этого хабрапоста узнать краткие описания докладов. А те, кто идти не собираются, могут всё равно пробежаться глазами и понять, какие темы сейчас актуальны (и добавить в комментариях, о чём ещё хотели бы послушать).
В программу ещё вносят последние детали, и отдельные доклады здесь не описаны — пусть тогда они будут секретом-сюрпризом.
Жизнь каждого человека складывается по-разному: кто-то с 16 лет уже четко знает, что ему интересно, а кто-то приходит к этому гораздо позже. Я отношусь ко второму типу. Отучившись в вузе и не проработав ни дня по профессии, я находилась в постоянном размышлении, к чему у меня лежит душа, что может приносить стабильный доход, что будет с этим миром и где в нем мое место. Я пошла в продажи, основываясь на принципе “Нужно попробовать, а дальше посмотрим”. Но продажи не вдохновляли меня от слова “совсем”. Жизненный опыт постепенно накапливался, но у меня не было никаких идей, как реализовать свои хотелки. И вот в очередной раз я начала новую главу своей жизни, пытаясь следовать своим потребностям и мечтам, - я занялась машинным обучением ИИ. В этой статье я расскажу, как я осваивала профессию тестировщика программного обеспечения.
Привет, Хабр! На связи Николай Анисеня из отдела перспективных технологий Positive Technologies. Так вышло, что в компании я уже много лет занимаюсь безопасностью мобильных приложений, исследую тренды этого направления и, как и все, наверно, специалисты в этой области, ломаю голову: как сделать мобильное приложение более защищенным. Этой публикацией я открываю цикл статей на тему безопасности мобильных приложений и устройств, корень которой (начнем со спойлера!) — в анализе кода. В этой статье расскажу об угрозах мобильных приложений, сценариях атак на них и о главном парадоксе в их разработке. Интересно? Тогда погнали!
Пирамида тестирования — это модель, помогающая сбалансировать юнит-, интеграционные и UI/E2E-тесты по скорости, затратам и эффективности. В статье разбираются классическая пирамида (Майк Коун), песочные часы (Маурисио Аниче), перевернутая пирамида и гибридные подходы, востребованные в Agile и DevOps.
Особое внимание уделено перевернутой пирамиде: несмотря на ее неэффективность в классическом тестировании, она применяется в геймдеве, мобильной разработке и AR/VR, где критически важны UI и пользовательские сценарии.
Также рассматривается связь тестирования с DevOps и CI/CD: как распределение тестов влияет на скорость релизов, стабильность пайплайнов и качество продукта. В статье есть практические рекомендации по автоматизации, параллельному запуску, контрактному тестированию и CI/CD-интеграции.
Ссылки на авторитетные источники — включая Continuous Delivery (Хамбл, Фарли) и Agile Testing (Грегори, Криспин) — помогут глубже разобраться в теме.
