Тестирование мобильных приложений

У меня скоро день рождения и я решил таки дописать статью, которую задумал лет 8 назад. Лучше поздняк пометаться, чем никогда, да и закрыть гештальт напрочь. Хотя сейчас мне нужно продолжать писать свои и чужие патенты, стартапы и статьи научные всякие, но очень хочется поделиться тем, что я вижу отчётливо, а другие не используют для полезностей и soft skills. Потом я ещё расскажу, что лечит боли клиентов на самом деле, без поверхностного подхода.

Не буду открывать USA, но всем ясно, что каждый самый хороший продаван, хоть на рынке у трассы или в Белом Доме или в автосалоне Bentley это великий психолог, если без непотизма, конечно. Самые успешные люди умеют понимать других и воздействовать на людей лучше остальных, иногда врождённо или бессознательно. Все самые популярные книги в рекламе и маркетинге написаны в реале психотерапевтами, которые называют себя почему-то всякими консультантами. По сути и кратко гутаря социальный и эмоциональный интеллекты для продаж важнее логики и IQ и поэтому почти все ненавидят чат-ботов (кроме тех, кто их делает и втюхивает, конечно).

К сожалению, трудно рассказывать о том, что ты знаешь с юношества назубок по базовым учебникам, но недоступно большинству хороших людей других профессий. Будучи старым (бывшим старшим) научным сотрудником и ИП (сейчас КФХ), изучающим уже две пятилетки разный таргетинг с ТРИЗом и сто лет преподающим всякую психологию и психотерапию, я не могу не видеть, что реклама и маркетинг не существуют без методик и техник именно лечения души душой.

Для начала разберём три моих любимых направления в психотерапии и сравним их с самыми частыми и модными приёмами, способами, техниками и вечными трендами в рекламе и маркетинге. Так вышло, что я больше всего работал врачом ЛФК и спортивной медицины, но первая моя диссертация была таки наполовину именно по сертификату специалиста психотерапевт и про лечение невротической депрессии, поэтому имею право.

С 16 лет я чрезвычайно тащусь от всех краткосрочных техник психотерапии, но сейчас я хочу рассказать только про три самых (потом и других) любимых это 1) аутогенная тренировка, 2) когнитивная терапия, 3) биологическая обратная связь. Про клиент-ориентированную психотерапию и юнгианский анализ с символдрамой и арттерапией попозже расскажу, наверно, как-нибудь.

Кстати! Обожаемое многими неспециалистами нейролингвистическое программирование, преподносимое, как панацея просто очень эффективный гибрид давно известных хороших техник разных направлений психотерапии и не признано в научной медицинской среде, как доказанный статистически метод и не оплачивается по страховке ни в одной стране.

Моя же родная аутогенная тренировка состоит и 2 основных групп методик релаксация и концентрация. Релаксация это способы повышения активности парасимпатической вегетативной неровной системы, что приводит к чувству покоя, расслабона, кайфа и рекреации вообще. Вопрос часто ли используют в рекламе креативщики образ отдыха, релакса и удовольствия? Удовлетворенность (Customer Satisfaction, CSAT) же - это таки из психологии, не?

Концентрация в аутотренинге это сосредоточение и повторение одних и тех же стимулов, которые человек специально рекурсирует, чтобы проникнуться, диффундировать в семантику образов слов, стать оборотнем-супергероем и отлететь. Самая известная концентрация это повторение я самая обаятельная и привлекательная много-много раз, как мантру или молитву. Хотя в этом фильме пародия на аутотренинг, так он не работает. Нужно более коротко и без всех, в частности. Внимание, а теперь собственно вопрос по теме является ли многократная повторяемость теле-, радио- или интернет-рекламы для потребителей несколько похожей на этот способ аутотренинга? Слоган - это не аффирмация? Реклама не как мантра? Ну не религия, наверно, таки.

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

Кстати говоря, популярная сейчас ещё книга Джозефа Пайна II и Джеймса Гилмора неправильно названа после перевода, теми же людьми, которые меняют названия американских фильмов в нашем кинопрокате. У них не Экономика впечатлений, а экономика опыта, тоже понятие из когнитивной терапии это. Я уж молчу о том, что Customer Journey Map это применение техник эмпатия и отзеркаливание, а Customer Satisfaction Index (CSI, индекс удовлетворенности клиентов) вообще классика точных измерений в психодиагностике и психотерапии, одно слово антидепрессивное satisfaction наглядно вопиет об этом научном понятии) И т.д. и т.п.

Теперь про биологическую обратную связь коротко и буду сразу потом рассказывать собственно про веб-сервис. Я уже писал на Хабре про биологическую обратную связь. Поэтому про саму методику не буду говорить, но тоже сравню этот чудеснейший метод психотерапии с понятием feedback, которое хорошо описано тоже на Хабре ранее. Разве тут не воочию видна тоже параллель? Обратная связь, будь она биологическая или маркетинговая - суть одна повышение психической и физиологической (медицинской) удовлетворённости)) А термин боль - это вообще рекордсмен по психотерапии в рекламе и маркетинге, ибо альгология точно вышла из медицины и психологии, давно также доказана психосоматичность ноципепции и показано при боли применение антидепрессантов, если она хроническая.

Ну и ещё много всяких случайных совпадений аналогичных. Например, в маркетинге есть такое понятие Net Promoter Score (NPS) инструмент выявления степени приверженности клиентов к бренду, опираясь на личный опыт (когнитивный то есть) потребителя. Сбор данных для NPS осуществляется преимущественно посредством проведения опросов (психодиагностических то есть методов). Далее клиентов разделяют на три категории критики, нейтралы, промоутеры и проводится расчет. Если получен отрицательный или нейтральный индекс, то необходимо срочно вносить коррективы для изменения уровня удовлетворенности, менять маркетинговую (психотерапевтическую) стратегию.

Поэтому, когда я осознал эти многочисленные все схожести, лет 10 назад ещё, то заявился с проектом ФидбекПрофит на митап Greenfield-project, но очень плохо провёл презентацию и меня отругали, что такое есть уже) Из-за всяких дел мне пришлось забыть это, как и многие другие свои родные инновации, но в этом году терпелка кончилась и я решил таки написать патент на изобретение по теме и сдал его 3 дня назад в Роспатент.

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

Изобретение относится к области рекламы, в частности, к методам оценки и коррекции эффективности рекламных кампаний. Способ оценки эффективности рекламы, отличающийся тем, что проводят верифицированное анкетирование и голосование для подсчёта рейтинга и оценки отдельных характеристик рекламы. Пользователи через систему, состоящую из мобильного или стационарного устройства отображения информации, с помощью программы для ЭВМ 2021617263 Feedback: diagnosis, rating, correction идентифицируются в личном кабинете (ЛК) через авторизацию OAuth 2.0.

Затем проходят затем дополнительно верификацию по одному из пяти уровней, имеющим последовательно и пропорционально номеру далее увеличивающуюся степень повышения коэффициента получаемого за голосование и отзывы вознаграждения бонусами через: 1) электронную почту или социальные сети, 2) номер мобильного телефона, 3) аккаунт на Госуслугах, 4) банковское приложение, 5) электронную цифровую подпись.

Там они заполняют раздел целей: мечты, желания, задачи, планы покупок, выставляют в ЛК для них три параметра: временные отметки, степень потребности и поиск решений. Затем через носимое вычислительное устройство с сенсорным экраном фотографируют с разрешением от 3264 на 2448 пикселей, снимают на видеокамеру с разрешением от 640 на 480 пикселей, наблюдаемое и происходящее в данный момент рекламное сообщение.

Дальше отвечают в мобильном приложении сервиса через психотерапевтический опросник, состоящий из семи вопросов о параметрах повышения (увеличения) или понижения (уменьшения) или без изменений после получения рекламного сообщения: 1) положительных эмоций бодрости, работоспособности и стеничности, повышения личной самооценки, 2) биофильных эмоций (любовь к природе, животным, детям, близким, друзьям, искусству, знаниям, здоровью, пище, сексу и т.д.), 3) антидепрессивного и противотревожного эффекта, 4) юмористического действия, в том числе пранки и сатира, 5) искренность, лояльность, приверженность и доверие к рекламируемому бренду, товару или услуге, 6) мотивации купить рекламируемый объект, 7) согласиться и сделать предлагаемое в рекламе.

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

На сервере происходит формирование и анализ соответствующих баз данных (БД) профилей, исключение оценок с недостоверными идентификационными данными, после чего им подбирается индивидуально скорректированная реклама по итогам проведенного анализа и раздела целей в ЛК. За оценивание рекламы пользователи сразу получают вознаграждение в виде бонусов и регулярного розыгрыша денежных призов, которые можно обменять на рубли, призы, скидки, купоны. Далее данной информацией они делятся с личными юмористическими или позитивно эмоциональными комментариями к своей оценке общего рейтинга и отдельных параметров в десяти социальных сетях, на пяти форумах, на семи сайтах.

И после чего происходит подсчёт всех голосов и рейтингов, имеющих верифицированные идентификаторы в БД всей системы, о данной рекламе за минуту, час, день, месяц и год с делением их на затраченные финансовые средства за такой же промежуток времени по формуле - КЭР=(Р1 + Р2 + Pn) / Сn, где КЭР коэффициент эффективности рекламы, Р1 рейтинг, набранный рекламой за 1 промежуток времени, Рn набранный рейтинг за дополнительные отрезки времени измерения эффективности, а Сn- общая сумма денежных средств, затраченных на создание и показ данной рекламы за изучаемый промежуток времени.

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

Способ по получаемым через интерфейс прикладного программирования параметрам использует специальные методики медицинской психологии, психиатрии, психодиагностики, client-centered и cognitive therapy, аутотренинга, психогигиены, санологии, экологии человека, для увеличения персонализации и верификации target group, lifetime value и покупок клиентов в краткосрочных и долгосрочных планах, улучшения omni-channel brand health, customer experience marketing, cross-device service blueprint, programmatic backstage adverts, addressable, connected и advanced television, увеличивая индивидуализацию и пользу рекламы для целей и покупок потребителей.

Как вам такой веб-сервис и мобильное приложение? Я его отправил в несколько компаний, чтобы улучшить и масштабировать, надеюсь, что прокатит. Много фидбека не бывает))

Только примерно 20% больных реальной депрессией ищут медицинскую или психологическую помощь, причем большинство из них обращаются к участковым терапевтам и неврологам. Те, в свою очередь, не всегда готовы к правильной диагностике, вследствие чего лишь около 30% депрессий (из числа 20% обратившихся) диагностируются своевременно и из них лишь 25% пациентов, в среднем, получает необходимую антидепрессивную терапию, лекарственную или иную. Трагичность (почему бы и не да) этих цифр тем более очевидна, если учесть тот факт, что в 60-70% случаев правильное научное лечение приносит пациентам быстрый желаемый эффект.

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

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

Весь прикол КТ в том, например, что известен эксперимент, в котором однажды один ученый впрыскивал в кровь испытуемым добровольцам в большой дозе адреналин, не говоря им, что это он. Люди становились психосоматически и объективно, по показаниям приборов, возбужденными, но 2/3 из них заявляли, что не испытывают никаких эмоций, а 1/3 говорила, что испытывала что-то похожее на эмоцию. Исследования других ученых показали, что одного физиологического возбуждения (или другого ощущения) недостаточно для возникновения эмоции, необходимо, чтобы человек распознал это реальное возбуждение, осознал, оценил и обозначил его словесно, мысленно, как это ему свойственно. Например, учащенное после подъема по лестнице на 10-й этаж сердцебиение ипохондричный пессимист назовет страшным приступом тахикардии, а спортивный оптимист - кайфовой тренировкой кровообращения. Изменения в организме у обоих одинаковые, но через минуту или час у первого настроение и здоровье ухудшится (приболел), а у второго - улучшится (потренил), причем не только субъективно, но и объективно, по показаниям самых современных высокоточных приборов. Получается, что отрицательные или положительные эмоции - следствие привычного (чаще наученного или наследственного) оценивания и убеждения в том, что они вызваны вредной или полезной данной конкретной причиной. Приблизить субъективное к объективному ради здоровья и успеха первоклассно помогает как раз КТ.

Начало практики когнитивной самокоррекции включает более подробное информирование о её философии (коротко повторим - эмоциональные проблемы вызывают не сами события, а их оценка) и о последовательных этапах восприятия события человеком в виде:

Ао --> Ас --> В --> C

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

Описательные мысли, как уже отмечалось, соединены с оценочными установками связями разной степени жесткости. Начиная от абсолютно исключающих какие-либо варианты, протекающих по типу рефлекса, при которых отношение к событию уже предопределено и тогда можно говорить о наличии у вас иррациональной установки (ИУ), заканчивая многовариантными, когда при принятии решения о действии осуществляется анализ альтернативных вариантов, хотя он может протекать неосознанно, и тогда можно говорить о наличии рациональной установки. Цель КТ перевод в проблемных ситуациях с иррациональных, депрессивных и стрессовых установок на максимально рациональные и приятные.

Работа в КТ всегда строится с учетом схемы А, В, С. Сначала:

Первый этап - выяснение, прояснение слагаемых события (А), в том числе элементов, наиболее эмоционально затронувших вас, вызвавших неадекватные реакции. Фактически у всех нас на этом этапе происходит индивидуальная, личностная оценка события. Выяснение же позволяет вам различать события, которые могут или не могут быть изменены. При этом цель когнитивной СК - не поощрение вас к уходу от столкновения с событием, не резкое изменение его (например, переход на новую работу при наличии неразрешимого конфликта с начальником), а осознание системы оценочных убеждений, затрудняющих разрешение этого конфликта, перестройка ее и только после этого - принятие решения об изменении ситуации. В противном случае вы сохраняете потенциальную уязвимость в сходных ситуациях, т.к. от себя уйти никому ещё не удавалось.

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

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

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

а) самонаблюдение за мимическими проявлениями при вашем воспоминании об эмоции и предоставление письменной обратной связи вами самими,

б) высказывание предположений о чувствах и мыслях у другого человека в подобной ситуации (обычно такое высказывание соответствует вашим неосознаваемым эмоциям).

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

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

a) вспоминательная фокусировка на тех мыслях, которые приходили Вам на ум в момент столкновения со стрессовым событием,

b) высказывание вами самими гипотетических предположений типа У меня в такой стрессовой ситуации возникли бы следующие мысли,

c) вопросы с проекцией в будущее время, например: Предположим, что произойдет самое худшее в ситуации стресса, что же это будет? и др.

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

Самая распространенная группа ИУ, создающих всеразличные проблемы - это катастрофические установки (отмечайте тут возможные ваши):

Я настолько расстроен(а) и несчастлив(а), что не могу это выдержать.

Мое будущее безнадежно, и ничто не может измениться к лучшему.

Я чувствую, что как личность, я полный(ая) неудачник(ца).

Я полностью не удовлетворен(а) жизнью и мне все надоело.

Я постоянно испытываю чувство вины.

Я чувствую себя уже наказанным(ой).

Я себя ненавижу.

Ко мне приходят мысли покончить с собой, но я не буду их осуществлять.

Я виню себя во всем плохом, что происходит.

Раньше я мог(ла) плакать, а сейчас не могу, даже если мне хочется.

Теперь я постоянно чувствую, что раздражен(а).

Я полностью утратил(а) интерес к другим людям.

Я с трудом заставляю себя сделать что-либо.

Я полностью утратил(а) сексуальный интерес.

Мой аппетит теперь значительно хуже.

