Делай хорошо, плохо не делай

Лучший отзыв на мок-собес :)

Но волк. Но яйца. Но балансировать составами всех команд и онбордином людей в них. Чем я занимаюсь на работе — иллюстративно.

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

Поучаствовала в уже третьей конференции сообщества QA Sisters, и как кураторка чужого доклада, и совместно с Еленой Скрипаль провели вокршоп по разбору кейсов на 1-1 от участниц сообщества: https://youtu.be/4z33BtEHqNg

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

Сегодня еще одна тема из комментариев — метрики для автоматизации тестирования глазами лида мануальных тестировщиков. Как говорится, «хороший вопрос». Главная задача автотестов — чтобы они улучшали нашу жизнь, а не ухудшали. Если мы регрессили вручную 3 часа, а автотесты запускаем и разбираем по 6 часов; если у нас автоматизировано не то, что мы регресссим — это не помогает. И во всей оценке автотестов мы отталкиваемся от этого: они должны нам помогать, и это «помогать» желательно пощупать на метриках, а не «ну вроде запускаются, а какая там польза — никто не знает». Потому что если мы потратили 100500 часов на автоматизацию, но она не принесла практической пользы в ежедневной работе (или сделала ее хуже) — мы автоматизируем не туда. Какие метрики я вижу полезными: 1. Тестовое покрытие, в первую очередь основного регресса. Какой % кейсов у нас покрыт. Желательно с разбивкой по критичности (и мб функционалу), чтобы не оказалось, что мы покрыли неприоритетные кейсы первыми. 2. В дополнение к этому — % автоматизируемых кейсов (для не автоматизируемых — выделить основные причины, разделить и считать % по ним). Не настолько животрепещущая в регулярной работе мануальщика метрика, но очень полезная для лида и для обсуждения с лидом автоматизации/автоматизаторами. Если у нас большой % не автоматизируемых кейсов — это повод приглядеться к тому, почему так. Разбивка по причинам позволит определить, какие основные проблемы на пути автоматизации у нас есть (тесты для специфического окружения, сложно получаемый стейт юзера, etc), и попробовать их решить; например, если мы всегда автоматизируем честный E2E, а у нас много кейсов, которые требуют специфического сложно получаемого стейта юзера (например: купить подписку, сделать покупку с ней, обрезать в админке подписку, подождать 5 минут, пока прорастет)  — это повод обсудить АТ на моках для этой группы кейсов. Или совместно найти другое решение. 3. Время ручного прохождения регресса VS время разбора автотестов + время прохождения вручную не автоматизированных кейсов (еще не автоматизированных, сломанных или тех, которые и нельзя автоматизировать). Возможно, стоит мерить еще и со временем прогона автотестов, зависит от вашего релизного флоу (если релиз собирается с вечера, а утром вы приходите и идете разбирать автотесты — это менее критично; если релиз собирается, тестируется и выпускается за 1 день, и у вас жесткие сроки поставки — это критичнее). Если время прохождения очень большое и это аффектит нашу работу — это повод сходить к лиду автоматизаторов и поговорить про это и про оптимизацию (сделать запуск нескольких джоб/сьютов параллельно и другие лайфхаки). 4. Время прохождения автотестов может быть также нужно для запуска на каждом мердж-реквесте/стенде, и тут оно может быть даже критичнее. Особенно если стендов у нас немного, поднимаются они на определенное время, и автотесты, которые идут дольше, чем живет стенд — нам не очень-то помогают. 5. Стабильность тестов и % прохождения. Если у нас в каждом прогоне падает половина автотестов — это какая-то очень грустная история, и ее тоже надо решать централизованно вместе с автоматизаторами. Часто на каждый упавший тест мы просто заводим тикет на починку, но если у нас проблемы со стабильностью в целом — может быть, надо не по 1 тесту чинить, а чтобы самый опытный автоматизатор или их лид сел и посмотрел на картину в целом, в чем может быть причина и как пофисить ее глобально (кейс из моего опыта). 6. Найденные баги (как на релизе, так и на мр/стендах) — опционально. Во-1, приятно видеть, что от автотестов есть польза, и убедиться, что мы реально находим баги с их помощью. Во-2, при запуске на мр-ах можно даже не по багам метрику собирать, а что в принципе АТ работает как подсвечивание разработчику каких-то багов, которые он исправляет до попадания задачи в тестирование, что сокращает цикл передачи задачи туда-сюда и экономит всем время и силы.

