Привет, мой дорогой читатель!
За все время работы в ИТ, я понял, что материалов по тестированию или управлению командами много, и порой уходят часы или дни на то, чтобы отсмотреть кучу всего. Редко нахожу видео настолько крутое, что хочется поделиться им или посоветовать кому-то в будущем. Этот канал - закладки хороших выступлений, а иногда и каких-то мыслей на злобу дня.

Чтобы было легче найти материал, я сделал теги:
#mobile - все, что связано с мобильным тестированием
#web - все, что связано с тестированием web приложений, или не специфичными мобильному тестированию.
#auto - немножко про автоматизацию тестирования
#team - мысли по управлению командами.
#free - свободные темы.

Следи за каналом, будет интересно!

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

Прежде всего давайте вспомним, как можно вообще получить координату? Сегодня в мобильных телефонах существует три основных варианта ее получения:
• Geo IP
• GPS (Он же Глонасс / Бейдоу / Галелео / итд)
• Cell ID (По вышкам)

Все эти системы могут включаться в определенном порядке для максимально точного и быстрого определения вашей координаты.
Данные, которые мы получаем, надо как-то обрабатывать, и снова задача нетривиальная. Например, как обработать кейс, когда при ошибке получения координат нас перемещает за 1000км от нашей текущей точки? Конечно же мы ждем, что приложение корректно отработает и этот кейс. Чтобы проверить как приложение будет работать в таких случаях, нам помогут инструменты. С помощью Maps to GPX мы можем построить любой маршрут с любыми отклонениями, а, загрузив этот файл в эмулятор Android Studio (в разделе Location можно загрузить файл и воспроизвести), проблем с тестированием у нас не будет. Если нам необходимо посмотреть что-то на живом девайсе, как вариант можно использовать приложения, которые позволяют подставлять фейковые данные, например Lockito.
Для некоторых сервисов, особенно знакомств, также важно не забывать о том, что в ряде случаев нам надо защитить юзера, и не выдавать его точную координату, при этом не потерять функциональность приложения. Одно из решений ребят - это выдавать примерные координаты пользователя с заданной погрешностью и, конечно же, все это надо тоже проверять с учетом настроек приватности.

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

https://www.youtube.com/watch?v=AiRGHjxaVf0&t=1271s

Тестирование «капитальных» объектов

Доклад не сильно применим практически, но уникален для расширения кругозора. Обычно все доклады про тестирование ПО, а это редкий случай, когда рассказывают про «другое» тестирование.

Работая в IT, мы привыкли, что цена нашей ошибки — это либо деньги, либо репутация компании, ведь многие сервисы созданы для того, чтобы «лайкать котиков». А что, если у нас задача протестировать работу атомной электростанции? Подход к тестированию подобной вещи иной. Цена ошибка — жизни миллионов, как вам такой челлендж? Дополнительно, тут надо обеспечивать качество, а не просто контролировать его, ведь задача не только протестировать софт, но и провести испытания всех составляющих.

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

🌀 Ребята из РосАтома применяют полностью цифровой подход в работе: создаётся информационная модель, к ней применяется классическая V-модель управления жизненным циклом. Таким образом, АЭС превращается в тиражируемый и полностью цифровой объект.

🌀 Тестирование и запуск современных АЭС происходит в цифровом виде, и только после этого строители приступают к монтажу, используя всё те же цифровые модели.

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

https://www.youtube.com/watch?v=q86nKzs4_RI&t=9s

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

Причин может быть много, и одна из них — недорабатывает руководитель. Мне сложно говорить за всех, но по моему опыту, в ИТ, бывает, что должность управленца «падает». Вот был крутой специалист, давайте сделаем руководителем! Он справился там, справится и тут. Хороший специалист != по умолчанию хороший руководитель. С моей точки зрения, после входа в должность, у молодого руководителя начинается долгая, кропотливая работа развития навыков управления, мотивации и удерживания людей.