Я очень обеспокоен(а) своим физическим состоянием и мне трудно думать о другом.

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

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

Следующие же духовные враги психосоматического здоровья и эффективного развития, которых тоже желательно заменять на более оптимистичные и уверенные убеждения, менее катастрофичны и опасны, нежели предыдущие, но зато чаще встречаются у всех нас (ставьте мысленно плюсы, если есть соответствия):

Я расстроен(а).

Я все время расстроен(а) и не могу от этого отключиться.

Я чувствую, что озадачен(а) будущим.

Я чувствую, что меня ничего не ждет в будущем.

Я чувствую, что пережил(а) больше неудач, чем другие люди.

Когда я оглядываюсь на мою жизнь, я вижу в ней очень много неудач.

Я не получаю столько же удовольствия от жизни, как и раньше.

Я больше не получаю удовлетворения ни от чего.

Достаточно часто я чувствую себя виноватым(ой).

Большую часть времени я чувствую себя виноватым(ой).

Я чувствую, что могу быть наказан(а).

Я ожидаю, что могу быть наказан(а).

Я разочаровался(ась) в себе.

Я себе противен(на).

Я критикую себя за ошибки и слабости.

Я все время обвиняю себя за свои проступки.

Сейчас я плачу чаще, чем раньше.

Теперь я все время плачу.

Я более легко раздражаюсь, чем раньше.

Я меньше интересуюсь другими людьми, чем раньше.

Я почти потерял(а) интерес к другим людям.

Я чаще, чем раньше, откладываю принятие решения.

Я больше не могу принимать решения.

Я знаю, что выгляжу безобразно.

Мне необходимо сделать дополнительное усилие, чтобы начать делать что-нибудь.

Я совсем не могу выполнить никакую работу.

Сейчас я сплю хуже, чем раньше.

Я просыпаюсь на 1-2 часа раньше обычного и мне трудно заснуть опять.

Теперь я устаю быстрее, чем раньше.

Я устаю почти от всего, что я делаю.

Я не могу ничего делать из-за усталости.

Мой аппетит стал хуже, чем раньше.

Сейчас я значительно меньше интересуюсь сексуальными вопросами.

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

Я настолько обеспокоен своим физическим состоянием, что больше ни о чем не могу думать.

Результаты: 0-1 нормально, до 5 плюсов требуется помощь психолога, более 5 нужно к врачу-психотерапевту или психиатру.

Цель диагностического этапа реализована, когда в области стресса или депрессии выявлены такие или им подобные ИУ, показан характер связи между ними и отношениями в семье, на работе и т.д. Уточнение рациональных установок и целей также необходимо, поскольку они составляют ту позитивную часть отношения, которая в последующем может быть расширена. Что мы и сделаем, насколько это возможно, чуть дальше. Хотя в приложения есть хорошие для здесь и сейчас), например - Mindspa: психологическая помощь в любой момент или Психология самооценки: 6 практик. Личностный рост с BestHelp Психологическая помощь онлайн.

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

Чтобы успешно уменьшить депрессию и любые неприятные мысли, обязательно нужно понять и принять базисное и наиглавнейшее положение когнитивной самокоррекции о зависимости эмоций от мышления: Если мы хотим изменять чувства, надо изменять вызвавшие их идеи. КТ уже началась сразу после осознания и принятия вами самими (и только так) некоторых ваших суждений и идей о проблемах и желаниях с постепенным переводом некоторых из них на позиции улучшения ИУ.

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

Максимально быстрое осознание способов неадекватной обработки информации и замена их правильными - таковы главные общие задачи когнитивной самокоррекции. Она наиболее показана людям с 14-16 лет со способностью к самонаблюдению и анализу своих мыслей. Т.е. сознательным товарищам.

Важная задача начального этапа - письменное описание проблем (идентификация проблем, имеющих в основе одни и те же причины, и их группировка). Эта задача относится как к симптомам (соматическим, психическим), так и просто к эмоциональным проблемам. При этом достигается укрупнение мишеней воздействия КТ. Другим вариантом описания проблем является идентификация первого звена в цепи симптомов, который и запускает всю цепочку, что иногда приводит к выходу на уровень ваших конкретных ощущений. Этому посвящены минимум два мобильных приложения - Когнитивная Tерапия: Три Колонки и Личный дневник настроения и эмоций, ежедневник.

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

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

Обращение вашего внимания на параллельно текущий поток мыслей в стрессовой ситуации, осознание этих мыслей (вплоть до записывания на бумаге) обучит вас методике последовательного анализа своего восприятия объекта или события. Распознавание неадаптивной убеждений может быть облегчено также с помощью приема коллекционирования автоматических мыслей. Кстати, термин неадаптивная установка применяется к любой авто-мысли, вызывающей неадекватные или болезненные эмоции и затрудняющей решение какой-либо проблемы.

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

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

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

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

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

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

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

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

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

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

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

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

Меня зовут Владислав Романенко, я старший iOS QA Engineer в Badoo и Bumble. Несколько лет назад мы начали активнее использовать автотесты в разработке, но столкнулись с некоторыми трудностями.

Логичный вопрос: почему мы занялись автоматизацией тестирования? Ответ кроется в еженедельном выпуске новых версий наших мобильных приложений. QA-отделу приходится тестировать новые фичи, их интеграцию в сервисы и заниматься регрессионным тестированием. За неделю комплексное регрессионное тестирование нужно проводить как минимум один раз, что довольно утомительно. Автоматизация помогла нам выпускать новые версии быстрее и без потери качества. Подробнее об автоматизации мобильного тестирования в докладе моих коллег.

В разработке проблемы часто решаются с помощью паттернов обобщённых решений для часто возникающих проблем в заданном контексте. То же и с автоматизацией тестирования, есть даже хорошее wiki-описание. В этой статье мы поговорим о паттернах процессов (Process Patterns). Они помогают организовать и улучшить процесс автоматизации тестирования.

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

Паттерн 1. Просьба о помощи (Ask for Help)

Как это часто бывает, мы все имели разный опыт, знания и навыки. На тот момент не все в команде сталкивались с автоматизацией тестирования некоторым пришлось учиться на ходу. Чтобы помочь коллегам из команды QA справиться со сложностями, мы предложили им обратиться за помощью к команде автоматизации. Идея в том, что если ты застреваешь на какой-то проблеме, то не нужно самостоятельно бороться с ней слишком долго, ведь другие уже могли столкнуться с подобным и найти решение. А чтобы автоматизаторов не завалили вопросами, мы решили формализовать этот подход. Прекрасным решением оказался паттерн ASK FOR HELP:

Просите о помощи, а не теряйте время, пытаясь всё сделать самостоятельно.

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

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

Внутрениий StackOverflow

Стоит отметить, что в нашей вики есть документация и описания решений для большинства распространённых проблем. Возможно, документировать все возможные ошибки и объяснения в вики не лучший подход, но мы считали, что сохранить их в одном месте будет полезно. Так у нас возникла идея создания локального Stack Overflow. Для этого мы воспользовались open source-решением Scoold. Оно предназначено для использования на первой линии обработки запросов и работает как обычная Stack Overflow, только для сотрудников компании. Когда у кого-нибудь возникает проблема, достаточно зайти в наш локальный Stack Overflow, чтобы найти решение или написать вопрос, на который ответит кто-то из специалистов.

Преимущества

• Процесс геймифицируется, поэтому в поиск решений вовлекается больше людей. Мы не стали придумывать разные лычки или звания количество голосов или звёзд ничего не значит и вам не советуем этим увлекаться. Геймификация лишь дополнительный стимул для участников, а не основной фактор.

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

• Стало меньше сообщений и веток в чатах, где их трудно отслеживать и искать. Мессенджеры не лучшее место для хранения документации и обращения к ней как к источнику истины. Stack Overflow гораздо удобнее.

Недостатки

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

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

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

Паттерн 2. Введение стандартов (Set Standards)

По мере возможности мы стараемся переиспользовать код в разных приложениях и на разных платформах, чтобы упростить сопровождение и поддержку. Но, как и в любой другой системе, которую несколько лет разрабатывало много людей, разные части кода могут быть написаны в разных стилях. Наш основной язык для сквозных автотестов это Ruby (об истории автоматизации мобильного тестирования в нашей компании рассказывал agile_seph здесь), потому что он как раз позволяет писать код в разных стилях (автор языка Юкихиро Мацумото хотел, чтобы разработчики использовали его язык так, как им удобно). Однако работать с чужим кодом бывает сложно.

Для решения этой проблемы мы выбрали паттерн SET STANDARDS:

Введите и соблюдайте стандарты для артефактов автоматизации.

Без этого может получиться, что над одним проектом работают несколько человек, и у каждого свой стиль и методы (как если бы все говорили на разных языках). Решать проблему мы начали со сбора мнений тех, кто непосредственно занимается автоматизацией. Мы стремились выработать такие соглашения о стиле, которые будут полезны всем пользователям. И чтобы каждый, кто участвовал в принятии решения, в будущем старался его придерживаться. Так мы создали руководства, которые принимают и соблюдают все участники процесса, что в буквальном смысле помогло нам найти общий язык.

Что мы сделали

• Создали локальную вики с актуальными руководствами и документами (например, как настроить окружение, как запускать и поддерживать тесты), которая помогла сократить циклы ревизии кода. Всю документацию мы храним в Confluence, который разделили на несколько частей. Команды регулярно проверяют актуальность своей документации.

• Добавили в вики межкомандные ретроспективы и соглашения. Ежемесячно мы проводим встречи и по результатам каждой из них делаем какие-то практические выводы.

• Что касается самого кода тестов и ограничений на уровне кода для основных этапов и методов верификации, мы внедрили стандартные инструменты, включая RuboCop (статический анализатор и инструмент форматирования кода для Ruby), защитные проверки (Guard Cheсks) и pre-commit-хуки.

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

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

Преимущества

• На сопровождение тестов и исправление ошибок тратится меньше времени и сил. Руководство по написанию кода очень облегчает понимание того, что и как писать.

• На ревью кода уходит меньше времени. С одной стороны, код становится аккуратнее, с другой всегда есть источник истины для рецензента и рецензируемого.

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

Недостатки

• После создания документации её никто не сопровождает. Это общая проблема для любой документации, особенно для той, что не используется постоянно. Поэтому мы назначили ответственных за сопровождение документов и настроили отправку им на почту уведомлений из Confluence, чтобы ничьи комментарии не оставались без внимания.

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

Паттерн 3. Делимся информацией (Share Information)

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

Этот паттерн называется SHARE INFORMATION:

Просите и давайте информацию начальству, разработчикам и другим тестировщикам.

Для нас это способ улучшить автоматизацию тестирования за счёт более широкого набора знаний. Для реализации этого паттерна мы запустили еженедельные короткие презентации QA Lightning Talks. Любой человек может предложить тему и в течение 10-15 минут выступить с ней. Поскольку у встреч чёткий тайминг, это хорошая возможность узнать что-то новое, не потратив на это много времени. Для тех, кто не смог присутствовать, мы сохраняем видеозаписи встреч во внутренней библиотеке.

Доклады могут быть посвящены не только тестированию и его автоматизации. Например, однажды bayandin рассказывал о своём опыте поддержки проекта Homebrew. А я как-то рассказывал о том, что я диванный картограф в Humanitarian OpenStreetMap. Я создаю карты районов, которые плохо картографированы, и потом ими пользуются в работе сотрудники разных организаций вроде Красного Креста или Врачей без границ. Сокращённая версия этого доклада позднее была представлена на сессии Soapbox конференции EuroSTAR 2020.

Преимущества

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

• Общий объём знаний растёт. А согласно исследованию, обмен знаниями улучшает взаимодействие между департаментами и внутри них.

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

Недостатки

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

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

Бонус: паттерн для обучения разделение на пары (Pair Up)

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

Чтобы достичь цели, мы воспользовались паттерном PAIR UP:

Более опытный сотрудник получает себе в пару менее опытного.

Для QA-инженеров мы запустили внутреннюю программу менторства. Что это такое? QA-инженеры присоединяются к автоматизаторам на короткий промежуток времени (обычно на две недели) и работают над задачами из бэклога этой команды, а не из своего. Помогают им в этом менторы из числа старших инженеров-автоматизаторов. Цель внутреннего менторства заключается в обучении. Мы разработали такой манифест:

• Сосредоточенность на обучении, а не на строгом соблюдении сроков.

• Интерактивные обсуждения, а не работа в бункере.

• Ранняя и регулярная обратная связь, а не ретрообзор в конце менторства.

Хотя утверждения справа ценны, утверждения слева для нас ценнее.

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

Итоги

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

Какие проблемы мы смогли решить

• Нежелание обращаться за помощью к коллегам (решили с помощью паттерна Ask for help). Как отметили в своей книге A Journey through Test Automation Patterns: One teams adventures with the Test Automation Серетта Гамба и Дороти Грэхем, не бойтесь просить о помощи: большинству людей на самом деле нравится помогать.

• Высокая стоимость сопровождения кодовой базы тестирования (решили с помощью паттерна Set Standards). Если вы давно работаете над автоматизацией, то стандарты просто необходимы.

• Информационный бункер (решили с помощью паттерна Share Information). Общайтесь с другими людьми: в процессе обсуждения часто рождаются новые идеи.

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

Расскажите в комментариях, с какими сложностями при автоматизации тестирования столкнулись вы и как их решали.

Привет! Меня зовут Мария Лещинская, я QA-специалист в Surf. Наша компания разрабатывает мобильные приложения с 2011 года. В этом материале поговорим о тестировании устройств Android, на которых нет поддержки Google Services.

Huawei без Google-сервисов начали массово выпускаться в 2019 году. Мы в Surf, разумеется, задумались о будущем: как сильно пострадают наши процессы и что нужно незамедлительно осваивать.

Я поделюсь впечатлениями от работы с Android без Google-сервисов и расскажу, какие возможности имеют такие мобильные устройства при тестировании.

В начале статьи общая информация про AppGallery и AppGallery Connect. Если вы всё это уже знаете, переходите сразу к сути к особенностям тестирования Android-платформы c поддержкой Huawei без Google-сервисов.

Что такое AppGallery, AppGallery Connect и почему Huawei без поддержки Google

Приложения под iOS- и Android-платформы можно встретить в официальных магазинах AppStore и Google Play. Туда мы идём в первую очередь, когда хотим установить новое мобильное приложение на телефон.

С 2018 года во всем мире (а в Китае ещё раньше) появился другой магазин мобильных приложений AppGallery, а с ним и AppGallery Connect.

AppGallery это менеджер пакетов и платформа распространения приложений, разработанная Huawei для операционной системы Android. AppGallery Connect универсальная платформа для поддержки всего жизненного цикла приложения: разработки, распространения, управления, тестирования и анализа.

За AppGallery последовал и выпуск устройств на базе Huawei: с 2019 года для нихв принципе отсутствует возможность работать с Google-сервисами, поэтому работа с Android стала сложнее. Нужно было оперативно включиться в работу и придумать, какизменить процессы тестирования платформы.

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

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

Во-вторых, у AppGallery солидное количество пользователей. Магазин появился в 2018 году, к октябрю 2020 года приложение доступно в 170 странах мира, число уникальных пользователей 700 миллионов человек. Как говорит статистика, ежемесячная аудитория составляет 490 миллионов активных пользователей.

При этом для Huawei написали всего 96 000 приложений. Для сравнения в Play Store 2.9 миллиона приложений: это значит что более двух с половиной миллионов приложений отсутствуют в AppGallery.

