Привет, Хабр. Довольно часто при покрытии различных сервисов автотестами (selenium или appium) нам приходится использовать аккаунты других социальных сетей. Это может понадобиться, например, если мы тестируем регистрацию на нашем сервисе через эту социальную сеть, или авторизацию, шаринг, лайки и так далее.

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

Обычно на должность руководителя проектов в IT-компании требуются люди с опытом от 1 года. Поэтому часто неопытные менеджеры устраиваются на работу аналитиками, тестировщиками, иногда даже разработчиками.

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

В этой статье я делюсь наблюдениями и выводами. Как в одном человеке конфликтуют привычки тестировщика и обязанности руководителя проекта? С какими проблемами приходится сталкиваться? Какую пользу можно извлечь при таком переходе? Если хотите получить ответы на эти вопросы, добро пожаловать под кат.

Коротко о событии
Конференция: Heisenbug 2017 Moscow
Дата: 8-9 декабря 2017 года
Бесплатная трансляция (только первый зал): страница трансляции на официальном сайте.

Какой самый частый вопрос в комментариях на Хабре? «Будет ли запись?» Сразу возьмём быка за рога: запись будет, как всегда, через 3-4 месяца. Но из тех, кто задавал вопрос, смотреть её будет едва ли половина.

Чтобы понять, почему так происходит, нужно разобраться — как мы смотрим видео с конференций, зачем это вообще нужно?

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

ARPDAU (Average Revenue Per Daily Active User или средняя выручка на ежедневно активного пользователя) — важная метрика, которая позволяет не только считать выручку, но и оценивать эффективность любого решения для медиации рекламы. Вот как она рассчитывается:

Автор этой лекции — Константин Заикин kzaikin, руководитель группы разработки Яндекс.Браузера для Android в Санкт-Петербурге. Он рассказал об инструментах Android-разработчика и всей команды, а также о том, как справляться с legacy-кодом, публиковать большой проект вовремя и улучшать качество кода.


— Друзья, привет. Я очень рад, что вас так много сегодня пришло. Я приехал из Питера, в Яндексе работаю около шести лет. Успел засветиться в Картах, Такси, Метрике и Поиске. Уже два года я работаю над Яндекс.Браузером для Android.

«Без разочарований не ощутишь вкус победы» © Мемфис Реймс

История началась банально. В каком то ролике на YouTube рассказывали про каршеринг. С демонстрацией функции «приветствия», когда вам не удается найти автомобиль на большой парковке. У меня тут же возникла мысль проверить — а не смогу ли я активировать функцию приветствия на абсолютно все автомобили этой компании?! Ну весело же. Крупный российский город. И в какой то момент тысячи автомобилей по команде начинают сигналить и моргать фарами. Почти как в фильме «Крепкий Орешек 4».

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

Вступление

Как вы уже, наверное, знаете, 8-9 декабря в Москве пройдёт очередной Heisenbug, поэтому мы решили познакомить Хабр с программой предстоящего события.

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

Почему тебе, дорогой хаброжитель, вообще стоит слушать какого-то маркетолога, который пишет эту статью? Что он может понимать в нашем нелёгком труде? За этой инфой пришлось лезть в самые тёмные глубины LinkedIn: когда-то давно, в 2010 году я устроился в одну небольшую уютную компанию в Новосибирском Академгородке на первую свою работу Java-программистом. Чтобы немножко изучить продукт, руководство поручило ответственную миссию: вручную бегать по интерфейсу нашего веб-приложения, прокликивать кнопочки и выдергивать оттуда ошибки. Довольно скоро мне поручили придумывать тест-планы, а потом и вовсе дали невероятно ответственную задачу: написать совершенно новый фреймворк для автоматического тестирования.

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

Одним из устоявшихся мифов по поводу тестирования является идея, что тестировать ПО — дело как раз для стажеров. Другим мифом можно назвать мысль, что тестированием как таковым называется сам процесс ловли багов, а успешность ловли определяется числом зарепорченных проблем (особенно это актуально для ручного тестирования, а не просто для прогонов автотестов). И тот, и другой мифы весьма живучи не просто среди ИТ-шников, но даже среди разработчиков — факт довольно удивительный, поскольку уж кто-кто, а они кухню процесса создания действительно хорошего ПО знают отлично. Однако живём с тем, с чем живём, остаётся лишь по мере сил менять ситуацию.

Ради такой темы мы пригласили к общению двух специалистов в области тестирования: Никиту Макарова, занимающегося тестированием в Одноклассниках, и Юлию Атлыгину, отвечающую за то же направление в ALM Works.

Мы в GlobalDots используем разные инструменты для увеличения производительности приложений. В списке популярных проблем мобильных приложений часто всплывает низкая конверсия, большой процент обрывов соединений, медленная работа сторонних API. CDN не спасает от всех бед. Мы хотим рассказать о PacketZoom Mobile Expresslane — программном решении ускоренной передачи контента между облаками и мобильными приложениями через собственный протокол на основе UDP для обработки HTTP-запросов вместо TCP/IP.

PacketZoom Mobile Expresslane SDK — не единственное решение своего рода, но оно распространено достаточно широко и умеет решать разные проблемы. В этой статье мы составили выборку из различных кейсов, чтобы вы могли прикинуть, будет ли вам интересен PacketZoom Mobile Expresslane, стоит ли присматриваться к нему дальше.