Моя история такая, пришел на новое место работы и задал вопрос своему руководителю: «Как будет оцениваться моя работа и как я пойму, что справляюсь?» Руководитель посмотрел на меня с широко открытыми глазами и говорит: «Делай свою работу хорошо!» Проработав там пару лет, я так и не понял, что он хотел сказать фразой — «делай свою работу хорошо». Я думаю, именно это дало мне стимул не делать так же, когда мне пришлось отвечать за кого-то, кроме себя. Я думаю, что недорабатывающий руководитель может убить на корню удовлетворенность работой у своих подчиненных.
Страшно то, что молодые, а иногда даже опытные руководители не понимают, что цена этого — как в экономическом, так и в человеческом измерении — огромна. У таких сотрудников сильно страдает производительность труда, такой человек приходит домой и выплескивает свои негативные эмоции на других.

Почему так случается? Что с этим делать? Несколько причин это: неизмеримость, обезличенность и ненужность сотрудника в глазах начальника.

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

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

🌀 Ненужность: когда мы что-то делаем, для кого-то важно, но мы не всегда знаем, для кого. Был свидетелем, руководитель подходит к разработчику и говорит: «Какая тебе разница, зачем ты это делаешь? Просто делай свою задачу». Такие реплики не поднимают мотивацию. Но все же просто. Тестировщик помогает разработчику сделать код лучше. Разработчик помогает менеджеру воплотить крутую идею. Ассистент помогает руководителю все успеть. Хирург помогает пациенту поправиться. Бариста дарит клиенту хорошее настроение. Руководитель должен помочь подчиненному понять, на кого влияет его работа. Когда у нас есть понимание нужности, мы более мотивированы.

И конечно, для тех, кто дочитал до конца!
Все эти мысли пришли ко мне после прочтения крутой книги — «Почему не все любят ходить на работу» Патрика Ленсиони. Книга будет полезна всем, вообще неважно какую позицию вы занимаете: руководитель, простой разработчик, дизайнер, продавец в магазине или школьный учитель. Потрясающая подача. Автор рассказывает сложные вещи в формате бульварного романа, и только 5 процентов книги это техническая часть. Советую.
#team

⁠Charles - полезный инструмент в тестировании.

Я обещал образовательно - техническое, а все посты про «другое» тестирование или про управление. Буду чередовать контент.

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

К чему я? А, к стандартам и базовым знаниям. Сейчас тренд по базовым знаниям, с точки зрения инструментов, стал адекватнее, а главное полезным для работы, один из них - сниферытрафика. Спору нет, инструмент нужный. Можно подменить текст на клиенте и потестировать верстку, можно легко зашейпить трафик без инструментов Chrome / developer menu iOS, да вообще, можно много всего. Плюс ко всему, типичная строчка в вакансии тестировщика, а особенно мобильного: умение сниферить HTTPS трафик и модифицировать запросы / ответы с помощью снифера (Charles, Fiddler и другие) (с).

Не хочется делать сравнение инструментов, агитировать за какой-то, выбирайте сами. Лично я использовал оба, но оставил Charles, как боевого товарища, поэтому примеры будут на нем.

Что вам надо, чтобы разобраться в этой области?

🌀 Прочитать статью на Habr под постом. Статья даст понимание, на сколько эти знания необходимы вам прямо сейчас.

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

🌀Посмотреть видео про работу с физическими телефонами. Видео очень короткое и содержательное. К сожалению, не видел хорошего публичного материала про работу с эмуляторами / симуляторами, но у кого будет запрос на это - пишите в ЛС, подскажу.

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

Полученных знаний, с учетом небольшой практики с вашей стороны, должно хватить для прохождения собеседования по этому блоку.
Удачи в освоении Charles.
#web #mobile

Как автотесты ускоряют релизы в Одноклассниках

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

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

Не хочу спойлерить, скажу только то, что в докладе нету технических деталей, однако, можно понять, куда двигаться на пути перехода от ручного тестирования к автоматизированному, зачем вообще нужна автоматизация и что она может дать.
#free
https://youtu.be/2IRlRRycaTw