В AppGallery нет, например, Instagram, Facebook и WhatsАpp. Их, конечно, можно скачать и установить вручную без ограничений: найти по отдельности в браузере или через какой-нибудь агрегатор. Также в сети появились сервисы, с помощью которых можно скачать самые популярные приложения. Но не каждый пользователь захочет выполнять дополнительные манипуляции.

Три вида Android-устройств

Как только кAndroidс Google-сервисами прибавились Huawei с сервисами HMS, некоторые устройства стали автоматически поддерживать оба вида сервисов (например, как Huawei до 2020 года выпуска).

Ниже представлено сравнение трёх типов устройств Android: с Google-cервисами, без них и с поддержкой обоих.

Устройства разные, особенности взаимодействия и тестирования тем более. Казалось бы, все понятно: нужно знать, как с ними работать и никаких проблем. Но ещё очень важно понимать, из чего составить этот рабочий процесс: как выбрать инструменты, чему обучить команду и к каким проблемам подойти с правильной стороны.

Возможности тестирования через AppGallery Connect

Проблемы начинаются при использовании разных библиотек на двух видах устройств Android. Мы в Surf пользуемся различными сервисами для работы с push-уведомлениями, аналитикой, dynamic или deep links, performance-мониторингом. Поэтому когда стали брать на вооружение работу с Huawei без Google-сервисов, волновались, насколько сильно изменится работа QA: получится ли тестировать push-уведомления и dynamic links в привычном ритме или придётся адаптироваться к абсолютно новому процессу? К счастью, сам процесс меняется несильно. Но есть вещи, о которых необходимо знать, прежде чем браться за работу с устройствами без поддержки Google.

Huawei без Google-сервисов не имеет доступа к инструментам, которые работают с Google, например, Firebase. Сервисы для тестирования и работы мобильного приложения нужно настраивать через AppGallery (к счастью, AppGallery Connect имеет базовые возможности из коробки) или другие доступные инструменты. А возможно, придумывать и свои решения.

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

Аналитика

При тестировании аналитики полезно просматривать события в реальном времени это помогает обеспечить качество реализации отправки событий в мобильном приложении. Проверять аналитику в AppGallery Connect в реальном времени можно, например, с помощью Отладки приложения (аналогично DebugView в Firebase).

Отладка приложения (App Debugging) позволяет смотреть события, приходящие от МП, и их параметры в реальном времени. Чтобы подключить устройство к Отладке приложения в AppGallery Connect, нужно подключить устройство к компьютеру и в терминале выполнить команду:

adb shell setprop debug.huawei.hms.analytics.app <package_name>

Чтобы отключить устройство от отладки, выполнить команду:

adb shell setprop debug.huawei.hms.analytics.app .none.

Чтобы быстрее найти <package_name>, можно воспользоваться командой adb:

adb shell pm list packages

Общий сбор аналитики в AppGallery Connect тоже доступен. Он называется Просмотр в реальном времени (аналогично Events в Firebase)

Просмотр в реальном времени (Real-Time Overview) собирает все события с МП в одном месте. Можно строить графики по выбранным критериям, активировать фильтры и в целом проводить анализ по мобильному приложению.

Удалённая настройка и параметры

Удалённая настройка (Remote Configuration) позволяет управлять различными параметрами для приложения, и при необходимости обращаться к AppGallery Connect прямо из МП для работы с ними (аналогично RemoteConfig в Firebase).

Push-уведомления

При работе с push-уведомлениями Surf использует разные инструменты: Flocktory, Mindbox, Firebase и другие. Не все инструменты пока ещё могут работать с Android без поддержки Google, но базовая возможность подключить push-уведомления для Huawei есть: это их фирменная реализация через AppGallery Connect. Настройка пyшей происходит в PushKit.

Важно отметить, что пушер бэкэнда обязательно должен уметь взаимодействовать с AppGallery PushKit. Иначе push-уведомления придётся отправлять вручную из AppGallery Connect.

App Linking

App Linking сервис для работы с dynamic links. На основании deep links App Linking предоставляет пользователям доступ к нужному контенту непосредственно на веб-страницах и в мобильных приложениях: это повышает конверсию пользователей (аналогично Dynamic Links в Firebase).

На данный момент при работе с AppGallery Connect нет возможности создавать кастомные dynamic links: например, которые были бы одинаковыми и для обоих видов устройств Android (с поддержкой Google и без). Но c deep links всё в порядке.

Crash

Чтобы ловить незаметные с первого взгляда баги, стоит мониторить crash-аналитику даже на debug-версиях. Это необходимо, когда приложение потенциально разрабатывается на большую аудиторию и релиз близко не говоря уже о ситуации, когда МП уже доступно магазине и им пользуется много людей.

Нам было важно, чтобы такой инструмент был доступен и для Huawei без Google-сервисов. Crash плагин, позволяющий отслеживать и анализировать баги, краши и ошибки в приложении (аналогично Crashlytics в Firebase).

APM

Чтобы обеспечить качество клиент-серверного взаимодействия, удобно использовать инструмент, который бы помогал анализировать ответы от сервера и отрисовку экранов и элементов в приложении. В AppGallery Connect такой инструмент APM. Это сервис, который помогает искать и устранять проблемы производительности приложения и улучшать таким образом пользовательский интерфейс (аналогично Performance в Firebase).

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

Особенности тестирования Android-платформы c поддержкой Huawei без Google-сервисов

В первое время при работе с устройствами Huawei без Google-сервисов мы тратили много времени на анализ и выстраивание процессов. Сейчас всё наладилось.

В целом можно выделить следующие проблемы и решения.

Шаринг сборок

На проектах мы часто шарим сборки через Firebase, или напрямую скачиваем .apk из Jenkins, или собираем вручную из Android Studio. Проблем со скачиванием или ручной установкой .apk для Huawei без Google-сервисов нет. Проблем с App Tester приложением Firebase для шаринга сборок тоже нет. Использовать непосредственно приложение не получится, но пройти по invite из почты в браузер для скачивания сборки удастся.

Лайфхак: сохраняйте страницу из браузера на рабочий стол телефона и не знайте горя.

Устройства

Конечно, для тестирования необходимы устройства и эмуляторы без Google-сервисов.

• Если на проекте планируется адаптация под AppGallery, можно отправить заявку Huawei. Они пришлют девайсы для тестирования.Правда, финальное слово всегда за самим Huawei: отправка запроса ничего не гарантирует. Но опция приятная.

• Неплохой вариант использовать эмуляторы. Конечно, они не восполнят полную работу с устройством, но могут помочь в отдельных случаях.

  • Можно работать с эмуляторами через ферму устройств App Gallery.

  • Можно установить HMS Toolkit в Android Studio и работать с Huawei без Google-сервисов прямо из IDE.

На что обратить внимание

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

1. Push-уведомления. На Huawei без Google-сервисов не будут работать push-уведомления, реализованные на backend через Firebase (а такое встречается сейчас часто). Такие устройства имеют свой hms-токен, и для работы с ними нужна специальная реализация.

2. Dynamic links. Инструмент AppGallery Connect не поддерживает кастомный формат dynamic links, поэтому нельзя настроить унифицированную ссылку на оба вида конфигураций устройств Android. Решение: использовать deep links или другой инструмент по работе с ссылками, работающий без Google Services.

3. Библиотеки с Google-сервисами. Различия в реализации и потенциальное скопление багов в логике будут, если в проекте используются библиотеки с Google-сервисами. Для Huawei их придётся заменить на другие фреймворки или if-ответвления. Тогда понадобится более тщательно тестировать оба вида устройств.

• Google Pay. На Android без Google-сервисов можно столкнуться с окном Оплата недоступна, так как для нее нужен доступ к Google-сервисам, которые ваше устройство не поддерживает. Аналогичную ошибку можно встретить при запуске других приложений, не предназначенных для Huawei без Google.

• Google-карты. Работа с Google-картами может содержать проблемы с кластеризацией, поиском, отрисовкой текущего местоположения и так далее.

• Google-аккаунт. Авторизация через Google-аккаунт на Huawei без поддержки Google недоступна. Но реализация авторизации-регистрации через Huawei-аккаунт была бы кстати.

• Магазины. Если мобильное приложение может отправить пользователя в магазин (для оценки, например), то необходимо проверить, что Android без Google Services отправляет в App Gallery, а Android с поддержкой Google в Google Play. Если устройство поддерживает обе конфигурации, было бы здорово, если бы пользователь мог выбрать между магазинами.

4. Сервисы с поддержкой Google. Для Huawei без Google придётся найти аналоги или разработать их самостоятельно. Хорошо, что важные базовые инструменты, как упоминалось выше, доступны в AppGallery Connect из коробки.

Например, на Android-устройствах можно открывать ссылки из приложения тремя разными способами:

• WebView,

• CustomTabs (разработка Google),

• браузер.

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

Android с Google и без: сколько времени понадобится на тестирование

Базовые активности QA:

• планирование,

• ревью ТЗ и дизайна,

• написание проверок,

• прогоны по фиче, итоговые, регрессионные,

• написание отчётности

Это пример активностей QA в среднем по больнице. Мы исключаем особенности компании и проектов и говорим немного в вакууме.

При работе с Huawei без Google-сервисов точно добавляется время к каждой из активностей:

• Ревью ТЗ и дизайна, написание проверок. Будут дополнительные кейсы, отражающие особенности работы с такими устройствами. Можно смело увеличивать оценку временных затрат на это в 1,41,6 раза. Здесь время уйдёт либо на обработку дополнительных сценариев в ТЗ и дизайне, либо на анализ и подтверждение, что никакой особенной реализации для Android без Google-сервисов нет.

• Прогоны. Во время прогонов (по фиче, итоговых, регрессионных) рекомендуется проводить тестирования как на Android с Google-сервисами, так и без. Особое внимание устройствам, где доступны оба вида сервисов. Здесь сокращение количества устройств может когда-нибудь неприятно выстрелить. Время может увеличиться в 1,82 раза и уйдёт на осуществление прогона на всех трёх видах устройств.

• Обратная связь. Под обратной связью мы в Surf подразумеваем просмотр маленьких задач (которые не требует прогона по фиче например, Смену статичного текста) и исправленных багов. При работе с обратной связью, а также при анализе и просмотре импакта от багов и прочих задач, снова не стоит забывать про тот же список устройств (без и с Google-сервисами, а также с двумя видами сервисов) для тестирования. Время увеличивается примерно в 1,3 раза снова для того, чтобы осуществить ретест или проверку задачи на этих видах устройств.

• Послерелизные активности. При релизе приложения в AppGallery необходимо продолжать мониторить работу МП как минимум по crash-сервису, чтобы поддерживать качество и исправлять ошибки вовремя. Если в проекте не используется один инструмент мониторинга обоих видов устройств, то времени на работу с двумя инструментами и анализом багов будет уходить больше. Пожалуй, тут лучше увеличить время в 2 раза.

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

При тестировании на Android с Google Services хочется покрыть наибольшее количество устройств: разные операционные системы, оболочки, разрешения экранов, внутренние особенности и возможности. Устройств становится ещё больше, когда добавляются девайсы Huawei с HMS-сервисами.

Таким образом, необходимо покрыть бОльшее количество устройств: не забывая про Android с Google-сервисами, Android без их поддержки, и Android с поддержкой HMS-сервисов помимо Google.

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

Время общего тестирования фичи увеличится:

• в 1,82 раза в случае разных инструментов для реализации фичи;

• в 1,31,5 раза в случае одного инструмента для реализации фичи (в том числе при отсутствии отличий на первый взгляд);

• в 1,41,6 раза в случае дополнительных требований и отличительной части реализации.

Таблица-сравнение по тестированию фичи для устройств с Google и без

Мы оценили фичи по пунктам, о которых говорили выше ревью, написание проверок, прогоны по фиче, обратная связь.

_{Значение Х время на тестирование Android с Google-сервисами. Оценка Y*X время на тестирование Android с двумя видами сервисов, где Y коэффициент увеличения времени на работу с Huawei с HMS-сервисами}

Все временные оценки исходя из нашего опыта. Приводим их для примерного понимания.

Что хотелось бы сказать в конце...

Мы в Surf поддерживаем устройства Huawei без Google-сервисов на некоторых проектах и довольны процессами. Конечно, поработать головой иногда приходится чуть дольше: разработчикам чтобы найти универсальное решение. QA чтобы найти максимальное количество дефектов, широко покрыть фичи проверками и обеспечить качественное тестирование. И на мой взгляд, оно того стоит.

*bypass - обход

Мы будем использовать библиотеку python Selenium для байпаса google reCaptcha v3. Следуйте пошаговой инструкции, чтобы получить результат.

Для примера мы будем использовать демо-версию Google reCaptcha api.

Здесь ссылка: https://www.google.com/recaptcha/api2/demo

Сначала необходимо отключить настройку защиты контента в браузере Chrome.

Для этого зайдите в Настройки в Chrome. И напишите "настройки сайта" в строке поиска.

Перейдите в настройки сайта и найдите "Защищенный контент".

Перейдите к защищенному контенту и отключите его.

Теперь перейдем к части кодирования.

В этой статье мы будем работать с Python 3. Мы будем использовать две библиотеки. Если вы хотите настроить Selenium и узнать, как это сделать - изучите эту статью: https://medium.com/@mrabdulbasit1999/selenium-with-python-web-automation-f85dfa2e58fa

Двигаемся дальше,

Установите библиотеку Beautiful Soup для скрипта.

pip install beautifulsoup4

Откройте файл-скрипт и импортируйте в него упомянутые библиотеки.

from selenium import webdriverfrom selenium.webdriver.common.keys import Keysfrom webdriver_manager.chrome import ChromeDriverManagerfrom selenium.webdriver.common.by import Byfrom http_request_randomizer.requests.proxy.requestProxy import RequestProxyimport os, sysimport time,requestsfrom bs4 import BeautifulSoup

Установите "delayTime" и "audioToTextDelay" в соответствии с вашей скоростью интернета. Установленные значения работают для всех.

delayTime = 2audioToTextDelay = 10

byPassUrl - это URL, на который вам нужно ориентироваться. Опция используется для выбора драйвера chrome, и ей передаются некоторые аргументы.

filename = 1.mp3byPassUrl = https://www.google.com/recaptcha/api2/demo'googleIBMLink = https://speech-to-text-demo.ng.bluemix.net/'option = webdriver.ChromeOptions()option.add_argument('--disable-notifications')option.add_argument("--mute-audio")

Остальная часть кода приведена ниже. Теперь я объясню, как это работает.

Когда скрипт запускается, проверяется поле I'm not a robot.

И дальше все появляется (как обычно).

После по скрипту выбирается кнопка аудио внизу слева.

И появляется вот это. После этого загружается аудио с именем "1.mp3".

Это займет несколько секунд, не волнуйтесь. После этого в браузере откроется новая вкладка, которая перейдет от речи watson к конвертеру в текст и загрузит файл.

Как видите, аудиофайл преобразуется в текст. Он копирует текст и вставляет его в текстовое поле.

И далее нажимается кнопка "Проверить".

Вот, смотрите... Проблема решена. Если у вас есть какие-либо проблемы и вопросы, пишите. Я отвечу на них как только смогу.

Код

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

- Demo Day курса "Python QA Engineer"

- Demo Day курса "Java QA Automation Engineer".

Привет! На связи компанияKODE. Мы занимаемся разработкой мобильных приложений, голосовых интерфейсов, IoT и других цифровых решений для государства и крупного бизнеса в России и Европе с 2013 года.

