Менять и меняться — это нормально.

Этой весной я получила один из самых необычных, интересных и полезных опытов моей жизни — стала менторкой двух тестировщиц в рамках программы Mentor in Tech.

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

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

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

Мы часто боимся изменений извне: привычные процессы и обстановка помогают мозгу меньше грузиться простыми задачами и выполнять их «на автомате». Лично у меня к этому добавляется ощущение страха неизвестности: нет гарантий, что перемены принесут нечто лучшее, а здесь и сейчас есть стабильность и четкое понимание, что хорошо, а что не очень.
Тем не менее, самый существенный рост происходил в моей жизни ровно тогда, когда я больше всего боялась что-то изменить: переход в физмат-школу, поступление в другой город и переезд в третий город на ПМЖ. А как страшно было впервые подавать заявку в формочку для спикеров конференции…

Ещё бывают перемены, которые приходят изнутри. Например, ты всю жизнь думаешь, что хочешь развиваться в одном направлении, а потом пробуешь другое и совершенно безвозвратно влюбляешься. И это тоже нормально!
Мир вокруг нас стремительно меняется, мы сами узнаем новое и понимаем, что что-то больше, а что-то меньше подходит нам на данном этапе. Это не предательство своих идеалов и не метания; это тоже часть роста, которую так или иначе необходимо прожить и понять.

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

QA: shift left? Shift right?

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

На тот момент я была единственной тестировщицей в проекте, в автоматизацию только робко заходила одной ножкой, поэтому моей мечтой была, пожалуй, фея-крёстная, которая прилетела бы, взамхнула волшебной палочкой и заявила: "Да, Настя, иногда написать работающие и находящие баги тесты без использования POM — приемлемая мера, если проект закончится через пару месяцев, и никому, кроме тебя, эти тесты не будут нужны".
А потом бы поправила очки на носу и добавила бы: "Но вообще, знаешь, есть такой подход, когда QA подключается к работе над тестами ещё на этапе, когда готовы лишь макеты. Ты можешь написать "каркасы" тестов без локаторов, подключить команду к настройке CI и потом быстро править тесты, чтобы они выполняли свою работу и находили регрессионные баги".

Фей-крёстных не существует, конечно, но есть кое-кто покруче — эксперты в области тестирования, которые готовы делиться своим опытом, отвечать на вопросы и на практике показывать, как делать то, что в теории звучит сложно и неподъемно.

17 мая стартует новый сезон Podlodka QA Crew – онлайн-конференции для QA-инженеров, которая, как мне кажется, за прошедшие 3 сезона успела завоевать столько внимания благодаря клёвым докладам и формату, заточенному под онлайн, что уже не нуждается в отдельном представлении.

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

На первой неделе “Shift-left: QA до этапа тестирования” будут разобраны техники, процессы и инструменты, которые еще до начала тестирования позволяют вовлечь всю команду в процесс QA и добиться максимального качества.

На второй неделе “Shift-right: QA после этапа тестирования” мы посмотрим на QA под другим углом. После выпуска релиза борьба за качество не прекращается, поэтому мы обсудим, что можно и нужно делать, чтобы выйти из нее победителями.

Помимо докладов в программе множество нескучных форматов: рулетки кейсов, батлы, лайв-кодинги и не только.

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

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

Оффбоардинг

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

Однако, делая шаг к чему-то новому, очень важно не забывать о том, что ты оставишь после себя там, откуда уходишь.
Многим знаком термин онбоардинг, а вот как назвать обратный процесс — оффбоардинг? Пусть будет так :)
В рамках этого текста я буду называть оффбоардингом последние 2-3 недели в компании, из которой мы уходим: с момента информирования нашего руководителя и до последнего дня.

Что я считаю для себя важным сделать, покидая компанию?

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