A/Б-тестирование на сервисах Яндекса проводится постоянно. «Раскатить на такую-то долю аудитории» и посмотреть на реакцию людей — настолько стандартная практика, что ни у кого в команде не возникает вопроса, зачем это нужно. А чтобы не было проблем с самим тестированием, у нас есть специальная инфраструктура для экспериментов. Подробности рассказывают разработчики Сергей Мыц и Данил Валгушев.


Сергей:
— Я попробую упрощенно описать задачу A/Б-тестирования. Есть абстрактная система с пользователями, в нее мы вносим какие-то изменения, и нужно уметь измерять в ней пользу. Пока все просто, но слишком абстрактно. Пример. Есть веб-сервис по сравнению пары фотографий котов. Пользователь должен выбрать наиболее понравившуюся фотографию. При этом он может выбрать не только левый или правый снимок, но и «против всех». Значит, мы подобрали картинки не очень хорошо. Наша задача — обоснованно улучшать сервис, доказывая это цифрами.

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

Не так давно свет увидел World Quality Report 2017–2018 (Мировой стандарт проверки качества), выпущенный благодаря совместному труду сразу нескольких крупных компаний (Capgemini, Sogeti и Micro Focus), в котором было отмечено ряд интересных трендов в разработке и тестировании программного обеспечения. Авторы этого отчета считают, что основные направления в развитии разработки ПО заключаются в постоянном совершенствовании автоматизации тестирования и повсеместном применении гибких и DevOps-методологий (методология, которая объединяет в себе работу программистов и системных администраторов). Так, в данном отчете указано, что компаниям необходимо внедрять интеллектуальную автоматизацию и смарт-аналитику, для того чтобы ускорить процессы принятия ключевых решений и валидации продукта. Благодаря таким нововведениям компании смогут более эффективно справляться с тестированием интеллектуальных устройств нового поколения и высокоинтегрированных продуктов, изменения в которые вносятся постоянно. В отчете также говорится о необходимости создания интеллектуальных платформ для тестирования, характеризующихся высоким уровнем адаптивности. Благодаря таким платформам можно будет обеспечить эффективную поддержку полного жизненного цикла приложения.

Что такое тестируемый код? Каких правил стоит придерживаться для его написания? Как начать писать такой код, если кодовая база к этому не готова?

Статья с большим количеством примеров кода и иллюстраций, в основе которой – выступление Антона на конференции Mobius 2017 в Питере. Антон является разработчиком Android-приложений в Juno, и в своей работе затрагивает множество смежных технологий. Этот доклад не об Android и не о Kotlin, он о тестировании в целом, об идеях, которые лежат над платформой и над языком и которые могут быть адаптированы к любому контексту.

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



В основе статьи – выступление Яна на июньской конференции Heisenbug 2017 в Питере. Ян занимается тестированием более двадцати лет. В настоящее время он работает тест-менеджером для приемочных тестов в голландской компании по стандартизации Squerist. Этот доклад о самых разных подходах к тестированию: от детальной проработки сценариев и до исследовательских туров, от сессионного тестирования и до поиска ошибок совместно с пользователями. Его цель – помочь вам повысить профессионализм, обратив внимание на те методы, которые вы до сих пор не использовали.

Так получилось, что инструменты DevOps обычно иллюстрируются на примере CI/CD какого-то масштабного веб-сервиса. Отчасти так получилось по историческим причинам, отчасти свою роль сыграли замечательные книги типа Google SRE Book.

К черту, давайте посмотрим на что-нибудь действительно новое. На Mobius 2017 к нам приезжает Jing Li из Viacom, с докладом «Android meets Docker».

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

— У нас дыра в безопасности.
— Ну, хоть что-то у нас в безопасности.

— Айфоны, вон, каждый год ломают, и ничего.

Я нашел эту ошибку случайно. Уверен, что ни один тестировщик и не подумал бы пойти таким путем — это настолько не очевидно, дико и непредсказуемо, что только случайность помогла мне поучаствовать в bug bounty от Xiaomi. В этом посте расскажу о том, как мне это удалось, что за это было и почему китайские сервисы — зло.

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

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

Привет тебе, хабр! Меня зовут Максим и я работаю в отделе QA компании Trinity Digital. В сфере обеспечения качества я уже более двух лет, люблю мобильные приложения, их сложность и динамичность. В этой статье я попытался сделать относительно небольшой список инструментов, источников информации и скилов, которые тестировщик мобильных приложений всегда должен иметь при себе в нашем 2к17 году.

Если разбить статью на части, то она будет выглядеть так:

• Источники информации для максимально успешного тестирования
• Инструменты для упрощения жизни тестировщика
• Hint’ы
• Доставка и анализ приложений
• Куда расти дальше, если постигли дзен

26 августа прошёл первый Avito Automation meetup. Говорили о проблемах управления тестами, векторах развития систем автоматизации тестирования, эффективности каждого из тестов, инструментах для тестирования iOS-приложений и запуске тестов в Continuous Integration. Под катом — видеозаписи и слайды докладов, отзывы слушателей и ссылка на фотоотчет.

Привет, Хабр! Меня зовут Виталий Котов, я работаю в Badoo в отделе QA, занимаюсь автоматизацией тестирования, а иногда и автоматизацией автоматизации тестирования.

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

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

Статья ориентирована на тестировщиков, которых просят провести ревью ТЗ и найти в нём несоответствия, и на аналитиков, которым разработчики после прочтения ТЗ часто задают вопросы формата: «А что должно быть, если …?».