⁠Пять пороков команды.

Когда я слышу фразу: «Я работаю в команде мечты», снимаю шляпу перед руководителем этого человека. Обычно за этой фразой стоит огромная работа.

Очень часто встречаю людей, которые думают, что наладив разные технические процессы, например банальное внедрение Jira, настройка CI, переход на новый, модный язык программирования и.т.д, можно расслабиться. Команда должна быть этим довольна, ведь у нас все модно и молодежно. К сожалению этого не достаточно. Кроме технических моментов надо вкладываться и в атмосферу в команде. Многие недооценивают, как бы это назвать, «ментальную составляющую», а она важна для продуктивной работы. Что можно сделать, чтобы улучшить атмосферу? Прежде всего бороться с так называемыми «пороками».

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

Как бонус, в конце поста вы найдете тест, пройдя который, вы сможете оценить, какое положение дел у вас.

Итак, давайте по всем пунктам, которые затрудняют создать команду мечты:

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

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

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

Нетребовательность к другим
Я часто слышу от людей фразу «Это не мое дело». Причем эту фразу используют даже тогда, когда понимают, что какие-то действия (или, наоборот, бездействие) вредны для компании. Возможно это пережиток прошлого, ведь во времена СССР был лозунг — не высовывайся. Я убежден, что в первую очередь, надо руководствоваться интересами компании, а не страхом того, что ты скажешь кому-то, что-то неудобное. Надо быть требовательным к себе, и в разумной степени, к другим.

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

Все эти мысли я подчеркнул из книги того же автора, Патрика Ленсиони - «Пять пороков команды». К сожалению нельзя так же хорошо передать все мысли этой книги, поэтому советую всем этот крутой бизнес роман.
#team

Вернемся к техническим темам, поговорим об энергопотреблении приложений.

Страшный сон разработчикам мобильных приложений - попасть в топ энергопотребления на телефонах своих пользователей. Одно время люди удаляли приложение Facebook и переходили на использование мобильной версии сайта, большой расход энергии. Наверно именно поэтому, часто слышу идеи: «Давайте мерить энергопотребление в мобильных приложениях!»

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

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

И да, если понравился какой-то пост, поделитесь с другом или подругой, пусть в профессии будет больше профессионалов.
#mobile

https://youtu.be/FRWvJpwyYrU

Краудсорсинг в тестировании

Вернемся к свободным темам. С каждым днем программное обеспечение становится все сложнее и сложнее. Но люди все так же хотят: быстро, качественно и дёшево, классический оксюморон. Не смотря на то, что в этом требовании есть явное противоречие, с этим надо жить. Классическое решение части этих проблемы «в лоб»:
🌀Оптимизировать процессы.
🌀Раздувать штат пропорционально увеличению загрузки, если оптимизировали все, что только можно.

Кроме вариантов «в лоб», есть ли еще варианты? Да есть, и на самом деле их много. Один из них - внедрять различные вариации краудсорсинга, или групп внешнего тестирования. Мне понравилось определение, которое дали на одном из докладов Гейзенбага.

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

Где это можно применить? По моим наблюдениям, краудсорсинг в тестировании, чаще всего используется в игровых проектах (Innova Systems, Wargaming.net, Mail.ru Group, и другие). В первую очередь это связано с миксом сложности самого функционала ПО и сложности его автоматизации. Я думаю, что подобное применений краудсорсинга полностью оправдано. Есть и не игровые проекты, где этот подход используется, например в Mail.ru Group на проекте ВКонтакте, тестирование ассессорами в Яндексе, различные отдельные площадки, на которых можно заказать такую услугу / стать бета-тестером. Гугл выдает массу ссылок на эту тему.

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

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

Анастасия Семенюк — «Бета-тестирование ВКонтакте»
Ольга Мегорская — «Краудсорсинг в тестировании»

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

