Привет, хабрасообщество.

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

Этот инструмент — приложение FoneMonkey от фирмы Gorilla Logic. Как ни странно, не нашла упоминаний о нем в рунете. Хотя приложение может оказаться очень и очень полезным для многих разработчиков/тестировщиков/etc.

Наша новая статья представляет собой список рекомендаций и советов. Из неё вы узнаете:

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

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

Как облегчить процесс тестирования?

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

• Набор интеллект-карт на все случаи жизни: test insane, ministry of testing
• Эвристики, мнемоники: I SLICED UP FUN (моя любимая), COP FLUNG GUN, SFDPOT, LONG FUN CUP

2. Скриншоты, логи и видео — лучшие аргументы тестировщика!
К сожалению, с логами «общения» с сервером зачастую не всё так гладко, как с клиентскими логами. Обычно они добавляются скорее для удобства разработчика при отладке работы с сервером, чем для работы тестировщика.

В северном полушарии настало лето! А это означает, что к публикации в Google Play теперь предъявляются новые требования. За прошедшие годы было несколько обновлений требований для публикации новых приложений. А также обновлений для Google Play. В этом году все сводится к обновлению вашего приложения до работы на Android 10 (API 29). Ниже приведены важные даты, которые должны быть восприняты всерьез всеми разработчиками.

Требования и даты по Android 10

• 3 августа 2020 г. — новые приложения должны быть ориентированы на Android 10 (API 29).
• 2 ноября 2020 г. — все приложения и обновления приложений должны быть ориентированы на Android 10 (API 29).

Сегодня давайте пройдемся по обновлению существующего приложения Android, чтобы оно полностью соответствовало требованиям.

1. Введение

Недавно встала задачка периодически проверять, все ли события в мобильном приложении работают корректно, передаются ли в AppMetrica.

Подробности интеграции я опущу, имеется в виду, что она уже есть в МП.

Для проверки нашел два варианта:

• через web интерфейс
• через API

Если одно-два события можно посмотреть на web интерфейсе, то, когда их десятки и сотни, без API уже не обойтись.

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

В этой статье рассматривается создание достаточного простого автотеста. Статья будет полезна начинающим автоматизаторам.

Материал изложен максимально доступно, однако, будет значительно проще понять о чем здесь идет речь, если Вы будете иметь хотя бы минимальные представления о языке Java: классы, методы, etc.

Давайте представим себе гипотетическую ситауацию (в которой мы регулярно оказываемся). Вас назначили на проект «запилить» автоматизацию. Вам дают огромный тест план с большим количеством (тысячи их!) «ручных» тестов, и говорят что надо что-то сделать, и вотпрямщас. А еще, чтоб быстро и стабильно.

Писать Unit тесты, или даже думать о TDD — уже поздно, код продукта давным-давно написан. Ваше слово, товарищ автотестер!



К счастью, есть небольшой трюк, который позволит и coverage повысить, и сделать тесты стабильными и быстрыми — Subcutaneous tests («подкожные тесты»), но обо всем по порядку.

Часть 1: Web / Android

Примечание: данная статья является переводом на русский язык оригинальной статьи «DevOps tools are not only for DevOps. Building test automation infrastructure from scratch». Однако все иллюстрации, ссылки, цитаты и термины сохранены на языке оригинала, чтобы избежать искажения смысла при переводе на русский язык. Желаю вам приятного изучения!

В интернете масса информации об A/B-тестированиях, но многие до сих пор проводят их неправильно. Ошибиться действительно легко, поэтому подобные исследования требуют серьезной предварительной подготовки. В этой статье рассматриваются основные аспекты A/B-тестирования, которые необходимо учитывать для эффективного анализа веб-страниц.

Что такое A/B-тестирование?

A/B тестирование (сплит-тестирование) разделяет трафик в соотношении 50/50 между разными версиями страницы. По сути, этот метод — новое название для старой техники, известной как «контролируемый эксперимент».

Для проверки эффективности новых лекарств специалисты проводят сплит-тесты. Фактически, большинство исследовательских экспериментов можно назвать A/B-тестированием. Они включают в себя гипотезу, основной объект исследования, его вариацию и результат, представленный в виде статистических данных.

Вот и все. В качестве примера можно привести простое A/B-тестирование, при котором трафик в соотношении 50/50 делится между основной страницей и ее вариацией:

Привет, меня зовут Александр Васин, я бэкенд-разработчик в Едадиле. Идея этого материала началась с того, что я хотел разобрать вступительное задание (Я.Диск) в Школу бэкенд-разработки Яндекса. Я начал описывать все тонкости выбора тех или иных технологий, методику тестирования… Получался совсем не разбор, а очень подробный гайд по тому, как писать бэкенды на Python. От первоначальной идеи остались только требования к сервису, на примере которых удобно разбирать инструменты и технологии. В итоге я очнулся на сотне тысяч символов. Ровно столько потребовалось, чтобы рассмотреть всё в мельчайших подробностях. Итак, программа на следующие 100 килобайт: как строить бэкенд сервиса, начиная от выбора инструментов и заканчивая деплоем.



TL;DR: Вот репка на GitHub с приложением, а кто любит (настоящие) лонгриды — прошу под кат.

Приглашаем инженеров по тестированию и всех сочувствующих на первый DINS QA EVENING в онлайн-формате. Встречаемся 21 апреля в 19:00.

