Искренне рекомендую очередной сезон Подлодки QA Crew.

Как в прошлые сезоны, есть промокод для читательниц и читателей канала: QA11_with_a_spoon.
Еще у меня есть проходка и я ее тут разыграю (пока не решила, каким конкретно способом, но скоро решу).

К сожалению, в соответствии с текущими российскими законами нельзя просто сделать репост и дать промокод, нужно процессить такие посты определенным образом:( Даже если это некоммерческий репост за проходку для участников и промокод. Поэтому в посте есть маркировка о рекламе.

Итак, если хотите выиграть проходку на ближайший сезон Podlodka QA Crew - записывайтесь в формочку. В воскресенье в 11 часов (по Москве) я закрою прием ответов, а рандомайзер выберет, кому повезет в этот раз:)

УПД: форма закрыта, проходка выслана победительнице)

Я начала читать блог Ольги довольно давно, еще года четыре назад. Он дал мне ворох поводов для рефлексии и огромную поддержку. Позднее мне посчастливилось познакомиться с Ольгой лично и сделать вместе некоторое количество активностей внутри сообщества QA Sisters.

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

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

Очень рекомендую Ольгу как менторку!

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

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

Ко мне приходят женщины, которые часто считают, что проблема в них. Это они не справляются и плохо работают. И ищут, чтобы такое сделать с собой ещё.

Я верю, что проблема не в человеке. Проблема – это проблема.

Я стараюсь помочь посмотреть на систему целиком, на то как она взаимодействует и влияет на человека.

Нам часто говорят, что мы можем все, если достаточно постараемся.

Фокус. Дисциплина. Контроль.

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

Мне нравится модель из трёх кругов уровня контроля. Что-то мы можем контролировать, на что-то влиять, а на что-то даже влиять не можем.

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

Мы можем что-то делать, у нас есть наша агентность, но далеко не все зависит от нас.

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

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

Как выгорание в айти, где систематически не признаются факторы рабочей среды. Или долина смерти при переходе в автоматизацию тестирования.

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

Фемоптика. Нарративная практика. Теория Волн Тоффлера. Нейроотличность. Dragon Dreaming. Модели выгорания. Подходы к обучению. И куча всего ещё.

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

Зато об меня можно подумать и поорать про процессы, релизы и рабочие сложности. И почувствовать, что вы не одни.

Если вам сложно, вы запутались и не понимаете, что делать – пишите в личку @red_foks, подумаем.

Организационные детали:

1. Я работаю без видео, только по аудио
2. Сессия длится 1-1.5 часа
3. Стоимость 4000 рублей за первую встречу, 3000 рублей за вторую и далее в рамках одного кейса.

#консультации_по_тестированию
#подпольный_евангелизм

В честь праздника 8 марта проведу одну бесплатную консультацию по тестированию или управлению командой.
Возьму в работу тот запрос, который мне самой больше отзовется. Писать можно в комменты или личку @pony_the_immortal.

Консультация в зуме, часовой пояс -1 к Мск.

Предложение актуально только для женщин.

Огромное спасибо Очень интересно, только плакать хочется за идею.

...Прохожу курс по управлению качеством от Наташи Петровской. Вообще я планировала не брать дополнительную нагрузку, но искушение оказалось слишком велико, а режим обучения выглядел посильным. А еще мне очень заходит Наташин стиль повествования (мне кажется, у нее calming managerial voice:)

...На работе готовлю доклад про тим-лидство для митапа в Порту. Заодно запланировала отпуск там же - буду несколько дней заставлять себя лежать, гулять и максимально делать ничего.

...Начала писать комментарии в collaborative articles в Линкедине. Испытываю неприятное сильное ощущение, что я там единственный живой человек в компании ботов. Сама идея сборной солянки из мнений разных специалистов по какому-то вопросу мне нравится, но как-то так получается, что почти все мнения подозрительно похожи на мнение ChatGPT - красивые слова максимально общего характера. Не очень мотивирует продолжать.

...В начале февраля у меня случился приступ вдохновения и я решила сделать курс по тест-анализу. Месяц (и примерно 50 часов затреканной работы) спустя курс стартовал. Предположительно я на него потрачу еще часов 50. Это если считать только сфокусированную затреканную работу… Диффузную работу особо не затрекаешь. Делать курс помогает моя bestie-in-testing Оля Артемьева. С ней у нас почти 30 лет опыта в тестировании на двоих, а еще она знает, как сделать так, чтобы люди не умирали от скуки на лекциях.

Постепенно собираю поток на май (почти набрала) и аккуратно планирую июнь-июль.

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

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

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

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

Итак, о чем мы там говорим:

- Как принимать решения о необходимом и достаточном тестировании в разных контекстах?
- Как тестировать, если непонятно, как тестировать?
- Как аргументированно отвечать на вопросы “Почему вы тестировали именно так?”.
- Как уверенно артикулировать проблемы?