Материал будет полезен тем, кто занимается оптимизацией процессов, ну или для общего развития в области тестирования. Тем у кого нету ни первой ни второй задачи - просто ставьте лайк и идите пить чай. К сожалению, вы не сможете применить эти знания здесь и сейчас.
Ps: конечно, тут нет рекламы. Названия некоторых компаний в посте принудительно превращаются системой в урл. Чтобы было одинаково, прилепил ссылка на сайт всех упомянутых компаний.
#free

Деньги в мире ИТ.

Часто слышу фразу: «Вам слишком много платят, посмотрите, как люди живут!». Да, платят очень хорошо, но это по меркам России. По меркам мира, ИТшники зарабатывают просто нормально, а вот другим - недоплачивают. Приведу несколько цифр, это цифры не точные, но температура по больнице будет правильной. Врач в Германии, в среднем, получает около ~4k - 5k €, разработчик получает так же, ~4k - 5k €. И пусть будет разброс от квалификации, но порядок примерно сопоставим. Если посмотреть на ситуацию в России, то я вижу разницу зп (заработная плата) в 5 - 10 раз. Люди, которые создают сервисы, чтобы лайкать котиков имеют в разы больше, чем люди, которые спасают других людей. Это ужасно. Но почему у нас так? С моей точки зрения нет конкуренции с внешним миром для 90% профессий.

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

А теперь о совсем плохом. Большие зарплаты негативно влияют на модель мира молодых ИТшников. Многие хотят на старте зарабатывать много. Гонятся не за опытом, а за деньгами. Лично я, первые 5 лет, выбирал место работы по принципу: «Чему я там научусь?», а не: «Сколько буду зарабатывать?». И только после набора определенной массы знаний, стал продавать свои знания на рынке. С моей точки зрения, это самый правильный путь, чтобы получить больше денег в перспективе. Я думаю, что если взять человека, который гнался за деньгами и человека который гнался за опытом, посмотреть их зп через 10 лет после старта, второй будет иметь больше, ну или в крайнем случае столько же, но знать он будет точно больше.

Не надо на старте карьеры устраиваться единственным тестировщиком / разработчиком, и.т.д. в стартап на большие деньги. Скорее всего у вас не хватит опыта его затащить. Пока есть возможность, работайте в стабильных проектах корпораций, смотрите, как там сделано и получайте опыт. Отдавайте себе отчет в том, что сейчас вы получаете меньше, но в будущем, сможете продать свои знания гораздо дороже. Как правильно было написано в блоге Никиты Макарова:

«Место где ты получаешь опыт, и место, где ты его продаешь - это два разных места»

Каждая ваша ошибка, которую вы совершаете на работе - деньги для компании. Эти деньги - прямая инвестиция в вас, как в работника. Чем меньше компания в вас инвестирует, тем больше вам платят.
#team #free

Отчеты, отчеты и еще раз отчеты.

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

Один из таких инструментов - Allure, система отчетов автотестов, который стал самым популярным в своей области. Основная задача Allure - сделать процесс автотестирования прозрачным для всех, от тестировщика до менеджера продукта. Какие основные проблемы решает Allure?

1. Мануальные тестировщики не знают, насколько автотесты соответствуют написанным тест-кейсам.
2. Мануальные тестировщики не знают, что именно покрывается автотестами, а что нет.

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

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

История о том, как в Одноклассниках начали работать с QA стажерами

Очень часто слышу о том, что стажеры в тестировании - зло. Почему люди так думают? Классические тезисы по этому вопросу:
1. Стажеры ничего не знают.
2. Они съедают время ментора.
3. Они не стабильны в посещении работы.
4. Они могут уйти, ибо растут быстрее, чем компания может им предлагать новую заработную плату.
5. Им может надоесть профессия, перегорят.
6. И.т.д.

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

Подробнее, о том, как это делалось в ОК можно посмотреть в моем выступлении на Гейзенбаге.

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

ps: Я не считаю, что джунами можно заменить всю команду. Везде нужен баланс. Однако правильное замешивание джунов, мидлов и синьоров может дать отличный результат.
#team