2. По возможности описать и сохранить инфу о фичах/проектах, с которыми работала.
Это будет полезно не только тестировщикам, но и другим членам команды. Дело в том, что аккумулирование знаний по фичам в одном человеке происходит чаще, чем нам бы того хотелось. Это нормальный процесс: невозможно быть в курсе всего, и распределение ответственности внутри продукта помогает углубиться в свои задачи, не беспокоясь за покрытие остальных функций. Тем не менее, надо отдавать себе полный отчет в том, что твои знания могут казаться супер-очевидными тебе, но их отсутствие сильно усложнит работу другому человеку.
Даже если в команде ситуация идеальная, и все знают обо всём поровну, описание фич/проектов, с которыми мы работали, упростит онбоардинг нового специалиста.

3. Если работа требовала каких-то особых знаний, либо есть неочевидные процессы, к которым, тем не менее, многие привыкли — задокументировать их.
По той же причине, что и прошлый пункт, но необходимость здесь более очевидна. Например, когда я уходила с руководящей позиции, мне было максимально важно описать процесс 1-1, собеседований и ревью — не потому, что было желание, чтобы все делали так же на 100%, а потому что это были знания, подкрепленные опытом, и я понимала, что новому сотруднику на этой позиции такие знания могут упросить интеграцию в коллектив и добавить понимания, как «было раньше».

4. Починить то, что не работает.
Например, нестабильные автотесты, неактуальные репорты или задачу, которая висит в in Progress уже 2 недели. Это довольно очевидный пункт, но я даже словами не могу описать, сколько радости приносит напоследок добить-таки проблему, которая довольно долго стреляла и расстраивала.
Да, не круто, конечно, делать такие штуки в последний момент. Но это определенно лучше, чем проявить безразличие и не делать вообще.

5. Проинформировать о том, что не удалось починить.
Например, про нестабильные автотесты :D Мне кажется, это просто хороший тон, и тут даже не стоит вдаваться в подробности.

6. Записать итоги работы.
Для себя на будущее. Провести небольшую ретроспективу. Что удалось сделать? Что хотелось, но не удалось? Что было круто? Что улучшила бы? Всё это желательно хотя бы тезисно зафиксировать.
Во-первых, это поможет в будущем: когда яркие воспоминания станут тускнеть, будет возможность вспомнить, почему ты работала в этой компании (и каковы были причины ухода), — земля круглая, а в мире IT так вообще велики шансы поработать в одном месте более раза.
Во-вторых, когда-то придется обновлять резюме, и лучше записать свои обязанности и достижения, пока они свежи в памяти.
В-третьих, анализ сделанного — неотъемлемая часть осознанного развития, поэтому он не будет лишним.

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

Спасибо, Команда 💙

Про тестовую отчетность

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

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

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

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

Как же тогда быть?
Читать, искать и разбираться. Ведь, как мы все помним, тестировние — это не про ручные и автоматизировнные сценарии; это про мышление, рассуждения и умение собрать из разных крупиц информации то, что будет работать именно для вас.

По этому поводу — небольшая подборка того, что можно почитать на тему.

🔹 https://www.instagram.com/p/COP6BSKnR0U — блог Натальи, Senior QA в DataArt. Наталья пишет о собеседованиях, карьере и тестировании в целом, — а по ссылке вы найдете пост про то, что можно включить в отчет о тестировании (даже если кажется, что вообще нечего!).

🔹 https://habr.com/ru/company/performance_lab/blog/207512 — довольно старая, но вполне годная статья про написание отчета о тестировании с очень важным вопросом: для кого мы его формируем?

🔹 https://sergeygavaga.gitbooks.io/kurs-lektsii-testirovanie-programnogo-obespecheni/content/lektsiya-5-ch4.html — лекция (в задокументированном виде) про тестовую отчетность. Мне нравится, что там есть упоминание Definition of done.

Задачу нормально поставьте.

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

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

Тут есть несколько моментов, о которых надо помнить.