Вебинар 1: Знакомство. Общие идеи и термины. На этом занятии мы с вами немного познакомимся, а затем поговорим об общих идеях, которые будут проходить через весь курс. Возможно, узнаем новое слово (1 шт).

Вебинар 2:
Работа с (как будто) понятными задачами. Если задача понятна - значит ли это, что ее можно просто протестировать? Просто протестировать - это вообще как конкретно? Можно ли применить такой же подход к сложным задачам? Давайте обсудим:)

Вебинар 3:
Теперь посмотрим в бездну:) Спросим себя - а что мы вообще тестируем? Заглянем под капот. Вспомним о нуждах бизнеса и пользователей. Найдем "слепые пятна" в покрытии.

Вебинар 4:
"Ты просто проверь, что ничего не сломалось!". Немаловероятно, что всем или почти всем из вас это знакомо:) Что-то порефакторили, или обновили библиотеку, или принесли идею фичи/улучшения... Подумаем вместе, с какой стороны тут можно подойти к тестированию.

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

Все же постараюсь не набирать больше активностей вне работы, потому что ну куда уже, оно же не лезет. Хотя вот Подлодка же - в ней так прикольно участвовать... И еще можно сделать доклад про то, как проектировался и реализовывался курс.

Интересных штук намного больше, чем времени и сил:(

Скоро стартует очередной сезон Podlodka TeamLead Crew. Я на него, кажется, не попаду - и так полна коробочка планов, а жаль.

Тем не менее приношу промокод для канала: QA_with_a_spoon_tl_crew_12 (скидка 500 р, суммируется со скидкой для ранних пташек тарифа "Моряк")

Также у меня есть одна проходка на бесплатное посещение конференции.

Если хотите ее получить, напишите мне в личку сегодня до 22:00 по Москве* о своей мотивации пойти на конференцию. Чья мотивация мне понравится больше - той/тому отдам проходку. UPD Проходка отдана)

*Тогда, если вам не достанется проходка, вы еще успеете купить билет с максимальной скидкой. В ночь на 28 марта скидка для ранних пташек закончится

Привет, на связи Podlodka Teamlead Crew!
Пришли со свежими подробностями сезона.
Стартуем уже 1 апреля: научимся выбирать, внедрять, анализировать и масштабировать метрики.

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

❓В каких сферах применимы метрики? Сергей Воробьёв объяснит как использовать популярные виды метрик и где брать для них данные.

❓Как принимать решения на основе метрик? Сергей Петрук из QIWI владеет этой магией: проведёт воркшоп по фреймворку принятия решений, разберёт реальные кейсы.

❓Как говорить с бизнесом на языке метрик? Серафима Чекулаева поделится священными тайнами продуктовых метрик и их потенциальной пользой.

Билеты уже на сайте, забирай свой!
https://podlodka.io/tlcrew

———
Реклама. ИП Толстая Елена Петровна ИНН:507503278104, erid:2SDnjcrNQ3T

*Без маркировки о рекламе, к сожалению, нельзя делать даже дружественные перепосты за промокод/проходку для читательниц и читателей канала.

Коротко о разном: всякое бывает (с)

- Приехала в Порту в командировку и отпуск
- Сходила на Geek Girls Portugal (правда, не с докладом, а просто постоять на стойке компании:) Никогда не пробовала этот вид деятельности, было в каком-то смысле интересно
- Выступила с презентацией "Think Twice Before Becoming a Team Lead" на митапе. Видео будет когда-нибудь (скорее всего, в ближайшие дни)
- На следующей неделе уйду в отпуск, планирую максимально гулять, лежать и не думать про трудовые подвиги

Несу видео моей презентации "Think Twice Before Becoming a Team Lead", с которой я выступила на оффлайн митапе dxTechTalk в нашем португальском офисе.

Возможно, потом сделаю отдельный пост с текстом презентации, но это не точно.

https://www.youtube.com/watch?v=SC3EaC5nqVA

Очень благодарна себе-из-прошлого за то, что с самого начала работы над курсом трекала время.

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

В эти 106 часов входит подготовка презентаций к 6 вебинарам (перекладывание идеи из головы на “бумагу”, черновые прогоны, обработка фидбэка от Оли), взаимодействие с дизайнеркой и юристкой, административная работа, проведение самих вебинары, подготовка и рассылка сертификатов.

На второй поток (апгрейд презентаций, административная работа, взаимодействие с дизайнеркой, проведение вебинаров (на данный момент - 2 из 6) ) я пока потратила 36 часов. Ожидаю, что в сумме уйдет примерно 50.

Очень помогает не впадать в иллюзии вроде “быстренько сделаю презентацию, у меня ж все в голове есть, надо просто презентацию набросать” или “у меня весь материал готов, надо просто рассказать его еще раз”.

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

🌟 Проверки логирования в тестах (формулировка проблемы)

