В начале 2024 года я устроилась Senior Software Test Automation Engineer в финтех-стартап. После работы в большой стабильной корпорации это был настоящий вызов ― попасть в живой дышащий мир молодой продуктовой компании, пытающейся занять своё место на рынке. Мне понравился продукт и привлекала возможность влиять на процессы, даже устанавливать новые.
Сперва я изучала как всё работало на тот момент, особенно меня интересовал вопрос обеспечения качества. В жизни я стремлюсь к эффективности: получать больше, а тратить меньше. В бизнесе такой подход приветствуется, особенно в стартапе. Причем стартап банально не выживет если он неэффективен. Я чувствовала себя на месте.
Так вот, в этой компании я встретила подход automation first. Это означало, что весь разрабатываемый функционал сразу же покрывался автотестами. В добавок к этому были задействованы многие продвинутые инженерные практики, к которым, как я знала из опыта, компании и проекты приходили через боль, страдания, унижения и годы беспросветного мануального регрессионного тестирования.
Однако не всё было идеально, проблем тоже хватало, даже при том, что скорости релизов мы достигли прямо таки нереальной, обеспечивая при этом отличное качество. В этой компании существовала доселе не встречавшаяся мне структура ― инженерное комьюнити. В каждой дисциплине было своё. У инженеров по качеству ― QA Community. Польза его для процветания компании неочевидна при первом взгляде. Как человеку, который любит докопаться до причин всего на свете, мне было любопытно как это работает и почему. В том числе влекомая этом любопытством я спустя некоторое время выдвинула свою кандидатуру на должность очередного QA Community Lead. Да, должность выборная, как президенство, срок правления ― год, потом смена власти. Немного ранее выборов у нас сменился СТО и объявил, что теперь теперь избранный кандидат должен получить также апрув от него, а также он может оставаться на должности дольше, если нет возражений от комьюнити и/или СТО. Или пока не настанет импичмент, а такое тоже было в истории компании.
Итак, на момент написания статьи я занимаю позицию QA Community Lead уже более года. Избранная комьюнити, состоящим более чем из 20 QA инженеров, апрувнутая СТО и до сих не свергнутая.
Среди инженеров есть поговорка “Работает ― не трогай”, так что я очень осторожно подошла к изменению процессов. Сперва я внимательно их изучила. Потом наметила план действий. А потом СТО запросил сделать аудит QA процессов и составить стратегию развития комьюнити на следующий год. Так что мои мысли и заметки сумасшедшего обрели формальную форму.
В этой статье изложены те части моей истории в этой компании, которые могут быть полезны для айти-комьюнити, добавлен мой опыт за всю карьеру, наблюдения, мысли и данные научных исследований, объясняющие почему оно так, а не иначе.
Кому будет интересно и полезно читать эту статью: в первую очередь руководителям направлений, СТО, тех-лидам, QA лидам, всем тем, кто отвечает за процессы и стремится к их оптимизации.
Сразу хочу прояснить, что я применяю в работе и жизни человеко-ориентированный подход и тут не будет инструкций как заменить всех инженеров искусственным интеллектом. Хотя некоторые члены руководящего состава были бы только рады такому повороту.
Про что расскажу:
Финтех-стартап: ожидания и реальность
Сила сложного процента в разработке ПО
Топ-5 принципов эффективности в разработке ПО
Где искать автоматизаторов тестирования
Итоги и выводы
Финтех-стартап: ожидания и реальность
Не знаю как вы, а у меня ассоциации были такие как на картинке выше. Самые современные технологии, всё чётко, стерильно, богато ― ведь речь о деньгах, роботы повсюду, мониторинг, графики.
Реальность не то чтобы сильно отличается, на самом деле. Технологии действительно современные, реально есть постоянный мониторинг и куча графиков. Стартап особенно чувствителен к реакции рынка, ему есть что терять. Лучшие инженеры тщательно отобранные из разных стран ― ведь надо быстро делать поставки и проверять гипотезы и качество тоже должно быть на уровне чтобы клиенты не разбежались. Высокий уровень инициативности, личной ответственности и бешеный темп работы. Часто изменения нужны были ещё вчера. У нас есть локальная шутка про то, что важным критерием при приеме к нам на работу являются горящие глаза кандидата.
Из того, что я выделила бы самого важного для программного обеспечения в этой сфере:
Высокая точность и безопасность: ведь работа идёт с деньгами
Гибкость и высокая скорость реагирования: ведь как финансовая организация мы вынуждены неукоснительно следовать букве закона и выполнять требования регуляторов.
Красивый и понятный интерфейс: поскольку на рынке высокая конкуренция и пользователи доверят свои кровно-заработанные только приложениям, которые просты и им можно доверять.
Всё это делает очень сложным баланс пирамиды время-качество-скорость.
С одной стороны ресурсы ограничены, организация молодая и не имеет миллионного капитала, а значит надо брать максимум от того, что есть.
Время работает против нас, конкуренты наступают на пятки, а мы вынуждены стараться больше и быстрее чтобы завоевать аудиторию, успевая при этом соблюдать все ограничения и законы.
А также мы обязаны поддерживать качество на высоком уровне. С одной стороны ради безопасности, с другой ― чтобы удержать клиентов.
Кажется невозможным решить это уравнение без потерь, не так ли?
Здесь вступает в силу мой любимый подход ― эффективность.
Эффективность — это способность достигать поставленных целей с минимально необходимыми затратами времени, ресурсов и усилий, при этом максимально улучшая результат.
Чтобы измерить эффективность я использую понятие из мира инвестици: ROI ― Return On Investment.
ROI в сфере разработки ПО:
Где:
Выгода — это то, что вы получаете (сэкономленные деньги, время, ресурсы, скорость релиза и т.д.).
Затраты — это вложения (деньги, время сотрудников, ресурсы, ПО, обучение и т.д.).
“Звучит здорово!” ― скажете вы. Кто же не хочет платить меньше, а получать больше. Но то, что хорошо звучит не всегда так просто реализовать на практике.
Это подводит нас к следующему пункту моего рассказа.
Сила сложного процента в разработке ПО
Наверняка, многие из вас слышали про силу сложного процента ― термин опять же из мира инвестиций.
Сила сложного процента — это когда проценты начисляются не только на изначальную сумму, но и на уже накопленные проценты. Со временем это создаёт эффект «процентов на проценты», и капитал растёт быстрее, чем при обычных процентах. Если короче: это механизм, при котором деньги зарабатывают деньги.
Так вот, автоматизация ― это сила сложного процента для жизни. Причем я сейчас говорю об автоматизации как о широком понятии. Один раз настроенная она помогает нам накапливать позитивные эффекты от регулярных правильных действий. Ведь если взглянуть шире: наши привычки это тоже автоматизация. Наш мозг тоже стремится к эффективности и тоже не хочет лишний раз тратить когнитивную энергию. Автоматизация помогает экономить ресурс там, где действия повторяются и нам не надо каждый раз напрягать мозги чтобы принимать одно и то же решение снова и снова. И нет нужды напрягать силу воли каждый раз. Помимо прочего, автоматизация никогда не устает, не просит есть и не совершает ошибки потому что у неё был тяжелый день и глаз замылился, не напивается после аванса и не уходит к другому работодателю потому что там есть стоматологическая страховка.
В мире разработки программного обеспечения опять же я имею ввиду автоматизацию в широком смысле. Не только автоматизацию тестирования. Всякое CI/CD, статические анализаторы кода, инфраструктура, мониторинг, алерты и многое другое ― тоже автоматизация. Но как инженер по автоматизации тестирования я буду подробно говорить именно об этом виде автоматизации.
Хочу сразу прояснить: автоматизация не панацея, не волшебная таблетка, решающая все проблемы. И не везде она применима. Но в ситуациях, когда имеет место повторяющийся процесс ― точно есть смысл посмотреть в сторону автоматизации. А также в ситуациях, когда человеческому существу сложно выполнить требуемое действие, например, нужны расчеты высокой точности. Мало кто станет умножать в уме трехзначные числа, скорее мы используем калькулятор. И это тоже пример автоматизации.
Приведу пример работы сложного процента. Допустим у вас родились близнецы и вы открыли каждому по счету на $1000. Любой найдет на будущее малыша. И положили в банк под 15% годовых. Малыш 1 получает обычный счет, проценты просто складываются в отдельную кучку, вы получите их в день окончания счета ― через 25 лет. А малыш 2 получает счет с услугой сложного процента. Т.е начисленные проценты добавляются к сумме изначальной инвестиции. И так каждый год. Угадайте какой будет разница у близнецов когда придет время забирать денюжки и начинать строить собственную жизнь? В семь раз! В семь раз, Карл! Малыш 1 получит $4 750, в то время как малыш 2 почти $33 000! Можно сделать первый взнос по ипотеке. Или купить машину. Малыша 2 явно любили больше.
“Но какое это имеет отношение к разработке ПО?” ― спросите вы. А дело вот в чём: перед первым релизом вам нужно провести тестирование разработанного функционала (объемом n). Перед следующим: надо протестировать новый функционал n и сделать регрессионное тестирование предыдущего функционала чтобы убедиться, что вы не сломали то, что уже работало с первого релиза ― n. Итого 2n. Всего ко второму релизу объем тестирования уже увеличился вдвое. Затраты будут расти вместе с продуктом.
К концу первого года функционирования при стандартной скорости 1 релиз в спринт, а спринт 2 недели, у вас ожидается 26 релизов. Т.е перед последним релизом надо проверить 26n.
Узнаёте формулу? Это арифметическая прогрессия.
А суммарный выполненный объем тестирования за год = 351n.
Если б вначале у вас было 100 тест-кейсов, к концу их было бы 2600.
Как думаете сколько времени занимало бы мануальное регрессионное тестирование 2600 тест-кейсов? А я вам скажу, я это видела ― несколько дней работы целой команды мануальных QA. А еще прибавьте сюда тот факт, что глаз замыливается и люди устают. Кто-то сжульничал. Кто-то отвлёкся. Притом что объем тестирования растет линейно, затрачиваемое время растет быстрее потому что уставшие люди работают медленнее, им нужны перерывы. Качество потихоньку деградирует, потому что уставшие люди делают ошибки. Несколько дней от спринта вся команда сидит и ждет результата от команды мануальных тестировщиков. Сколько времени пройдет прежде чем тестирование доберется до недели? Сколько Manual QA нам придется нанять чтобы выдерживать эту гонку?
А ещё я могу сказать сколько занимает регрессионное тестирование такого объема у нас при помощи автоматизации ― примерно 30 минут. И ограничены мы лишь количеством потоков для параллельного запуска на раннерах.
Многие пренебрегают силой сложного процента и полезными привычками. Считают лишней тратой или незначительным приобретением. И это понятно ― выгода видна не сразу. Но все мы видели примеры, когда наш приятель, например, внедрял одну крошечную привычку, такую как делать зарядку каждое утро по 10 минут. Кажется такая мелочь, ну что это может изменить. А через год мы не могли поверить как подтянулось его тело, возросла работоспособность, повысился уровень энергии. Внезапно он решил открыть бизнес или новое хобби. А через 10 лет оказалось, что он меньше подвержен риску сердечно-сосудистых заболеваний и весит на 20 кг меньше, чем его ровесники в среднем.
Работает и в обратную сторону. Начните съедать всего по одной шоколадке каждый день. Или выкуривать по сигарете. Как изменится ваше состояние через год? Одной штучкой вы ведь не ограничесь, верно?
Не буду скрывать, что у меня особое отношение к автоматизации, ведь я провела около 6 лет изучая автоматизацию сперва в бакалавриате по специальности автоматизация технологический процессов и производсв, а после в магистратуре на специальности автоматизированные системы управления. А теперь я уже более 7 лет работаю автоматизатором тестирования программного обеспечения. Я достаточно давно изучаю и применяю автоматизацию чтобы понять её недооцененность и силу.
Правильно настроенная автоматизация, по моему скоромному мнению, дает ответ на вопрос “Как построить систему, которая будет работать без меня?”. А такой вопрос задают далеко не простаки.
Топ-5 принципов эффективности в разработке ПО
Я рассказала достаточно об автоматизации. Теперь я расскажу какое место она занимает в эффективном производстве ПО.
Сперва покажу как я это вижу, а далее раскрою каждый пункт подробно.
CI/CD и автоматизация
Приоритизация задач
Ежедневная синхронизация
Обратная связь и метрики
Фокус на энергии команды
CI/CD и автоматизация
Я поставила этот пункт первым, поскольку считаю его краеугольным в контексте производства ПО. Без этого очень трудно выпускать код быстро и качественно. Хотя, конечно, возможно. CI/CD стоит автоматизировать в первую очередь, т.е они и повторяющиеся, и сложные для ручного выполнения. К имеющемуся CI/CD имеет смысл тут же добавлять автоматизированное тестирование. Сейчас расскажу почему.
На рисунке выше представлен график зависимости стоимости бага от стадии жизненного цикла разработки программного обеспечения, на которой он был обнаружен. Из изображения очевидно, что жук растет по мере приближения релиза. Причем потери могут быть в связи с упущенной выгодой, репутационными, правовыми и т.д. Как же предотвратить появление таких дорогих багов? Очевидным решением кажется смещение проверки качества левее по графику, т.е раньше в релизном цикле.
Такой подход называется Shift-left и он проиллюстрирован на рисунке ниже.
Как мы уже знаем, повторяющиеся действия ― идеальные кандидаты на автоматизацию. Как только внедрены регулярные проверки на протяжении всего релизного цикла, пора дать им реальную власть. Снизить количество точек, где человек должен принимать решение и может принять его неправильно. Ведь разработчик, в конце концов, может просто проигнорировать тот факт, что тесты на его PR-валидации красные и спокойно смержить код, никто его не остановит. А на выходе получим баги на следующих стадиях. А чем дальше в лес, тем крупнее становятся жуки.
Ответом на задачку этого уровня становятся quality gates. Это механизм автоматического запирания ворот на следующий уровень релизного цикла если не пройдена проверка на текущем уровне.
Давайте представим, что релизный поток ― это поток реки, в котором могут быть нежелательные примеси ― наши баги. Чем чище будет вода, тем выше качество. Наши quality gates это сети-ловушки, которые мы расставим на всю длину реки. И чем больше таких сетей и мельче их ячейки, тем чище будет вода на выходе. Можно, конечно, собирать мусор в реке вручную, но потребуется гораздо больше людей, усилий этих людей и результат все равно может вас не удовлетворить. Кого-то из людей может укусить краб, или ему солнце светит прямо в глаза и он пропустит мусор. Сети же может сплести и расставить вовсе один человек и они будут работать пока он спит, ест или загорает.
Дальше встает вопрос какие именно сети ставить и где, насколько мелкими они будут и прочее. Здесь нам поможет пирамида тестирования.
Опять же на примере сетей и реки очень хорошо можно объяснить почему пирамида устроена именно так.
Нижний уровень ― юнит-тесты. Это простые сети с крупными ячейками, они задержат большой мусор: бревна, крупные ветки и все в таком духе. Такую сеть легко плести и она должна быть самой большой.
Дальше интеграционные тесты. Писать их немного сложнее, дольше и выполняются они чуть медленее. В нашей аналогии это сеть с ячейками поменьше. Однако такие сети нужны в местах интеграции. Например, там, где в реку впадают другие ручейки, принося свои кусочки мусора.
И на самой вершине стоят е2е-тесты. Е2е значит end-to-end. Значит это такая сеть-бредун, с которой надо пройти от самого начала до самого конца. Звучит сложно правда? Плести ее сложно, долго, дорого. Еще и ходить с ней туда-сюда. Кажется, проще кому-то пройти от начала до конца и руками проверить не осталось ли какого мусора в реке, чем мастерить такую сеть. В производстве ПО такая же история. Автоматизировать е2е сценарии очень ресурсозатратно, тяжело их отлаживать, поддерживать. Такие тесты редко ловят баги. Имеет смысл их писать только есть это закрывает какую-то уязвимость, которую руками дороже тестировать, чем автоматизацией. Таких автотестов тестов должно быть по минимуму. Иначе всю пользу автоматизации (скорость, надежность и высвободившийся человеческий ресурс) поглотит сложность и срок написания, отладки и поддержки таких тестов.
Приоритезация
Как-то раз делая ревью своих планов на жизнь, я осознала, что моих желаний слишком много ― они просто не уместятся все в одну жизнь. Придется от чего-то отказаться. Тогда же меня будто пронзило это осознание: говоря “да” одному, мы автоматически говорим “нет” другому. Значит мне придется приоритезировать ― выбрать что для меня важнее всего и поставить в начало списка. Если не успею конец списка ― ничего страшного, ведь эти желания не были самыми важными для меня. Эта же идея подтвердилась когда я подводила итоги года, смотря на список планов и список того, что на самом деле я успела. Успеть все невозможно. Всегда что-то может пойти не так. Поэтому так важно точно знать, что более важно и делать это в первую очередь.
Большинство мудрых идей универсальны, они распространяются на многие другие области жизни. То же касается и этого подхода ― приоритезации. Но как понять что важно? В жизни каждый сам отвечает на этот вопрос, он скорее индивидуален. Зависит от ваших ценностей.
А что конкретно важно для автоматизатора? Тут у меня есть ответ! Если смотреть на вопрос глобально ― то, что важно для бизнеса (потому что все усилия автоматизации в конечном итоге рассчитаны на процветание бизнеса) ― то ответ не хитрый: то, что приносит максимальную прибыль при минимальных затратах + то, что защищает от крупных потерь. А поскольку тестирование главным образом занимается защитой от рисков, то мы сосредоточимся на том, как избежать потерь, потратив минимум ресурсов.
Если перенестись снова в мир метафор, то нам надо сделать так, чтобы жуков, прорывающихся в продакшн было как можно меньше и сами жуки не должны вырастать в гигантов с планеты Клендату.
Итак, глобально список приоритетов автоматизатора будет такой:
Shift Left
Quality gates
Пирамида тестирования
Достаточно помнить об этих трех китах и воплощать их в жизнь (даже маленькими шажочками) и автоматизация поможет достичь вышеупомянутой цели ― избежать максимум потерь, потратив минимум ресурсов.
Надо понимать, что иногда появляются срочные вопросы, которые требуют решения. Например, центробанк ввел новые правила и все компании, имеющие дело с деньгами пользователей должны подчиниться. В таком случае, конечно, стоит сперва потушить пожар, а уже после вернуться к работе над приоритетными направлениями.
Хорошо иллюстрирует эту идею матрица Эйзенхауэра.
Такие задачи как новые регуляции от центробанка ― очень срочные и важные.
Но доля таких задач-пожаров должна быть минимальна ― не более 10-20%. Многим знакома такая ситуация, когда они словно живут в режиме непрерывного тушения пожаров при этом не чувствуют значительного движения вперед. Есть много метафор такого явления. Это и дырявая лодка и люди в ней усерднее и усерднее вычерпывающие воду вместо того чтобы залатать дыры. Естественно такая лодка далеко не уплывет не смотря на все усилия команды. Другая метафора ― дровосек, который пилит дерево затупившейся пилой. Ему нужно спилить много деревьев и он пилит быстрее и быстрее и старается изо всех сил, но работа идет медленно и тяжело. Дело пошло бы быстрее, заточи он свою пилу. Также и в жизни и в бизнесе. Вместо пустых усилий, следует вкладываться больше в то, что важно, но не срочно. Нарочно планировать такие работы и приоритезировать в списке дел. Иначе в режиме тушения пожаров время никогда не найдется само.
Доля задач из второго квадранта должна быть высокой ― 80-90%.
Всё, что не важно, но срочно стоит делегировать. Другим людям или механизмам ― т.е автоматизировать. Доля таких задач может быть сколь угодно высока, но они не идут в общий зачет, т.е не требуют активного внимания.
Задачи 4го квадранта не срочные и не важные, таких задач в идеале вовсе не должно быть, старайтесь держать их процент как можно ближе к 0.
Бывает сложно понять что действительно важно, на чем сосредоточиться. Это действительно необходимо определить как следует чтобы не расходовать зря усилия. Часто компании выбирают что-то модное и популярное вместо того чтобы сделать исследование и прислушаться к профессионалам. Нашумевшие подходы, работающие для других компаний, могут не сработать в ваших конкретных условиях: культура компании, особенности рынка, структура иерархии и т.д.
Три пункта, что я упоминала выше ― универсальные и проверенные временем. Реализация же будет отличатся от компании к компании ― ведь все мы разные. Универсален может быть подход, но не реализация. Реализация должна отличаться чтобы подход сработал.
Ежедневная синхронизация
При упоминании этого словосочетания на ум сразу приходит синхронное плавание. По необъяснимой для меня причине во время олимпийских игр мне непременно хочется посмотреть выступление в этой области.
Синхронизация при разработке ПО нужна по нескольким причинам. Во-первых, без выравнивания невозможно спланировать работы. А без этого бизнес практически парализован. Если действовать наобум, то неизбежно где-то будет дублирование работы, а где-то важные вещи не будут сделаны. Синхронизация может быть в формате встречи (но тогда обязательно отправлять участникам договоренности в письменном виде), может быть в общем чате или на доске ― важно чтобы объем работ, приоритеты и сроки были прозрачны и легко доступны для всех заинтересованных лиц. Членам команды это дает ясность что делать, а менеджерам ощущение, что всё под контролем и движется в правильном направлении.
Есть и другая важная причина ― мы социальные животные. Нам действительно важно устанавливать и поддерживать значимые связи с другими людьми. Это наша базовая потребность. Наглядно это объясняется в теории самодерминации, которая называет 3 базовые моральные потребности, удовлетворение которых рождает мотивацию на свершения и радость от работы. Я ещё вернусь к ней чуть позднее. Регулярно встречаясь с членами команды, мы чувствуем, что мы не одни, мы часть группы, делающей общее дело ― и это очень важно для мотивации.
Обратная связь и метрики
Обратная связь нужна и важна чтобы понимать в правильную ли сторону мы движемся. На самом деле можно успешно развивать что-то с минимумом знаний и умений если сделать ставку на обратную связь. Любой идиот понимает принцип “Дают ― бери, а бьют ― беги”. Даже инфузория-туфелька своими ресничками гребёт подальше от соли и поближе к сахарку.
А чтобы как-то формализовать обратную связь и сравнивать ее сквозь время нужны метрики.
Обратная связь может быть:
технической,
производственной,
обратная связь от команды и менеджеров,
анализ обращений в службу поддержки.
Каждый из видов имеет свои особенности и источник. Техническая обратная связь включает в себя анализ технический параметров, сгенерированных системой. Для автоматизатора примерами такой обратной связи могут быть: лог падений, время выполнения автотестов, количество флаки-тестов и ложно-положительных срабатываний и т.д. Такая обратная связь помогает улучшить качество автотестов.
Далее идет производственная обратная связь. Она помогает корректировать процессы. Её можно получить на ретроспективе, подсчитав покрытие автотестами, оценив качество отчетов.
Обратная связь от команды и менеджеров очень помогает автоматизатору работать с приоритетами. Сюда могут входить информация о сроках, качестве релизов, возникающих трудностях при работе людей с конкретным автоматизатором и т.д.
Важным каналом обратной связи, которым многие пренебрегают, является анализ обращений в службу поддержки. Пользователи часто чётко дают знать, что их не устраивает. Если уж они не поленились позвонить или написать, значит эта боль достаточно сильна для них. Анализ помогает увидеть паттерны и взять в работу самые раздражающие клиентов области продукта. Часто оказывается, что мы как специалисты по качеству можем усилить контроль над конкретной областью продукта и повысить удовлетворение клиентов.
Как вы убедились, в области автоматизации можно собирать обратную связь из множества источников, применяя много различных метрик, но как приоритезировать, с чего начать?
Тут я сделаю небольшое отступление и расскажу о принципе Парето. Также он известен как принцип 80/20 или “закон немногого действительно важного”. Основная идея его в том, что мир неоднороден и зависимость причин и следствий нелинейна. Т.е примерно 20% усилий приносит 80% результата, остальные 80% усилий ― лишь 20% результата. На практике это значит, что не все источники обратной связи и метрики одинаково важны.
Я постаралась выделить такие технические метрики автоматизации, которые действительно стоит собирать, т.к они оказывают наибольший эффект на результат. Как я выбирала: во-первых, брала метрики с высоким ROI, т.е небольшое усилие дает большой результат. Эти метрики просто собрать и интерпретировать, а также понятно как улучшать. А также эти метрики непосредственно влияют на время релиза и качество продукта. Для наглядности и трекинга надо сразу подумать как их визуализировать. Для этого подойдут дашборды, графики, чарты, таблицы ― это должно быть отслеживаемо и доступно всем заинтересованным сторонам.
Процент автоматизации (Automation Coverage)
Она показывает процент тест-кейсов, которые автоматизированы. Эта метрика непосредственно влияет на скорость релизов, ведь чем больше этот процент, тем быстрее пройдет регрессионное тестирование. Конечно, не всё следует автоматизировать бездумно ради достижения высокого процента по этой метрике. Как я писала выше, кандидаты на автоматизацию это повторяющиеся действия и действия, которые сложно выполнить человеку.
Flaky Tests (нестабильные тесты)
Это такие тесты, которые иногда падают, иногда проходят. Происходит это из-за недоработок в тесте, чрезмерной их чувствительности к среде, где они исполняются, недостаточной отладке новых тестов, таймаутов и рандомных сбоев . Такие тесты подрывают доверие к автоматизации. А без доверия автоматизацию сложно будет внедрять в процессы, люди будут избегать внедрения или игнорировать результаты, будет трудно получить время и человеческие ресурсы на разработку, внедрение и поддержку скриптов. Инженерам по качеству тоже сложно давать оценку качеству кода, опираясь на результаты таких тестов. Найти такие тесты можно проанализировав несколько запусков автотестов в одинаковых условиях. Важно писать автотесты так чтобы падения по причине нестабильности среды можно было достаточно легко вычислить. В тест-менеджмент системах обычно применяется цветокодировка. Например, зеленые тесты ― прошли, красные ― ошибка в продукте, желтые ― проблемы со средой. Чтобы снизить долю таких тестов следует применять стратегии стабилизации: механизм ретраев, умные ожидания внутри тестов, внедрение проверок состояния среды внутрь теста (например, проверка наличия нужных кафка-топиков перед тем как отправлять туда сообщение ― так тест быстрее покажет результат и сэкономит время выполнения). Более глобально такие тесты лечатся стабилизацией среды, однако для этого нужны ресурсы девопс-инженеров. Чтобы добится выделения этих ресурсов нужно собрать подтверждения того, что проблемы действительно вызваны средой, а не плохо написанными тестами. Поэтому выше я написала, что важно писать автотесты так, чтобы причины падения было максимально просто идентифицировать.
False Positives (Ложные срабатывания)
Это падения тестов, не связанные с реальными багами. Такое происходит когда тесты не успели адаптировать под изменившийся код, а также когда тест изначально плохо написан. Такие падения также здорово подрывают доверие к автоматизации, а также тратят время членов команды на разбор причин падения. Лечатся они исправлением самих тестов, а также тестовых данных. Такие тесты следует как можно раньше исключать из массовых прогонов чтобы не дезориентировать участников процесса и не отнимать их время.
Среднее время выполнения автотестов (Test Execution Time)
Считаю эту метрику также крайне важной. Чем быстрее мы получаем результат, тем скорее можем принять решение. Особенно критично это становится на этапе внедрения кволити гейтс. Никто из разработчиков не хочет ждать по полчаса при ПР-валидации в ожидании когда тесты пробегут. Чем быстрее прогон автотестов, тем быстрее релиз. Может показаться, что разница в пару минут в прогоне автотестов ничего не решит, однако подумайте о том, например, что мы внедрили кволити гейт на каждый коммит и разработчик вынужден ждать прогон тестов по нескольку раз в день. А теперь о том, что разработчиков несколько. Возьмем команду с 3 разработчиками. Каждый день они делают, например, по 5 комитов. В стандартном спринте 10 рабочих дней. Допустим код пишется 7 рабочих дней. 5*7=35 ― столько раз в среднем каждый разработчик запустит скрипты за спринт. В году в среднем 24 спринта, допустим один спринт он был в отпуске и счастливо забывал о прогонах автотестов ― 23 спринта. Это 23*35 = 805 запусков автотестов в год. Если мы снизим время каждого прогона всего на 2 минуты, это даст нам 2*805 = 1610 минут освободившегося времени (примерно 27 часов, а это около 3,5 рабочих дней) А 3 разработчика ― среднее для скрам-команды? Это уже 10 рабочих часов, которые может сэкономить команда в год всего лишь сократив время прогона на 2 минуты. А представьте, что в компании может быть много таких скрам-команд: 10, 20, 100 и т.д.
Есть очень много метрик автоматизации тестирования, но не все они одинаково важны. Вышеперечисленные 4 я нашла самыми показательными и стоящими отслеживания и внимания.
Фокус на энергии команды
Этот пункт последний в списке, но не по значимости. Почему же стоит уделить ему время и внимание? Часто я слышу аргументы в пользу того чтобы этого не делать или не ожидать этого от работодателя. Самым частым звучит что-то вроде: “Все здесь взрослые люди, знали на что шли”. На самом деле есть масса исследований на тему влияния энергии людей на результаты, которые они производят. Дело в том, что люди с низким уровнем энергии в одном шаге от выгорания.
В нормальном состоянии люди имеют высокий уровень энергии, им хочется свершать, творить, им интересно пробовать новое, им вкусно жить. А другие люди вокруг заряжаются от них этой самой энергией. Невозможно придумывать креативные решения, быть гибким и адаптивным когда у тебя нет сил жить. Как результат усталые, выгоревшие и несчастные работники не креативныы, выкладываются вполсилы и вскоре уходят. А нанять человека на его место стоит около 6 его месячных окладов. А еще через год с ним будет то же самое. И так по кругу. Это крайне неэффективно. Особенно важно уделить внимание энергии команды когда мы говорим о высококвалифицированных специалистах. Их сложнее искать, тяжелее привлечь и требует больше усилий удержать.
Дальше я расскажу причем здесь теория потребностей.
Теория самодетерминации (Self-Determination Theory, SDT), разработанная Эдвардом Деси и Ричардом Райаном. Эта теория, подтверждённая многочисленными эмпирическими исследованиями, фокусируется на внутренних источниках мотивации и выделяет три базовые психологические потребности:
Компетентность: стремление ощущать эффективность и мастерство в своих действиях (я расту, я умею, у меня получается).
Автономия: потребность в самостоятельности и ощущении контроля над своими решениями (я выбираю, у меня есть влияние, свобода).
Связь с другими: желание устанавливать и поддерживать значимые отношения с окружающими (я не один, я важен для других).
На данный момент это одна из самых подтвержденных, современных и влиятельных теории мотивации в мире. Если все три потребности удовлетворяются, то человек мотивирован изнутри, продуктивен, счастлив, развивается, проявляет креативность, инициативу и ответственность. Если нет ― выгорание, контроль, пассивность, цинизм, саботаж, уход.
Известные компании такие как Google, Atlassian, Spotify, Netflix и другие используют теорию самодетерминации для мотивации сотрудников.
На практике каждая из потребностей реализуется рядом процедур. Например, как удовлетворить потребность сотрудника в автономии? Позволить им контролировать свою работу, иметь свободу выбора и возможность принимать решения. Т.е никакого микроменеджмента, это убивает мотивацию напрочь. А помогает ее поддержать следующее:
Позвольте сотрудникам самостоятельно принимать решения в рамках своей зоны ответственности: выбирать инструменты, подходы и способы решения задач.
Позволить сотрудникам начинать и заканчивать работу в удобное для них время. Автономия в графике напрямую влияет на их мотивацию. Знаю случаи, когда люди увольнялись, потому что не успевали забирать детей из садика, а начальник не шел на уступки.
Вовлекайте сотрудников в обсуждения задач на планировании и ретроспективах. Спрашивайте какие у них идеи по улучшению процесса.
Не микроменеджите. Лучше установите понятные цели и критерии успеха и не вмешивайтесь в процесс работы без необходимости.
Дальше идет компетентность. Это потребность чувствовать себя способным и эффективным в выполнении задач, развивать свои профессиональные навыки. Критика и упреки точно не помогут закрыть эту потребность, а следующие действия могут помочь:
Доступ к обучению и развитию. Дайте сотрудникам возможность учиться новым технологиям и инструментам, а также профессионально расти.
Дайте сотрудникам задачи чуть выше их уровня ― это создает зону для оптимального вызова, которая держит интерес и мотивацию на высоком уровне. Хорошо, если получается выполнять 70% вызовов.
Регулярно предоставляйте конструктивную обратную связь, подчеркивая успехи и указывая пути для улучшения.
Отдельно я вынесла инструменты и методы для повышения компетентности:
Корпоративные учебные платформы: Coursera, Udemy, Pluralsight.
Ретроспективы: возможность делиться своим опытом и анализировать успехи.
1:1 встречи с менеджером: персонализированный план развития для каждого сотрудника.
И завершает обзор потребностей принадлежность или потребность в значимых связях с другими. Это потребность чувствовать принадлежность к сообществу, быть частью коллектива и иметь поддержку от коллег и руководства. Социальные взаимодействия сильно на нас влияют вне зависимости от того готовы мы себе в этом признаться или нет. Я гораздо чаще видела как человек расстраивался из-за грубого слова и терял мотивацию работать на остаток дня или дольше, чем от тот же эффект из-за технических проблем. Примеры действий, которые помогут укрепить чувство принадлежности я собрала ниже:
Единая цель для команды. Это может быть четкая цель спринта в agile-практиках, или north star метрика, или миссия. Все в команде должны иметь простое и понятное направление, куда все движутся. Непрозрачная коммуникация, неясные цели, неоформленная миссия могут значительно понизить мотивацию.
Создавайте условия для неформального общения и чувства принадлежности. Тимбилдинги, синхронизации, дружелюбная атмосфера и неформальные чаты помогают людям чувствовать себя частью команды, а не набором отдельных исполнителей.
Регулярно признавайте вклад сотрудников. Публичная благодарность за конкретные достижения усиливает
Инструменты и методы для создания связи:
Slack и Teams для создания общих каналов общения.
Ретроспективы для обсуждения общего прогресса и обмена мнениями.
1:1 встречи с сотрудниками, чтобы узнать их мнение и проблемы.
Мероприятия и тимбилдинги: оффлайн и онлайн встречи для личного общения.
Итак, мы разобрали все 5 пунктов эффективной разработки ПО. Я верю, что эффективность рождается из простоты. Слишком сложные системы никогда не бывают эффективны. Чем проще, примитивнее и ближе к законам природы что-то, тем больше у него шансов на долговременный успех.
Где искать автоматизаторов тестирования
Переходим к животрепещущему вопросу: где же брать автоматизаторов эффективно? Т.е потратив немного, а получив много. Я выделила 4 удачные области получения специалистов и распределила их от самой эффективной к менее, вот они:
Внутренние ресурсы (внутрнений рост)
Реферальная программа
Прямой поиск на рынке (например, через Linkedin)
Хакатоны и участие в айти-сообществах
Первый пункт может вызывать сомнение и недоумение, но позвольте объяснить. Тут имеются в виду 2 сценария: взращивание специалиста с нуля и переквалификация действующих работников в нужную нам специальность. В первом случае организуются курсы/стажировка. С одной стороны кажется, что здесь есть затраты компании в виде денег, времени и сил, а прибыль не гарантирована. Однако не гарантирована она и в случае прямого найма с рынка. Однако внутреннее обучение убивает 2х, а то и 3х зайцев. Для обучения молодых специалистов можно и нужно привлекать имеющихся ― так мы закрываем и у менторов и у студентов потребность в компетентности. Менторы передают свои знания и опыт, это дает им чувство значимости, компетентности. А ученики овладевают новой профессией, наращивают экспертизу и тоже чувствуют повышение значимости. Также растут и крепнут связи между студентами, а также между студентами и менторами ― закрываем потребность в значимых связях. Каждый участник процесса ощущает себя частью чего-то большего, создания будущего индустрии. В какой-то мере закрывается и потребность в автономности, ведь каждый ментор привносит в процесс что-то свое, а ученик имеет выбор продолжать ли карьеру в компании после окончания обучения. В итоге мы укрепляем внутреннюю мотивацию действующих сотрудников, повышаем их лояльность, а также сразу строим значимые отношения с новыми сотрудниками ― ведь компания дала им новую профессию, им хочется работать с менторами, которые их обучали, равняться на них. Многие компании-гиганты уже раскусили выгоды этого способа и сосредотачиваются на нем. Также обучение сотрудников делает вклад в индустрию, в тек-среде становится больше классных специалистов. Система мастер-подмастерье одна из самых древних систем обучения и она до сих пор блестяще делает свое дело.
Любопытно, что далеко не все понимают выгоды такого подхода. Я лично видела ситуации когда компания активно растет и естественно нуждается в свежих кадрах, но упорно продолжает искать их на рынке даже осознав, что их просто нет в таком количестве и квалификации там. И что же они делают ― переходят сразу к последнему пункту, т.е организуют конференции. Очевидно, что это влетает в копеечку, а конверсия оттуда очень низкая. Я не зря поместила этот вариант в конец списка.
Следующий пункт ― реферальная программа. Если у вас уже есть сильные специалисты, то наверняка они знают несколько экспертов из своей сферы или близко к ней. А принцип социального доказательства очень силен: сотрудник редко когда будет рекомендовать кого-то откровенно слабенького ― это репутационный риск, а кандидат будет заранее расположен к компании, ведь его пригласил хороший знакомый или друг, значит место стоящее. И всегда приятнее иметь в кругу общения “своих” людей. Премия за успешный реферал гораздо меньше, чем вы приобретаете выгоды. Такие люди заранее более лояльны к компании и мотивированы проявить себя (чтобы не посрамить товарища, которых их пригласил).
Если же специалист нужен срочно и нет времени на более эффективные методы выше, то остается поискать его на рынке. И тут я не рекомендую скупиться. Пусть даже это будет велком-бонус или какие-то еще бенефиты. Вы платите за срочность при поиске и за качественного кандидата. По-настоящему стоящие ребята редко когда пойдут работать за копейки.
Я поместила вариант с хантингом на мероприятиях в самый низ потому что конверсия из него невысокая, а затраты неочевидные. Требуется схема хантинга. Так тоже можно найти прекрасных специалистов, но либо нужно снаряжать действующих сотрудников на такие мероприятия как конференции, митапы и хакатоны, где они должны распознать звезду и установить контакт, либо проводить такие ивенты самим и тоже засылать своих людей в зал. Перспективные ребята вероятнее всего найдутся среди спикеров и активных участников. Однако недостаточно просто их найти, надо суметь заинтересовать их. А это многие упускают.
Заключение
Эти идеи созревали годами — из опыта, ошибок, экспериментов и пары сотен чашек моккачино. Формула простая, но простое не значит лёгкое. Автоматизируйте то, что повторяется. Расставьте сети раньше по течению. Заботьтесь об энергии команды.
И помните: эффективность — это вообще не про то, чтобы работать больше. Прикол в том, чтобы сделать так, чтобы система работала за вас.
Не масштабируйте усилия. Масштабируйте системы.
Остальное сложный процент сделает сам.
Иначе можно так и ходить с бреднем по реке по колено в мусоре.
Да пребудет с вами сила.