Самая сложная для меня задача при проведении собеседования — не делать выводы по первому впечатлению. Я могу прийти на собеседование в 17 в пятницу, уставшая и не радостная, и это может влиять на мое впечатление. Мне может не понравиться резюме кандидата, потому что по нему непонятно, чем он занимался, или потому что мне всегда бросается в глаза, когда в резюме по-разному оформлены отступы или списки, и это сразу дает предвзятость. Мне может не понравиться что-то в кандидате прямо в начале собеседования, что сразу повлияет на мое впечатление и отношение к нему. Надо не давать этому волю, собраться и провести собеседование в обычном ключе. Оценивать ответы и решения кандидата, а не свое первое впечатление. Да, интуиция важна, интуиция дает нам информацию, обработанную на подкорке, быстрее, чем мы сделаем это сознательно, но если мы не будем проверять ее и не будем подтверждать интуитивные решения объективной оценкой и методами с высокой валидностью (я выше выкладывала запись доклада, где я про это рассказываю — да что там, я даже вчера на уроке английского про это рассказывала, валидность методов моя валидность!), мы будем кормить наши когнитивные искажения и снижать эффективность собеседований. Если мы будем идти на поводу только у своих интуитивных впечатлений, мы свалимся в интервью «поговорить за жизнь», которое на самом деле не дает нам достаточно объективной оценки и снижает эффективность найма. Да, если на финальном собеседовании или выборе команды вы понимаете, что вам будет некомфортно работать с этим человеком — это важно и к этому стоит прислушаться. Но технические собеседования я обычно провожу для всего отдела тестирования, а не только для своей команды. Человек, с которым нет метча у меня, может хорошо подойти в ряд команд. Я могу ошибиться в своем первом впечатлении. Я могу быть не очень опытным собеседующим и интуитивно выбирать людей, похожих на себя, не замечая, что я занижаю «оценку» только из-за этого хорошим кандидатам. У нас есть методы с высокой валидностью, позволяющие более объективно сравнивать кандидатов. Давать им равные условия на собеседованиях, анализировать их ответы по достаточно валидным критериям, в определенной степени отсекать нашу субъективность. Да, часто лично мое первое впечатление не меняется по итогам собеседований. Но у меня за спиной много часов собеседований, построение дизайна оных, анализ постфактум, и моя интуиция попросту хорошо натренирована на правильных вводных. И то — я всегда откладываю в сторону свое первое впечатление и провожу собеседование без оглядки на него, чтобы не обмануть саму себя.