Первый:
Каждый раз, когда вы хотите, что бы вам принесли идеально проработанную задачу - вы просто перекладываете ответственность.
Вы хотите упростить себе жизнь, не ломая голову над тем, что от вас хотят, избежать всех этих уточняющих вопросов и, заодно, минимизировать риски.
Что бы если к вам придут и спросят "почему это работает вот так?" можно было просто сказать "я сделал как в ТЗ было написано".
В желании упростить себе жизнь нет ничего плохого, но надо понимать, что в данном случае вы делаете это в ущерб команде и продукту.
Потому что ответственность, риски и проблемы вы снимаете с себя, но перекидываете на кого-то другого.

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

Третий:
Способность (и готовность) работать в условиях неявных требований - это конкурентное преимущество.
Даже при хорошо отлаженных процессах требования всегда будут неполными.
Задачи без описания и definition of done "Работает хорошо" будут периодически появляться.
Вопрос только в том, какую цепочку проработки они будут проходить прежде, чем окажутся в продакшене.
Переоткрывая задачу в формате "требования опишите нормально" вы просто докидываете ещё одно звено в эту цепочку и увеличиваете time to market.
Инженеры, способные получить слабо формализованную задачу, взять за неё ответственность и выдать результат ожидаемого уровня качества - на вес золота.
Они стоят гораздо дороже и ценятся компаниями гораздо выше, чем инженеры, просто транслирующие ТЗ в код.

Помните, что разные подходы работают для разных команд.

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

Классический подход "вот вам супер-подробное ТЗ, превратите это в код" - обратная крайность.
Это стандартные проектные рельсы, которые легко масштабировать и можно получать прогнозируемый результат.
Минус в том, что результат - средненький, скорость - тоже.
Создать что-то действительно классное с таким подходом довольно сложно.

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

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

Поэтому, каждый раз, когда слышите истории успеха и сладкие речи про идеально проработанные ТЗ и вот это всё - задавайтесь вопросом, а действительно ли это плюс?

Бесконечно можно смотреть на 3 вещи: как горит огонь, как течет вода, и как я в очередной раз рассказываю о том, почему тестировщик — больше, чем просто "кликать кнопки", даже на начальном уровне.

Статья родилась на основе моих соображений после прочтения поста в Т—Ж о входе в IT.

https://telegra.ph/Testirovshchik-prosto-klikaet-07-22

Как ставить задачи джунам?

Самый быстрый ответ на этот вопрос: максимально детально. Но давайте копнём глубже.

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

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

- Покажите проблему, а не только решение. Так будет «тренироваться нейронка», которая в дальнейшем для подобных задач будет находить подобные же решения.
- Поясните решение и ответьте на вопрос «почему?». Не «добавь индекс в базу данных», а «добавь индекс, иначе будет работать медленно. Можешь локально попробовать сделать то-то – увидишь, что всё тормозит. Кстати, explain analyze до/после поможет понять детали»
- Расширьте его кругозор, делитесь опытом (и не только своим). Вместо коммента на код-ревью «добавь контекста и переименуй переменную из users в `availableUsers`» можно написать тоже самое + добавить «Кстати, про именование можешь посмотреть классный доклад или почитать мини-книжку Naming Things!».
- Оставьте нерешенную проблему. Легко привыкнуть к тому, что в задаче приняты все решения и нужно просто «поработать руками». Но для роста нужно обратное и хорошо бы сразу тренировать «мышцу» принятия решений, поэтому оставьте место, где этим можно заняться

А есть ещё мнения по этому поводу?

Мы договорились с Евгением Антоновым, автором канала Тимлид Очевидность, написать посты на эту тему. Его вариант я ещё не видел, но знаю, что он будет тут – го читать.

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

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

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

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

Из других новостей: я воооот на столечко 🤏🏼 близка к тому, чтобы стать преподавательницей ещё одного курса. Буду рассказывать, что и как, а пока, чтобы не скучать, поделюсь парой ссылок, которые в последнее время часто открыты в моем браузере — раз уж мы заговорили про обучение 🙂

