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

Чтобы было легче найти материал, я сделал теги:
#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