В комментариях задали интересный вопрос, на который у меня, кажется, есть неочевидный ответ :) Самый занятный кейс в карьере О чем думала в процессе, как распутала или решила, чем дело закончилось Вот так сев и подумав, я могу вспомнить самые занятные задачки из своей работы руками — когда проводила прямо детективную работу при анализе бага, углублялась в работу сервиса примерно до ядра Земли... Но у меня нет какого-то одного самого занятного кейса из лидской работы. Были разные истории про поиск подхода к людям, поиск общего языка, чтобы объяснить человеку так, чтобы он тебя услышал и понял. Преодоление сопротивления; изменение процессов, которые люди должны принять и начать следовать новым процедурам; корректирующая обратная связь, которую нужно донести так, чтобы пошло во благо; решение личностных конфликтов. Каждый такой случай — уникальный и непростой, этот подбор ключика, и самые сложные кейсы для меня — те, которые я еще не решила или не встретила, потому что я не еще знаю, как их решать. Но у меня есть самая занятная и сложная задача, которую мне пришлось решать на позиции лида, и героиня этого кейса — я сама. Я никогда не думала, что я хочу быть лидом и работать с людьми (скорее была уверена в обратном), поэтому лидство на меня упало довольно внезапно: был нужен человек на эту роль, мои руководители видели мой потенциал в росте в эту сторону, и предложили мне попробовать. 3 месяца пытаешься затащить, потом оцениваем, если пошло — остаешься, если нет — мы сможем безболезненно провернуть фарш назад. Я согласилась и на меня разом упало 15 человек из 5 разных команд, не про все из которых я вообще хорошо что-то знала. А я, знаете ли, по природе тот еще суетолог, и чем больше я переживаю или чем больше всего надо сделать одновременно — тем больше я суечусь, по поводу и без. И вот я поставила все 15 1-1 в первую же неделю, чтобы побыстрее разобраться в том, что же на меня упало, и начала бегать по потолку с подпаленным хвостом. И по опен-спейсу, с вот этой суетой «аааа мои усики, мои лапки, мои 15 1-1, аааа». Где была поймана начальницей, усажена в переговорку, и дальше мне объясняли, что вот эту всю суету наводить я перестаю. Я могу переживать, я могу бегать по потолку, я могу приходить с этим всем к ней и орать и суетиться на 1-1 с ней. Но я не транслирую эту суету в своих подчиненных и свои команды, потому что если я буду постоянно на взводе, то и все мои тестировщики — тоже. «Спокойная мать — спокойные дети». А это очень важно для лида. Ох. Это было реально сложно! С таким суетливым устройством себя я прожила большую часть жизни, а тут надо было научиться действовать и относиться к этому по-новому. Я останавливала себя от эмоций при командах, я следила за тем, что и как я говорю, я бегала по потолку на своих 1-1, мне было, кроме шуток, очень тяжело. Но я смогла измениться, и считаю это самым большим своим челленджем и самой непростой задачей за все это время. И я смогла понять, насколько это было важно, и как мне это умение помогает и в работе, и в жизни. Сейчас пытаюсь научить тому же самому уже свою подчиненную — и вижу в ней себя тогда.

P.s. Может быть, попробовать вариант «напишу пост по вашему запросу/теме»? Если есть вопросы или предложения, велкам в комменты :)

За прошлый год я поменяла работу (поменяла компанию + вернулась из позиции Engineering manager обратно в QA департамент, на роль QA manager), переехала на Кипр, и на канал времени и мозга, к сожалению, не особо хватало и пока не хватает. С одной стороны, жаль, а с другой – всему свое время: как известно, бывает время разбрасывать камни, а бывает – собирать, мой фокус внимания пока на других задачах, а канал стал немножко местом для складывания интересного из других каналов. Зато в этом году снова вписалась в конференцию, которую делает сообщество девушек-тестировщиц QA Sisters, буду там кураторкой доклада и, может быть, прочитаю и свой (про свой пока не знаю точно, посмотрим). Для участия в конференции нужно присоединиться к сообществу http://qa-sisters.com/, после этого уже будет вся информация.

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

А НУ ОТДАЙ Волею судеб в последнее время часто рассказываю про смену тимлида в команде. То на Тимлидконфе (ждете запись? я тоже!!), то своим ребятам. Недавно уходящий вдаль тимлид спросил у меня чек-лист, что передавать при уходе. Поделюсь им и с вами: Про каждого из людей в команде ◻️Что человек регулярно делает в проекте, какие задачи решал, что умеет делать хорошо ◻️Какие задачи нравятся, а каких хотелось бы избежать ◻️Темперамент, мотивация, подходящий стиль управления ◻️Планы на развитие и карьеру, предыдущие договоренности ◻️Известные слабые места и сложности Про проект ◻️Что проект делает и как он устроен (обзорно) ◻️Кто стейкхолдеры проекта и чего они от него ждут ◻️Формальные обязательства: цели, роадмап, KPI, метрики, показатели ◻️Обещания стейкхолдерам и пользователям ◻️Какие есть известные проблемы и риски ◻️Текущее видение краткосрочного и долгосрочного развития продукта Про себя ◻️Что ты делал в проекте с разной регулярностью ◻️Какими уникальными знаниями по проекту ты обладаешь ◻️Доски, тикеты и прочая бухгалтерия, желательно приведенная в порядок ◻️Будешь ли ты готов отвечать на вопросы по проекту после ухода, как долго и в каком формате Еще раз про обещания ◻️Публичные ◻️Внутри команды ◻️Смежникам ◻️Руководителям ◻️Стейкхолдерам Можно дополнять! #тимлид