📖 https://devqa.io/ — типа Хабра, но англоязычного и суховатого :) В принципе, там довольно много интересных статей, в том числе с примерами кода а-ля "стартуй свой первый проект". Поковыряться на досуге — самое то.
📖 https://codernet.ru/books/ — онлайн-портал с книгами, видео и статьями. Правда, раздел Books вызывает вопросы: я вполне допускаю, что это пиратство (хотя, конечно, соблазн скачать все и сразу велик). В описании заявлено, что всё это для программиста, но не верьте: QA тоже найдет там много крутой информации.
📖 https://www.freecodecamp.org/ — бесплатный англоязычный портал с курсами на разных ЯП. К слову, там есть раздел QA, в который очень приятно заглянуть: там есть и тренировочные проекты, на которые надо писать автотесты, и курсы, и сертификация — можно пройти курсы и получить красивое подтверждение (я не уверена, что сейчас можно кого-то этим впечатлить, но некоторых такие вещи мотивируют — приятно же!).
Также там есть раздел с подготовкой к интервью — задачки, челленджи, вот это всё.

На этой ноте желаю всем продуктивной недели 💪🏼

Ну всё, теперь окончательно могу поделиться обновленями и радостью — я теперь часть программного комитета ближайшего, пятого, сезона конференции Podlodka QA Crew!

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

Это не первый мой опыт бытия частью ПК, однако прошлая конференция — SECR 2019, — была больше научной, чем IT-шной. Сейчас же есть отличный шанс сделать свой вклад в контент, который смотрю я, мои друзья, коллеги, приятели. Короче, догфудинг как он есть 🙂

Вопросы к будущей команде

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

https://telegra.ph/Voprosy-k-budushchej-komande-cheklist-08-04

Сложно — это хорошо?

Кратко: однозначно да!
Длинно:
https://telegra.ph/Slozhno--ehto-horosho-08-17

Алгоритмы написания автотестов

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

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

Написала отдельно про два случая:
🔹 API-тесты
🔹 GUI-тесты
— для удобства чтения, обсуждения и навигации.

Буду рада узнать от тех, кто регулярно работает с автотестами: что бы вы добавили, что бы убрали? Какими лучшими практиками вы пользуетесь?

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

Итак, мы готовы анонсировать новый сезон Podlodka QA Crew — погружение начнется 13 сентября!

Во время первой недели обсудим интеграционное тестирование:
- Будем учиться тестировать интеграции внутренних и внешних сервисов;
- Узнаем лайфхаки реализации интеграционного тестирования необычных систем;
- Разберемся, как эффективно тестировать микросервисы.

Вторую неделю посвятим тестированию с ограниченными ресурсами:
- Узнаем, как бороться с легаси;
- Поймём, как наладить процессы QA в команде;
- Будем учиться строить процесс QA, в который вовлечена вся команда.

Это тот случай, когда я действительно горужсь тем, что получилось: огненная программа, классные опытные спикеры, много активностей и холиварные — в хорошем смысле — обсуждения :)

Подробности и билеты уже на сайте!
До конца недели действует скидка ⚡️

Внезапно спикаю на GDG Kaliningrad 25-26 сентября. Подключайтесь послушать, если есть возможность!

Между тем, SQA Days выставили в открытый доступ плейлист с записями 28-го сезона конференции ☺️

И я там была: рассказывала про систему автоматизации тестирования в VK и про то, как красиво (и не очень, you know, it ain't much, but it's honest work...) стабилизировать непослушные тесты для GUI.
На самой конференции доклад встретили супер позитивно. Надеюсь, и в записи он кому-то окажется полезен и интересен!

Послушать можно тут: https://youtu.be/at0GZJXZ5bc

Офигенная заметка о декомпозиции больших метрик и о неочевидных «бытовых» факторах, влияющих на общий результат.

Time-to метрики