Руководители наших отделов собрали полноценную библиотеку IT-компании: сайты, блоги, книги, онлайн-курсы, подкасты, Telegram- и YouTube-каналы. Подборка будет полезна менеджерам, аналитикам, разработчикам, дизайнерам и QA.

Направления:

• Проджект-менеджмент.

• Аналитика.

• UX/UI-дизайн.

• Android.

• iOS.

• Backend.

• Frontend.

• QA.

• DevOps.

Сохраняйте, чтобы не потерять!Используйте и совершенствуйтесь.

Проджект-менеджмент

Сайты:

• Блог Школы Менеджеров Стратоплан.

• Wait But Who блог об управлении и общечеловеческих темах.

Книги:

• Подборки книг с рецензиями agile-коуча Алексея Пименова.

• Панкратов В. Чёрная книга менеджера.

• Орлов А. Белая книга менеджера.

• Дэниел Гоулман. Эмоциональный интеллект.

• Хенссон Фрайд. Rework. Бизнес без предрассудков.

• Ицхак Адизес. Идеальный руководитель. Почему им нельзя стать и что из этого следует.

• Джим Кэмп. Сначала скажите Нет.

• Гэвин Кеннеди. Договориться можно обо всём.

• PMI PMBoK методология управления проектами.

Курсы:

• Менеджмент проектов и работа с людьмиот Школы Менеджеров Стратоплан.

• Полный курс подготовки PMP.

YouTube-каналы:

• Иван Селиховкин интервью с экспертами и записи выступлений о проектном управлении.

• Максим Дорофеев о психологии умственного труда и личной эффективности.

Telegram-каналы:

• Psilonsk канал Сергея Колганова об управлении проектами и продуктами.

• Селиховкин о проектном управлении в другом формате.

Аналитика

Книги:

• Прерва А., Иванова В. Путь аналитика. Практическое руководство IT-специалиста.

• Карл Вигерс. Разработка требований к программному обеспечению.

• Донелли Медоуз. Азбука системного мышления.

• Карл Андерсон. Аналитическая культура. От сбора данных до бизнес-результатов.

• Богачев А. Графики, которые убеждают всех.

• Дуглас У. Хаббард. Как измерить все, что угодно. Оценка стоимости нематериального в бизнесе.

• Левенчук А. Системное мышление.

Курсы:

• Системное мышление курс Анатолия Левенчука на Coursera.

• Постановка задачи на разработку ПОна Stepik.

Telegram-каналы:

• Banana Analyst канал аналитика KODE Анны Денисовой о работе с данными и аналитике в разработке цифровых продуктов.

• Бизнес-анализ & IT.

• Product Analytics актуальные материалы по продуктовой аналитике.

• Интернет-аналитика.

UX/UI-дизайн

Сайты:

• Подборки советов Бюро Горбунова.

• Студия Лебедева.

• Дизайн-паб святыня русскоязычного медиума.

Книги:

• Бирман И. Пользовательский интерфейс.

• Горбунов А. Типографика и вёрстка.

• Ильяхов М.Пиши, сокращай+Ясно, понятно.

• Дональд Норман.Дизайн привычных вещей+Дизайн вещей будущего.

• Пол Рэнд. Дизайн: Форма и хаос.

• Йоханнес Иттен.Искусство цвета+Искусство формы.

• Ян Чихольд.Новая типографика+Облик книги.

• Йозеф Мюллер-Брокманн. Модульные сетки в графическом дизайне.

• Тим Харровер. Настольная книга газетного дизайнера.

• Эдвард Тафти. Представление информации.

• Генрих Альтшуллер. Найти идею.

• Дитер Рамс. 10 правил хорошего дизайна.

• Королькова А. Живая типографика(опубликована в открытом доступе).

• Фитцпатрик Р. Спроси маму: Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?

• Алан Купер об интерфейсах. Психбольница в руках пациентов.

• Виктор Папанек. Дизайн для реального мира.

• Майк Монтеро. Дизайн это работа.

• Бред Фрост. Атомарный дизайн.

Курсы:

• Графический дизайн специализация на Coursera.

• Школа мобильного дизайнаот Яндекса.

• Управление проектами и продуктомот Яндекса.

• Дизайн мобильных приложенийот Redmadrobot.

• Дизайн мобильных приложенийот Нетологии.

• Дайджест продуктового дизайнера Юрия Ветрова.

• Bang Bang Education онлайн-школа дизайна и иллюстрации.

• Гайдлайны наMaterial Design.

Фильмы:

• 33 слова о дизайне глазами российских дизайнеров.

• 100 лет дизайна документальный фильм о развитии дизайна.

• Современный российский дизайн о последних 20 годах индустрии.

YouTube-каналы:

• Mail.ru x Dribbble MeetUp о дизайне от команды Mail.ru Group.

• Академия Яндекса лекции из курсов различных школ Яндекса, в том числе о дизайне.

Android-разработка

Сайты:

• Developing Android Appsна Reddit новости из мира Android.

• Блог Android Developers Backstageс подкастами и полезными ссылками.

Книги:

• Фредерик Брукс. Мифический человеко-месяц о процессах в разработке.

• Роберт Мартин. Чистая архитектура об организации кодовой базы.

• Хориков В. Принципы юнит-тестирования.

• Android. Программирование для профессионалов доисторическая, но полезная книга, где хорошо описаны этапы разработки мобильного приложения.

Курс:

• Видеокурс по мобильной разработкеот создателя PRISMA.

Подкасты:

• Fragmented подкаст о том, как стать лучшим разработчиком ПО.

• Сушите вёсла о разработке, аналитике, тестировании и других аспектах создания приложений.

• CoRecursive истории, скрывающиеся за кодом, от экспертов в мире разработки.

• Signals And Threads интервью о тонкостях разработки с инженерами из глобальной торговой компании Jane Street.

• Software Engineering Radio еженедельные беседы о ПО.

• Microsoft Research Podcast о передовых технологиях Microsoft Research.

Telegram-каналы:

• Android Guards чат о безопасности Android.

• Android Good Reads полезные статьи, видео и новости.

Twitter:

• Руководитель Android-разработки в CuvvaАдам Беннетт.

• Разработчик GitHubАлексис Кинг.

• Разработчик ПО в MicrosoftДэвид К.

• Android-разработчик вAuto.ruМиша Левченко.

• Разработчик в Cash AppАдам Эрб.

• Android-разработчикСакет Нараян.

• Инженер ПО в GoogleЛеланд Ричардсон.

• Технический руководитель в SquareРальф Вондрачек.

• Руководитель проектов в JetBrainsРоман Елизаров.

• Физик, математик, инженер ПОБартош Милевски.

iOS-разработка

Сайты:

• Издание Swift Talk видео о разработке на Swift.

• Digest MBLT DEV еженедельная подборка новостей.

• iOS Dev Weekly свежие новости, статьи и гайды.

Книги:

• Документация поSwiftот Apple (перевод).

• Роберт Мартин. Чистый код.

• Эрик Фримен, Элизабет Робсон. Паттерны проектирования.

Курсы:

• Онлайн-коллекция Raywenderlich гайды по программированию.

• Классический курс по разработкеот Стэнфордского университета.

Подкаст:

• Подлодка еженедельное аудиошоу о разработке.

YouTube- и Telegram-каналы:

• YouTube-каналПола Хадсонапо SwiftUI.

• Telegram-каналdeprecated чат для новичков, где разбирают сложные для них вопросы.

Backend-разработка

Книги:

• Дональд Э. Кнут. Искусство программирования.

• Стив Макконнелл. Совершенный код.

• Алан Донован, Брайан Керниган. Язык программирования Go.

• Джеффри Фридл. Регулярные выражения.

• Новиков Ф. А. Дискретная математика для программистов.

• Марк Лутц. Изучаем Python.

• Мартин Клеппман. Высоконагруженные приложения. Программирование, масштабирование, поддержка.

YouTube-каналы:

• Доклады с IT-конференции HighLoad++ на YouTube.

• YouTube-канал Хусейна Нассера о разработке ПО с примерами.

Telegram-каналы:

• Официальный Telegram-канал Хабра.

• ClickHouse не тормозит.

Frontend-разработка

Ресурсы и сайты:

• Современный учебник JavaScript.

• V8 движок JavaScript с открытым исходным кодом.

• MDN Web Docs ресурсы для разработчиков от разработчиков.

• JavaScript Weekly свежие статьи, новости и проекты по JavaScript.

Блоги:

• Дэн Абрамов личный блог разработчика, одного из авторов Redux.

• Katz Got Your Tongue статьи Иегуды Каца, соавтора Ember.js и ответственного за разработку плагинов в jQuery.

Книги:

• Серия книг Вы не знаете JS(перевод).

• Марейн Хавербеке. Выразительный JavaScript.

• Джон Резиг. Секреты JavaScript ниндзя.

• Борис Чёрный. Профессиональный TypeScript. Разработка масштабируемых JavaScript-приложений.

Подкасты:

• FrontoWeek важные события фронтенда за неделю.

• Веб-стандарты ещё один новостной канал.

• UnderJS обсуждения JS на Frontend и Backend, React Native, Linux.

• Фронтенд Юность вся правда о фронтенд-разработке.

• Frontend Weekend интервью с известными людьми из веб-разработки.

• Пятиминутка React подкаст о React и смежных технологиях в мире JavaScript и фронтенда.

• kamyshev.talk об архитектуре, коде и гибких навыках.

YouTube-каналы:

• АйТи Синяк канал разработчика с семилетним стажем в HTML, CSS и JS.

• Фронтенд школа разработки интерфейсов.

• Mozilla Developer ролики для веб-дизайнеров и разработчиков.

• Канал Тимура Шемсединова открытые лекции, конференции и школы по программной инженерии, JavaScript и Node.js.

Telegram-каналы:

• FrontoWeek: Недельный дайджест.

• For Web фронтенд, дизайн, программирование.

• Вебня JS VMs, спецификации, встречи.

• Веб-стандарты ежедневные новости и события фронтенда от сообщества веб-разработчиков.

QA

Сайты:

• ПорталSoftware Testing сотни тематических статей, подборок книг по тестированию и обзор новостей отрасли.

• БлогQCoder концентрат полезных знаний.

Курсы:

• Python: основы и применения.

• Автоматизация тестирования с помощью Selenium и Python.

Telegram-каналы:

• Серьёзный тестировщик кроме полезной информации, в описании собраны разные болталки: для джуниоров, русскоговорящего сообщества, о компаниях и деньгах в QA, для поиска работы и сотрудников.

• Тестировщик от бога подборки статей, роликов, инструментов и новые фичи со всего интернета.

• Радио QA неформальный канал о тестировании и QA.

• Load & Performance о нагрузочном тестировании.

• QA ninjas подборки статей из Хабра, YouTube-роликов и интервью с практикующими тестировщиками.

• QA Автоматизация.

• Отдельнаяподборка полезных материаловс канала Postman.

YouTube-каналы:

• Любительский канал Алексея Баренцева полезные видео для начинающих тестировщиков.

• QAGuild об автоматизации тестирования и ИТ.

• Heisenbug доклады с международной технической QA-конференции.

• Канал ИТ-компанииiTechArt, где еженедельно публикуются записи выступлений разработчиков и тестировщиков.

DevOps

Книги:

• Официальное руководство Cisco по подготовке к сертификационным экзаменам CCENT/CCNA ICND1 100-101.

• MikroTik RouterOS. Руководство пользователя.

• Олифер В. Г., Олифер Н. А. Компьютерные сети. Принципы, технологии, протоколы.

• Дуглас Камер. Сети TCP/IP. Принципы, протоколы и структура.

• Скляров. О. К. Волоконно-оптические сети и системы связи.

• Сваруп Читлур. A Byte of Python, или Укус питона руководство по Python для начинающих.

• Арнольд Роббинс. Bash. Карманный справочник для системного администратора.

• Рэндал Шварц. Изучаем Perl.

• UNIX и LINUX. Руководство системного администратора.

• Барон Шварц, Пётр Зайцев, Вадим Ткаченко. MySQL по максимуму.

• Джез Хамбл, Дейвид Фарли. Непрерывное развёртывание ПО автоматизация процессов сборки, тестирование и внедрения новых версий программ.

• Джон Арундел, Джастин Домингус. Kubernetes для DevOps развёртывание, запуск и масштабирование в облаке.

• Роланд Хасс. Паттерны Kubernetes шаблоны разработки собственных облачных приложений.

• Джен Ким, Патрик Дебуа и др. Руководство по DevOps. Как добиться гибкости, надёжности и безопасности мирового уровня в технологических компаниях.

• Евгений Брикман. Terraform. Инфраструктура на уровне кода.

• Лорин Хоштейн, Рене Мозер. Запускаем Ansible.

Telegram-каналы:

• Книги для Системного Администратора.

• Слёрм вечерняя школа с трёхдневными интенсивами и видеокурсы.

• Кибер****** о технологии и информационной безопасности.

• DaRk NeT 911 книги по практической ИБ.

Не забудьте поделиться с коллегами и теми, кому может быть интересна эта подборка!

Привет! На связи компанияKODE. Мы занимаемся разработкой мобильных приложений, голосовых интерфейсов, IoT и других цифровых решений для государства и крупного бизнеса в России и Европе с 2013 года.

Руководители наших отделов собрали полноценную библиотеку IT-компании: сайты, блоги, книги, онлайн-курсы, подкасты, Telegram- и YouTube-каналы. Подборка будет полезна менеджерам, аналитикам, разработчикам, дизайнерам и QA.

Направления:

• Проджект-менеджмент.

• Аналитика.

• UX/UI-дизайн.

• Android.

• iOS.

• Backend.

• Frontend.

• QA.

• DevOps.

Сохраняйте, чтобы не потерять!Используйте и совершенствуйтесь.

Проджект-менеджмент

Сайты:

• Блог Школы Менеджеров Стратоплан.

• Wait But Who блог об управлении и общечеловеческих темах.

Книги:

• Подборки книг с рецензиями agile-коуча Алексея Пименова.

• Панкратов В. Чёрная книга менеджера.

• Орлов А. Белая книга менеджера.

• Дэниел Гоулман. Эмоциональный интеллект.

• Хенссон Фрайд. Rework. Бизнес без предрассудков.

• Ицхак Адизес. Идеальный руководитель. Почему им нельзя стать и что из этого следует.

• Джим Кэмп. Сначала скажите Нет.

• Гэвин Кеннеди. Договориться можно обо всём.

• PMI PMBoK методология управления проектами.

Курсы:

• Менеджмент проектов и работа с людьмиот Школы Менеджеров Стратоплан.

• Полный курс подготовки PMP.

YouTube-каналы:

• Иван Селиховкин интервью с экспертами и записи выступлений о проектном управлении.

• Максим Дорофеев о психологии умственного труда и личной эффективности.

Telegram-каналы:

• Psilonsk канал Сергея Колганова об управлении проектами и продуктами.

• Селиховкин о проектном управлении в другом формате.

Аналитика

Книги:

• Прерва А., Иванова В. Путь аналитика. Практическое руководство IT-специалиста.

• Карл Вигерс. Разработка требований к программному обеспечению.

• Донелли Медоуз. Азбука системного мышления.

• Карл Андерсон. Аналитическая культура. От сбора данных до бизнес-результатов.

• Богачев А. Графики, которые убеждают всех.

• Дуглас У. Хаббард. Как измерить все, что угодно. Оценка стоимости нематериального в бизнесе.

• Левенчук А. Системное мышление.

Курсы:

• Системное мышление курс Анатолия Левенчука на Coursera.