🌲Из всех активностей, которые я делаю в течение года, адвент-календарь кажется самой доброй и уютной таской! В этом году я подготовил для вас отдельную страницу с 31 подарком. 14 уже открыто, еще 16 будут открыты после 15 декабря и последнее окно станет доступно 31 декабря. QA Advent включает задачи, ресурсы, книги, подписки и прочие вещи, которые могут быть полезны как совсем новичкам, так и моим коллегам. Все бесплатно. В общем, переходите, делитесь, оценивайте! Надеюсь, что вы полюбите его, как и я ❤️ Также все подарки я буду дублировать каждый день в канале @qa_sklad, если не хотите проходить все разом. Кстати, черная пятница еще не закончилась, так что буду рад вашей поддержке в посте выше :)

Подарок от работы в честь этого праздника (тамблер) 😂

В честь профессионального праздника хочется написать, почему тестирование — это не «сломать все», и чем этот подход вреден (спасибо Артему Русову, на днях упомянувшему это и наведшему меня на эти размышления). Тестирование — процесс гораздо шире и глубже, чем только «ломание»: проверка требований и дополнение их на основе нашего знания системы; тест-анализ и тест-дизайн «как мы будем это тестировать» и «как эффективно это протестировать». Выстраивание процесса вместе с разработкой. Оценка рисков и трудозатрат (надо ли упарываться в 100500 минорных проверок? но там же можно что-то «сломать»?). И так далее. Безо всего этого просто «ломание» будет довольно неэффективным. Да, есть ad-hoc тестирование, но это только одна (небольшая) часть тестирования, да и оно тоже не только про это. Вдобавок самоопределение как «Халк ломать», на мой взгляд, не помогает строить продуктивные отношения с другими членами команды. Кому будет приятно работать вместе с человеком, кто говорит, что его цель — сломать то, что ты сделал, no matter how? Это помимо того, что тестирование не ломает ничего. Тестирование находит, где уже было сломано или работало, но не так, как ожидается. Но если приходить и говорить «я вам тут все сломаю», то вспомнить про это будет сложно. И когда на собеседовании человек говорит, что ему нравится в тестировании именно ломать (или это вообще было его мотивацией прийти в тестирование — без какой-либо еще), я сразу задумываюсь, насколько он помнит про все остальные части процесса тестирования. Давайте не ломать, давайте строить вместе процессы обеспечения качества.

