Есть ещё один важный для меня пункт — от души поблагодарить людей, с которыми работала, за то, что мы делали вместе. Потому что это и правда было круто, но дальше тоже будет замечательно — и у меня, и у вас.
Спасибо, Команда 💙
Спасибо, Команда 💙
🔥1
Про тестовую отчетность
Тестовая отчетность — один из так называемых артефактов тестирования. Когда я говорю со студентами курса "Тестировщик", лекции на котором читаю, о документации, то всегда стараюсь донести, что артефакты — не просто скучная формальность, а важный инструмент работы команды, который повышает прозрачность процессов, помогает оценить проделанную работу и, особенно на начальных этапах, помогает тестироващикам понять свой комфортный темп.
Более того, конкретно отчеты о тестировании — это возможность зафиксировать какие-то проблемы или договоренности, а ещё сохранить итоги работы для ретроспективного взгляда и анализа спустя некоторое время (как известно, вернуться к старым вопросам полезно, потому что спустя время критическое мышление может помочь взглянуть на свою же работу с новой стороны).
Как тимлидам 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.
Тестовая отчетность — один из так называемых артефактов тестирования. Когда я говорю со студентами курса "Тестировщик", лекции на котором читаю, о документации, то всегда стараюсь донести, что артефакты — не просто скучная формальность, а важный инструмент работы команды, который повышает прозрачность процессов, помогает оценить проделанную работу и, особенно на начальных этапах, помогает тестироващикам понять свой комфортный темп.
Более того, конкретно отчеты о тестировании — это возможность зафиксировать какие-то проблемы или договоренности, а ещё сохранить итоги работы для ретроспективного взгляда и анализа спустя некоторое время (как известно, вернуться к старым вопросам полезно, потому что спустя время критическое мышление может помочь взглянуть на свою же работу с новой стороны).
Как тимлидам 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.
Forwarded from Shoo and Endless Agony (Shoo)
Задачу нормально поставьте.
Многие разработчики и тестировщики очень не любят работать с плохо проработанными задачами.
Неустанно повторяя древнюю мантру про "нет ТЗ - ..." они выступают на конференциях с рассказами о том,
как классно у них получилось перевоспитать аналитиков и менеджеров, что б им приносили хорошо проработанные задачи.
Или наоборот делятся болью в профессиональных чатиках мол "бардак, прилетают задачи без описания".
Меня эти дискуссии неизменно печалят.
В основном потому, что многие люди действительно считают, что вот так - это хорошо, а по другому - это плохо.
Реальность, конечно, немножко сложнее.
Тут есть несколько моментов, о которых надо помнить.
Первый:
Каждый раз, когда вы хотите, что бы вам принесли идеально проработанную задачу - вы просто перекладываете ответственность.
Вы хотите упростить себе жизнь, не ломая голову над тем, что от вас хотят, избежать всех этих уточняющих вопросов и, заодно, минимизировать риски.
Что бы если к вам придут и спросят "почему это работает вот так?" можно было просто сказать "я сделал как в ТЗ было написано".
В желании упростить себе жизнь нет ничего плохого, но надо понимать, что в данном случае вы делаете это в ущерб команде и продукту.
Потому что ответственность, риски и проблемы вы снимаете с себя, но перекидываете на кого-то другого.
Второй:
Каждый раз, требуя детальное ТЗ вы сужаете собственное пространство решений.
Сначала люди жалуются, что хотят идеально проработанные задачи, потом сокрушаются, что их работа - это бездумное перекладывание джейсонов между моделями данных.
Но если задуматься, то вы самостоятельно загнали себя в ситуацию, когда у вас нет пространства для творчества и свободы выбора.
Потому что свобода выбора напрямую связана с ответственностью за принимаемые решение, от которой вы так старательно открещивались, требуя идеальной проработки задач.
Третий:
Способность (и готовность) работать в условиях неявных требований - это конкурентное преимущество.
Даже при хорошо отлаженных процессах требования всегда будут неполными.
Задачи без описания и definition of done "Работает хорошо" будут периодически появляться.
Вопрос только в том, какую цепочку проработки они будут проходить прежде, чем окажутся в продакшене.
Переоткрывая задачу в формате "требования опишите нормально" вы просто докидываете ещё одно звено в эту цепочку и увеличиваете time to market.
Инженеры, способные получить слабо формализованную задачу, взять за неё ответственность и выдать результат ожидаемого уровня качества - на вес золота.
Они стоят гораздо дороже и ценятся компаниями гораздо выше, чем инженеры, просто транслирующие ТЗ в код.
Помните, что разные подходы работают для разных команд.
Я много работал с ребятами, которым можно было поставить задачу в формате "сделай вот такую вот фигню" и быть уверенным, что человек её сделает хорошо.
За счёт технической экспертизы, за счёт погружения в продукт, за счёт взаимопонимания и cultural fit, за счёт наличия софт-скиллов и способности вовремя задать вопросы, если возникают проблемы.
Но, этот подход плохо масштабируется.
Собирать такие команды долго и дорого.
Классический подход "вот вам супер-подробное ТЗ, превратите это в код" - обратная крайность.
Это стандартные проектные рельсы, которые легко масштабировать и можно получать прогнозируемый результат.
Минус в том, что результат - средненький, скорость - тоже.
Создать что-то действительно классное с таким подходом довольно сложно.
И, конечно же, есть целый спектр промежуточных состояний.
Все они по разному подходят для разных команд, разных продуктов и разных этапов жизни компании.
В этом, собственно, и основной поинт, который хотелось бы донести:
Детально проработанные задачи могут нести за собой не меньший набор проблем и ограничений, чем задачи, прилетающие без описания вообще.
Поэтому, каждый раз, когда слышите истории успеха и сладкие речи про идеально проработанные ТЗ и вот это всё - задавайтесь вопросом, а действительно ли это плюс?
Многие разработчики и тестировщики очень не любят работать с плохо проработанными задачами.
Неустанно повторяя древнюю мантру про "нет ТЗ - ..." они выступают на конференциях с рассказами о том,
как классно у них получилось перевоспитать аналитиков и менеджеров, что б им приносили хорошо проработанные задачи.
Или наоборот делятся болью в профессиональных чатиках мол "бардак, прилетают задачи без описания".
Меня эти дискуссии неизменно печалят.
В основном потому, что многие люди действительно считают, что вот так - это хорошо, а по другому - это плохо.
Реальность, конечно, немножко сложнее.
Тут есть несколько моментов, о которых надо помнить.
Первый:
Каждый раз, когда вы хотите, что бы вам принесли идеально проработанную задачу - вы просто перекладываете ответственность.
Вы хотите упростить себе жизнь, не ломая голову над тем, что от вас хотят, избежать всех этих уточняющих вопросов и, заодно, минимизировать риски.
Что бы если к вам придут и спросят "почему это работает вот так?" можно было просто сказать "я сделал как в ТЗ было написано".
В желании упростить себе жизнь нет ничего плохого, но надо понимать, что в данном случае вы делаете это в ущерб команде и продукту.
Потому что ответственность, риски и проблемы вы снимаете с себя, но перекидываете на кого-то другого.
Второй:
Каждый раз, требуя детальное ТЗ вы сужаете собственное пространство решений.
Сначала люди жалуются, что хотят идеально проработанные задачи, потом сокрушаются, что их работа - это бездумное перекладывание джейсонов между моделями данных.
Но если задуматься, то вы самостоятельно загнали себя в ситуацию, когда у вас нет пространства для творчества и свободы выбора.
Потому что свобода выбора напрямую связана с ответственностью за принимаемые решение, от которой вы так старательно открещивались, требуя идеальной проработки задач.
Третий:
Способность (и готовность) работать в условиях неявных требований - это конкурентное преимущество.
Даже при хорошо отлаженных процессах требования всегда будут неполными.
Задачи без описания и definition of done "Работает хорошо" будут периодически появляться.
Вопрос только в том, какую цепочку проработки они будут проходить прежде, чем окажутся в продакшене.
Переоткрывая задачу в формате "требования опишите нормально" вы просто докидываете ещё одно звено в эту цепочку и увеличиваете time to market.
Инженеры, способные получить слабо формализованную задачу, взять за неё ответственность и выдать результат ожидаемого уровня качества - на вес золота.
Они стоят гораздо дороже и ценятся компаниями гораздо выше, чем инженеры, просто транслирующие ТЗ в код.
Помните, что разные подходы работают для разных команд.
Я много работал с ребятами, которым можно было поставить задачу в формате "сделай вот такую вот фигню" и быть уверенным, что человек её сделает хорошо.
За счёт технической экспертизы, за счёт погружения в продукт, за счёт взаимопонимания и cultural fit, за счёт наличия софт-скиллов и способности вовремя задать вопросы, если возникают проблемы.
Но, этот подход плохо масштабируется.
Собирать такие команды долго и дорого.
Классический подход "вот вам супер-подробное ТЗ, превратите это в код" - обратная крайность.
Это стандартные проектные рельсы, которые легко масштабировать и можно получать прогнозируемый результат.
Минус в том, что результат - средненький, скорость - тоже.
Создать что-то действительно классное с таким подходом довольно сложно.
И, конечно же, есть целый спектр промежуточных состояний.
Все они по разному подходят для разных команд, разных продуктов и разных этапов жизни компании.
В этом, собственно, и основной поинт, который хотелось бы донести:
Детально проработанные задачи могут нести за собой не меньший набор проблем и ограничений, чем задачи, прилетающие без описания вообще.
Поэтому, каждый раз, когда слышите истории успеха и сладкие речи про идеально проработанные ТЗ и вот это всё - задавайтесь вопросом, а действительно ли это плюс?
Бесконечно можно смотреть на 3 вещи: как горит огонь, как течет вода, и как я в очередной раз рассказываю о том, почему тестировщик — больше, чем просто "кликать кнопки", даже на начальном уровне.
Статья родилась на основе моих соображений после прочтения поста в Т—Ж о входе в IT.
https://telegra.ph/Testirovshchik-prosto-klikaet-07-22
Статья родилась на основе моих соображений после прочтения поста в Т—Ж о входе в IT.
https://telegra.ph/Testirovshchik-prosto-klikaet-07-22
Telegraph
Тестировщик просто "кликает"?
На одном популярном ресурсе натолкнулась на статью про вход в IT, где QA-инженеров (никогда такого не было, и вот опять) характеризуют как «людей, которые прокликивают кнопочки», а «если люди умные, то они учатся автоматизировать, и кнопочки за них прокликивает…
Forwarded from Saturday Night Hack
Как ставить задачи джунам?
Самый быстрый ответ на этот вопрос: максимально детально. Но давайте копнём глубже.
Я как-то писал, что рост сотрудников можно оценивать по количеству конкретных задач, которые им ставят. Недавно я понял, что кроме метрики количества задач, есть ещё обратная – количество принимаемых решений. Так джуну ставят много четких указаний и он принимает мало решений, а чем «синьорней» он становится – тем больше он принимает решений сам и меньше выполняет конкретных задач, причем чем дальше – тем выше качество этих принимаемых решений. Он может сам находить проблемы, реализовывать решения (или раздавать задачи другим).
С такой моделью в голове ответить на вопрос из заголовка можно уже немного иначе: задачи джуну нужно ставить так, чтобы он быстрее начал сам принимать решения, причем чтобы качество этих решений вас устраивало. Как помочь?
- Покажите проблему, а не только решение. Так будет «тренироваться нейронка», которая в дальнейшем для подобных задач будет находить подобные же решения.
- Поясните решение и ответьте на вопрос «почему?». Не «добавь индекс в базу данных», а «добавь индекс, иначе будет работать медленно. Можешь локально попробовать сделать то-то – увидишь, что всё тормозит. Кстати,
- Расширьте его кругозор, делитесь опытом (и не только своим). Вместо коммента на код-ревью «добавь контекста и переименуй переменную из
- Оставьте нерешенную проблему. Легко привыкнуть к тому, что в задаче приняты все решения и нужно просто «поработать руками». Но для роста нужно обратное и хорошо бы сразу тренировать «мышцу» принятия решений, поэтому оставьте место, где этим можно заняться
А есть ещё мнения по этому поводу?
Мы договорились с Евгением Антоновым, автором канала Тимлид Очевидность, написать посты на эту тему. Его вариант я ещё не видел, но знаю, что он будет тут – го читать.
Самый быстрый ответ на этот вопрос: максимально детально. Но давайте копнём глубже.
Я как-то писал, что рост сотрудников можно оценивать по количеству конкретных задач, которые им ставят. Недавно я понял, что кроме метрики количества задач, есть ещё обратная – количество принимаемых решений. Так джуну ставят много четких указаний и он принимает мало решений, а чем «синьорней» он становится – тем больше он принимает решений сам и меньше выполняет конкретных задач, причем чем дальше – тем выше качество этих принимаемых решений. Он может сам находить проблемы, реализовывать решения (или раздавать задачи другим).
С такой моделью в голове ответить на вопрос из заголовка можно уже немного иначе: задачи джуну нужно ставить так, чтобы он быстрее начал сам принимать решения, причем чтобы качество этих решений вас устраивало. Как помочь?
- Покажите проблему, а не только решение. Так будет «тренироваться нейронка», которая в дальнейшем для подобных задач будет находить подобные же решения.
- Поясните решение и ответьте на вопрос «почему?». Не «добавь индекс в базу данных», а «добавь индекс, иначе будет работать медленно. Можешь локально попробовать сделать то-то – увидишь, что всё тормозит. Кстати,
explain analyze до/после поможет понять детали»- Расширьте его кругозор, делитесь опытом (и не только своим). Вместо коммента на код-ревью «добавь контекста и переименуй переменную из
users в `availableUsers`» можно написать тоже самое + добавить «Кстати, про именование можешь посмотреть классный доклад или почитать мини-книжку Naming Things!».- Оставьте нерешенную проблему. Легко привыкнуть к тому, что в задаче приняты все решения и нужно просто «поработать руками». Но для роста нужно обратное и хорошо бы сразу тренировать «мышцу» принятия решений, поэтому оставьте место, где этим можно заняться
А есть ещё мнения по этому поводу?
Мы договорились с Евгением Антоновым, автором канала Тимлид Очевидность, написать посты на эту тему. Его вариант я ещё не видел, но знаю, что он будет тут – го читать.
Telegram
Saturday Night Hack
💹 Количество конкретных задач, как показатель роста
О многих IT-компании ходят легенды, что там не ставят задачи сотрудникам. Например, в Netflix сотрудника закидывают в компанию и ничего не требуют (но потом могут уволить, если не будет результатов). Джобс…
О многих IT-компании ходят легенды, что там не ставят задачи сотрудникам. Например, в Netflix сотрудника закидывают в компанию и ничего не требуют (но потом могут уволить, если не будет результатов). Джобс…
Отличный пост про оценку компетентности джуниора. Я полностью согласна с позицией авторов — чем больше опыта, тем больше самостоятельного принятия решений и ответственности за них.
Важно, что под "принятием решения" я имею в виду не упертое "будем делать так, и всё тут", а именно что умение задать правильные вопросы, учесть мнение тех, на кого эта задача напрямую повлияет, и выбрать оптимальный исход.
Мне кажется, именно умение взглянуть на ситуацию с разных сторон, учесть риски и ограничения и определяет существенное различие между опытным и начинающим специалистом, потому что второй пока умеет выполнять задачи только по заданной модели. И это ещё одно доказательство того, насколько же многогранная штука наша профессиональная идентичность, и насколько же формальны "грейды": можно спокойно принимать решения в одной области и не уметь действовать за рамками представленной модели в другой.
Важно, что под "принятием решения" я имею в виду не упертое "будем делать так, и всё тут", а именно что умение задать правильные вопросы, учесть мнение тех, на кого эта задача напрямую повлияет, и выбрать оптимальный исход.
Мне кажется, именно умение взглянуть на ситуацию с разных сторон, учесть риски и ограничения и определяет существенное различие между опытным и начинающим специалистом, потому что второй пока умеет выполнять задачи только по заданной модели. И это ещё одно доказательство того, насколько же многогранная штука наша профессиональная идентичность, и насколько же формальны "грейды": можно спокойно принимать решения в одной области и не уметь действовать за рамками представленной модели в другой.
Обновила описание канала, добавив туда ссылку на GetMentor — да, теперь меня можно попросить стать вашим ментором на раз или на длительное время.
Небесплатно, потому что моё время стоит денег, однако стоимость пока не выставила — буду смотреть, исходя из длительности и сложности взаимодействия.
Кроме того, я пока в процессе формирования стоимости своей работы в качестве индивидуальной наставницы, и первые встречи планирую провести за донат.
Из других новостей: я воооот на столечко 🤏🏼 близка к тому, чтобы стать преподавательницей ещё одного курса. Буду рассказывать, что и как, а пока, чтобы не скучать, поделюсь парой ссылок, которые в последнее время часто открыты в моем браузере — раз уж мы заговорили про обучение 🙂
📖 https://devqa.io/ — типа Хабра, но англоязычного и суховатого :) В принципе, там довольно много интересных статей, в том числе с примерами кода а-ля "стартуй свой первый проект". Поковыряться на досуге — самое то.
📖 https://codernet.ru/books/ — онлайн-портал с книгами, видео и статьями. Правда, раздел Books вызывает вопросы: я вполне допускаю, что это пиратство (хотя, конечно, соблазн скачать все и сразу велик). В описании заявлено, что всё это для программиста, но не верьте: QA тоже найдет там много крутой информации.
📖 https://www.freecodecamp.org/ — бесплатный англоязычный портал с курсами на разных ЯП. К слову, там есть раздел QA, в который очень приятно заглянуть: там есть и тренировочные проекты, на которые надо писать автотесты, и курсы, и сертификация — можно пройти курсы и получить красивое подтверждение (я не уверена, что сейчас можно кого-то этим впечатлить, но некоторых такие вещи мотивируют — приятно же!).
Также там есть раздел с подготовкой к интервью — задачки, челленджи, вот это всё.
На этой ноте желаю всем продуктивной недели 💪🏼
Небесплатно, потому что моё время стоит денег, однако стоимость пока не выставила — буду смотреть, исходя из длительности и сложности взаимодействия.
Кроме того, я пока в процессе формирования стоимости своей работы в качестве индивидуальной наставницы, и первые встречи планирую провести за донат.
Из других новостей: я воооот на столечко 🤏🏼 близка к тому, чтобы стать преподавательницей ещё одного курса. Буду рассказывать, что и как, а пока, чтобы не скучать, поделюсь парой ссылок, которые в последнее время часто открыты в моем браузере — раз уж мы заговорили про обучение 🙂
📖 https://devqa.io/ — типа Хабра, но англоязычного и суховатого :) В принципе, там довольно много интересных статей, в том числе с примерами кода а-ля "стартуй свой первый проект". Поковыряться на досуге — самое то.
📖 https://codernet.ru/books/ — онлайн-портал с книгами, видео и статьями. Правда, раздел Books вызывает вопросы: я вполне допускаю, что это пиратство (хотя, конечно, соблазн скачать все и сразу велик). В описании заявлено, что всё это для программиста, но не верьте: QA тоже найдет там много крутой информации.
📖 https://www.freecodecamp.org/ — бесплатный англоязычный портал с курсами на разных ЯП. К слову, там есть раздел QA, в который очень приятно заглянуть: там есть и тренировочные проекты, на которые надо писать автотесты, и курсы, и сертификация — можно пройти курсы и получить красивое подтверждение (я не уверена, что сейчас можно кого-то этим впечатлить, но некоторых такие вещи мотивируют — приятно же!).
Также там есть раздел с подготовкой к интервью — задачки, челленджи, вот это всё.
На этой ноте желаю всем продуктивной недели 💪🏼
https://getmentor.dev
Анастасия Заречнева | GetMentor – открытое сообщество IT-наставников
QA engineer @ ex. VK, Semrush | GetMentor – это открытое комьюнити IT-наставников, готовых делиться своими опытом и знаниями. Наша задача – помогать людям находить ответы на свои вопросы в работе или жизни через прямой доступ к экспертизе в разговоре 1-на…
Ну всё, теперь окончательно могу поделиться обновленями и радостью — я теперь часть программного комитета ближайшего, пятого, сезона конференции Podlodka QA Crew!
Пока что не буду спойлерить ни тему, ни другие крутые штуки — всему своё время. Но, думаю, многие из нас уже успели посмотреть хотя бы один из сезонов этой конференции (а если нет — бегом смотреть! Это совершенно крутейший формат, подстроенный под онлайн, с кучей полезной информации в разных активностях — от классических докладов до лайвкодинга, круглых столов и "барного" нетворкинга), а значит, не нуждаются в отдельной рекламе — потому что по прошлому опыту помнят, что будет очень круто.
Это не первый мой опыт бытия частью ПК, однако прошлая конференция — SECR 2019, — была больше научной, чем IT-шной. Сейчас же есть отличный шанс сделать свой вклад в контент, который смотрю я, мои друзья, коллеги, приятели. Короче, догфудинг как он есть 🙂
Пока что не буду спойлерить ни тему, ни другие крутые штуки — всему своё время. Но, думаю, многие из нас уже успели посмотреть хотя бы один из сезонов этой конференции (а если нет — бегом смотреть! Это совершенно крутейший формат, подстроенный под онлайн, с кучей полезной информации в разных активностях — от классических докладов до лайвкодинга, круглых столов и "барного" нетворкинга), а значит, не нуждаются в отдельной рекламе — потому что по прошлому опыту помнят, что будет очень круто.
Это не первый мой опыт бытия частью ПК, однако прошлая конференция — SECR 2019, — была больше научной, чем IT-шной. Сейчас же есть отличный шанс сделать свой вклад в контент, который смотрю я, мои друзья, коллеги, приятели. Короче, догфудинг как он есть 🙂
podlodka.io
Онлайн-конференция Podlodka QA Crew, сезон #15
Недельное мероприятие от команды Podlodka: ежедневные интерактивные сессии в Zoom по актуальным проблемам QA-индустрии, нон-стоп общение с экспертами и звёздами индустрии, закрытое профессиональное сообщество в Telegram.
Вопросы к будущей команде
В последнее время очень часто разговаривали с друзьями и коллегами про вопросы, которые можно задать будущим коллегам на собеседовании (как правило, финальном).
Оформила свои мысли по этому поводу в пост, а в конце добавила свой личный список вопросов.
https://telegra.ph/Voprosy-k-budushchej-komande-cheklist-08-04
В последнее время очень часто разговаривали с друзьями и коллегами про вопросы, которые можно задать будущим коллегам на собеседовании (как правило, финальном).
Оформила свои мысли по этому поводу в пост, а в конце добавила свой личный список вопросов.
https://telegra.ph/Voprosy-k-budushchej-komande-cheklist-08-04
Telegraph
Вопросы к будущей команде: чеклист
– С нашей стороны это всё. Наверняка у Вас есть какие-то вопросы к команде? Эту фразу я слышала на каждом собеседовании, которое я посещала. И каждый раз я ждала её с нетерпением, – это ведь моя возможность узнать всё, о чем не пишут в вакансии, но что, несомненно…
❤1
Алгоритмы написания автотестов
Недавно в рамках менторинга мне поступил вопрос: можно ли написать пошаговый алгоритм, следуя которому команда сможет писать автотесты, даже если раньше с ними не работала? (при условии, что выбран инструмент автоматизации, и есть достаточно знаний ЯП/фреймворка/библиотеки, с которыми будет идти работа).
Я постаралась создать чек-лист, основываясь на своем опыте погружения в автоматизацию тестирования, который может быть полезен начинающим специалистам. Впрочем, многие советы я до сих пор держу на виду и следую им, прежде чем отдать тесты на код-ревью.
Написала отдельно про два случая:
🔹 API-тесты
🔹 GUI-тесты
— для удобства чтения, обсуждения и навигации.
Буду рада узнать от тех, кто регулярно работает с автотестами: что бы вы добавили, что бы убрали? Какими лучшими практиками вы пользуетесь?
Недавно в рамках менторинга мне поступил вопрос: можно ли написать пошаговый алгоритм, следуя которому команда сможет писать автотесты, даже если раньше с ними не работала? (при условии, что выбран инструмент автоматизации, и есть достаточно знаний ЯП/фреймворка/библиотеки, с которыми будет идти работа).
Я постаралась создать чек-лист, основываясь на своем опыте погружения в автоматизацию тестирования, который может быть полезен начинающим специалистам. Впрочем, многие советы я до сих пор держу на виду и следую им, прежде чем отдать тесты на код-ревью.
Написала отдельно про два случая:
🔹 API-тесты
🔹 GUI-тесты
— для удобства чтения, обсуждения и навигации.
Буду рада узнать от тех, кто регулярно работает с автотестами: что бы вы добавили, что бы убрали? Какими лучшими практиками вы пользуетесь?
Немного ранее я писала и делилась радостью, что вошла в состав программного комитета нового сезона небезызвестной конференции. Пришла пора наслаждаться результатами работы :)
Итак, мы готовы анонсировать новый сезон Podlodka QA Crew — погружение начнется 13 сентября!
Во время первой недели обсудим интеграционное тестирование:
- Будем учиться тестировать интеграции внутренних и внешних сервисов;
- Узнаем лайфхаки реализации интеграционного тестирования необычных систем;
- Разберемся, как эффективно тестировать микросервисы.
Вторую неделю посвятим тестированию с ограниченными ресурсами:
- Узнаем, как бороться с легаси;
- Поймём, как наладить процессы QA в команде;
- Будем учиться строить процесс QA, в который вовлечена вся команда.
Это тот случай, когда я действительно горужсь тем, что получилось: огненная программа, классные опытные спикеры, много активностей и холиварные — в хорошем смысле — обсуждения :)
Подробности и билеты уже на сайте!
До конца недели действует скидка ⚡️
Итак, мы готовы анонсировать новый сезон Podlodka QA Crew — погружение начнется 13 сентября!
Во время первой недели обсудим интеграционное тестирование:
- Будем учиться тестировать интеграции внутренних и внешних сервисов;
- Узнаем лайфхаки реализации интеграционного тестирования необычных систем;
- Разберемся, как эффективно тестировать микросервисы.
Вторую неделю посвятим тестированию с ограниченными ресурсами:
- Узнаем, как бороться с легаси;
- Поймём, как наладить процессы QA в команде;
- Будем учиться строить процесс QA, в который вовлечена вся команда.
Это тот случай, когда я действительно горужсь тем, что получилось: огненная программа, классные опытные спикеры, много активностей и холиварные — в хорошем смысле — обсуждения :)
Подробности и билеты уже на сайте!
До конца недели действует скидка ⚡️
Внезапно спикаю на GDG Kaliningrad 25-26 сентября. Подключайтесь послушать, если есть возможность!
gdg-kld.ru
Ожидания и реальность стабилизации Selenium-тестов
<strong>Анастасия Заречнева</strong>
QA engineer, Semrush
QA engineer, Semrush
Между тем, SQA Days выставили в открытый доступ плейлист с записями 28-го сезона конференции ☺️
И я там была: рассказывала про систему автоматизации тестирования в VK и про то, как красиво (и не очень, you know, it ain't much, but it's honest work...) стабилизировать непослушные тесты для GUI.
На самой конференции доклад встретили супер позитивно. Надеюсь, и в записи он кому-то окажется полезен и интересен!
Послушать можно тут: https://youtu.be/at0GZJXZ5bc
И я там была: рассказывала про систему автоматизации тестирования в VK и про то, как красиво (и не очень, you know, it ain't much, but it's honest work...) стабилизировать непослушные тесты для GUI.
На самой конференции доклад встретили супер позитивно. Надеюсь, и в записи он кому-то окажется полезен и интересен!
Послушать можно тут: https://youtu.be/at0GZJXZ5bc
Офигенная заметка о декомпозиции больших метрик и о неочевидных «бытовых» факторах, влияющих на общий результат.
Forwarded from Saturday Night Hack
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 у вас какой?
В общем, иногда достаточно просто начать обращать внимание на то, куда уходит время – идеи о том, как ускориться придут сами. Так же полезно думать об этом, когда вы создаёте продукты и процессы для других – как вы можете ускорить и упростить для них использование вашего процесса/продукта?
Все знают про метрику 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 у вас какой?
В общем, иногда достаточно просто начать обращать внимание на то, куда уходит время – идеи о том, как ускориться придут сами. Так же полезно думать об этом, когда вы создаёте продукты и процессы для других – как вы можете ускорить и упростить для них использование вашего процесса/продукта?
Management 3.0
Delegation Poker: A Management 3.0 Game
Use Delegation Poker to clarify who’s responsible for what and to what level. This is a method where you can encourage employee engagement through controlled self-organization and clarified value and decision-making.
Forwarded from Тестирование и жизнь • про работу для живых людей (Olga Artemyeva)
Use case и тестирование требований
Хорошая статья про тестирование требований и разработку use case. Очень люблю это метод, мне он позволяет сфокусироваться на разных типах пользователей и их потребностях.
#база_тестирования
#записная_книжка
Хорошая статья про тестирование требований и разработку use case. Очень люблю это метод, мне он позволяет сфокусироваться на разных типах пользователей и их потребностях.
#база_тестирования
#записная_книжка
Хабр
Тестирование требований: как я нахожу ошибки в бизнес-логике фичи прежде, чем их закодят
Привет, Хабр. Меня зовут Ольга, я работаю в тестировании с 2013 года, специализируюсь на тест-анализе и тест-дизайне. Сегодня хочу рассказать, как при планировании тестирования сохранить фокус на...
Вроде в проде?
Однажды жизнь в лице сообщества 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 :)
Однажды жизнь в лице сообщества 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 :)
SoundCloud
Hear the world’s sounds
Explore the largest community of artists, bands, podcasters and creators of music & audio
Привет!
В последнее время в канале появились новые лица, так что предлагаю познакомиться чуть ближе 😉
Меня зовут Настя, я работаю QA-инженером (в трудовой это записано как "старший инженер по тестированию и автоматизации тестирования", хотя на лычку senior я себя очень редко ощущаю) в продуктовой компании в команде, которая занимается разработкой инструментов аналитики ключевых слов для продвижения в поисковых системах.
Моя специализация — веб. Большую часть времени я пишу автотесты (Golang + Testing plugin; Kotlin + retrofit 2 + TestNG; Kotlin + Selenide + TestNG), но кроме этого также тестирую руками, пишу тестовую документацию и с недавних пор не боюсь настраивать пайплайны в CI 🙂
Ещё я одна из создательниц сообщества QA sisters, со-ведущая подкаста "Вроде в проде", преподавательница Stepik Academy и Нетологии и авторша и лекторша курса по тестированию.
Этот канал я заводила году в 2019, потому что тяга к делению знаниями была слишком велика, а ещё я немного использовала его как "уточку" для рассуждений о работе, когда было совсем одиноко. Сейчас стараюсь писать сюда регулярно, вкидывать что-то полезное, дублирую свои выступления на митапах и конференциях и в целом довольно охотно делюсь полезностями из других каналов классных айтишниц и айтишников.
О чем можно почитать/посмотреть, если вы тут недавно:
🔹 Список тестовых песочниц, если надо на чем-то потренировать навыки тестирования
🔹 Наш с коллегой доклад про базу знаний в компании: как организовать и зачем
🔹 Моя статья про тестирование на основе моделей
🔹 Мой доклад про локаторы в вебе и их применение
🔹 Заметка про оффбоардинг
🔹 Заметка про вопросы будущей команде
🔹 Пошаговая инструкция, на что обратить внимание при сетапе автоматизации в проекте
🔹 Мой доклад про лайфхаки автотестирования UI с SQA days 28
В последнее время в канале появились новые лица, так что предлагаю познакомиться чуть ближе 😉
Меня зовут Настя, я работаю QA-инженером (в трудовой это записано как "старший инженер по тестированию и автоматизации тестирования", хотя на лычку senior я себя очень редко ощущаю) в продуктовой компании в команде, которая занимается разработкой инструментов аналитики ключевых слов для продвижения в поисковых системах.
Моя специализация — веб. Большую часть времени я пишу автотесты (Golang + Testing plugin; Kotlin + retrofit 2 + TestNG; Kotlin + Selenide + TestNG), но кроме этого также тестирую руками, пишу тестовую документацию и с недавних пор не боюсь настраивать пайплайны в CI 🙂
Ещё я одна из создательниц сообщества QA sisters, со-ведущая подкаста "Вроде в проде", преподавательница Stepik Academy и Нетологии и авторша и лекторша курса по тестированию.
Этот канал я заводила году в 2019, потому что тяга к делению знаниями была слишком велика, а ещё я немного использовала его как "уточку" для рассуждений о работе, когда было совсем одиноко. Сейчас стараюсь писать сюда регулярно, вкидывать что-то полезное, дублирую свои выступления на митапах и конференциях и в целом довольно охотно делюсь полезностями из других каналов классных айтишниц и айтишников.
О чем можно почитать/посмотреть, если вы тут недавно:
🔹 Список тестовых песочниц, если надо на чем-то потренировать навыки тестирования
🔹 Наш с коллегой доклад про базу знаний в компании: как организовать и зачем
🔹 Моя статья про тестирование на основе моделей
🔹 Мой доклад про локаторы в вебе и их применение
🔹 Заметка про оффбоардинг
🔹 Заметка про вопросы будущей команде
🔹 Пошаговая инструкция, на что обратить внимание при сетапе автоматизации в проекте
🔹 Мой доклад про лайфхаки автотестирования UI с SQA days 28
О чем рассказать на митапе?
*прочищаю горло и включаю режим бабули*
Я помню времена, когда выступление на митапе или конференции было для меня целым событием, к которому надо было готовиться несколько месяцев, а то и полгода.
Во-первых, как будто бы их тогда в целом было меньше; во-вторых, я жила в Новосибирске, и там выбор оффлайн-событий был скуднее, чем в центральной части страны; в-третьих, опыта спикерства было катастрофически мало, и приходилось компенсировать это оооочень долгой подготовкой (справедливости ради, это та же наработка часов, только не перед публикой, а перед зеркалом или друзьями).
Сейчас всё в разы проще.
Во-первых, пресловутый опыт: чем его больше, тем легче собраться и с первого раза всё сделать правильно.
Во-вторых, количество онлайн-событий кратно выросло по сравнению с ситуацией пару лет назад, а значит, появилось больше возможностей для выступления тем, кто может рассказать интересное, но стесняется выступать перед живой аудиторией.
Это накладывает и определенные сложности. Митапы в онлайн-формате чаще идут под запись — а это значит, что темы надо выбирать более тщательно: я часто мучаюсь в сомнениях, что тему, которую я выбрала, кто-то рассказал до меня (и намного лучше меня).
Итак, вас зовут выступать на митапе, — или же вы сами хотите, — но пока не знаете, о чем поведать. Или же у вас есть идеи, но вы боитесь, что будете не уникальны в своей теме.
Я бы предложила в этом случае ответить на несколько вспомогательных вопросов, которые в итоге помогут принять оптимальное решение.
А ещё я всегда рекомендую сразу же определить цель выступления: что вы хотите донести? Какую основную мысль должны вынести слушатели после вашего доклада?
Это можно сделать и в другой момент подготовки, но если всё определено заранее, проще готовить содержание выступления: цель спича всегда будет маячить впереди, как путеводная звезда, и помогать не отвлекаться от темы — и не забывать рассказывать попутно важные вещи, которые в ином случае можно упустить (потому что мы-то погружены в контекст своего доклада и может не заметить, что не донесли до слушателя какие-то ключевые детали).
А если хотите послушать классных спикеров и вдохновиться, приходите на митап в четверг, 11 ноября!
Питерское QA-сообщество проводит офлайн-митап (разумеется, со всеми мерами эпидемиологической безопасности) с интерактивной трансляцией на ютубе.
В программе доклады про регрессионное тестирование, работу с Android Auto в условиях пандемии и выступление Артема Ерошенко об организации процесса тестирования (если вы не знаете, кто такой Артём — срочно поищите! Это человек из команды, подарившей нам экосистему Allure 🙂).
Начинаем в 19:00 по Москве. Онлайн трансляция будет тут, а если вы из Питера и хотите прийти лично, то вам сюда.
*прочищаю горло и включаю режим бабули*
Я помню времена, когда выступление на митапе или конференции было для меня целым событием, к которому надо было готовиться несколько месяцев, а то и полгода.
Во-первых, как будто бы их тогда в целом было меньше; во-вторых, я жила в Новосибирске, и там выбор оффлайн-событий был скуднее, чем в центральной части страны; в-третьих, опыта спикерства было катастрофически мало, и приходилось компенсировать это оооочень долгой подготовкой (справедливости ради, это та же наработка часов, только не перед публикой, а перед зеркалом или друзьями).
Сейчас всё в разы проще.
Во-первых, пресловутый опыт: чем его больше, тем легче собраться и с первого раза всё сделать правильно.
Во-вторых, количество онлайн-событий кратно выросло по сравнению с ситуацией пару лет назад, а значит, появилось больше возможностей для выступления тем, кто может рассказать интересное, но стесняется выступать перед живой аудиторией.
Это накладывает и определенные сложности. Митапы в онлайн-формате чаще идут под запись — а это значит, что темы надо выбирать более тщательно: я часто мучаюсь в сомнениях, что тему, которую я выбрала, кто-то рассказал до меня (и намного лучше меня).
Итак, вас зовут выступать на митапе, — или же вы сами хотите, — но пока не знаете, о чем поведать. Или же у вас есть идеи, но вы боитесь, что будете не уникальны в своей теме.
Я бы предложила в этом случае ответить на несколько вспомогательных вопросов, которые в итоге помогут принять оптимальное решение.
1. Есть ли у меня идея, о чем я хочу рассказать, или же это просто желание выступить?Ответив на все эти вопросы, вы получите более полное понимание, о чем вы можете рассказать — и нужно ли вам выступление прямо сейчас. После этого можно переходить к более решительным действиям: составить план выступления, показать его друзьям или коллегам и начать работу над “мясом” вашей темы.
2. Если идеи нет: действительно ли мне нужно выступление? Что я хочу получить, побыв спикером? Как ещё я могу это получить?
3. Если идеи нет, но выступление всё равно хочется: в чем я хороша?
4. Если идеи нет, но выступление всё равно хочется: что я могла бы рассказать коллеге помладше? Коллеге из другой сферы?
5. Если идея есть, уникальна ли она?
6. Если идея есть, подкреплена ли она моим опытом?
7. Если идея есть, решает ли она какую-то проблему слушателей?
8. В каком формате я хочу донести идею?
9. Могу ли я как-то улучшить содержание доклада?
10. Сколько времени мне требуется на подготовку?
11. Есть ли у меня план?
А ещё я всегда рекомендую сразу же определить цель выступления: что вы хотите донести? Какую основную мысль должны вынести слушатели после вашего доклада?
Это можно сделать и в другой момент подготовки, но если всё определено заранее, проще готовить содержание выступления: цель спича всегда будет маячить впереди, как путеводная звезда, и помогать не отвлекаться от темы — и не забывать рассказывать попутно важные вещи, которые в ином случае можно упустить (потому что мы-то погружены в контекст своего доклада и может не заметить, что не донесли до слушателя какие-то ключевые детали).
А если хотите послушать классных спикеров и вдохновиться, приходите на митап в четверг, 11 ноября!
Питерское QA-сообщество проводит офлайн-митап (разумеется, со всеми мерами эпидемиологической безопасности) с интерактивной трансляцией на ютубе.
В программе доклады про регрессионное тестирование, работу с Android Auto в условиях пандемии и выступление Артема Ерошенко об организации процесса тестирования (если вы не знаете, кто такой Артём — срочно поищите! Это человек из команды, подарившей нам экосистему Allure 🙂).
Начинаем в 19:00 по Москве. Онлайн трансляция будет тут, а если вы из Питера и хотите прийти лично, то вам сюда.
👍1🔥1
Так как моё внерабочее время сейчас целиком и полностью занято подготовкой курса по тестированию, то, чтобы канал не пылился, спешу поделиться анонсом хорошего митапа.
Ребята из Factory Talks очень приятные: они делают некоммерческие митапы без рекламы и хантинга. Когда-то я и сама подобным занималась! И, честно говоря, надеюсь вернуться к такому движу в будущем, — а пока с радостью слушаю коллег, и вас зову с собой ☺️
Программа:
🧐 19:05 Как понять хороший ли я наставник для стажера? / Станислав Яковлев, Юла
📚 QA Team Lead Станислав Яковлев расскажет о том, когда пора нанимать стажера и как погружать его в работу тестировщика, а также по каким параметрам оценивать, насколько ты хорош в качестве наставника.
🧐 19:30 Чудаки в IT и как с этим жить / Василий Кирнос, Авито (Товары)
📚 QA-инженер с опытом работы более 10 лет Василий Кирнос поделится кейсом о том, как менять жизнь, выбирая работу с теми, кто тебе нравится.
Начало в 19.00 по московскому времени.
Уведомление о трансляции можно поставить здесь.
Ребята из Factory Talks очень приятные: они делают некоммерческие митапы без рекламы и хантинга. Когда-то я и сама подобным занималась! И, честно говоря, надеюсь вернуться к такому движу в будущем, — а пока с радостью слушаю коллег, и вас зову с собой ☺️
Программа:
🧐 19:05 Как понять хороший ли я наставник для стажера? / Станислав Яковлев, Юла
📚 QA Team Lead Станислав Яковлев расскажет о том, когда пора нанимать стажера и как погружать его в работу тестировщика, а также по каким параметрам оценивать, насколько ты хорош в качестве наставника.
🧐 19:30 Чудаки в IT и как с этим жить / Василий Кирнос, Авито (Товары)
📚 QA-инженер с опытом работы более 10 лет Василий Кирнос поделится кейсом о том, как менять жизнь, выбирая работу с теми, кто тебе нравится.
Начало в 19.00 по московскому времени.
Уведомление о трансляции можно поставить здесь.