На встрече Виталий Сидуков из DINS расскажет, как оптимизировать работу с API и начать применять Postman в работе. Артём Ерошенко из QametaSoftware поделится способами оценки покрытия тестов, написанных автоматизаторами тестирования.

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

Под катом — подробная программа и информация о спикерах.

На конференциях и в неформальных беседах на работе нет-нет да и возникает разговор о важности работы QA-инженера и его роли в проекте. Это может быть и робкий вопрос коллеги-программиста «А, может, выпустим без QA?», и объёмный доклад.

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

Привет! Давайте поговорим о том, как сейчас в 2020-ом году можно протестировать мультиязычное iOS приложение, если не хочется проверять локализацию вручную.

Техники управления временем и различные системы учёта ежедневных задач интересовали меня с первых дней работы в офисе. Матрица Эйзенхауэра стала спасением от трясины рутинных дел, и в первое время уберегала от неэффективного использования рабочего времени. Но, спустя несколько месяцев, количество задач увеличилось настолько, что методика квадрантов показала свои слабые места. Для того, чтобы лучше их рассмотреть, вспомним принцип построения Матрицы Эйзенхауэра. Две оси: срочность и важность, и 4 квадранта соответственно:

• срочно и важно
• срочно и не важно
• не срочно и важно
• не срочно и не важно

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

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

Привет, Хабр! Мы в Wrike тестируем новые форматы технических мероприятий и приглашаем всех посмотреть видео нашего первого онлайн-митапа на английском. Поговорили про DevOps инфраструктуру для тестирования веб-приложений, кубы, Selenium и его альтернативы.

Недавно мы с коллегами были на TeamLeadConf — это конференция об управлении, мотивации, найме, процессах и других штуках, полезных тимлидам.

Обычно после конференций мы делимся впечатлениями с теми, кто на конференцию не пошел. Самый популярный формат — список топовых докладов с краткими заметками, который рассылается в Слаке и по почте.

В этот раз я написала такой обзор для коллег и подумала: а почему бы не опубликовать эти заметки для всех? Так текст на Вики переродился в эту статью.

Работа программиста настолько сложна и разнообразна, что в ней просто не обойтись без помощи различных инструментов. Подготовил список из 34 полезных расширений Google Chrome, которые облегчат вашу жизнь и сэкономят время.



1. Octotree

Если вы любите GitHub и помногу читаете код, то, вероятно, знаете, как неудобно устроен обзор GitHub-файлов онлайн. Теперь этот процесс можно упростить при помощи расширения Octotree. Здесь предоставляется панель инструментов с удобной навигацией, также поддерживающая приватные репозитории.

2. PerfectPixel by WellDoneCode

Это расширение позволяет разработчикам накладывать изображения полупрозрачным слоем поверх HTML и делать попиксельное сравнение.

3. GitHub Repository Size

Удобный и простой плагин, отображающий как объем отдельного репозитория, так и размер кажого файла в нем.

Сегодня мы открываем исходный код testsuite — фреймворка для тестирования HTTP-сервисов, который разработан и применяется в Яндекс.Такси. Исходники опубликованы на GitHub под лицензией MIT.

С помощью testsuite удобно тестировать HTTP-сервисы. Он предоставляет готовые механизмы, чтобы:

• Взаимодействовать с сервисом через вызовы его HTTP API.
• Перехватить и обработать HTTP-вызовы, которые сервис отправляет во внешние сервисы.
• Проверить, какие вызовы во внешние сервисы сделаны и в каком порядке.
• Взаимодействовать с базой данных сервиса, чтобы создать предусловие или проверить результат.

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


Под катом — наши размышления выводы. А родились они из того, что нас постоянно сравнивают с TimePad. По крайней мере, припоминают нам его, когда хотят за что-то поругать. И мы с этим живем. Дожили до почти миллиона зарегистрированных участников и можем кое-что об этом рассказать.

Год назад компания Axelos представила четвёртую версию ITIL, библиотеки лучших практик управления ИТ-услугами. Один из ключевых её разделов посвящён руководящим принципам ITIL 4 (The ITIL guiding principles).



Вместе с потоками создания ценностей и практиками, которые пришли на смену «процессам», семь руководящих принципов — основа ITIL 4. Принципы эти можно использовать ИТ-компаниям вне зависимости от стратегии, подхода к управлению и типа предоставляемых услуг. Как подчёркивают авторы библиотеки, каждый из принципов универсален и фундаментален. Вместе они воплощают основные идеи ITIL и ITSM.

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

Клиент при этом рассматривается не как потребитель услуги, просто получающий результат, а как партнёр. Это помогает клиенту влиять на качество и функциональность услуг.

Как раз в «Основах», первой из семи книг новой библиотеки, подробно изложены руководящие принципы ITIL 4. Базируются они на известных методиках: Agile, Lean, DevOps и т. п. То есть guiding principles помогают интегрировать лучшие практики в единый подход к управлению ИТ-услугами.

Всем привет! Я руковожу командой антиспама в Mail.ru Group, а также несколькими группами по машинному обучению. Тема этой статьи — саморазвитие для тимлидов/руководителей, но на самом деле многие техники и рецепты совершенно не зависят от роли. Для меня этот вопрос очень актуален, так как машинное обучение развивается крайне стремительно, и чтобы хотя бы быть в теме, надо потратить уйму времени. Поэтому вопрос, как и на что тратить время для развития, стоит достаточно остро.

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