О, давайте последний день лета отметим нудежом про собеседования и как не надо делать. Я сейчас много собеседую; поняла тут, что есть три самые бесящие меня на собеседованиях вещи. Резюме, в котором по описанию работ и обязанностей вообще непонятно, чем человек занимался. «Тестировал тесты». Я говорю не про подготовку резюме к HR-этапу, а именно про этап, когда на резюме перед собеседованием кидает взгляд нанимающий менеджер, чтобы понять бекграунд и скиллы кандидата, о чем вообще спрашивать-то. Иногда по резюме я не могу даже понять, что именно человек тестировал — веб там, бэк, мобилки. Интрига! Хотелось бы без нее, правда. И если вы думаете, что я преувеличиваю про «тестировал тесты» — увы! Описание, состоящие полностью из такой неконкретики и воды с 0 подробностей я видела своими глазами. Если пишете резюме с ChatGPT — хоть проверяйте после него, дописывайте сами или корректируйте с ним. Всем будет легче. Рассказ о себе как сага на полчаса, начинающаяся от сотворения мира или тяжелого детства и прибитых к полу игрушек. (Рекорд — 28 минут, и я опять не шучу, я засекала время). «Расскажите о себе и своем опыте» обычно подразумевает краткий, на 5, максимум 10 минут рассказ про ваш профессиональный опыт, сильные стороны и достижения, которые хочется подсветить. (Особенно если достижения вы в резюме не вписали, расскажите о них сейчас!). Достаточно. Если этого не хватило, вас попросят продолжить или развернуть подробнее. Но попробуйте базовый рассказ о себе уложить в эти 5-10 минут сути, потренируйтесь дома по таймеру, например. Утомительно, когда это превращается в анекдот «люблю ходить по собеседованиям, можно поговорить о себе» и подробный экскурс во всю жизнь человека… У нас не сеанс психотерапии, спасибо-пожалуйста. (Нет, у меня есть коллега, который любит такие подробные рассказы, с ним я эти 28 минут и получила, потому что вел собеседование он, но это скорее исключение; и даже с этим исключением — вы всегда можете перейти к более подробному рассказу по наводящим вопросам от интервьюверов). Вписанные «шоб было» в резюме тулзы-скиллы, к вопросам про которые вы не готовы. Например, все это прошли только на курсах, в работе не использовали, вписали в резюме, потому что вам на курсах так сказали или чтобы по этим ключам резюме прошло. На собеседовании почему-то часто превращается в диалог формата: — А у вас автотесты указаны — Ой, это только на курсах проходили — А SQL? — Ой, это тоже только на курсах, в работе не нужно было... — А (подставить следующее, и так до конца списка) — Ну это я сам(а) поизучал(а), но не применяла(с) И с каждым следующим вопросом грустнеет что кандидат, что нанимающий менеджер, у которого ощущение, что он детей бьет. Ну ребят (и девчат). Нашли в себе силы вписать какую-то тулзу, которую только в теории поизучали или на курсах? Найдите в себе силы на вопрос про нее бодро и уверенно ответить «изучали на курсах/самостоятельно, такой вот уровень знаний, если надо будет разбираться дальше — я готов(а)». Просто сравните: — Автотесты? — Изучала на курсах, писала простые автотесты на фронтенд с такими-то селекторами, знания такие-то — SQL? — Писала запросы уровня select, представлю, как работать с join-ами, с ними практики мало было, но если надо будет разобраться, это не проблема. Всё! Лучше же?

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

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

Из случайного диалога на своем балконе (начали за НРИ, продолжили про работу, все как мы любим х) принесу несколько мыслей. Профессионал — это человек, который умеет не только применять изученные инструменты (или паттерны проектирования), но и понимать, в какой ситуации какие их них нужны и почему. Для меня джун-тестировщик становится миддлом*, когда на практике понимает принципы «исчерпывающее тестирование невозможно» и «тестирование показывает наличие багов, а не их отсутствие». Перестать верить в то, что можно идеально протестировать все, принять это, и перейти от блокирования собственной грудью (или страданий по выпуску) неидеального релиза к пониманию и оценке рисков — очень важный шаг внутреннего роста. Сеньором — когда начинает мыслить со стороны бизнеса. Понимать, в каких условиях какие риски для нас приемлемы, уметь говорить с бизнесом на его языке (от «так нельзя» — к «мы можем сделать А или B с такими-то рисками, риски C превышают допустимое всё, но можно посмотреть на это с такой-то стороны и обсудить вариант D») с учетом бизнес value и потребностей для каждого конкретного случая — оценка рисков для MVP и проверки гипотез отличается от ключевого и стабильного продукта. * Конечно, не только по этому критерию, но в каждой шутке есть доля шутки! Лид — тот, кто умеет посмотреть на проект широко, учесть те самые риски и потребности бизнеса, принять решение, какая стратегия нам нужна, исходя из этого, и донести это до членов команды — как мы будем делать в этом случае (возможно — еще с «почему»).

Еще один мой доклад на второй конференции QA Sisters — как провести хорошее интервью кандидата (а также как подготовить все к интервью, и что нужно сделать в цело, чтобы собеседования и наём были более продуктивными и валидными): https://youtu.be/BoKYOQkLPuw