Привет!
На связи Podlodka QA Crew🐞 — мы организовываем онлайн IT-конференции по разным темам, одна из которых — тестирование.
Бесконечно можно смотреть на огонь, воду и извечный баттл между «знать только то, с чем сталкиваешься в работе ежедневно» и «не знать теорию — ограничить себя только известными способами решения проблем».
Мы считаем, что хорошая теоретическая база – это то, что отличает обычного QA-инженера от крутого.
За 5 дней Podlodka QA Crew мы вместе вдохновимся теорией и начнём использовать её на практике:
🔹 выясним, как эффективно выстраивать экосистему тестовой документации;
🔹 начнём правильно применять SCRUM-методологию в работе тестировщика;
🔹 научимся обеспечивать качество тестирования, повышать скорость и точность выполнения задач с помощью матанализа и алгоритмов;
🔹 избавимся от страха программировать и заставим тезис «писать код может каждый» работать в реальной жизни;
🔹 обсудим главные теоретические вопросы собеседований на уровень middle+ и выше, узнаем как правильно на них отвечать.
Ну и хватит пока теории на один анонс :) Отправляйтесь на сайт за билетом и вперёд практиковаться:
https://podlodka.io/qacrew
Реклама. ИП Толстая Елена Петровна ИНН:507503278104 erid:2SDnjcpzE7S
На связи Podlodka QA Crew
Бесконечно можно смотреть на огонь, воду и извечный баттл между «знать только то, с чем сталкиваешься в работе ежедневно» и «не знать теорию — ограничить себя только известными способами решения проблем».
Мы считаем, что хорошая теоретическая база – это то, что отличает обычного QA-инженера от крутого.
За 5 дней Podlodka QA Crew мы вместе вдохновимся теорией и начнём использовать её на практике:
🔹 выясним, как эффективно выстраивать экосистему тестовой документации;
🔹 начнём правильно применять SCRUM-методологию в работе тестировщика;
🔹 научимся обеспечивать качество тестирования, повышать скорость и точность выполнения задач с помощью матанализа и алгоритмов;
🔹 избавимся от страха программировать и заставим тезис «писать код может каждый» работать в реальной жизни;
🔹 обсудим главные теоретические вопросы собеседований на уровень middle+ и выше, узнаем как правильно на них отвечать.
Ну и хватит пока теории на один анонс :) Отправляйтесь на сайт за билетом и вперёд практиковаться:
https://podlodka.io/qacrew
Реклама. ИП Толстая Елена Петровна ИНН:507503278104 erid:2SDnjcpzE7S
Please open Telegram to view this post
VIEW IN TELEGRAM
podlodka.io
Онлайн-конференция Podlodka QA Crew, сезон #13
Недельное мероприятие от команды Podlodka: ежедневные интерактивные сессии в Zoom по актуальным проблемам QA-индустрии, нон-стоп общение с экспертами и звёздами индустрии, закрытое профессиональное сообщество в Telegram.
Искренне рекомендую очередной сезон Подлодки QA Crew.
Как в прошлые сезоны, есть промокод для читательниц и читателей канала: QA11_with_a_spoon.
Еще у меня есть проходка и я ее тут разыграю (пока не решила, каким конкретно способом, но скоро решу).
К сожалению, в соответствии с текущими российскими законами нельзя просто сделать репост и дать промокод, нужно процессить такие посты определенным образом:( Даже если это некоммерческий репост за проходку для участников и промокод. Поэтому в посте есть маркировка о рекламе.
Как в прошлые сезоны, есть промокод для читательниц и читателей канала: QA11_with_a_spoon.
Еще у меня есть проходка и я ее тут разыграю (пока не решила, каким конкретно способом, но скоро решу).
К сожалению, в соответствии с текущими российскими законами нельзя просто сделать репост и дать промокод, нужно процессить такие посты определенным образом:( Даже если это некоммерческий репост за проходку для участников и промокод. Поэтому в посте есть маркировка о рекламе.
Итак, если хотите выиграть проходку на ближайший сезон Podlodka QA Crew - записывайтесь в формочку. В воскресенье в 11 часов (по Москве) я закрою прием ответов, а рандомайзер выберет, кому повезет в этот раз:)
УПД: форма закрыта, проходка выслана победительнице)
УПД: форма закрыта, проходка выслана победительнице)
Я начала читать блог Ольги довольно давно, еще года четыре назад. Он дал мне ворох поводов для рефлексии и огромную поддержку. Позднее мне посчастливилось познакомиться с Ольгой лично и сделать вместе некоторое количество активностей внутри сообщества QA Sisters.
Сейчас Ольга помогает мне делать курс по тест-анализу, который стартует через неделю (о нем напишу когда-нибудь потом. Не планирую объявлять туда набор в ближайшем будущем).
Одна голова - хорошо, а две - лучше, особенно когда вторая голова имеет знания не только в сфере тестирования, но еще и в сфере проектирования образовательного опыта, а еще рефлексию 100 lvl, критический взгляд на вещи и умение деликатно и бережно эту критику преподнести.
Очень рекомендую Ольгу как менторку!
Сейчас Ольга помогает мне делать курс по тест-анализу, который стартует через неделю (о нем напишу когда-нибудь потом. Не планирую объявлять туда набор в ближайшем будущем).
Одна голова - хорошо, а две - лучше, особенно когда вторая голова имеет знания не только в сфере тестирования, но еще и в сфере проектирования образовательного опыта, а еще рефлексию 100 lvl, критический взгляд на вещи и умение деликатно и бережно эту критику преподнести.
Очень рекомендую Ольгу как менторку!
Forwarded from Тестирование и жизнь (Olga Artemyeva)
Много консультировала за последние три месяца и сформулировала про что я работаю и хочу работать. В корпоративном мире это называется миссия, но у меня это вызывает лютый кринж.
Я работаю, чтобы помочь в айтишной работе выйти из кладовки стыда и осмотреться, что происходит вокруг.
Ко мне приходят женщины, которые часто считают, что проблема в них. Это они не справляются и плохо работают. И ищут, чтобы такое сделать с собой ещё.
Я верю, что проблема не в человеке. Проблема – это проблема.
Я стараюсь помочь посмотреть на систему целиком, на то как она взаимодействует и влияет на человека.
Нам часто говорят, что мы можем все, если достаточно постараемся.
Фокус. Дисциплина. Контроль.
А потом на нас наступает реальная жизнь. И выясняется, что мы не можем полностью контролировать даже наше тело и психику.
Мне нравится модель из трёх кругов уровня контроля. Что-то мы можем контролировать, на что-то влиять, а на что-то даже влиять не можем.
И в работе по моему опыту очень много располагается в этой средней зоне, в зоне влияния, но не контроля.
Мы можем что-то делать, у нас есть наша агентность, но далеко не все зависит от нас.
Я не стремлюсь к полной нейтральности, и не верю, что одна возможна, у меня есть свой опыт и свои ограничения. Для меня важно называть хуйню хуйней и рассказывать как может быть иначе. Если это все становится становится видимым, то с этим уже можно что-то сделать.
Меня бесит, что проблемы людей, которые встречаются повсеместно, по прежнему считаются только их частными. проблемами.
Как выгорание в айти, где систематически не признаются факторы рабочей среды. Или долина смерти при переходе в автоматизацию тестирования.
Я опираюсь на свой опыт в айти, рефлексию и стремление разобраться как все это устроено. Я предлагаю модели, точки зрения и оптики, которые могут быть полезны и в которые можно покопать.
Фемоптика. Нарративная практика. Теория Волн Тоффлера. Нейроотличность. Dragon Dreaming. Модели выгорания. Подходы к обучению. И куча всего ещё.
Я не психологиня и не лезу в эту работу, стараясь определять свою зону компетентности и советуя людям других специалисток. Семь лет в терапии и иногда ношу туда рабочие кейсы.
Зато об меня можно подумать и поорать про процессы, релизы и рабочие сложности. И почувствовать, что вы не одни.
Если вам сложно, вы запутались и не понимаете, что делать – пишите в личку @red_foks, подумаем.
Организационные детали:
1. Я работаю без видео, только по аудио
2. Сессия длится 1-1.5 часа
3. Стоимость 4000 рублей за первую встречу, 3000 рублей за вторую и далее в рамках одного кейса.
#консультации_по_тестированию
#подпольный_евангелизм
Я работаю, чтобы помочь в айтишной работе выйти из кладовки стыда и осмотреться, что происходит вокруг.
Ко мне приходят женщины, которые часто считают, что проблема в них. Это они не справляются и плохо работают. И ищут, чтобы такое сделать с собой ещё.
Я верю, что проблема не в человеке. Проблема – это проблема.
Я стараюсь помочь посмотреть на систему целиком, на то как она взаимодействует и влияет на человека.
Нам часто говорят, что мы можем все, если достаточно постараемся.
Фокус. Дисциплина. Контроль.
А потом на нас наступает реальная жизнь. И выясняется, что мы не можем полностью контролировать даже наше тело и психику.
Мне нравится модель из трёх кругов уровня контроля. Что-то мы можем контролировать, на что-то влиять, а на что-то даже влиять не можем.
И в работе по моему опыту очень много располагается в этой средней зоне, в зоне влияния, но не контроля.
Мы можем что-то делать, у нас есть наша агентность, но далеко не все зависит от нас.
Я не стремлюсь к полной нейтральности, и не верю, что одна возможна, у меня есть свой опыт и свои ограничения. Для меня важно называть хуйню хуйней и рассказывать как может быть иначе. Если это все становится становится видимым, то с этим уже можно что-то сделать.
Меня бесит, что проблемы людей, которые встречаются повсеместно, по прежнему считаются только их частными. проблемами.
Как выгорание в айти, где систематически не признаются факторы рабочей среды. Или долина смерти при переходе в автоматизацию тестирования.
Я опираюсь на свой опыт в айти, рефлексию и стремление разобраться как все это устроено. Я предлагаю модели, точки зрения и оптики, которые могут быть полезны и в которые можно покопать.
Фемоптика. Нарративная практика. Теория Волн Тоффлера. Нейроотличность. Dragon Dreaming. Модели выгорания. Подходы к обучению. И куча всего ещё.
Я не психологиня и не лезу в эту работу, стараясь определять свою зону компетентности и советуя людям других специалисток. Семь лет в терапии и иногда ношу туда рабочие кейсы.
Зато об меня можно подумать и поорать про процессы, релизы и рабочие сложности. И почувствовать, что вы не одни.
Если вам сложно, вы запутались и не понимаете, что делать – пишите в личку @red_foks, подумаем.
Организационные детали:
1. Я работаю без видео, только по аудио
2. Сессия длится 1-1.5 часа
3. Стоимость 4000 рублей за первую встречу, 3000 рублей за вторую и далее в рамках одного кейса.
#консультации_по_тестированию
#подпольный_евангелизм
В честь праздника 8 марта проведу одну бесплатную консультацию по тестированию или управлению командой.
Возьму в работу тот запрос, который мне самой больше отзовется. Писать можно в комменты или личку @pony_the_immortal.
Консультация в зуме, часовой пояс -1 к Мск.
Предложение актуально только для женщин.
Огромное спасибо Очень интересно, только плакать хочется за идею.
Возьму в работу тот запрос, который мне самой больше отзовется. Писать можно в комменты или личку @pony_the_immortal.
Консультация в зуме, часовой пояс -1 к Мск.
Предложение актуально только для женщин.
Огромное спасибо Очень интересно, только плакать хочется за идею.
...Прохожу курс по управлению качеством от Наташи Петровской. Вообще я планировала не брать дополнительную нагрузку, но искушение оказалось слишком велико, а режим обучения выглядел посильным. А еще мне очень заходит Наташин стиль повествования (мне кажется, у нее calming managerial voice:)
...На работе готовлю доклад про тим-лидство для митапа в Порту. Заодно запланировала отпуск там же - буду несколько дней заставлять себя лежать, гулять и максимально делать ничего.
...Начала писать комментарии в collaborative articles в Линкедине. Испытываю неприятное сильное ощущение, что я там единственный живой человек в компании ботов. Сама идея сборной солянки из мнений разных специалистов по какому-то вопросу мне нравится, но как-то так получается, что почти все мнения подозрительно похожи на мнение ChatGPT - красивые слова максимально общего характера. Не очень мотивирует продолжать.
...В начале февраля у меня случился приступ вдохновения и я решила сделать курс по тест-анализу. Месяц (и примерно 50 часов затреканной работы) спустя курс стартовал. Предположительно я на него потрачу еще часов 50. Это если считать только сфокусированную затреканную работу… Диффузную работу особо не затрекаешь. Делать курс помогает моя bestie-in-testing Оля Артемьева. С ней у нас почти 30 лет опыта в тестировании на двоих, а еще она знает, как сделать так, чтобы люди не умирали от скуки на лекциях.
Постепенно собираю поток на май (почти набрала) и аккуратно планирую июнь-июль.
Возможно, через полгодика сделаю открытый набор людей (но это не точно, я еще посмотрю на свои ощущения и желания).
...В общем, задачу “снизить нагрузку” я несколько провалила. Неприятный побочный эффект любви к тому, что делаешь. Стоит только расслабиться и потерять контроль - и ты уже опять по уши в какой-то максимально интересной деятельности.
Ну и раз уж я начала рассказывать про курс - принесу текущую версию анонса и программу. Скорее всего, он будет меняться со временем, но пока что это выглядит так.
Курс рассчитан на специалисток и специалистов, уже имеющих опыт в тестировании. Особенно полезен он будет тем, кто редко получает обратную связь от коллег: что вы протестировали особенно хорошо (и почему конкретно), а что не очень (и почему конкретно).
Итак, о чем мы там говорим:
- Как принимать решения о необходимом и достаточном тестировании в разных контекстах?
- Как тестировать, если непонятно, как тестировать?
- Как аргументированно отвечать на вопросы “Почему вы тестировали именно так?”.
- Как уверенно артикулировать проблемы?
Вебинар 1: Знакомство. Общие идеи и термины. На этом занятии мы с вами немного познакомимся, а затем поговорим об общих идеях, которые будут проходить через весь курс. Возможно, узнаем новое слово (1 шт).
Вебинар 2:
Работа с (как будто) понятными задачами. Если задача понятна - значит ли это, что ее можно просто протестировать? Просто протестировать - это вообще как конкретно? Можно ли применить такой же подход к сложным задачам? Давайте обсудим:)
Вебинар 3:
Теперь посмотрим в бездну:) Спросим себя - а что мы вообще тестируем? Заглянем под капот. Вспомним о нуждах бизнеса и пользователей. Найдем "слепые пятна" в покрытии.
Вебинар 4:
"Ты просто проверь, что ничего не сломалось!". Немаловероятно, что всем или почти всем из вас это знакомо:) Что-то порефакторили, или обновили библиотеку, или принесли идею фичи/улучшения... Подумаем вместе, с какой стороны тут можно подойти к тестированию.
Вебинар 5:
Работа с инцидентами. Поговорим про локализацию багов, про исследование проблем на продакшен системах и про то, что мы можем сделать на стадии тест-анализа, чтобы в будущем облегчить себе этот процесс.
...На работе готовлю доклад про тим-лидство для митапа в Порту. Заодно запланировала отпуск там же - буду несколько дней заставлять себя лежать, гулять и максимально делать ничего.
...Начала писать комментарии в 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 марта скидка для ранних пташек закончится
Тем не менее приношу промокод для канала: QA_with_a_spoon_tl_crew_12 (скидка 500 р, суммируется со скидкой для ранних пташек тарифа "Моряк")
Также у меня есть одна проходка на бесплатное посещение конференции.
Если хотите ее получить, напишите мне в личку сегодня до 22:00 по Москве* о своей мотивации пойти на конференцию. Чья мотивация мне понравится больше - той/тому отдам проходку. UPD Проходка отдана)
*Тогда, если вам не достанется проходка, вы еще успеете купить билет с максимальной скидкой. В ночь на 28 марта скидка для ранних пташек закончится
Привет, на связи Podlodka Teamlead Crew!
Пришли со свежими подробностями сезона.
Стартуем уже 1 апреля: научимся выбирать, внедрять, анализировать и масштабировать метрики.
Если вам кажется, что язык метрик сродни заклинаниям, которые знают лишь избранные, то вы попали по адресу. Мы пригласили крутых спикеров из известных компаний, которые обладают этим знанием и на метриках уже «собаку съели». Они научат правильно применять метрики, говорить с бизнесом и продактами на одном языке во благо разрабатываемому решению.
❓В каких сферах применимы метрики? Сергей Воробьёв объяснит как использовать популярные виды метрик и где брать для них данные.
❓Как принимать решения на основе метрик? Сергей Петрук из QIWI владеет этой магией: проведёт воркшоп по фреймворку принятия решений, разберёт реальные кейсы.
❓Как говорить с бизнесом на языке метрик? Серафима Чекулаева поделится священными тайнами продуктовых метрик и их потенциальной пользой.
Билеты уже на сайте, забирай свой!
https://podlodka.io/tlcrew
———
Реклама. ИП Толстая Елена Петровна ИНН:507503278104, erid:2SDnjcrNQ3T
*Без маркировки о рекламе, к сожалению, нельзя делать даже дружественные перепосты за промокод/проходку для читательниц и читателей канала.
Пришли со свежими подробностями сезона.
Стартуем уже 1 апреля: научимся выбирать, внедрять, анализировать и масштабировать метрики.
Если вам кажется, что язык метрик сродни заклинаниям, которые знают лишь избранные, то вы попали по адресу. Мы пригласили крутых спикеров из известных компаний, которые обладают этим знанием и на метриках уже «собаку съели». Они научат правильно применять метрики, говорить с бизнесом и продактами на одном языке во благо разрабатываемому решению.
❓В каких сферах применимы метрики? Сергей Воробьёв объяснит как использовать популярные виды метрик и где брать для них данные.
❓Как принимать решения на основе метрик? Сергей Петрук из QIWI владеет этой магией: проведёт воркшоп по фреймворку принятия решений, разберёт реальные кейсы.
❓Как говорить с бизнесом на языке метрик? Серафима Чекулаева поделится священными тайнами продуктовых метрик и их потенциальной пользой.
Билеты уже на сайте, забирай свой!
https://podlodka.io/tlcrew
———
Реклама. ИП Толстая Елена Петровна ИНН:507503278104, erid:2SDnjcrNQ3T
*Без маркировки о рекламе, к сожалению, нельзя делать даже дружественные перепосты за промокод/проходку для читательниц и читателей канала.
podlodka.io
Онлайн-конференция Podlodka Teamlead Crew, сезон #14
Недельное мероприятие от команды Podlodka: ежедневные интерактивные сессии в Zoom по актуальным проблемам тимлидства, нон-стоп общение с экспертами и звёздами индустрии, закрытое профессиональное сообщество в Telegram.
Коротко о разном: всякое бывает (с)
- Приехала в Порту в командировку и отпуск
- Сходила на Geek Girls Portugal (правда, не с докладом, а просто постоять на стойке компании:) Никогда не пробовала этот вид деятельности, было в каком-то смысле интересно
- Выступила с презентацией "Think Twice Before Becoming a Team Lead" на митапе. Видео будет когда-нибудь (скорее всего, в ближайшие дни)
- На следующей неделе уйду в отпуск, планирую максимально гулять, лежать и не думать про трудовые подвиги
- Приехала в Порту в командировку и отпуск
- Сходила на 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
Возможно, потом сделаю отдельный пост с текстом презентации, но это не точно.
https://www.youtube.com/watch?v=SC3EaC5nqVA
YouTube
Think Twice Before Becoming a Team Lead
Have you ever wondered what it’s like to be a team lead?
Are you aspiring to become a team lead or are you already in that role and striving to optimize your daily operations? Or are you concerned about your colleagues' technical skills advancing while…
Are you aspiring to become a team lead or are you already in that role and striving to optimize your daily operations? Or are you concerned about your colleagues' technical skills advancing while…
Очень благодарна себе-из-прошлого за то, что с самого начала работы над курсом трекала время.
Конечно же, это не даст полной картины затрат времени. Затрекана только сфокусированная работа, а сколько было размышлений в диффузном режиме - не сосчитать.
Тем не менее, на основе трекинга я могу сказать, что на проведение первого потока курса было потрачено точно не меньше 106 часов.
В эти 106 часов входит подготовка презентаций к 6 вебинарам (перекладывание идеи из головы на “бумагу”, черновые прогоны, обработка фидбэка от Оли), взаимодействие с дизайнеркой и юристкой, административная работа, проведение самих вебинары, подготовка и рассылка сертификатов.
На второй поток (апгрейд презентаций, административная работа, взаимодействие с дизайнеркой, проведение вебинаров (на данный момент - 2 из 6) ) я пока потратила 36 часов. Ожидаю, что в сумме уйдет примерно 50.
Очень помогает не впадать в иллюзии вроде “быстренько сделаю презентацию, у меня ж все в голове есть, надо просто презентацию набросать” или “у меня весь материал готов, надо просто рассказать его еще раз”.
* Пока что меня устраивает проводить его внутри сообщества. Внешний поток хочу взять примерно в октябре. Анонс и т п подготовлю во второй половине лета, если планы не поменяются. Мне еще очень хочется проводить его в англоязычном пространстве - и я работаю над этим тоже.
Конечно же, это не даст полной картины затрат времени. Затрекана только сфокусированная работа, а сколько было размышлений в диффузном режиме - не сосчитать.
Тем не менее, на основе трекинга я могу сказать, что на проведение первого потока курса было потрачено точно не меньше 106 часов.
В эти 106 часов входит подготовка презентаций к 6 вебинарам (перекладывание идеи из головы на “бумагу”, черновые прогоны, обработка фидбэка от Оли), взаимодействие с дизайнеркой и юристкой, административная работа, проведение самих вебинары, подготовка и рассылка сертификатов.
На второй поток (апгрейд презентаций, административная работа, взаимодействие с дизайнеркой, проведение вебинаров (на данный момент - 2 из 6) ) я пока потратила 36 часов. Ожидаю, что в сумме уйдет примерно 50.
Очень помогает не впадать в иллюзии вроде “быстренько сделаю презентацию, у меня ж все в голове есть, надо просто презентацию набросать” или “у меня весь материал готов, надо просто рассказать его еще раз”.
* Пока что меня устраивает проводить его внутри сообщества. Внешний поток хочу взять примерно в октябре. Анонс и т п подготовлю во второй половине лета, если планы не поменяются. Мне еще очень хочется проводить его в англоязычном пространстве - и я работаю над этим тоже.
🌟 Проверки логирования в тестах (формулировка проблемы)
Эта тема давно у меня побаливает. Что конкретно болит? Например, вот это: в функциональные тесты довольно часто добавляются не только функциональные ожидаемые результаты, но и логи, которые тоже нужно проверить. То есть в одном тесте проверяется
- функциональный сценарий
- то, как этот сценарий залогирован
В чем проблема, собственно? Мне навскидку пришло в голову несколько.
Проблема 1: Консистентность бага тесту. Точнее, ее отсутствие.
Например, баг observability фейлит функциональный тест. Функционально некритичный баг фейлит функционально критичный кейс.
А что бы мне хотелось? Чтобы баги фейлили соответствующие тесты, чтобы была консистентность между багом и тестом. Критичный функциональный баг фейлит критичный функциональный тест. Мелкий баг про смещенную кнопку фейлит некритичный тест про отображение кнопки.
Из проблемы консистентности вытекает проблема прозрачности.
Проблема 2: Прозрачность документации.
Если функционально все ок, а в логах проблема (например, что-то не залогировано или есть эксепшен) - получается, я должна пометить этот кейс как failed.
То есть документация говорит: у нас не работает важный функциональный сценарий!
Чтобы увидеть, что проблема именно с логами, а не функциональностью, нужно уже посмотреть на баг репорт.
А что бы мне хотелось: чтобы документация максимально прозрачно показывала, какие есть проблемы и какова их критичность. Если в тест ране пофейлен тест про создание сделок - значит, у нас проблема именно с созданием сделок (а не с логированием, цветом кнопок, расположением окна создания сделки и т п). Если у нас проблема с логированием/цветом кнопок и т п - то тест на создание сделки Passed, тест на логирование/цвет кнопок и т п Failed.
Проблема 3: Затраты на прогон тестов.
Точно ли надо проверять логирование каждый раз, когда мы проверяем создание сделки? Какой риск мы хотим этим закрыть? Точно ли надо его закрывать именно этим способом? Не можем ли мы сэкономить время и силы, проверяя логи только тогда, когда это действительно нужно?
Если мы не можем аргументировать, почему мы тестируем это так - возможно, мы тестируем это просто по привычке, потому что так принято, потому что кто-то в прошлом написал тесты такого вида, а все остальные просто повторяют этот паттерн, принимая его на веру.
А что бы мне хотелось: чтобы мы не только тестировали то, что нужно протестировать, но и НЕ тестировали то, что НЕ нужно протестировать. Чтобы мы не только уточняли и расширяли тестовое покрытие там, где нужно, но и сокращали его там, где оно не нужно, и не делали работу, которую можно не делать.
Эта тема давно у меня побаливает. Что конкретно болит? Например, вот это: в функциональные тесты довольно часто добавляются не только функциональные ожидаемые результаты, но и логи, которые тоже нужно проверить. То есть в одном тесте проверяется
- функциональный сценарий
- то, как этот сценарий залогирован
В чем проблема, собственно? Мне навскидку пришло в голову несколько.
Проблема 1: Консистентность бага тесту. Точнее, ее отсутствие.
Например, баг observability фейлит функциональный тест. Функционально некритичный баг фейлит функционально критичный кейс.
А что бы мне хотелось? Чтобы баги фейлили соответствующие тесты, чтобы была консистентность между багом и тестом. Критичный функциональный баг фейлит критичный функциональный тест. Мелкий баг про смещенную кнопку фейлит некритичный тест про отображение кнопки.
Из проблемы консистентности вытекает проблема прозрачности.
Проблема 2: Прозрачность документации.
Если функционально все ок, а в логах проблема (например, что-то не залогировано или есть эксепшен) - получается, я должна пометить этот кейс как failed.
То есть документация говорит: у нас не работает важный функциональный сценарий!
Чтобы увидеть, что проблема именно с логами, а не функциональностью, нужно уже посмотреть на баг репорт.
А что бы мне хотелось: чтобы документация максимально прозрачно показывала, какие есть проблемы и какова их критичность. Если в тест ране пофейлен тест про создание сделок - значит, у нас проблема именно с созданием сделок (а не с логированием, цветом кнопок, расположением окна создания сделки и т п). Если у нас проблема с логированием/цветом кнопок и т п - то тест на создание сделки Passed, тест на логирование/цвет кнопок и т п Failed.
Проблема 3: Затраты на прогон тестов.
Точно ли надо проверять логирование каждый раз, когда мы проверяем создание сделки? Какой риск мы хотим этим закрыть? Точно ли надо его закрывать именно этим способом? Не можем ли мы сэкономить время и силы, проверяя логи только тогда, когда это действительно нужно?
Если мы не можем аргументировать, почему мы тестируем это так - возможно, мы тестируем это просто по привычке, потому что так принято, потому что кто-то в прошлом написал тесты такого вида, а все остальные просто повторяют этот паттерн, принимая его на веру.
А что бы мне хотелось: чтобы мы не только тестировали то, что нужно протестировать, но и НЕ тестировали то, что НЕ нужно протестировать. Чтобы мы не только уточняли и расширяли тестовое покрытие там, где нужно, но и сокращали его там, где оно не нужно, и не делали работу, которую можно не делать.
Проблема 4: Затраты на автоматизацию
Если принят процесс, по которому тестировщики пишут тесты для выполнения людьми, а команда автоматизаторов потом их автоматизирует - функциональный тест с кусками логов отправляется на автоматизацию и создает дополнительную работу, которая потенциально не приносит ценности.
А что бы мне хотелось: опять же, не делать лишнюю работу: автоматизировать то, что действительно стоит автоматизировать, и не автоматизировать лишнего.
Проблема 5: Очень сложно сфокусированно протестировать именно логирование.
Например: решили улучшить логирование, для чего начали использовать Кибану. Чтобы логи можно было смотреть через Кибану, логи должны быть в одном формате. В настоящее время они в другом формате. То есть нужно переделать логирование так, чтобы оно производилось в другом формате.
Логирование каждого компонента переписывается ручками разных людей и тестируется отдельно. Каждая область логирования может сломаться более-менее независимо от другой.Проверки логов размазаны ровным слоем по примерно всем тестам. Гонять все тесты как есть - очень дорого. Придется проводить много функциональных проверок, причем с точки зрения проверки именно логирования значительная часть этих проверок будет дублировать друг друга. Будет сложно искать пробелы - что мы НЕ проверили в логах и какие функциональные тесты покрывают именно эти пробелы. То есть по сути надо будет полностью продумать тестовое покрытие для логирования, сделать черновик этого покрытия, потом как-то сматчить функциональные тесты на этот черновик… Решать эту задачу "в лоб" довольно долго и мучительно.
Что с этими проблемами делать, как решать?
Да просто давайте уберем логи из тестов! С вас пять тыщ (с)
Шутка. Над решением я еще думаю, но кое-какие идеи есть, я ими обязательно поделюсь в следующем посте.
Если принят процесс, по которому тестировщики пишут тесты для выполнения людьми, а команда автоматизаторов потом их автоматизирует - функциональный тест с кусками логов отправляется на автоматизацию и создает дополнительную работу, которая потенциально не приносит ценности.
А что бы мне хотелось: опять же, не делать лишнюю работу: автоматизировать то, что действительно стоит автоматизировать, и не автоматизировать лишнего.
Проблема 5: Очень сложно сфокусированно протестировать именно логирование.
Например: решили улучшить логирование, для чего начали использовать Кибану. Чтобы логи можно было смотреть через Кибану, логи должны быть в одном формате. В настоящее время они в другом формате. То есть нужно переделать логирование так, чтобы оно производилось в другом формате.
Логирование каждого компонента переписывается ручками разных людей и тестируется отдельно. Каждая область логирования может сломаться более-менее независимо от другой.Проверки логов размазаны ровным слоем по примерно всем тестам. Гонять все тесты как есть - очень дорого. Придется проводить много функциональных проверок, причем с точки зрения проверки именно логирования значительная часть этих проверок будет дублировать друг друга. Будет сложно искать пробелы - что мы НЕ проверили в логах и какие функциональные тесты покрывают именно эти пробелы. То есть по сути надо будет полностью продумать тестовое покрытие для логирования, сделать черновик этого покрытия, потом как-то сматчить функциональные тесты на этот черновик… Решать эту задачу "в лоб" довольно долго и мучительно.
Что с этими проблемами делать, как решать?
Да просто давайте уберем логи из тестов! С вас пять тыщ (с)
Шутка. Над решением я еще думаю, но кое-какие идеи есть, я ими обязательно поделюсь в следующем посте.
🌟 Итак, тесты по логированию (big picture)
Что точно не хочу делать:
- тестировать логирование, когда это не надо (например, тестировать его по умолчанию для каждого релиза, особенно в рамках смоук тестирования)
- тестировать функциональность библиотеки логирования
Что хочу делать:
- тестировать, что нужная нам информация залогирована
- тестировать это недорого (не прогонять 100500 функциональных тестов, чтобы проверить логи)
Какое решение вижу:
- вынести проверки логирования в отдельные тест-кейсы
- убирать или добавлять их в план в зависимости от рисков возникновения проблем с логированием
Какие тесты я бы прогоняла в разных контекстах:
Контекст 1: Разработка новой фичи
- функциональные тесты: да
- тесты на логирование: да
Контекст 2: Фича уже в продакшен (активная работа над ней закончена)
- функциональные тесты: да
- тесты на логирование: нет
Контекст 3: Фича меняется (изменения функциональности, рефакторинг, что-то еще)
- функциональные тесты: да
- тесты на логирование: да
Контекст 4: Библиотека логирования существенно меняется (например, переходим на радикально другую версию библиотеки)
- функциональные тесты: нет
- тесты на логирование: да
Контекст 5: Переходим на другую библиотеку логирования (или интегрируемся с сервисом логирования, или что-то в этом роде)
- функциональные тесты: нет
- тесты на логирование: да
Позже напишу про дизайн конкретных тестов.
Что точно не хочу делать:
- тестировать логирование, когда это не надо (например, тестировать его по умолчанию для каждого релиза, особенно в рамках смоук тестирования)
- тестировать функциональность библиотеки логирования
Что хочу делать:
- тестировать, что нужная нам информация залогирована
- тестировать это недорого (не прогонять 100500 функциональных тестов, чтобы проверить логи)
Какое решение вижу:
- вынести проверки логирования в отдельные тест-кейсы
- убирать или добавлять их в план в зависимости от рисков возникновения проблем с логированием
Какие тесты я бы прогоняла в разных контекстах:
Контекст 1: Разработка новой фичи
- функциональные тесты: да
- тесты на логирование: да
Контекст 2: Фича уже в продакшен (активная работа над ней закончена)
- функциональные тесты: да
- тесты на логирование: нет
Контекст 3: Фича меняется (изменения функциональности, рефакторинг, что-то еще)
- функциональные тесты: да
- тесты на логирование: да
Контекст 4: Библиотека логирования существенно меняется (например, переходим на радикально другую версию библиотеки)
- функциональные тесты: нет
- тесты на логирование: да
Контекст 5: Переходим на другую библиотеку логирования (или интегрируемся с сервисом логирования, или что-то в этом роде)
- функциональные тесты: нет
- тесты на логирование: да
Позже напишу про дизайн конкретных тестов.
К вопросу о лишних словах.
Я знаю одного человека, который знает одного человека...
...который запустил поиск по тестам в Jira по слову "успешно" и нашел примерно 2700 тестов.
То есть в тестовой документации есть минимум 2700 слов, которые совершенно точно не приносят никакой пользы.
Только засоряют пространство.
Я знаю одного человека, который знает одного человека...
...который запустил поиск по тестам в Jira по слову "успешно" и нашел примерно 2700 тестов.
То есть в тестовой документации есть минимум 2700 слов, которые совершенно точно не приносят никакой пользы.
Только засоряют пространство.
Скоро стартует очередной сезон Podlodka Team Lead Crew (анонс будет ниже). Для читательниц и читателей канала действует промокод tl_crew_13_nFLCPm (суммируется со скидкой для ранних пташек).
Также у меня есть две проходки. Чтобы получить проходку, напишите мне в личку о своей мотивации идти на конференцию, выдам проходки тем, чья мотивация мне больше понравится. УПД решение приму в среду в 22:00 EEST/MSK
Также у меня есть две проходки. Чтобы получить проходку, напишите мне в личку о своей мотивации идти на конференцию, выдам проходки тем, чья мотивация мне больше понравится. УПД решение приму в среду в 22:00 EEST/MSK
(По мотивам обсуждения презентации коллеги)
Darling, you got to let me know
Should I test or should I no?
If you say the ticket's mine
I'll be testing till the end of time
So you got to let me know
Should I test, or should I no?
UPD:
Should I test, or should I no?
Should I test, or should I no?
If I no, there will be trouble
And if I test, it will be double
So come on and let me know
Darling, you got to let me know
Should I test or should I no?
If you say the ticket's mine
I'll be testing till the end of time
So you got to let me know
Should I test, or should I no?
UPD:
Should I test, or should I no?
Should I test, or should I no?
If I no, there will be trouble
And if I test, it will be double
So come on and let me know
Помимо промокода, у меня есть две проходки на конференцию. Если хотите получить проходку - напишите, пожалуйста, мне в личку и расскажите, что вас мотивирует пойти на конференцию.
Отдам проходку той (или тому), чья мотивация мне больше понравится.
УПД: приму решение вечером в среду.
УПД 2: решила отдать проходки @justjuju и @snezhana_qa)
Отдам проходку той (или тому), чья мотивация мне больше понравится.
УПД: приму решение вечером в среду.
УПД 2: решила отдать проходки @justjuju и @snezhana_qa)
Тут мог бы быть длинный список тулзов, но не будет
Вместо этого принесу нечто другое - идеи, с которыми столкнулась на курсе Rapid Software Testing Explored (автор и тренер: James Bach) и в книге Lessons Learned in Software Testing: A Context-Driven Approach (Cem Kaner, James Bach, Bret Pettichord).
Итак, над чем можно поработать?
Собственно, над процессами думания.
Первое, что должно помочь в этом - это эпистемология. Это про то, как думать хорошо и использовать критическое мышление.
Эпистемология в тестировании это про то, как мы
- понимаем, что что-то работает хорошо
- определяем критерии, которые нам скажут, что что-то работает НЕ хорошо
- принимаем решение, что протестировали достаточно
Это про сбор доказательств (и их критическое осмысление), про обоснованные выводы, про использование различных форм логики. Про обоснование убеждений и аргументацию. Про распространенные заблуждения. Про принятие хороших решений:)
Второе, что авторы рекомендуют изучать - когнитивная психология.
Это про то, как мы думаем.
В контексте тестирования это, например, про то, как мы упрощаем принятие решений с помощью стереотипов и предубеждений, как думаем под давлением, как осмысляем сложные идеи и т. п.
А еще авторы обращают внимание на основные категории мышления, которые помогают нам тестировать хорошо.
1️⃣ Техническое
2️⃣ Практическое
3️⃣ Критическое
4️⃣ Творческое
У меня нехорошее сильное впечатление (с), что при обучении тестировщиков есть явный упор на первые два пункта, менее явный - на критическое мышление, а творческая составляющая как будто остается совсем невидимой. При этом качество тестирования напрямую зависит именно от нее. Это не что-то nice to have! Если мы не можем вообразить проблемы, которые потенциально могут возникнуть, не можем представить себе риски, которые могут сработать - мы не можем покрыть эти риски тестами.
Что еще подчеркивают авторы?
Тестирование - это гораздо больше про работу с неявным (implicit) знанием, чем про работу с явным (explicit).
Примечание: мне кажется, одна из самых больших иллюзий начинающих тестировщиков - то, что кто-то (например, Очень Умный Аналитик) напишет требования, а тестировщики возьмут эти требования и будут по ним тестировать.
Из этой идеи вытекают другие:
- если в требовании чего-то нет - это как будто на стороне того, кто эти требования написал
- для тестирования нужно техническое и практическое мышление (чтобы тестировать, следуя подготовленным указаниям)
На уровне junior специалиста работа в действительно похожа на что-то в этом роде.
Но, скорее всего, чем дальше - тем больше будет работы с неявными знаниями и меньше - с явными. Неопределенности будет больше, чем определенности, эвристик - больше, чем инструкций, и ползунок все больше и больше будет смещаться в сторону творческого мышления.
Принесу еще пару ссылок, которыми со мной поделилась Оля Артемьева:
➡️ Круговорот неявного и явного знания в природе. Нельзя так просто взять и зафиксировать знания (превратив неявное в явное). Генерация неявного знания - постоянный процесс, и если хочется это знание фиксировать, придется систематически прилагать усилия по экстериоризации новых неявных знаний.
➡️ Получение неявного знания через общение с пользователями и наблюдение.
Please open Telegram to view this post
VIEW IN TELEGRAM