• Постановка задачи на разработку ПОна Stepik.

Telegram-каналы:

• Banana Analyst канал аналитика KODE Анны Денисовой о работе с данными и аналитике в разработке цифровых продуктов.

• Бизнес-анализ & IT.

• Product Analytics актуальные материалы по продуктовой аналитике.

• Интернет-аналитика.

UX/UI-дизайн

Сайты:

• Подборки советов Бюро Горбунова.

• Студия Лебедева.

• Дизайн-паб святыня русскоязычного медиума.

Книги:

• Бирман И. Пользовательский интерфейс.

• Горбунов А. Типографика и вёрстка.

• Ильяхов М.Пиши, сокращай+Ясно, понятно.

• Дональд Норман.Дизайн привычных вещей+Дизайн вещей будущего.

• Пол Рэнд. Дизайн: Форма и хаос.

• Йоханнес Иттен.Искусство цвета+Искусство формы.

• Ян Чихольд.Новая типографика+Облик книги.

• Йозеф Мюллер-Брокманн. Модульные сетки в графическом дизайне.

• Тим Харровер. Настольная книга газетного дизайнера.

• Эдвард Тафти. Представление информации.

• Генрих Альтшуллер. Найти идею.

• Дитер Рамс. 10 правил хорошего дизайна.

• Королькова А. Живая типографика(опубликована в открытом доступе).

• Фитцпатрик Р. Спроси маму: Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?

• Алан Купер об интерфейсах. Психбольница в руках пациентов.

• Виктор Папанек. Дизайн для реального мира.

• Майк Монтеро. Дизайн это работа.

• Бред Фрост. Атомарный дизайн.

Курсы:

• Графический дизайн специализация на Coursera.

• Школа мобильного дизайнаот Яндекса.

• Управление проектами и продуктомот Яндекса.

• Дизайн мобильных приложенийот Redmadrobot.

• Дизайн мобильных приложенийот Нетологии.

• Дайджест продуктового дизайнера Юрия Ветрова.

• Bang Bang Education онлайн-школа дизайна и иллюстрации.

• Гайдлайны наMaterial Design.

Фильмы:

• 33 слова о дизайне глазами российских дизайнеров.

• 100 лет дизайна документальный фильм о развитии дизайна.

• Современный российский дизайн о последних 20 годах индустрии.

YouTube-каналы:

• Mail.ru x Dribbble MeetUp о дизайне от команды Mail.ru Group.

• Академия Яндекса лекции из курсов различных школ Яндекса, в том числе о дизайне.

Android-разработка

Сайты:

• Developing Android Appsна Reddit новости из мира Android.

• Блог Android Developers Backstageс подкастами и полезными ссылками.

Книги:

• Фредерик Брукс. Мифический человеко-месяц о процессах в разработке.

• Роберт Мартин. Чистая архитектура об организации кодовой базы.

• Хориков В. Принципы юнит-тестирования.

• Android. Программирование для профессионалов доисторическая, но полезная книга, где хорошо описаны этапы разработки мобильного приложения.

Курс:

• Видеокурс по мобильной разработкеот создателя PRISMA.

Подкасты:

• Fragmented подкаст о том, как стать лучшим разработчиком ПО.

• Сушите вёсла о разработке, аналитике, тестировании и других аспектах создания приложений.

• CoRecursive истории, скрывающиеся за кодом, от экспертов в мире разработки.

• Signals And Threads интервью о тонкостях разработки с инженерами из глобальной торговой компании Jane Street.

• Software Engineering Radio еженедельные беседы о ПО.

• Microsoft Research Podcast о передовых технологиях Microsoft Research.

Telegram-каналы:

• Android Guards чат о безопасности Android.

• Android Good Reads полезные статьи, видео и новости.

Twitter:

• Руководитель Android-разработки в CuvvaАдам Беннетт.

• Разработчик GitHubАлексис Кинг.

• Разработчик ПО в MicrosoftДэвид К.

• Android-разработчик вAuto.ruМиша Левченко.

• Разработчик в Cash AppАдам Эрб.

• Android-разработчикСакет Нараян.

• Инженер ПО в GoogleЛеланд Ричардсон.

• Технический руководитель в SquareРальф Вондрачек.

• Руководитель проектов в JetBrainsРоман Елизаров.

• Физик, математик, инженер ПОБартош Милевски.

iOS-разработка

Сайты:

• Издание Swift Talk видео о разработке на Swift.

• Digest MBLT DEV еженедельная подборка новостей.

• iOS Dev Weekly свежие новости, статьи и гайды.

Книги:

• Документация поSwiftот Apple (перевод).

• Роберт Мартин. Чистый код.

• Эрик Фримен, Элизабет Робсон. Паттерны проектирования.

Курсы:

• Онлайн-коллекция Raywenderlich гайды по программированию.

• Классический курс по разработкеот Стэнфордского университета.

Подкаст:

• Подлодка еженедельное аудиошоу о разработке.

YouTube- и Telegram-каналы:

• YouTube-каналПола Хадсонапо SwiftUI.

• Telegram-каналdeprecated чат для новичков, где разбирают сложные для них вопросы.

Backend-разработка

Книги:

• Дональд Э. Кнут. Искусство программирования.

• Стив Макконнелл. Совершенный код.

• Алан Донован, Брайан Керниган. Язык программирования Go.

• Джеффри Фридл. Регулярные выражения.

• Новиков Ф. А. Дискретная математика для программистов.

• Марк Лутц. Изучаем Python.

• Мартин Клеппман. Высоконагруженные приложения. Программирование, масштабирование, поддержка.

YouTube-каналы:

• Доклады с IT-конференции HighLoad++ на YouTube.

• YouTube-канал Хусейна Нассера о разработке ПО с примерами.

Telegram-каналы:

• Официальный Telegram-канал Хабра.

• ClickHouse не тормозит.

Frontend-разработка

Ресурсы и сайты:

• Современный учебник JavaScript.

• V8 движок JavaScript с открытым исходным кодом.

• MDN Web Docs ресурсы для разработчиков от разработчиков.

• JavaScript Weekly свежие статьи, новости и проекты по JavaScript.

Блоги:

• Дэн Абрамов личный блог разработчика, одного из авторов Redux.

• Katz Got Your Tongue статьи Иегуды Каца, соавтора Ember.js и ответственного за разработку плагинов в jQuery.

Книги:

• Серия книг Вы не знаете JS(перевод).

• Марейн Хавербеке. Выразительный JavaScript.

• Джон Резиг. Секреты JavaScript ниндзя.

• Борис Чёрный. Профессиональный TypeScript. Разработка масштабируемых JavaScript-приложений.

Подкасты:

• FrontoWeek важные события фронтенда за неделю.

• Веб-стандарты ещё один новостной канал.

• UnderJS обсуждения JS на Frontend и Backend, React Native, Linux.

• Фронтенд Юность вся правда о фронтенд-разработке.

• Frontend Weekend интервью с известными людьми из веб-разработки.

• Пятиминутка React подкаст о React и смежных технологиях в мире JavaScript и фронтенда.

• kamyshev.talk об архитектуре, коде и гибких навыках.

YouTube-каналы:

• АйТи Синяк канал разработчика с семилетним стажем в HTML, CSS и JS.

• Фронтенд школа разработки интерфейсов.

• Mozilla Developer ролики для веб-дизайнеров и разработчиков.

• Канал Тимура Шемсединова открытые лекции, конференции и школы по программной инженерии, JavaScript и Node.js.

Telegram-каналы:

• FrontoWeek: Недельный дайджест.

• For Web фронтенд, дизайн, программирование.

• Вебня JS VMs, спецификации, встречи.

• Веб-стандарты ежедневные новости и события фронтенда от сообщества веб-разработчиков.

QA

Сайты:

• ПорталSoftware Testing сотни тематических статей, подборок книг по тестированию и обзор новостей отрасли.

• БлогQCoder концентрат полезных знаний.

Курсы:

• Python: основы и применения.

• Автоматизация тестирования с помощью Selenium и Python.

Telegram-каналы:

• Серьёзный тестировщик кроме полезной информации, в описании собраны разные болталки: для джуниоров, русскоговорящего сообщества, о компаниях и деньгах в QA, для поиска работы и сотрудников.

• Тестировщик от бога подборки статей, роликов, инструментов и новые фичи со всего интернета.

• Радио QA неформальный канал о тестировании и QA.

• Load & Performance о нагрузочном тестировании.

• QA ninjas подборки статей из Хабра, YouTube-роликов и интервью с практикующими тестировщиками.

• QA Автоматизация.

• Отдельнаяподборка полезных материаловс канала Postman.

YouTube-каналы:

• Любительский канал Алексея Баренцева полезные видео для начинающих тестировщиков.

• QAGuild об автоматизации тестирования и ИТ.

• Heisenbug доклады с международной технической QA-конференции.

• Канал ИТ-компанииiTechArt, где еженедельно публикуются записи выступлений разработчиков и тестировщиков.

DevOps

Книги:

• Официальное руководство Cisco по подготовке к сертификационным экзаменам CCENT/CCNA ICND1 100-101.

• MikroTik RouterOS. Руководство пользователя.

• Олифер В. Г., Олифер Н. А. Компьютерные сети. Принципы, технологии, протоколы.

• Дуглас Камер. Сети TCP/IP. Принципы, протоколы и структура.

• Скляров. О. К. Волоконно-оптические сети и системы связи.

• Сваруп Читлур. A Byte of Python, или Укус питона руководство по Python для начинающих.

• Арнольд Роббинс. Bash. Карманный справочник для системного администратора.

• Рэндал Шварц. Изучаем Perl.

• UNIX и LINUX. Руководство системного администратора.

• Барон Шварц, Пётр Зайцев, Вадим Ткаченко. MySQL по максимуму.

• Джез Хамбл, Дейвид Фарли. Непрерывное развёртывание ПО автоматизация процессов сборки, тестирование и внедрения новых версий программ.

• Джон Арундел, Джастин Домингус. Kubernetes для DevOps развёртывание, запуск и масштабирование в облаке.

• Роланд Хасс. Паттерны Kubernetes шаблоны разработки собственных облачных приложений.

• Джен Ким, Патрик Дебуа и др. Руководство по DevOps. Как добиться гибкости, надёжности и безопасности мирового уровня в технологических компаниях.

• Евгений Брикман. Terraform. Инфраструктура на уровне кода.

• Лорин Хоштейн, Рене Мозер. Запускаем Ansible.

Telegram-каналы:

• Книги для Системного Администратора.

• Слёрм вечерняя школа с трёхдневными интенсивами и видеокурсы.

• Кибер****** о технологии и информационной безопасности.

• DaRk NeT 911 книги по практической ИБ.

Не забудьте поделиться с коллегами и теми, кому может быть интересна эта подборка!

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

С чем мы столкнулись, пока выпускали релизы по этой схеме:

1. Сложно спрогнозировать, когда выйдетфича.Ок,мы как-топрикидывалисроки, ночембольшебыл разрабатываемый функционал, тем сложнееточно оценить срок.Трекатьпрогресс фичитоже не очень удобно, потому что оно там делается,и промежуточныебилдыс чем-то готовым для посмотретьсложнособирать.

2. Долгоправитьбаги.Вкоде они могутбыть исправленыбыстро. А вотдо пользователейфиксдоходит уже вместе с той самой глобальной фичей.

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

4. Долго релизить мелкие фичи. Какие-то улучшения могут занимать немного времени на разработку, но быть важными для пользователей и бизнеса. Точно так же, какисправления багов в пункте выше, для релиза они будут ждать того монстра, которого мы пилимтримесяца.

5. Невыносимо долго проводить регрессионное тестирование. Всё,что было переделаноза несколько месяцев,мы будем проверять, чинить, перепроверять, чинить, перепроверятьНу, вы поняли

6. Многохотфиксов. Чем больше число и объем изменений, тем сложнеебудет найти все баги перед релизом. Вот и появляютсяхотфиксы. Ещёза такой долгий срок разработки может прилететь какая-то очень срочная фича, ждать нельзя надо срочно выпускать(например, поддержать разрешение на отслеживание или добавить что-то по срочному рекламному контракту).

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

Тут у насслучиласьстадия отрицания:Мы не успеем всёпроверить, никаких фичей в релиз не попадет, Apple ревьюит о-го-госколько.Зачем, почему, может,не надо?.В ответ мы услышали: Релизы раз в неделю.

Сокращаем время выпуска релиза: первая попытка

Решили, что надодвигаться к целиитерационно.

Сначала научитьсявыпускать релизхотя быкопределённойдате. Первой попыткой был план успетьзарелизитьза месяц. Условно,мы решили 1 мая, что следующий релиз должен выйти 1 июня.

Ок, дата есть. Прикинули, что неделя уходит на регресс. На разработку остается три недели. Запланировали работына весь срок девелопмента.

Параллельно решили начать писатьавтотесты. Ну, как начать. У нас и до этого они были, но пользы не ощущалось. Поняли, что пора их встраивать в процессы.

Идёт первый месяц. Работаем. Пилим фичи, тестируем. Все заряжены.Но в итоге получили: тотобъём работ, который запланировали разработать за три недели, закончили под конецчетвёртой. Стали искать, где же выиграть время,нашли только один варианттестирование. Как могли, сократили регресс, но всёравно нашлинесколько критичных багов. В итогев зависимости от платформы с релизом опоздали на неделю-полторы.

Вторая попытка: нужно что-то менять

Да, мы решили, что нужны изменения. Но поменяли не процессы, а... сроки. Раз тяжело планировать на месяц давайте запланируем релизчерездве недели! Меньше успеем сделать фичей, быстрее проведем регрессионное тестирование - проще будет запланировать объем работ.

Тем временемтестировщикипродолжают писатьавтотесты

Пробуем всёравно каждый раз не успеваем.

Стали анализировать,из-за чегоне выходит уложиться в срок:

1. Неправильно оцениваем время на разработку.

2. Блочимсябекендом от этого тормозится и разработка, и тестирование.

3. Продактыпоздно вносятпоследниеправки в ТЗ.

4. Не учитываем время на починкубагов.

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

И тут пришлиQA.Сказали, что при двухнедельных релизахскоупнеособосократился.

Разработчиков много, они разделены по разномуфункционалуи задвенедели успеваютнакомититьпрактически во все компоненты. Стало понятно, что несмотря на то, что мыНИ РАЗУне успели в срок ни при месячном релизе, ни при двухнедельных пора двигаться дальше.

Недельные релизымыидём к вам!

Прежде всего надо было составить календарь наших действий на неделю. По разработке получилось так:

Меняемся в тестировании

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

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

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

1. Дизайн;

2. Бекенд;

3. Контракт.

Если чего-то из этого нет смысла братьфичув разработку на мобильной платформе тоже нет.

Дальше встал вопрос о том, когда же можно включатьфичув релиз. Получились такие правила:

1. Бекендфичидолжен быть напродакшене.

2. К началурелизноготестирования нет критичныхбагов(ни на фронте, ни набекенде).

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

Меняемся в разработке

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

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

Тикетавтоматом двигается по статусам. Запушилкоммит перешел вinprogress.Создалmergerequest перешел вcodereview.ПрошелreviewпопалвQA.

Втикетеавтоматически проставляется версия релиза, куда он попал и номербилда.

По каждой сборке запускаютсяUI-автотестыпозатронутомуфункционалу.Это тоже определяется самопо измененным файлам вmergerequest.В результате репорт попадаетвкомментарийтикета вJira.