Эта тема давно у меня побаливает. Что конкретно болит? Например, вот это: в функциональные тесты довольно часто добавляются не только функциональные ожидаемые результаты, но и логи, которые тоже нужно проверить. То есть в одном тесте проверяется
- функциональный сценарий
- то, как этот сценарий залогирован

В чем проблема, собственно? Мне навскидку пришло в голову несколько.

Проблема 1: Консистентность бага тесту. Точнее, ее отсутствие.

Например, баг observability фейлит функциональный тест. Функционально некритичный баг фейлит функционально критичный кейс.

А что бы мне хотелось? Чтобы баги фейлили соответствующие тесты, чтобы была консистентность между багом и тестом. Критичный функциональный баг фейлит критичный функциональный тест. Мелкий баг про смещенную кнопку фейлит некритичный тест про отображение кнопки.

Из проблемы консистентности вытекает проблема прозрачности.

Проблема 2: Прозрачность документации.

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

То есть документация говорит: у нас не работает важный функциональный сценарий!
Чтобы увидеть, что проблема именно с логами, а не функциональностью, нужно уже посмотреть на баг репорт.

А что бы мне хотелось: чтобы документация максимально прозрачно показывала, какие есть проблемы и какова их критичность. Если в тест ране пофейлен тест про создание сделок - значит, у нас проблема именно с созданием сделок (а не с логированием, цветом кнопок, расположением окна создания сделки и т п). Если у нас проблема с логированием/цветом кнопок и т п - то тест на создание сделки Passed, тест на логирование/цвет кнопок и т п Failed.

Проблема 3: Затраты на прогон тестов.

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

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

А что бы мне хотелось: чтобы мы не только тестировали то, что нужно протестировать, но и НЕ тестировали то, что НЕ нужно протестировать. Чтобы мы не только уточняли и расширяли тестовое покрытие там, где нужно, но и сокращали его там, где оно не нужно, и не делали работу, которую можно не делать.

Проблема 4: Затраты на автоматизацию

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

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

Проблема 5: Очень сложно сфокусированно протестировать именно логирование.

Например: решили улучшить логирование, для чего начали использовать Кибану. Чтобы логи можно было смотреть через Кибану, логи должны быть в одном формате. В настоящее время они в другом формате. То есть нужно переделать логирование так, чтобы оно производилось в другом формате.

Логирование каждого компонента переписывается ручками разных людей и тестируется отдельно. Каждая область логирования может сломаться более-менее независимо от другой.Проверки логов размазаны ровным слоем по примерно всем тестам. Гонять все тесты как есть - очень дорого. Придется проводить много функциональных проверок, причем с точки зрения проверки именно логирования значительная часть этих проверок будет дублировать друг друга. Будет сложно искать пробелы - что мы НЕ проверили в логах и какие функциональные тесты покрывают именно эти пробелы. То есть по сути надо будет полностью продумать тестовое покрытие для логирования, сделать черновик этого покрытия, потом как-то сматчить функциональные тесты на этот черновик… Решать эту задачу "в лоб" довольно долго и мучительно.

Что с этими проблемами делать, как решать?

Да просто давайте уберем логи из тестов! С вас пять тыщ (с)

Шутка. Над решением я еще думаю, но кое-какие идеи есть, я ими обязательно поделюсь в следующем посте.

🌟 Итак, тесты по логированию (big picture)

Что точно не хочу делать:
- тестировать логирование, когда это не надо (например, тестировать его по умолчанию для каждого релиза, особенно в рамках смоук тестирования)
- тестировать функциональность библиотеки логирования

Что хочу делать:
- тестировать, что нужная нам информация залогирована
- тестировать это недорого (не прогонять 100500 функциональных тестов, чтобы проверить логи)

Какое решение вижу:
- вынести проверки логирования в отдельные тест-кейсы
- убирать или добавлять их в план в зависимости от рисков возникновения проблем с логированием

Какие тесты я бы прогоняла в разных контекстах:

Контекст 1: Разработка новой фичи
- функциональные тесты: да
- тесты на логирование: да

Контекст 2: Фича уже в продакшен (активная работа над ней закончена)
- функциональные тесты: да
- тесты на логирование: нет

Контекст 3: Фича меняется (изменения функциональности, рефакторинг, что-то еще)
- функциональные тесты: да
- тесты на логирование: да

Контекст 4: Библиотека логирования существенно меняется (например, переходим на радикально другую версию библиотеки)
- функциональные тесты: нет
- тесты на логирование: да

Контекст 5: Переходим на другую библиотеку логирования (или интегрируемся с сервисом логирования, или что-то в этом роде)
- функциональные тесты: нет
- тесты на логирование: да

Позже напишу про дизайн конкретных тестов.

К вопросу о лишних словах.

Я знаю одного человека, который знает одного человека...

...который запустил поиск по тестам в Jira по слову "успешно" и нашел примерно 2700 тестов.

То есть в тестовой документации есть минимум 2700 слов, которые совершенно точно не приносят никакой пользы.
Только засоряют пространство.