Все знают про метрику time-to-market, которая по-сути отражает скорость разработки. Чем медленнее мы будем выкатывать гипотезы – тем с большей вероятностью нас обгонят конкуренты или мы просто потратим все деньги на команду и не найдём product-market fit. Но почему-то редко анализируются другие time-to метрики, а чем меньше нужно времени (и мозговых ресурсов) на какое-то действие, тем больше времени остаётся для других дел.

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

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

На какое ещё время можно обращать внимание?

– Time-to-data – время на доступ к информации. Как сложно найти нужную информацию? Например, почему сделали изменение в коде? Где взять логин и пароль в админку аналитического сервиса? Какие были договорённости на прошлом планировании? Где и как мы можем хранить эту информацию? Как сделать так, чтобы её можно было легко и быстро найти?
– Time-to-action – время для действия. Сколько времени нужно, чтобы начать что-то делать? Например, к вам на проект пришел новый разработчик – сколько проходит времени до его первого коммита? Как можно это ускорить? Завернуть всё в докер? Предоставить компьютер с предустановленным и настроенным проектом? Потратить час на поверхностное объяснение проекта или скинуть ссылку на подробнейшую документацию на 500 страниц?
– Time-to-decision – время для принятия решения. Сколько времени уходит на принятие решения в команде? Если вы каждый свой шаг согласовываете, то дела у вас наверняка идут очень медленно, а большой процент начатых активностей просто глохнет. Может можно что-то просто взять и сделать без апрува сверху или от всей команды? Или заранее всем вместе решить, кто какие решения принимает и в каких вопросах хочет принимать участие, например с помощью delegation poker?
– Time-to-interaction – время на взаимодействие с другими людьми. Сколько времени ждать code-review? А сколько времени уйдёт у другого разработчика на этот code-review? На что из этого вы можете повлиять? Как это время уменьшить?
– Time-to-small-things - время на разные мелочи. Наверняка, в день вы делаете сотни и тысячи мелких действий и небольшое ускорение в них может освободить вам голову и время. Как быстро вы печатаете? Как быстро навигируетесь в проекте/коде? Используете шорткаты? А time-to-coffee у вас какой?

В общем, иногда достаточно просто начать обращать внимание на то, куда уходит время – идеи о том, как ускориться придут сами. Так же полезно думать об этом, когда вы создаёте продукты и процессы для других – как вы можете ускорить и упростить для них использование вашего процесса/продукта?

Use case и тестирование требований

Хорошая статья про тестирование требований и разработку use case. Очень люблю это метод, мне он позволяет сфокусироваться на разных типах пользователей и их потребностях.

#база_тестирования
#записная_книжка

Вроде в проде?

Однажды жизнь в лице сообщества QA sisters связала меня с потрясающей тестировщицей, лидкой, евангелисткой computer science в тестировании и просто вдохновляющей девушкой — @alexpshe.

Когда мы переписывались в общем чате, я ещё не знала, что приду в Semrush, и мои первые деньки пересекутся с последними рабочими днями Саши перед уходом в команду Qodana; я не думала, что с Сашей я проведу одну из самых огненных сессий на 5-м сезоне Podlodka QA Crew, и уж точно представить себе не могла, что спустя какое-то время мы выпустим своё детище — подкаст!

Дамы и господа, представляю вашему вниманию первый выпуск "Вроде в проде" — подкаста про качество в IT и не только!
Теперь нас можно не только читать, но и слушать :)
В первом эпизоде мы говорим про то, с чего начинается любая работа тестировщика: собеседования, и даем себе из прошлого советы, которые сейчас сильно упрощают жизнь.

Твиттер, Spotify, Apple Podcasts, Soundcloud и Яндекс.Музыка (coming soon) — слушайте, делитесь, пишите Ваши мысли и вопросы!

За офигенный джингл спасибо @alloshmallo, а за юзерпик — https://www.instagram.com/abazhanova_v.
Ребята, благодаря которым появилась наша айдентика — это отличный пример тех, кто делает качество вне IT :)