Дажеmergerequestна влитие эпика вdevсоздаётсяпросто по принятию продактом фичивJira.Если нет конфликтов, то и вливается сам.Релиз сам закрывается, а новый самсоздаётся.

QA Notes

Ещёмы ввели требования к разработчикам писатьQANotes.Там указывается:

1. Что было сделано.

2. Что могло быть задето.

3. Приложены скриншоты или видео.

4. На какой среде удалось проверить.

5. Для багаещёпричина, из-за чегосломалось(в идеалетикет, которыйпривёл к такому поведению).

QANotesпозволили значительно ускоритьтестированиеиревьюкода. А ещёдали нам скрытый бонус:пропалиреопеныотQAиз-закрешейна старте.

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

Автотестыраньше находят баги. Теперь не надо ждатьрелизноготестирования, чтобы увидеть проблемы после интеграции. Прогоныавтотестовпроисходят после каждоговливания эпика вdev,а такжекаждуюночь. Еслинадо, то можно запустить на эпик-веткедо вливания вdev. Раньше нашли баг раньше исправили.

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

А еще добавиласьротируемаяроль QAза релиз.Этоттестировщикгде-то раз вдватримесяцаделаетповторяющиесявещи:

1. Составляет наборрелизныхтестов.

2. Распределяет нагрузку команды тестирования пофичам. Если видит, что у одних сейчас малотикетов, а другие не успевают может перекинуть кого-то в помощь.

3. Напоминаеттестировщикампосмотретьотчёты поавтотестамнарелизномбилде.

4. Пушитпересборкурелиз-кандидатов, если что-то добавилось.

5. После релиза неделюмониторитпаденияи отвечает на запросы поддержки.

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

Автоматизация помогает контролировать стабильность среды с помощью выполнения тестов после изменения кода приложения:

Мы также проверяем, что новыеавтотестыне ломают существующие:

Новая схема релиза мобильных приложений

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

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

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

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

Какиеестьсложности

В первую очередь этонепростойрефакторинг. Когдавмерживодинкоммит, вам надо перепроверить всёприложение.Сейчас мы прежде всеговливаемтакое по понедельникам-вторникам, чтобырефакторингмаксимально настоялся вdev, накрутилсяавтотестамии был потроган при тестированиифичей.

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

Что ещёможно улучшить

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

Ещёмы никогда не останавливаемся в автоматизации процессов. Постоянно находим возможность убрать ручную рутину. И покрываемавтотестамивсёбольшефункционала.

Для себя мы выработали такие шаги, на которые надо пойти, чтобы завести у себя релизы раз в неделю:

1. Строгие требования к готовностифичи.

2. Приоритет напереоткрытыхтикетах.

3. Весь функционалзакрытфичефлагами.

4. Строгое расписание релизов.

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

Заголовок конечно громковат, может не убивает, но уменьшит им доходы точно. Давайте кратко посмотрим что представила Apple на WWDC 2021, что такое Xcode Cloud?

Xcode Cloud - это сервис CI/CD, встроенный в Xcode и разработанный специально для разработчиков Apple. Он ускоряет разработку и доставку приложений, объединяя облачные инструменты, которые помогают создавать приложения, параллельно запускать автоматические тесты, доставлять приложения тестировщикам, а также просматривать отзывы пользователей и управлять ими.

Цикл разработки по мнению Apple заключается в этапах 1) Написать код 2) протестировать его 3) Интегрировать (в текущий) 4) Доставить до пользователя 5) Улучшить, и по новой. На то он и цикл. В принципе похоже на правду, так оно и есть.

Если вы хоть раз настраивали CI/CD для iOS приложений, вы знаете примерно какие там шаги, ничего сложного, но это может включать в себя использование нескольких сервисов, генерации сертификатов и тд и тп.

Теперь же Apple предлагает нам сделать это все не выходя из Xcode, давайте взглянем на процесс.

Для начала нам нужно настроить первый workflow, а потом уже который будет пробегать при PR/MR (pull request/merge request) на main/develop ветку в системе контроля версий.

I CI/CD

1) Жмем в новом Xcode при подключенном сервисе Xcode Cloud кнопку "создать workflow" и видим настройки

Name - название воркфлоу, Start condition когда запускать воркфлоу (например при изменении в main ветке), Environment - можно выбрать стабильную версию Xcode или новую бета версию, Actions - что собственно надо сделать, обычно выполнить archive и опубликовать например в TestFlight, после прогонки тестов, Post-Actions - что сделать после того как воркфлоу пройден, например написать в slack/telegram канал об этом событии

2) Выбираем репозиторий где хранится наш код

3) Выбираем с какой ветки собрать билд (при первой настройке)

Собственно готово, теперь можем посмотреть как выглядит в Xcode место где можно управлять сборками, запускать их, пересобирать и тд

Давайте теперь посмотрим как выглядит управлени воркфлоу (выше показан путь настройки первой сборки)

1) Выбираем "управление воркфлоу"

2) Выбираем настройки (например при pull/merge request что-то выполнять)

3) Выбираем какие тесты мы хотим прогнать в воркфлоу (UI или Unit тесты), я так понимаю речь именно про нативные тесты, про Appium и тд, пока ничего не известно.

4) И выбираем отправить сообщение в Slack после того как воркфлоу пройден

5) Готово

II Тесты

1) Давайте посмотрим как выглядит интерфейс работы с тестами, мы видим тут тесты которые пройдены при сборке а также устройства на которых они прогонялись

2) Посмотрим какие конкретно тесты прогнались на iPad Air, видим что тест кейс с Light mode, портретный режим, с Английским языком, далее видим какие конкретно тесты пройдены

3) Ну и совсем чудеса, можно смотреть скриншоты пройденных тестов

4) Можно также посмотреть какой тест упал, можно также пометить тест как Flaky (Флаки тест или другими словами тест неактуальный, который надо либо удалить либо переписать), для этого используется XCTExpectFailure (что в переводе логично видно по названию метода ожидаемый фейл)

Удобно.

III - Работа с системой контроля версий (и переписка прямо в коде в Xcode)

1) Изменения теперь видно еще нагляднее (привет всем кто пользуется визуальными штуками, а не через консоль при работе с git). Сверху мы видим наши локальные изменения (которые мы накодили) а снизу "висящие" pr/mr реквесты, которые можно посмотреть, и дать свой комментарий или approve (одобрение на слияние кода)

2) Даже видно какой тест план для этой фичи, которая просится в главную ветку

3) Переписка,комменты прямо в Xcode при pr/mr (а не на веб мордах gitlab/github/bitbucket и тд)

В общем очень круто и удобно

IV - Улучшения (Crashes/Сбои/Ошибки)

1) Все краши/сбои теперь видно прямо в Xcode (а не в веб морде Firebase или Sentry), код приходит сразу символизированный (symbolized log), то есть человекопонятный с указанием что и как произошло

2) А тестер (возможно и пользователь) может оставить комментарий при краше который вы сможете прочитать (и даже ответить!)

3) Ну и самое интересное вы сможете кликнуть открыть место краша в проекте

4) И вас за ручку проведут к вашему куску кода который натворил зло

Послесловие

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

В общем как по мне сервис выглядит очень интересно, но пока недоступен для всех. Понятно что видимо он еще в стадии разработки, но как все задумывается, это выглядит круто, и очень упростит разработку для iOS.

Можете подать заявку на бета-тест здесь https://developer.apple.com/xcode-cloud/

Сколько он будет стоить пока тоже неизвестно.

И пока непонятно что с Android потому что обычно сервисы CI/CD используют сразу для двух платформ, так как приложения обычно тоже для двух платформ разрабатывают. Но может быть когда нибудь приложения для Android можно будет писать и в Xcode))

Изображение и информацию брал из видеосессий WWDC 2021, кому интересно как это выглядит вот видео про Xcode Cloud https://developer.apple.com/videos/play/wwdc2021/102/

Тестировать рекламные механики не так просто, как может показаться. Главные действующие лица здесь сторонние SDK, которые не особо подконтрольны команде разработки. А так как рекламные интеграции важная часть наших мобильных приложений, то ниже вместе с @maiscourt и @santypa расскажем, как мы это делаем.

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

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

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

И тут нам понадобятся некоторые инструменты.

Инструменты

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

1. Сниффер для анализа трафика (у нас Charles).

2. Админка у медиатора, где можно настроить получение рекламы от конкретного партнёра на свой тестовый юнит (специальный id, используя который, паблишер запрашивает рекламу у медиатора).

3. Своя админка с фича-тогглами, где можно включить/отключить, или изменить наши эксперименты.

4. Наша дебаг-панель.

5. VPN.

6. Внешние гайдлайны.

7. Внутренняя база знаний и Confluence для её хранения.

8. Чек-листы.

9. Zephyr для хранения тест-кейсов.

Пройдёмся по каждому.

Инструмент 1. Charles. Активно используется не только тестировщиками, но и разработчиками. Практически все задачи требуют замены продакшн параметров на тестовые. Например, часто возникает необходимость добавить в конфиг эксперимент или обращаться к тестовым юнитам медиатора.

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

Инструмент 2. Тестовая админка медиатора. Медиатор это специальная платформа, которая позволяет подключать приложение сразу к нескольким рекламным сетям, а также управлять показом рекламы (например, Google AdMob, Fyber и другие). Ещё во время онбординга мы проводим обучающие курсы по рекламе, где сотрудники в тестовой админке медиатора создают свой тестовый юнит для настройки параметров рекламы под себя.

Инструмент 3. Админка с фича-тогглами. Практически все рекламные (и не только) механики в приложении iFunny закрыты под фича-тогглы (механизм реализации, при котором часть кода прячется за флаг, контролирующий его включение или выключение). Это нужно, чтобы сделать более надёжным и безопасным выпуск той или иной функциональности.

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

Документацию обновляем и дополняем по мере необходимости: если после обновления SDK изменилась описанная логика работы, или если вышли нормативы/регламенты, требующие внесения обязательных правок.

Инструмент 4. Дебаг-панель. Для удобства разработали свою рекламную дебаг-панель, которая представляет собой отдельный интерфейс и в большинстве случаев позволяет локально на клиенте настроить необходимые параметры, заменяя собой практически все инструменты, описанные выше.

Инструмент 5. VPN. В основном используется для проверки задач, связанных с GDPR и CCPA. Для тестирования GDPR подходит VPN с возможностью получения IP европейской страны. Для тестирования CCPA необходим VPN с возможностью получения калифорнийского IP.

Инструмент 6. Внешние гайдлайны. В работе с рекламными SDK часто используем их официальную документацию, где можно получить:

• рекламные креативы и их идентификаторы, которые используются для настройки и получения тестовой рекламы;

• форматы запросов и ответов рекламной SDK, а также параметры, из описания которых понимаем, за что они отвечают, и какие возможные значения для них допустимы;

• changelog изменений рекламных SDK чтобы понять, на какие изменения при обновлении SDK нужно обратить внимание во время тестирования.

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

Инструмент 8. Чек-листы. Наравне с внешней и внутренней документацией для проверок различных задач используем чек-листы (пример можно посмотреть ниже в разделе про обновление SDK). Для такого типа задач, как проверка обновлений SDK, обновлений медиатора или адаптеров, мы используем уже составленный чек-лист, который изменяется по мере необходимости.

Для остальных задач составляем чек-листы либо в процессе разработки задачи, либо непосредственно перед тестированием, в зависимости от сложности задач.

Инструмент 9. Тест-кейсы. Тест-кейсы неотъемлемая часть тестирования любого проекта/функциональности, в том числе рекламы. Тест-кейсы разделены по приоритетам, что позволяет использовать risk-based testing, о котором будет рассказано подробнее ниже. В тест-кейсах фигурируют такие проверки, как загрузка и показ рекламы, запросы на рекламу, работа разных механик (например: водопад, аукцион), а также запрос и отображение рекламы от партнёрских рекламных сетей. Данные проверки в полной мере позволяют убедиться, что рекламный функционал работает без сбоев/корректно.

Задачи

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

Разберём, с чем приходится сталкиваться на постоянной основе:

1. Обновление SDK.

2. Тестирование форматов.

3. Безопасность.

4. Регрессионное тестирование.

5. Смоук тестирование.

6. Другие задачи (юридические вопросы, локализации, эксперименты, аналитика, рефакторинг и так далее).

Задача 1. Обновление SDK. Можно сказать, что обновление SDK наиболее популярная задача в рамках тестирования рекламы. Из-за частого проведения тестирования обновлений SDK (а также медиатора или адаптеров) составили чек-лист проверок:

• Вёрстка. Проверяем всё: центрирование, размер, отображение на устройствах с разными разрешениями экранов.

• Пользовательские сценарии. Тап по контенту/кнопке и по privacy icon, возврат в приложение, воспроизведение и остановка видеорекламы.

• Репорт (отправка жалоб, связанных с рекламой). Пользователь может пожаловаться на рекламный контент или сообщить о технических проблемах.

• Соответствие стандартам GDPR и CCPA.

• Отправка аналитики. Внутренняя и внешняя (партнёру и медиатору).

• Технические проверки. Например, уход в фон во время загрузки рекламы.

Задача 2. Тестирование форматов. Баннерная и нативная рекламы у нас закрепились и работают стабильно, но мы пробуем интегрировать и другие виды, в частности, fullscreen-рекламу. В целом, тестирование Rewarded Video и Interstitial во многом схоже с тестированием других видов: проверяется корректная загрузка и отображение рекламы, а также отправка аналитики.

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

Отдельно нужно сказать про механику Rewarded Video после окончания просмотра рекламы (или просмотра до определённой временной метки) пользователь должен получить вознаграждение. Поэтому очень важно хорошо протестировать этот функционал.

Подробно про разные форматы мобильной рекламы мы уже писали в отдельной статье.

Задача 3. Безопасность. Чтобы следить за качеством трафика, интегрировали в iFunny внешнее антифрод-решение. В него для дополнительной проверки атрибуции показов и кликов на каждое событие генерируется новое. На стороне системы с помощью технологий машинного обучения и большого объёма накопленных данных происходит дальнейший анализ. Со своей стороны мы проверяем отправку и разметку событий для разных сетей и разных типов рекламы.

Задача 4. Регрессионное тестирование. Раз в две недели iFunny релизится на iOS и Android. Независимо от количества рекламных задач, попавших в релизную ветку, мы проводим регрессионное тестирование рекламного функционала/блока. В регрессионных паках собраны следующего рода проверки:

• Основные проверки, что реклама запрашивается и отображается на нужных экранах приложения.

• Работа нативной и баннерной рекламы, а также рекламных сетей, с которыми сотрудничаем по сути, это упрощённый чек-лист, используемый для тестирования SDK (добавления, обновления).

• Работа разных механик: водопад и биддинг (что это такое, можно ознакомиться здесь).

• Проверка на соответствие юридическим нормам.

• Проверки каких-то наших внутренних разработок (например, эксперименты с дизайном).

Если встречаем проблемы в процессе тестирования (не проходят какие-то кейсы регресса), то чиним в текущей релизной ветке не катимся с рекламой, которая не работает.

Проведение полного ручного прогона регресса занимает порядка 2-3 дней. Поэтому, чтобы сократить время прохождения регресса, используется практика проведения Risk-based testing (вид тестирования, основанный на вероятности риска). Суть такого тестирования исключить некоторое количество тест-кейсов из прогона, проведение которых не может выявить потенциальных ошибок на текущем релизном билде. Иными словами, кейс не имеет смысла включать в регрессионное тестирование, если при разработке не был затронут функционал, проверяющийся в кейсе.

Задача 5. Смоук тестирование. Перед тем, как выкладывать сборку в сторы, а также при тестировании хотфиксов, мы прогоняем смоук тесты. В рамках смоук тестирования реклама проверяется, но не так детально, как при регрессе. Мы тестируем основные моменты, связанные с рекламой, а именно её загрузку и отображение.

Задача 6. Другое. К тестированию других задач можно отнести:

• юридические задачи, например, связанные с GDPR и CCPA;

• задачи локализации (для пользователей iFunny из Бразилии);

• эксперименты, связанные с дизайном рекламы;

• задачи аналитики;

• рефакторинг, оптимизации. Например, оцениваем доступный нам для анализа контент на предмет валидности.

Бонус. Онбординг новых сотрудников

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

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

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

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

Вместо заключения

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

App Store самая строгая площадка для размещения приложений. Ревью проходит дольше и строже, чем у Google Play и Huawei App Gallery. В 2020 году AppStore отклонил миллион приложений, которые публиковались впервые, и миллион апдейтов.

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

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

Мы составили чек-лист очевидных и не очень очевидных причин, по которым AppStore отклоняет приложения. Сам чек-лист в гугл-доке. В статье раскроем подробнее каждый пункт.

Нарушения политики конфиденциальности и пользовательских данных

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

Данные передаются третьим лицам. Приложения, которые управляют другими мобильными устройствами, не должны продавать или передавать данные с управляемых устройств третьим лицам.Это также касается приложений, которые собирают данные в рамках медицинских исследований или данные о здоровье. Они не должны передавать их третьим лицам и использовать для аналитики и настройки контекстной рекламы.

Нарушение функциональных требований

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

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

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

UI, не соответствующий Human Interface Guideline. Сложное для использования приложение, имеющее нелогичное поведение и расположение элементов, отклонят.

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

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

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

Изменение поведения системных функций, кнопок или жестов. Нельзя изменять поведение кнопок громкости или жестов свайпа панели управления.

Для распознавания по FaceID используются сторонние технологии. Идентификация пользователя по FaceID должна происходить только с помощью библиотеки LocalAuthentication.

Нет входа по AppleID, если есть возможность входа через соцсети. Это обязательно для iOS 13 и новее.

Нарушения в оформлении приложения

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

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

Есть слова Beta, Demo или Debug в названии приложения. Такие приложения запрещены к публикации в магазине App Store. Для бета-версий есть Test Flight.

Нет описания новой функциональности у обновлённого приложения. Если в приложении появилась новая функциональность, необходимо описать её в поле в App Store Connect. Без чёткого описания приложение ревью не пройдёт.

Скриншоты приложения, иконка и другой контент на странице магазина не подходят для аудитории 4+. И не важно, что приложение может быть не предназначено для такого возраста: аудитория App Store дети от четырёх лет.

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

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

Файл с расширением .ipa превышает размер 50 мб в момент публикации.

Нет демо-пользователя для ревью, если приложение требует обязательной авторизации.

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

Реклама не соответствует возрастному рейтингу приложения. Также важно убедиться, что она не сбивает пользователя с толку и не мешает ему.

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

В период пандемии этот пункт стал особенно важен: Apple строго следит за распространением информации, связанной с COVID-19.

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

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

Приложение поощряет незаконное использование оружия или позволяет его купить.

Есть откровенно сексуальный или порнографический контент.

Приложение разрешает анонимную отправку смс/ммс, анонимные звонки, розыгрыши.

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

У карты лояльности в wallet нет контактной информации о компании. Её нужно добавить, чтобы пользователи могли связаться с компанией, если захотят.

Покупки в приложении

Цифровой контент продаётся не через in-app purchase.К цифровому контенту относятся подписки, музыка в приложении, видео, расширенный доступ к функциям.

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

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

Приложение не предоставляет пользователю всю необходимую информацию о покупке до момента продажи. Это важно, если приложение использует Apple Pay. Также недопустима кастомизация окна оплаты.

Категория Kids

Kids в App Store отдельный вид приложений. К ним Apple относится максимально строго. Категория Kids делится на три подкатегории: до 5 лет, 68 лет, 911 лет.

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

Не соблюдены законы, касающиеся защиты конфиденциальности детей в интернете. Запрещено отправлять личную информацию и данные об устройстве третьим лицам.

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

Составили гугл-док с чек-листом требований для ревью App Store.

А по каким причинам App Store отклонял ваши приложения? Расскажите в комментариях.

Как ни странно, мало кто знает о том, что у Huawei есть ферма устройств в облаке, которую можно использовать для отладки и тестирования. И речь идет не об отладке через веб-интерфейс, что является более-менее известной фичёй консоли разработчика Huawei. Мы поговорим об отладке непосредственно из студии, с возможностью пользоваться ADB.

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

Следующим шагом открываем студию и устанавливаем плагин HMS Toolkit из магазин плагинов в самой студии (File -> Settings -> Plugins).

В верхнем меню появится пункт HMS, в котором будет всё, относящееся к Huawei Mobile Services, но нас сейчас интересует именно Cloud Debugging.

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

Лично я предпочитаю логиниться по QR-коду, но опять же, сейчас это неважно. После успешного логина нам надо будет подтвердить, что мы выполняем логин для HMS Toolkit.

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

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

Можно выполнять все команды ADB, получать с устройства скриншоты и так далее.

Мне эта ферма помогла отладить своё приложение на разных моделях телефонов от Huawei. Когда-то в ней были и телефоны Honor, но сейчас когда бизнес Honor продан этих телефонов в ферме уже нет.

Если кому-то интересно, устройства в ферме все реальные, можно включить камеру с подсветкой и увидеть даже соседние девайсы.

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

Flutter позволяет вам писать простые и понятные тесты для разных частей приложения.

Сегодня мы попробуем написать несколько unit тестов, которые используются для тестирования классов, методов и отдельных функций.

Также мы попробуем использовать библиотеку Mockito, которая позволяет создавать фейковые реализации.

Ну что ж, приступаем к тестированию!

Добавления необходимых зависимостей

Нам понадобиться два дополнительных пакета mockito и build_runner, поэтому добавим их:

# зависимости для разработки# в данном случае подключено тестированиеdev_dependencies:  flutter_test:    sdk: flutter  mockito: ^5.0.10  build_runner: ^2.0.4

Теперь мы можем приступать к тестированию

Пишем первый тест

В качестве объекта тестирования будет небольшой класс Stack:

class Stack<T> {  final stack = <T>[];    void push(T t) {    stack.add(t);  }    T? pop() {    if (isEmpty) {      return null;    }    return stack.removeLast();  }    bool get isEmpty => stack.isEmpty; }

Обратите внимание: класс Stack является обобщенным.

В корневой директории нашего проекта есть папка test, которая предназначена для тестов.

Создадим в ней новый файл stack_test.dart:

import 'package:flutter_test/flutter_test.dart';import 'package:json_placeholder_app/helpers/stack.dart';void main() {  // группа тестов  group("Stack", () {    // первый тест на пустой стек    test("Stack should be empty", () {      // expect принимает текущее значение       // и сравнивает его с правильным      // если значения не совпадают, тест не пройден      expect(Stack().isEmpty, true);    });    test("Stack shouldn't be empty", () {      final stack = Stack<int>();      stack.push(5);      expect(stack.isEmpty, false);    });    test("Stack should be popped", () {      final stack = Stack<int>();      stack.push(5);      expect(stack.pop(), 5);    });    test("Stack should be work correctly", () {      final stack = Stack<int>();      stack.push(1);      stack.push(2);      stack.push(5);      expect(stack.pop(), 5);      expect(stack.pop(), 2);      expect(stack.isEmpty, false);    });  });}

Довольно просто! Не правда ли?

На самом деле, это один из типов тестирования, который называется unit (модульное).

Также Flutter поддерживает:

• Widget тестирование

• Интеграционное тестирование

В данной статье мы рассмотрим только unit тестирование.

Давайте выполним наши тесты командой flutter test test/stack_test.dart:

Успешно!

Тестируем получение постов

Сначала видоизменим метод fetchPosts:

Future<PostList> fetchPosts({http.Client? client}) async {  // сначала создаем URL, по которому  // мы будем делать запрос  final url = Uri.parse("$SERVER/posts");  // делаем GET запрос  final response =  (client == null) ? await http.get(url) : await client.get(url);  // проверяем статус ответа  if (response.statusCode == 200) {    // если все ок то возвращаем посты    // json.decode парсит ответ    return PostList.fromJson(json.decode(response.body));  } else {    // в противном случае вызываем исключение    throw Exception("failed request");  }}

Теперь переходим к написанию самого теста.

Мы будем использовать mockito для создания фейкового http.Client'а

Создадим файл post_test.dart в папке tests:

import 'package:flutter_test/flutter_test.dart';import 'package:http/http.dart' as http;import 'package:json_placeholder_app/data/repository.dart';import 'package:json_placeholder_app/models/post.dart';import 'package:mockito/annotations.dart';import 'package:mockito/mockito.dart';// данный файл будет сгенерированimport 'post_test.mocks.dart';// аннотация mockito@GenerateMocks([http.Client])void main() {  // создаем наш репозиторий  final repo = Repository();  group("fetchPosts", () {      test('returns posts if the http call completes successfully', () async {        // создаем фейковый клиент        final client = MockClient();        // ответ на запрос        when(client.get(Uri.parse('https://jsonplaceholder.typicode.com/posts')))            .thenAnswer((_) async => http.Response('[{"userId": 1, "id": 2, "title": "Title", "content": "Content"}]', 200));        // проверяем корректность работы fetchPosts        // при удачном выполнении        final postList = await repo.fetchPosts(client: client);        expect(postList, isA<PostList>());        expect(postList.posts.length, 1);        expect(postList.posts.first.title, "Title");      });      test('throws an exception if the http call completes with an error', () {        final client = MockClient();        // генерация ошибки        when(client.get(Uri.parse('https://jsonplaceholder.typicode.com/posts')))            .thenAnswer((_) async => http.Response('Not Found', 404));        // проверка на исключение        expect(repo.fetchPosts(client: client), throwsException);      });  });}

Перед запуском теста необходимо сгенерировать post_test.mocks.dart файл:

flutter pub run build_runner build

После этого выполняем наши тесты командой flutter test test/post_test.dart:

Вуаля!

Заключение

Мы разобрали один из самых простых и известных типов тестирования - unit (модульное).

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

Полезные ссылки:

• Github исходный код

• An introduction to unit testing

• Mock dependencies using Mockito

• Testing Flutter apps

Всем хорошего кода!

Предисловие

Это вторая часть обзора дозиметра-радиометра-спектрометра RadiaCode-101, новинки 2021 года в мире дозиметров от компании Скан-Электроникс. В первой части мы рассмотрели прибор, его характеристики, провели некоторые тесты и испытали функцию гамма-спектрометра. Но, прибор позволяет подключатся к смартфонам или ПК, поэтому сегодня мы рассмотрим программное обеспечение для них. Обзор описывает состояние приложения на начало июня 2021, v. 1.00.15, в дальнейшем, возможно, будут дополнения.

Android-приложение

Приложение для управления RadiaCode-101 бесплатное, доступно в Google Play и называется RadiaCode. После скачивания и установки мы попадаем в основное тело приложения, где имеются три вкладки: "Главная", "Журнал", "Спектр".

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

"Главная"

Вкладка "Журнал" представляет собой таблицу, в которую заносятся события и параметра прибора, автоматические измерения, измерения, выполненные вручную и измерения по расписанию. Сверху таблицы отображаются условные обозначения типов записей и значок "Настроек журнала". В "Настройках журнала" можно выбрать, какие события будут отображаться и как сортироваться. При длительном нажатии на запись в журнале ее можно выделить, а затем, при нажатии трех точек в верхнем правом углу, комментировать или удалить, а также очистить весь журнал.

"Журнал""Настройки журнала", (Фото 1)"Настройки журнала", (Фото 2)

Вкладка "Спектр" представляет собой поле, в котором происходит построение спектрограммы. Поле имеет две отградуированные оси, и элементы масштабирования и управления слева. Помимо этого сверху отображается время набора и частота обновления спектрограммы. Спектр можно приближать, изменять масштаб с логарифмического на линейный, изменять отображение фона. При нажатии трех точек можно перезапустить накопление спектра, поделится им, сохранить в "Библиотеку спектров" или войти в нее. "Библиотека спектров" представляет из себя список всех сохраненных спектров с небольшой иконкой, которые можно переименовывать, устанавливать как фон, делиться ими или удалять. Накопленные спектры можно экспортировать в формате .csv при нажатии кнопки "Поделиться спектром", а затем импортировать в Bequerel Monitor или InterSpec. Возможно три варианта отображения фона на спектре: без наложения фона, наложение поверх, отображение разницы фона и спектра. Накапливаемый спектр подсвечивается оранжевым, фон зеленым, а разница фиолетовым. В "Настройках спектра" можно выбирать единицы осей, масштаб, отображение фона и последнего канала, варианты отрисовки спектра и фона. Также через "Настройки спектра" можно ввести калибровочные коэффициенты (не трогайте эти настройки, если вы не знаете, как калибровать прибор, о калибровке будет отдельная статья).

"Спектр", наложение фона на спектр"Спектр", отображение разницы между фоном и спектром"Спектр", отображение фона отключено"Настройки спектра", (Фото 1)"Настройки спектра", (Фото 2)"Настройки спектра", (Фото 3)"Калибровочные коэффициенты""Библиотека спектров"

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

"Панель быстрого доступа"

Помимо этого в приложении есть выпадающее меню, вызываемое нажатием на три полоски слева в верхнем углу. В данном меня содержатся такие пункты как "Приборы", "Настройки приложения", "Настройки прибора", "Карта", "Справка", "Обратная связь" и "О RadiaCode".

В пункте "Приборы" можно выбрать интерфейс соединения, а затем и прибор, чтобы подключится к нему, также есть режим "Demo", для демонстрации работы приложения.

"Приборы"

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

"Настройки приложения", (Фото 1)"Настройки приложения", (Фото 2)"Экспертные настройки"

В пункте "Настройки прибора" можно изменять абсолютно все параметры RadiaCode-101 дистанционно, очень удобная функция, если прибор находится в сумке.

"Настройки прибора", (Фото 1)"Настройки прибора", (Фото 2)"Настройки прибора", (Фото 3)

А вот на пункте "Карта" остановимся поподробнее. Он представляет собой окно с Google-картой в центре, цветовой шкалой мощности дозы справа и элементами управления сверху. Для чего это нужно? Дело в том, что RadiaCode-101 вкупе с приложением смартфона умеет строить трек своего перемещения, отмечая новую позицию маркером на карте, цвет которого зависит от мощности дозы в этом месте. Таким образом, при помощи прибора и смартфона можно составлять карты радиационного фона на местности. Вернемся к элементам управления вверху окна. Данные элементы позволяют просмотреть список записанных треков, автоцентрировать карту, автоматически раскрасить маркеры по минимальным и максимальным значениям мощности дозы, быстро запустить или приостановить запись текущего трека, свернуть цветовую шкалу, а значок настроек позволяет войти в "Настройки карты", где можно изменять настройки, связанные с отрисовкой карты и маркеров, определением местоположения. Раздел "Треки" позволяет просмотреть записанные треки, переименовать, удалить или поделиться ими, а также начать запись нового трека. Для этого необходимо включить определение геолокации (GPS) на телефоне и нажать на зеленый значок справа в верхнем углу. После ввода названия и подтверждения на карте начнут появляться метки, расстояние между ними можно изменить в пункте "Настройки приложения". После остановки записи трек можно будет посмотреть на карте в приложении. Пример трека находится в спойлере ниже.

"Карта""Настройки карты", (Фото 1)"Настройки карты", (Фото 2)"Треки"Пример записанного трека

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

"Справка"

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

"Сообщение разработчикам""О RadiaCode"

Программа для Windows

Программа RadiaCode для Windows доступна для скачивания на сайте Скан-Электроникс в разделе "Загрузки". Программа почти полностью дублирует приложение для смартфона, за исключением немного другого оформления. Здесь так же имеются вкладки "Графики", "Журнал" и "Спектр", "Настройки прибора" и функции как в мобильной версии, за исключением "Карт" и наложения фона на спектр. Для стационарного использования такого набора функций более чем достаточно.

"Графики""Журнал""Спектр"

Итоги

Надо отметить, что у разработчиков получилось реализовать удобное и функциональное ПО для работы с прибором. На данный момент ПО RadiaCode-101 немного "сыровато", но разработчики активно исправляют ошибки и добавляют функции, которых просто нет в продуктах других производителей, обновления выходят часто и ПО быстро развивается. Учитывая то, сколько нововведений и исправлений ошибок было сделано, мне кажется, что прибор и его ПО имеют большую перспективу.

P.S. В дальнейшем после глобальных обновлений ПО и функций RadiaCode-101 будут дополнения, а также я намереваюсь написать статью про калибровку этого прибора.

Всех тех, кто купил прибор, приглашаю в Telegram-чат прибора, здесь можно узнать новости, задать вопросы, сообщить разработчикам о багах:https://t.me/radiacode101

Купить прибор можно на сайте компании Скан-Электроникс.

Буду рад, если обзор оказался полезным или интересным!

Это продолжение серии статей о нестабильных тестах.

В первой статье(оригинал/перевод на хабре) говорилось о 4 компонентах, в которых могут возникать нестабильные тесты.

В этой статье дадим советы как избежать нестабильных тестов в каждом из 4 компонентов.

Компоненты

Итак 4 компонента в которых могут возникать нестабильные тесты:

• Сами тесты;

• Фреймворк для запуска тестов;

• Сервисы и библиотеки, от которых зависит тестируемая система и тестовый фреймворк;

• Операционная система и устройство с которым взаимодействует фреймворк автотестирования.

Это отображено на рисунке 1.

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

Сами тесты

Сами тесты могут быть нестабильными.

Причины могут быть в тестовых данных, сценариях автотестов, предусловии автотестов и начальных состояниях других зависимостей.

Таблица 1 Причины, варианты локализации проблемы и варианты решения нестабильности в самих тестах.

Фреймворк для запуска тестов

Ненадежный фреймворк для запуска тестов может привести к нестабильности

Таблица 2 Причины, варианта локализации проблемы, и варианты решения нестабильности в фреймворке для запуска тестов

Сервисы и библиотеки, от которых зависит тестируемая система и тестовый фреймворк

Приложение (или тестируемая система) может быть источником нестабильности.

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

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

Таблица 3 Причины, варианта локализации проблемы, и варианты решения нестабильности в приложении или тестируемой системе

Операционная система и устройство с которым взаимодействует фреймворк автотестирования

Наконец, оборудование и операционная система могут быть источником нестабильности тестов.

Таблица 4 Причины, варианта локализации проблемы, и варианты решения нестабильности в ОС и устройстве с которым взаимодействует фреймворк автотестирования

Заключение

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

Ссылки на источники

• Откуда берутся нестабильные тесты? (оригинал/ перевод статьи на хабре)

• Нестабильные тесты в Google и как мы их исправляем (оригинал)

• Мои тесты на Selenium не стабильны! (оригинал)

• Избегайте нестабильных тестов (оригинал)

• Нестабильные тесты одна из основных проблем автоматизированного тестирования(оригинал/ перевод статьи на хабре)

Автоматизация тестирования обычно вводится в проект для решения таких проблем, как повторяющаяся ручная работа, работа с большими наборами данных или получение более быстрой обратной связи в пайплайне CI / CD. Из-за этого шума вокруг автоматизации тестирования вы можете подумать о том, чтобы автоматизировать все. Возможно, вы уже выбрали фреймворк тестирования и команду, которая будет выполнять автоматизацию тестирования. Но серьезно ли вы задумывались о том, что вам следует автоматизировать или насколько это выполнимо для вас?

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

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

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

Автоматизируйте ваши смоук тесты

Смоук тесты очень важно выполнять для получение уверенности, что ваше приложение функционирует на базовом уровне, после каждого измененияили при создании нового билда. Смоук тесты могут быть интегрированы в пайплайн CI / CD, чтобы убедиться, что блокирующие ошибки обнаруживаются на ранней стадии. Смоук тесты гарантируют, что наиболее важные аспекты и основные компоненты приложения работают правильно. Они тестируют области, которые всегда должны работать, и могут помочь вам понять, достаточно ли стабильна сборка или приложение для продолжения дальнейшего тестирования. Автоматизация смоук тестов может:

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

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

3. Приводит к меньшему количеству ручного труда и экономит время. Путем интеграции ваших автотестов в пайплайн CI/CD ваши смоук тесты сворершают проверку до завершения сборки. Это означает, что сборка не передается QA, если автотесты не пройдут смоук.

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

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

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

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

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

Автоматизируйте обширные тесты

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

Автоматизируйте тесты, требующие нескольких конфигураций

Речь идет о тестах в различных операционных системахи комбинациях браузеров. Делать все это вручную - утомительно. Также, автоматизация таких тестов может помочь сэкономить время. Автотесты можно запускать в различных средах (таких как Dev, QA, Staging, Integration или PROD), просто изменив переменную среды. Тесты также можно запускать параллельно, что сокращает время, необходимое для выполнения. Вы можете использовать различные инструменты CI, такие как CircleCI, чтобы указать ОС, браузеры и среды, в которых вы хотите запускать параллельные тесты. Убедитесь, что вы следуете лучшим практикам при создании параллельных тестов, чтобы получить от них максимальную пользу.

Автоматизируйте ваши тесты производительности

Это позволяет избежать сбоев при запуске, и снижения производительности. Тестирование производительности проверяет, как система работает под нагрузкой и стрессом, а также выявляет узкие места. Он проверяет скорость, время отклика, надежность, использование ресурсов и масштабируемость программного обеспечения в соответствии с ожидаемой рабочей нагрузкой. Автоматизация может помочь вам легко сгенерировать тысячи пользователей, чтобы увидеть, как приложение отреагирует. Например, Fandango - один из крупнейших в Америке сайтов по продаже билетов (около 36 миллионов посетителей в месяц покупают билеты на их сайте), и они хотели убедиться, что готовы к фильму Звездные войны: Последний джедай. Они хотели узнать, какова их пиковая производительность и определить узкие места. QualityWorks автоматизировала тесты производительности и предоставила им отчеты, которые помогли бы выявить узкие места, и в результате они успешно запустили продажу фильмов. Это то, что они могут продолжать использовать, чтобы гарантировать, что производительность их веб-сайта соответствует определенным стандартам.

Ваш следующий шаг

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

Переведено командой QApedia. Еще больше переведенных статей вы найдете на нашем телеграм-канале.

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

Митап и стрим стартуют 20 мая в 18:30 по московскому времени.

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

В программе три доклада.

Типичные ошибки при написании кода автотестов

Андрей Шальнев, QAA в Skyeng, расскажет, как его команда внедрила код-ревью как процесс, которого придерживаются в компании, и даст готовый чек-лист с примерами: что проверять и как поправить.

Data QA test reporting

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

Уволиться нельзя работать. Немного про эмоциональное выгорание

Гульшат Афлетунова, QA Lead в Skyeng, говорит о своем докладе так:

Я работала в офигенной команде, в офигенной компании и кайфовала от выпуска крутых продуктов. Пока не пропустила первую стадию выгорания. Затем вторую. Затем третью. А затем уволилась. И начала себя вытаскивать. Поделюсь, как не дойти до такого и выбираться, если дошли.

p.s. Запись митапа будет доступна по той же ссылке, что и трансляция.

Кукусики!

Меня зовут Юля, и я Mobile QA в компании Vivid Money.

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

В этой статье я расскажу, КАК ОБЛЕГЧИТЬ ЖИЗНЬ ТЕСТИРОВЩИКУ ВО ВРЕМЯ РЕГРЕССА!

Расскажу по порядку:

1. Наши процессы (для полноты картины)

2. Основную проблему

3. Анализ

4. Методы решения, с полученными результатами

Немного о наших процессах

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

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

Практически все позитивные сценарии проверки покрыты тест кейсами, которые ведутся в Allure TestOps.

У каждой платформы (я имею ввиду iOS, Android) своя документация и автотесты, но все хранится в одном месте. Любой QA из команды может посмотреть и отредактировать их. Если добавляются новые кейсы, то они обязательно проходят ревью. Тестировщик Android проводит ревью для iOS, и наоборот. Это актуально для ручных тестов.

Про тест план для регресса:

Для проведения регрессионного тестирования, составляется тест план с ручными тест кейсами и автотестами, отдельно для Android и iOS. Тестировщик собирает лаунч (запуск тест плана), в котором указывает версию релизной сборки и платформу. После создания лаунча, запускаются автотесты с выбранными кейсами, а ответственный за ручное тестирование назначает мануальные тест кейсы на себя. Каждый проходимый кейс отмечается статусом: Passed, Failed или Skipped. В ходе проверки сразу отображаются результаты.

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

Определим проблему

Увеличение объема тестируемого функционала при проведении регресса, и выход из временных рамок.
Или тест кейсов все больше и больше, а времени у нас только 8 часов максимум!

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

Анализ и решение

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

Расписав слабые места, мы решили доработать подход к автоматизации, а еще воспользовались импакт-анализом для выделения методов решения.

Impact Analysis (импакт анализ) это исследование, которое позволяет указать затронутые места в проекте при разработке новой или изменении старой функциональности.

Что же мы решили изменить, чтобы разгрузить ручное тестирование и сократить регресс:

1. Увеличение количества автотестов и разработка единого сценария перевода тест кейсов в автоматизацию

2. Разделение тестируемого функционала на фронтенд и бэкенд

3. Изменение подхода к формированию тест плана на регресс и смоук

4. Подключение автоматического анализа изменений, входящих в релизную сборку

Ниже я расскажу про каждый пункт более подробно и какие результаты были получены после введения.

Увеличение количества автотестов

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

Чтобы процесс был одинаковым для обеих платформ, была написана инструкция. В ней расписаны критерии перевода, шаги и инструменты. Я коротко распишу как происходит перевод тест кейсов в автоматизацию:

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

2. В Allure TestOps дорабатываются тест кейсы, например добавляется больше описания или json.

3. Переводятся соответствующие тест кейсы в статус need to automate (так же в Allure TestOps)

4. Создается задача в Youtrack. В ней описывается, что нужно автоматизировать. Прикладываются ссылки на тест кейсы из Allure TestOps. И назначается ответственный AQA.

5. Затем, задачи из Youtrack берутся в работу исходя из приоритетов. После того как изменения влиты в нужные ветки и прошли ревью, задачи закрываются, а тест кейсы в Allure переводятся в Automated со статусом Active. Ревью кода автотестов проводят разработчики.

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

Результаты:

• Сокращение нагрузки на ручное тестирование.

• Четкий и простой механизм перевода в автоматизацию. Все заняты - нет простоев.

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

Backend и frontend отдельно

Автоматизация тестирования у нас разделена для backend и frontend.

Но есть E2E тесты, которые тестируют взаимодействие.

E2E (end-to-end) или сквозное тестирование это когда тестируется вся система от начала до конца. Включает в себя обеспечение того, чтобы все интегрированные части приложения функционировали и работали вместе, как ожидалось.

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

Поработав в таком формате, мы решили, что много времени уходит на починку автотестов. И тогда E2E тесты приходится проходить вручную.

Было принято четко разделить функционал на модули с выделением логики на фронтенде и бэкенде. Оставить минимальное количество Е2Е тестов для ручного тестирования. Остальные сценарии упростить и автоматизировать. И так на бэкенде мы проверяем бизнес логику, а на клиенте корректное отображение данных от бэке и ui элементы.

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

Для наглядности вот табличка:

Результаты

После разделения:

• Стало проще локализовать проблему

• Раньше определяются проблемы и соответственно решаются быстрее

• Есть четкое разграничение зон ответственности. Нет лишних проверок на клиенте.

• Автотесты стали гораздо стабильнее, т.к. не завязаны на сервисы или моки, которые могут отваливаться в любой момент. (А этот любой момент обычно самый неподходящий)

• Сократилось время на реализацию автотестов, не нужно добавлять json в тест кейсы дополнительно при написании

Отфильтровали тест кейсы в тест плане на регресс

Формирование тест плана на регресс, исходя из того, в каких блоках были внесены изменения. А также выбор основных постоянных сценариев проверки.

Для того, чтобы проще было формировать план, мы стали использовать теги.

Пример: Regress_Deeplink, Regress_Profile, Regress_CommonMobile

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

Это позволяет нам оперативно отфильтровать и быстро сформировать определённый план в соответствии с вносимыми изменениями, а не тратить время на проверку того, что не было затронуто.

Результаты

Введение дополнительного анализа, при формировании тест планов, помогло сократить общее время прохождения регрессионного тестирования всего до 2 часов с 8ми изначальных. У нас есть несколько тест планов full и light. Обычно мы проходим light и он состоит из 98 кейсов (автотестов+ручных). Как видно на скрине, полный план регресса состоит из 297 тест кейсов!

Время на прохождение Regress iOS light в среднем составляет около 2 часов, но когда изменения были только в паре модулей, то можно провести регресс и за час. Это большой плюс, потому что остается запас на багофиксы (если понадобится что-то срочно исправить). Также, в будущем, всегда есть возможность посмотреть по отчетам, в какой сборке что проверялось.

Разработали скрипт с анализом изменений и оповещением через Slack

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

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

Логически возникло следующее решение - сделать этот процесс автоматическим!

Был создан скрипт, который собирает информацию по коммитам. И далее, сформировав отчет о том, какие модули были затронуты, отправляет необходимую информацию в специальный канал Slack.

Скрипт работает просто:

• После каждой сборки получает изменения между предыдущей версией приложения и коммитам, из которого собрался билд

• Получает список файлов, которые отражают изменения в каком-то экране

• Группирует эти изменения по фичам и командам, чтобы упростить жизнь тестировщикам

• Посылаем сообщение в специальный Slack канал со всей информацией по изменениям

Результаты

Какие плюсы мы получили, подключив аналитику по сборкам:

• Сократили время разработчиков на ручной анализ внесенных изменений

• Снизили вероятность упустить из виду и недопроверить необходимый функционал

• Упростили коммуникацию по данному вопросу

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

Коротко о главном

1. Использование тегов в тест кейсах и при формировании тест планов сократило объем тест плана, соответственно и время на тестирование.

2. Разработка и использование скрипта для оповещение об изменения дало возможность четко понимать какие модули были затронуты при разработке задач для релиза. Или при исправлении багов. Так же тестировщики перестали отвлекать разработчиков с такими вопросами.

3. Автоматизацией было покрыто около 46% тест кейсов, что сильно облегчило ручное тестирование. К тому же остается время на актуализацию кейсов и написание новых.

   

4. Разделение тестирования на backend и frontend помогло заранее определять локализацию проблем и своевременное исправление.