#общее #саморазвитие #рабочийпроцесс
Сегодня хочу быть краткой, поэтому разберем локальный, но важный вопрос: учиться (имеется в виду развиваться по своей профессии) прямо в рабочее время — это нормально?
Если совсем коротко: да, это нормально 🤓
Немного разверну свою мысль. Когда и при каких обстоятельствах это нормально и даже круто:
• Если в работе есть простои (что само по себе очень круто). Во время этих простоев можно заниматься разными полезными вещами (подробнее о том, чем заниматься во время простоев и почему это круто напишу в одном из постов, не переключайтесь 🙃), в т.ч. и саморазвитием.
• Когда есть договоренность об этом с руководителем. «Как это?» - спросишь ты. При хорошем процессе у тебя с твоим лидом/менеджером должна быть договоренность о периодических тет-а-тетах. Это могут быть регулярные встречи, а могут быть встречи «по запросу». Вот на такой встрече ты озвучиваешь лиду свою потребность в саморазвитии (хочу пройти курс N или хочу изучить тему M или еще что-то) и спрашиваешь, будет ли ок, если ты будешь заниматься этим саморазвитием в рабочее время (всё-таки вопрос то рабочий). Конечно, это не означает, что ты вместо работы теперь будешь только учиться. Нет! Можно договориться о, например, часе в день на учёбу. Или о том, что будешь учиться в периоды затишья между задачами, если в вашей команде они достаточно регулярны. Главное озвучить, что это не будет во вред проекту. Что если будет горящая задача ты будешь заниматься задачей, а не учебой посреди пожара 🧑🚒🚒
Тут, конечно, важный момент: если у тебя на работе пожары – обыденность, то договариваться надо о том самом «часе в день» несмотря на пожары ☝️
Я, как лид, только приветствую желание сотрудников развиваться и поощряю это стремление. Помогаю чем могу.
Конечно, твой лид может быть не с такими взглядами, но, я считаю, что договориться можно почти всегда. Главное найти правильный подход и обосновать своё стремление. Как пример: «Я научусь делать N и внедрю это у нас на проекте, будет круто и удобно!» 😇
Делитесь в комментах что думаете по этому поводу. Удаётся/удавалось ли вам учиться в рабочее время. Обсуждали ли вы это с руководителем. И что в итоге – получилось или забросили? 🤔
Сегодня хочу быть краткой, поэтому разберем локальный, но важный вопрос: учиться (имеется в виду развиваться по своей профессии) прямо в рабочее время — это нормально?
Если совсем коротко: да, это нормально 🤓
Немного разверну свою мысль. Когда и при каких обстоятельствах это нормально и даже круто:
• Если в работе есть простои (что само по себе очень круто). Во время этих простоев можно заниматься разными полезными вещами (подробнее о том, чем заниматься во время простоев и почему это круто напишу в одном из постов, не переключайтесь 🙃), в т.ч. и саморазвитием.
• Когда есть договоренность об этом с руководителем. «Как это?» - спросишь ты. При хорошем процессе у тебя с твоим лидом/менеджером должна быть договоренность о периодических тет-а-тетах. Это могут быть регулярные встречи, а могут быть встречи «по запросу». Вот на такой встрече ты озвучиваешь лиду свою потребность в саморазвитии (хочу пройти курс N или хочу изучить тему M или еще что-то) и спрашиваешь, будет ли ок, если ты будешь заниматься этим саморазвитием в рабочее время (всё-таки вопрос то рабочий). Конечно, это не означает, что ты вместо работы теперь будешь только учиться. Нет! Можно договориться о, например, часе в день на учёбу. Или о том, что будешь учиться в периоды затишья между задачами, если в вашей команде они достаточно регулярны. Главное озвучить, что это не будет во вред проекту. Что если будет горящая задача ты будешь заниматься задачей, а не учебой посреди пожара 🧑🚒🚒
Тут, конечно, важный момент: если у тебя на работе пожары – обыденность, то договариваться надо о том самом «часе в день» несмотря на пожары ☝️
Я, как лид, только приветствую желание сотрудников развиваться и поощряю это стремление. Помогаю чем могу.
Конечно, твой лид может быть не с такими взглядами, но, я считаю, что договориться можно почти всегда. Главное найти правильный подход и обосновать своё стремление. Как пример: «Я научусь делать N и внедрю это у нас на проекте, будет круто и удобно!» 😇
Делитесь в комментах что думаете по этому поводу. Удаётся/удавалось ли вам учиться в рабочее время. Обсуждали ли вы это с руководителем. И что в итоге – получилось или забросили? 🤔
#общее #рабочийпроцесс
Cегодня поднимем тему простоев в работе 👻
Классическая ситуация: команда работает по скраму, спринт длится 2 или 3 недели, в начале спринта разработчики кодят в поте лица, а тестировщики… 🤷♀️
Опытные тестировщики знают, что полезного можно сделать в это прекрасное «свободное время». А у начинающих тестировщиков происходит паника. Потому что кажется, что «я ничего не делаю, меня уволят, я в команде лишний/лишняя». Знакомая ситуация? Тогда читай дальше!
На самом деле, периодические простои в работе сотрудников полезны и для команды, и для проекта, как бы парадоксально это ни звучало {здесь должна была быть ссылочка на источник, но я так и не нашла, где я про это читала. Это был то ли Дорофеев, то ли Стратоплан, то ли еще кто-то. Если знаешь – напиши, пожалуйста, в комментариях хотя бы наводку} UPD замечательная Оля Артемьева мне подсказала где можно про это почитать/посмотреть: Дорофеев - Эффективность неэффективности и Теория ограничений Голдратта, можно почитать, например, в книге Цель
Суть такая, что если плотно планировать «утилизацию ресурсов» (бррр…ужасное выражение по отношению ко времени и силам сотрудников, но его очень любят особенно в больших компаниях), то на плане всё будет выглядеть красиво и замечательно – все сотрудники заняты всё рабочее время – 40 часов в неделю, красота же! Но на деле из этого получаются обычно нехилые такие овертаймы (переработки), потому что мы люди, а не роботы, у нас редко что идёт строго по плану, обычно происходит классическая ошибка планирования, реализуются всяческие риски и т.д. и план летит ко всем чертям. При таком постоянном овертайминге сотрудники выгорают и, как итог, увольняются.
Если план подразумевает не полную загрузку, то у сотрудников периодически появляется (обожемой) свободное время (имеется в виду время без чётких задач). И это время можно посветить очень крутым вещам на пользу себе и проекту!
Тестировщик в свободное время может:
0. Попить чай/кофе, поболтать с коллегами о жизни (это можно и нужно делать вне зависимости от загрузки задачами 😅)
1. Внимательно и вдумчиво изучить документацию на готовящиеся к тестированию задачи
2. Обсудить все возникающие по документации вопросы (обычно это влечет за собой правки в документации, а правки в документации до написания кода – это просто прекрасно!)
3. Финализировав требования можно вдумчиво и аккуратно написать тестовую документацию (тест-кейсы или чек-листы), что позволит не упустить каких-то деталей, т.к. не будет спешки и суеты.
4. Можно пообщаться с продакт-овнером или лидом команды или еще кем-то, кто занимается планированием задач на команду: обсудить дальнейшие планы на следующие спринты, напроситься в командировку к пользователям или на какие-то еще активности, чтобы лучше понимать боли и радости пользователей.
5. Заняться саморазвитием (см. предыдущий пост)
6. Привести в порядок бесящий кусок регрессионных тестов (наверняка есть такой)
7. Привести в порядок базу знаний, написать туда полезных статей, поделиться с коллегами
8. Разобрать залипшие в баг-трекере баги (наверняка такие есть везде)
9. И т.д.
UPD доп. варианты из комментов 😊
10. Устроить сессии исследовательского тестирования
11. Упорядочить хаос на рабочем компьютере/на рабочем столе
Пишите в комментариях, что еще полезного и классного можно сделать в такое «свободное» время, пока задачи еще не передали в тестирование ✌️
Cегодня поднимем тему простоев в работе 👻
Классическая ситуация: команда работает по скраму, спринт длится 2 или 3 недели, в начале спринта разработчики кодят в поте лица, а тестировщики… 🤷♀️
Опытные тестировщики знают, что полезного можно сделать в это прекрасное «свободное время». А у начинающих тестировщиков происходит паника. Потому что кажется, что «я ничего не делаю, меня уволят, я в команде лишний/лишняя». Знакомая ситуация? Тогда читай дальше!
На самом деле, периодические простои в работе сотрудников полезны и для команды, и для проекта, как бы парадоксально это ни звучало {здесь должна была быть ссылочка на источник, но я так и не нашла, где я про это читала. Это был то ли Дорофеев, то ли Стратоплан, то ли еще кто-то. Если знаешь – напиши, пожалуйста, в комментариях хотя бы наводку} UPD замечательная Оля Артемьева мне подсказала где можно про это почитать/посмотреть: Дорофеев - Эффективность неэффективности и Теория ограничений Голдратта, можно почитать, например, в книге Цель
Суть такая, что если плотно планировать «утилизацию ресурсов» (бррр…ужасное выражение по отношению ко времени и силам сотрудников, но его очень любят особенно в больших компаниях), то на плане всё будет выглядеть красиво и замечательно – все сотрудники заняты всё рабочее время – 40 часов в неделю, красота же! Но на деле из этого получаются обычно нехилые такие овертаймы (переработки), потому что мы люди, а не роботы, у нас редко что идёт строго по плану, обычно происходит классическая ошибка планирования, реализуются всяческие риски и т.д. и план летит ко всем чертям. При таком постоянном овертайминге сотрудники выгорают и, как итог, увольняются.
Если план подразумевает не полную загрузку, то у сотрудников периодически появляется (обожемой) свободное время (имеется в виду время без чётких задач). И это время можно посветить очень крутым вещам на пользу себе и проекту!
Тестировщик в свободное время может:
0. Попить чай/кофе, поболтать с коллегами о жизни (это можно и нужно делать вне зависимости от загрузки задачами 😅)
1. Внимательно и вдумчиво изучить документацию на готовящиеся к тестированию задачи
2. Обсудить все возникающие по документации вопросы (обычно это влечет за собой правки в документации, а правки в документации до написания кода – это просто прекрасно!)
3. Финализировав требования можно вдумчиво и аккуратно написать тестовую документацию (тест-кейсы или чек-листы), что позволит не упустить каких-то деталей, т.к. не будет спешки и суеты.
4. Можно пообщаться с продакт-овнером или лидом команды или еще кем-то, кто занимается планированием задач на команду: обсудить дальнейшие планы на следующие спринты, напроситься в командировку к пользователям или на какие-то еще активности, чтобы лучше понимать боли и радости пользователей.
5. Заняться саморазвитием (см. предыдущий пост)
6. Привести в порядок бесящий кусок регрессионных тестов (наверняка есть такой)
7. Привести в порядок базу знаний, написать туда полезных статей, поделиться с коллегами
8. Разобрать залипшие в баг-трекере баги (наверняка такие есть везде)
9. И т.д.
UPD доп. варианты из комментов 😊
10. Устроить сессии исследовательского тестирования
11. Упорядочить хаос на рабочем компьютере/на рабочем столе
Пишите в комментариях, что еще полезного и классного можно сделать в такое «свободное» время, пока задачи еще не передали в тестирование ✌️
YouTube
Максим Дорофеев — Эффективность неэффективности
Максим Дорофеев — Эффективность неэффективности
Встреча CodeFreeze в Москве, 10.07.2014
10 июля в московском офисе Мэйл.Ру прошла встреча CodeFreeze с Максимом Дорофеевым, известным проектным менеджером и консультантом. Речь шла об основах теории ограничений…
Встреча CodeFreeze в Москве, 10.07.2014
10 июля в московском офисе Мэйл.Ру прошла встреча CodeFreeze с Максимом Дорофеевым, известным проектным менеджером и консультантом. Речь шла об основах теории ограничений…
#общее #рабочийпроцесс
Одна и самых животрепещущих тем для джунов-тестировщиков, на мой взгляд – умение формулировать свои мысли так, чтобы донести до собеседника информацию за минимальное количество итераций переспрашивания. В частности, это касается умения задавать вопросы ☝️
Казалось бы, что сложного в том, чтобы задавать вопросы? «Это вам не мешки ворочать», - скажут некоторые 🥸
Давай посмотрим на пример вопроса. Представь, сидишь работаешь, а тут приходит в чатик коллега и происходит следующий диалог (К – коллега, Я - я):
К: Привет, <usrname>! Можно задать вопрос?
Я: Привет, да, конечно
К: Тут такое дело, не могу понять что в требованиях имеется в виду
Я: Таааак..?
К: Там что-то про алгоритм…
Я: Какие требования? Какой алгоритм?
К: А, ну требования по задаче Х, там алгоритм работы Г
Я: Хм…не помню что за задача, дай ссылку
К: <ссылка на задачу>
Я *изучаю задачу по ссылке, не вижу требований*: А где требования?
К: А, ну требования то вот тут - <ссылка на требования>
Я: Ага, вижу, а в чем вопрос то?
К: Да вот не понимаю как там в алгоритме Г обрабатывается ситуация Д
Я: Аааа, так бы сразу и сказал, это делается так-то и так-то. Попроси аналитика дописать это в требования, чтобы потом опять не мучаться
В этом выдуманном диалоге прекрасно всё, это квинтэссенция плохо заданного простого вопроса. Если задать этот же вопрос хорошо и правильно, то он решится не за 20 минут нервной переписки, а за 3 минуты и без нервов. Например, можно было спросить так:
К: Привет! Подскажи, пожалуйста, по задаче <ссылка на задачу>. Там в требованиях <ссылка на требования> есть такой момент: <цитата нужного куска требований или картинка из требований>. Мне тут не очень понятно, как обрабатывается в этом случае ситуация Д.
Я: Привет! Ситуация Д обрабатывается вот так-то и так-то. Попроси, пожалуйста, аналитика дописать это в требования, чтобы потом не забыть.
Итак, что же отличает хорошо сформулированный вопрос от не очень хорошо сформулированного?
В первую очередь – это контекст. Необходимо ввести в контекст вашей проблемы. Одно из самых популярных когнитивных искажений – считать, что окружающие знают тоже, что и ты. Именно отсюда растут ноги у плохо сформулированных вопросов. Не бойся быть кэпом и говорить, на твой взгляд, очевидные вещи. Это поможет быстрее решить твой вопрос.
Второй важный компонент – подкрепляющие вопрос материалы. Это могут быть ссылки, цитаты, картинки и т.д. – всё, что помогает быстро погрузиться в контекст вопроса и, соответственно, быстро дать ответ.
Третий компонент очевидный, но всё же скажу про него – это вежливость. Никому не понравится отвечать на вопрос, заданный без принятых вежливых оборотов и с интонацией «мне все должны»
Не забывай про эти составляющие и формулируй вопросы правильно!
Да пребудет с тобой сила 💪
Одна и самых животрепещущих тем для джунов-тестировщиков, на мой взгляд – умение формулировать свои мысли так, чтобы донести до собеседника информацию за минимальное количество итераций переспрашивания. В частности, это касается умения задавать вопросы ☝️
Казалось бы, что сложного в том, чтобы задавать вопросы? «Это вам не мешки ворочать», - скажут некоторые 🥸
Давай посмотрим на пример вопроса. Представь, сидишь работаешь, а тут приходит в чатик коллега и происходит следующий диалог (К – коллега, Я - я):
К: Привет, <usrname>! Можно задать вопрос?
Я: Привет, да, конечно
К: Тут такое дело, не могу понять что в требованиях имеется в виду
Я: Таааак..?
К: Там что-то про алгоритм…
Я: Какие требования? Какой алгоритм?
К: А, ну требования по задаче Х, там алгоритм работы Г
Я: Хм…не помню что за задача, дай ссылку
К: <ссылка на задачу>
Я *изучаю задачу по ссылке, не вижу требований*: А где требования?
К: А, ну требования то вот тут - <ссылка на требования>
Я: Ага, вижу, а в чем вопрос то?
К: Да вот не понимаю как там в алгоритме Г обрабатывается ситуация Д
Я: Аааа, так бы сразу и сказал, это делается так-то и так-то. Попроси аналитика дописать это в требования, чтобы потом опять не мучаться
В этом выдуманном диалоге прекрасно всё, это квинтэссенция плохо заданного простого вопроса. Если задать этот же вопрос хорошо и правильно, то он решится не за 20 минут нервной переписки, а за 3 минуты и без нервов. Например, можно было спросить так:
К: Привет! Подскажи, пожалуйста, по задаче <ссылка на задачу>. Там в требованиях <ссылка на требования> есть такой момент: <цитата нужного куска требований или картинка из требований>. Мне тут не очень понятно, как обрабатывается в этом случае ситуация Д.
Я: Привет! Ситуация Д обрабатывается вот так-то и так-то. Попроси, пожалуйста, аналитика дописать это в требования, чтобы потом не забыть.
Итак, что же отличает хорошо сформулированный вопрос от не очень хорошо сформулированного?
В первую очередь – это контекст. Необходимо ввести в контекст вашей проблемы. Одно из самых популярных когнитивных искажений – считать, что окружающие знают тоже, что и ты. Именно отсюда растут ноги у плохо сформулированных вопросов. Не бойся быть кэпом и говорить, на твой взгляд, очевидные вещи. Это поможет быстрее решить твой вопрос.
Второй важный компонент – подкрепляющие вопрос материалы. Это могут быть ссылки, цитаты, картинки и т.д. – всё, что помогает быстро погрузиться в контекст вопроса и, соответственно, быстро дать ответ.
Третий компонент очевидный, но всё же скажу про него – это вежливость. Никому не понравится отвечать на вопрос, заданный без принятых вежливых оборотов и с интонацией «мне все должны»
Не забывай про эти составляющие и формулируй вопросы правильно!
Да пребудет с тобой сила 💪
❤8👏1
#общее #собеседование
Сегодня хочу поговорить о том, что на собеседованиях/в тестовых заданиях (рассматриваем только собеседования на джунов-тестировщиков без опыта или с минимальным опытом) можно считать в пределах нормы, а что "за гранью" - по моему разумению, конечно. В комментариях пишите-добавляйте или оспаривайте, буду только рада 🙃
1. ✅ На собесе вас спрашивают какие-то сложные темы, которых вы не знаете. Погодите возмущаться и негодовать, что мол для джуна такие знания странны. Скорее всего собеседующий просто хочет прощупать границы ваших познаний. Не бойтесь отвечать, что не знаете. Лучше всего будет ответить примерно так: "какой интересный вопрос, я этого пока не знаю, но почитаю что найду. Может что-то посоветуете?" и записать. Вы великолепны! ❤️
2. ❌На собесе звучат вопросы личного характера, например, про жен/мужей, про детей, про планирование детей, про ипотеку, про возраст, сексуальную ориентацию, религию и т.д. Тут стоит взвесить все за и против и действовать по обстановке:
* Если вопросы исходят от эйчара в отсутствие технического собеседующего (возможного будущего коллеги или начальника), надо помнить, что это вполне может быть самодурством конкретного человека. Можно задать встречный вопрос - мол "для чего вы это спрашиваете? Эти факторы никак не влияют на мою работу". Если ответить на такие вопросы для вас ок, то можно и ответить. Если не ок, можно сказать, что не хотите на собеседовании обсуждать личные вопросы.
* Если вопросы исходят от технического собеседующего или в его присутствии (и он не останавливает эйчара с такими вопросами), то это звоночек и повод задуматься хотите ли вы работать с человеком, для которого на собеседовании важно выяснить личные вопросы, не касающиеся работы. Вполне нормально в такой ситуации сказать "я бы не хотела обсуждать личные вопросы на собеседовании", а если будут настаивать, можно и уйти, сказав, что они вам не подходят. Это тяжело, кажется, что это некрасиво, некультурно и всё такое. Но свои границы стоит отстаивать, я считаю 📛
3. ✅По результатам тестового задания вам не дали подробного фидбека, просто написали, что вы не подходите команде. Это, конечно, не очень информативно, но так часто бывает. Чтобы проверить все тестовые задания от всех кандидатов и написать хорошие фидбеки для каждого нужно очень много времени и сил. Зачастую такого количества времени и сил у лида/менеджера просто нет. Если уж тебе ну прям очень любопытно что же там не так, попробуй спросить. Напиши в ответ, например, так: "Спасибо за ваш ответ! Очень расстроилась, когда его прочитала, но понимаю, что такова жизнь. Если вас не сильно затруднит, напишите, пожалуйста, пару слов о том, почему моя работа вам не подходит. Я бы очень хотела поработать над своими ошибками и, возможно, когда-нибудь снова попробовать попасть к вам". Такого рода ответ обратит на тебя внимание, очень вероятно, что тебе дадут фидбек, а еще есть вероятность, что дадут второй шанс с другим тестовым заданием 🤞
4. ❌ По результатам тестового задания вам дали фидбек из серии "всё фигня, ты ничего не умеешь, гуляй отсюда". Т.е. хамовато и без конкретики. Не расстраивайся! Всё скорее всего не так плохо, как они написали. Скорее всего это такая корпоративная "культура". Чаще всего этим страдают госы. Предлагаю применить тут мысленное упражнение посылания на йух и возблагодарить Ктулху, что тебе не придется работать с такими людьми 🤬
Сегодня хочу поговорить о том, что на собеседованиях/в тестовых заданиях (рассматриваем только собеседования на джунов-тестировщиков без опыта или с минимальным опытом) можно считать в пределах нормы, а что "за гранью" - по моему разумению, конечно. В комментариях пишите-добавляйте или оспаривайте, буду только рада 🙃
1. ✅ На собесе вас спрашивают какие-то сложные темы, которых вы не знаете. Погодите возмущаться и негодовать, что мол для джуна такие знания странны. Скорее всего собеседующий просто хочет прощупать границы ваших познаний. Не бойтесь отвечать, что не знаете. Лучше всего будет ответить примерно так: "какой интересный вопрос, я этого пока не знаю, но почитаю что найду. Может что-то посоветуете?" и записать. Вы великолепны! ❤️
2. ❌На собесе звучат вопросы личного характера, например, про жен/мужей, про детей, про планирование детей, про ипотеку, про возраст, сексуальную ориентацию, религию и т.д. Тут стоит взвесить все за и против и действовать по обстановке:
* Если вопросы исходят от эйчара в отсутствие технического собеседующего (возможного будущего коллеги или начальника), надо помнить, что это вполне может быть самодурством конкретного человека. Можно задать встречный вопрос - мол "для чего вы это спрашиваете? Эти факторы никак не влияют на мою работу". Если ответить на такие вопросы для вас ок, то можно и ответить. Если не ок, можно сказать, что не хотите на собеседовании обсуждать личные вопросы.
* Если вопросы исходят от технического собеседующего или в его присутствии (и он не останавливает эйчара с такими вопросами), то это звоночек и повод задуматься хотите ли вы работать с человеком, для которого на собеседовании важно выяснить личные вопросы, не касающиеся работы. Вполне нормально в такой ситуации сказать "я бы не хотела обсуждать личные вопросы на собеседовании", а если будут настаивать, можно и уйти, сказав, что они вам не подходят. Это тяжело, кажется, что это некрасиво, некультурно и всё такое. Но свои границы стоит отстаивать, я считаю 📛
3. ✅По результатам тестового задания вам не дали подробного фидбека, просто написали, что вы не подходите команде. Это, конечно, не очень информативно, но так часто бывает. Чтобы проверить все тестовые задания от всех кандидатов и написать хорошие фидбеки для каждого нужно очень много времени и сил. Зачастую такого количества времени и сил у лида/менеджера просто нет. Если уж тебе ну прям очень любопытно что же там не так, попробуй спросить. Напиши в ответ, например, так: "Спасибо за ваш ответ! Очень расстроилась, когда его прочитала, но понимаю, что такова жизнь. Если вас не сильно затруднит, напишите, пожалуйста, пару слов о том, почему моя работа вам не подходит. Я бы очень хотела поработать над своими ошибками и, возможно, когда-нибудь снова попробовать попасть к вам". Такого рода ответ обратит на тебя внимание, очень вероятно, что тебе дадут фидбек, а еще есть вероятность, что дадут второй шанс с другим тестовым заданием 🤞
4. ❌ По результатам тестового задания вам дали фидбек из серии "всё фигня, ты ничего не умеешь, гуляй отсюда". Т.е. хамовато и без конкретики. Не расстраивайся! Всё скорее всего не так плохо, как они написали. Скорее всего это такая корпоративная "культура". Чаще всего этим страдают госы. Предлагаю применить тут мысленное упражнение посылания на йух и возблагодарить Ктулху, что тебе не придется работать с такими людьми 🤬
👍1
#общее #собеседование
5. ✅ На собесе тебя спрашивают про желаемый уровень дохода. Не пугайся, тебя не хотят "развести" на минимальную оплату или "отсечь", потому что ты "много хочешь". На самом деле хотят узнать какой уровень оплаты будет для тебя приемлемым и комфортным и понять, подходишь ли ты им по этому параметру. Т.е. совпадают ли ваши оценки твоих знаний и умений хотя бы приблизительно. А еще такой вопрос может быть вызван тем, что на вакансию нет конкретного бюджета, вилка очень сильно плавающая и, если кандидат очень подходящий и запрашивает больше, чем остальные, его скорее всего согласуют и пригласят. На такой вопрос лучше всего ответить вариантами, например, "на первое время приемлемо будет Х денег, а комфортная сумма на данном этапе была бы Y денег". Это еще кстати хороший повод обсудить карьерные и зарплатные перспективы, если еще не! 🤑
5. ✅ На собесе тебя спрашивают про желаемый уровень дохода. Не пугайся, тебя не хотят "развести" на минимальную оплату или "отсечь", потому что ты "много хочешь". На самом деле хотят узнать какой уровень оплаты будет для тебя приемлемым и комфортным и понять, подходишь ли ты им по этому параметру. Т.е. совпадают ли ваши оценки твоих знаний и умений хотя бы приблизительно. А еще такой вопрос может быть вызван тем, что на вакансию нет конкретного бюджета, вилка очень сильно плавающая и, если кандидат очень подходящий и запрашивает больше, чем остальные, его скорее всего согласуют и пригласят. На такой вопрос лучше всего ответить вариантами, например, "на первое время приемлемо будет Х денег, а комфортная сумма на данном этапе была бы Y денег". Это еще кстати хороший повод обсудить карьерные и зарплатные перспективы, если еще не! 🤑
#общее
Зачем нужны джуны компаниям?
Часто слышу от начинающих тестировщиков, что невозможно найти работу, потому что всем нужны опытные спецы.
Но мы же с вами знаем, что джунов без опыта тоже берут довольно много. Казалось бы, зачем это компаниям?
На мой взгляд:
1. Самое очевидное: джуны дешевле в плане зарплаты. Да, на них нужны затраты другого рода (время других специалистов и т.д.), но это временные затраты, пока джун не обретёт хотя бы минимальную автономность.
2. Джуны имеют свежий незамутнённый взгляд. Они ещё не видели других процессов и порой задают интересные вопросы, над которыми "бывалые" спецы уже просто не задумываются (пока их не спросят, конечно). Плюс свежий взгляд на продукт. Особенно полезно, если продукт не узкоспециализированный, а для широкой аудитории.
3. При менторинге джуна опытный спец тоже прокачивается. Конечно, если у него есть ресурс и желание для менторинга.
4. Джунам обычно поручаются рутинные задачи, тем самым мидлы от них освобождаются для выполнения более серьезных задач
Думаю, что у всех, кто нанимает джунов есть свои резоны для этого, вот еще статья на эту тему: https://rb.ru/young/junior-it/
Зачем нужны джуны компаниям?
Часто слышу от начинающих тестировщиков, что невозможно найти работу, потому что всем нужны опытные спецы.
Но мы же с вами знаем, что джунов без опыта тоже берут довольно много. Казалось бы, зачем это компаниям?
На мой взгляд:
1. Самое очевидное: джуны дешевле в плане зарплаты. Да, на них нужны затраты другого рода (время других специалистов и т.д.), но это временные затраты, пока джун не обретёт хотя бы минимальную автономность.
2. Джуны имеют свежий незамутнённый взгляд. Они ещё не видели других процессов и порой задают интересные вопросы, над которыми "бывалые" спецы уже просто не задумываются (пока их не спросят, конечно). Плюс свежий взгляд на продукт. Особенно полезно, если продукт не узкоспециализированный, а для широкой аудитории.
3. При менторинге джуна опытный спец тоже прокачивается. Конечно, если у него есть ресурс и желание для менторинга.
4. Джунам обычно поручаются рутинные задачи, тем самым мидлы от них освобождаются для выполнения более серьезных задач
Думаю, что у всех, кто нанимает джунов есть свои резоны для этого, вот еще статья на эту тему: https://rb.ru/young/junior-it/
rb.ru
Зачем IT-компаниям джуниоры? Отвечают работодатели | RB.RU
Не все IT-компании любят набирать начинающих специалистов — джуниоров: в них приходится инвестировать время и силы. Всегда легче пригласить в команду мидл- или сеньор-разработчика, который быстро включится и начнет приносить компании добавленную стоимость.…
#общее #бесплатное #саморазвитие
Меня иногда спрашивают, какие каналы/чаты в телеграме по профессиональной теме я читаю/пишу. Решила запостить свой список. Это не реклама, по крайней мере мне за неё не платили… пока что… может теперь заплатят 😅
Сразу рекомендация: если хочешь задать вопрос в тематическом чате на много тысяч человек, попробуй сначала почитать описание чата, закрепленные сообщения (их может быть несколько) и еще воспоспользуйся поиском. Вот если ничего не нашлось или нашлось, но маловато, тогда смело задавай вопрос. А как задавать вопрос так, чтобы не было мучительно больно я писала ранее 😉
https://t.iss.one/qa_bad_company - чатик про работу в разных компаниях, можно найти отзывы почти на всё
https://t.iss.one/qa_courses - чатик про курсы для тестировщиков. Отзывы, рекомендации и т.д.
https://t.iss.one/qa_resumes - чатик, где можно запостить резюме в поиске работы
https://t.iss.one/qa_jobs - чатик с вакансиями для тестировщиков
https://sites.google.com/view/qasisters - сообщество тестировщиц. Только для девочек! Есть премодерация.
https://t.iss.one/uporotqa - канал моей выпускницы, которая ещё во время учёбы устроилась в классный стартап
https://t.iss.one/godoftesting - статьи про тестирование
https://t.iss.one/serious_tester - ещё статьи про тестирование
https://t.iss.one/short_QA - шикарный канал с короткими советами для тестировщиков
https://t.iss.one/radioqa - канал подкаста Радиокуа с годными мемчиками про тестирование
https://t.iss.one/qahacking - статьи, мысли, мемчики, советы про тестирование и около него
https://t.iss.one/aboutqa - канал про тестирование (в описании есть ещё чат-болталка). Админ канала - бывший старший ревьюер курса Инженер по тестированию от Я.Практикума
https://t.iss.one/yetanotherqa - как сказано в названии: ещё один канал про тестирование 🙂
https://t.iss.one/joinchat/TllK7Oepcy-4PGCs - чат проекта Хомячки, одним из организаторов которого я являюсь
https://t.iss.one/whybugs - канал одного из наставников Я.Практикума, посвящен багам
https://t.iss.one/ITbugs - и ещё один канал про баги
https://t.iss.one/mnogosdelal - канал Макса Дорофеева. Это первый и единственный в мире прокрастинотолог (потому что он сам себя так назвал))) - не про тестирование, но про организацию времени. И Макс когда-то сам был тестировщиком 🙂
https://t.iss.one/testing_and_life - и ещё канал про тестирование и около него от крутой Ольги Артемьевой
https://t.iss.one/offerpower - канал про поиск работы и всё, что с ним связано
https://t.iss.one/test_pass - канал тестировщицы про её опыт в тестировании, мысли и полезности
https://t.iss.one/just_ordinary_qa - канал тестировщицы с рассказами о будничной работе и философскими вопросами
А что читаете/пишете вы? 😊
Меня иногда спрашивают, какие каналы/чаты в телеграме по профессиональной теме я читаю/пишу. Решила запостить свой список. Это не реклама, по крайней мере мне за неё не платили… пока что… может теперь заплатят 😅
Сразу рекомендация: если хочешь задать вопрос в тематическом чате на много тысяч человек, попробуй сначала почитать описание чата, закрепленные сообщения (их может быть несколько) и еще воспоспользуйся поиском. Вот если ничего не нашлось или нашлось, но маловато, тогда смело задавай вопрос. А как задавать вопрос так, чтобы не было мучительно больно я писала ранее 😉
https://t.iss.one/qa_bad_company - чатик про работу в разных компаниях, можно найти отзывы почти на всё
https://t.iss.one/qa_courses - чатик про курсы для тестировщиков. Отзывы, рекомендации и т.д.
https://t.iss.one/qa_resumes - чатик, где можно запостить резюме в поиске работы
https://t.iss.one/qa_jobs - чатик с вакансиями для тестировщиков
https://sites.google.com/view/qasisters - сообщество тестировщиц. Только для девочек! Есть премодерация.
https://t.iss.one/uporotqa - канал моей выпускницы, которая ещё во время учёбы устроилась в классный стартап
https://t.iss.one/godoftesting - статьи про тестирование
https://t.iss.one/serious_tester - ещё статьи про тестирование
https://t.iss.one/short_QA - шикарный канал с короткими советами для тестировщиков
https://t.iss.one/radioqa - канал подкаста Радиокуа с годными мемчиками про тестирование
https://t.iss.one/qahacking - статьи, мысли, мемчики, советы про тестирование и около него
https://t.iss.one/aboutqa - канал про тестирование (в описании есть ещё чат-болталка). Админ канала - бывший старший ревьюер курса Инженер по тестированию от Я.Практикума
https://t.iss.one/yetanotherqa - как сказано в названии: ещё один канал про тестирование 🙂
https://t.iss.one/joinchat/TllK7Oepcy-4PGCs - чат проекта Хомячки, одним из организаторов которого я являюсь
https://t.iss.one/whybugs - канал одного из наставников Я.Практикума, посвящен багам
https://t.iss.one/ITbugs - и ещё один канал про баги
https://t.iss.one/mnogosdelal - канал Макса Дорофеева. Это первый и единственный в мире прокрастинотолог (потому что он сам себя так назвал))) - не про тестирование, но про организацию времени. И Макс когда-то сам был тестировщиком 🙂
https://t.iss.one/testing_and_life - и ещё канал про тестирование и около него от крутой Ольги Артемьевой
https://t.iss.one/offerpower - канал про поиск работы и всё, что с ним связано
https://t.iss.one/test_pass - канал тестировщицы про её опыт в тестировании, мысли и полезности
https://t.iss.one/just_ordinary_qa - канал тестировщицы с рассказами о будничной работе и философскими вопросами
А что читаете/пишете вы? 😊
Telegram
QA - Bad Company!
Позитив и негатив про компании и курсы, где стоит или не стоит работать и учиться.
Пиратский контент=бан.
Большой @qa_ru
Флуд @qaFlood
Вакансии @qa_jobs
Финансы @qa_fin
Резюме @qa_resumes
Админ всегда админ
По поводу рекламы - к админу
РКН № 5025812413
Пиратский контент=бан.
Большой @qa_ru
Флуд @qaFlood
Вакансии @qa_jobs
Финансы @qa_fin
Резюме @qa_resumes
Админ всегда админ
По поводу рекламы - к админу
РКН № 5025812413
👍3
#общее #саморазвитие
Други мои! Недавно занималась подбором джуна для одного из своих продуктов, давала тестовое задание, по которому надо было написать чек-лист на основе требований и придумать и составить баг-репорт по этой же функциональности. Функционал для необычного мобильного приложения - инвентаризация в магазине с помощью плеера iPod и специального чехла-сканера на нём.
Я проверила 100 работ от джунов, закончивших курс Я.ПРактикума для тестировщиков и хочу поделиться с вами наиболее популярными ошибками, которые допускались в этой работе.
Самые популярные ошибки в чек-листе:
1. Употребление самоочевидных слов типа "проверка", "проверить, что" и т.д. - это делает проверки менее читабельными и более громоздкими
2. Нечитабельное оформление: проверки сплошной простынёй, без разделов, без нумерации, вперемешку, или с разделами, но без выделения заголовков каким-то видным шрифтом или заливкой. Такие работы просто сложно читать, старайтесь при выполнении тестового задания всегда думать о том, что читать это будет совершенно другой человек и надо сделать так, чтобы читать было комфортно и понятно.
3. Проверки полностью дублируют имеющиеся формализованные требования, т.е. не был проведен анализ, нет проработки серых зон и неявных требований. Не забывайте проводить тест-анализ, это наша основная работа!
4. Не хватает проверок особенностей мобильных девайсов. Если вы пишете проверки для мобильного приложения, подумайте как оно будет работать на самом девайсе.
5. Слишком много проверок особенностей мобильных девайсов, без оглядки на специфичность указанного в требованиях девайса (плеер iPod). Не стоит перечислять "всё, чему учили на курсе", надо продумать что применимо в каждом конкретном случае.
6. Тест-кейсы вместо чек-листа. Если в задании написано "составить чек-лист", не стоит переусердствовать и писать тест-кейсы, это никто не оценит 🤪
7. Отсутствуют додумки требований в части серых зон и/или отсутствуют комментарии к таким додумкам. В задании я специально указала в явном виде, что вопросы задавать нельзя, а можно и нужно додумать все неясности самостоятельно (проявить креативность и применить оракулов и здравый смысл) и при этом обязательно оставить комментарии о том что было додумано и почему.
Самые популярные ошибки в баг-репортах:
1. Составлено несколько баг-репортов, хотя по заданию нужен был один (не самый страшный косяк, конечно)
2. Не хватает некоторых полей баг-репорта, в основном это критичность/приоритет, вложения и иногда даже шаги 😱
3. В описании/шагах/результатах написано что система НЕ делает. Правильно писать только то, что система делает, это дает больше информации
4. Не хватает анализа происходящего. Из-за чего баг появился (предположения), на что баг влияет, что за собой влечёт, т.е. локализовать баг, ведь именно из этого и выявляется критичность
5. Выбран низкоприоритетный, косметический баг. Для таких заданий лучше выбирать критичный баг, это покажет то, что вы проанализировали доработку и продумали, что может пойти не так.
6. Оформление бага оставляет желать лучшего: вырвиглазные цвета выделяющие текст или наоборот вообще без выделений заголовков, сплошным текстом.
Надеюсь эти антипаттерны помогут вам в выполнении тестовых заданий, удачи! 😇
Други мои! Недавно занималась подбором джуна для одного из своих продуктов, давала тестовое задание, по которому надо было написать чек-лист на основе требований и придумать и составить баг-репорт по этой же функциональности. Функционал для необычного мобильного приложения - инвентаризация в магазине с помощью плеера iPod и специального чехла-сканера на нём.
Я проверила 100 работ от джунов, закончивших курс Я.ПРактикума для тестировщиков и хочу поделиться с вами наиболее популярными ошибками, которые допускались в этой работе.
Самые популярные ошибки в чек-листе:
1. Употребление самоочевидных слов типа "проверка", "проверить, что" и т.д. - это делает проверки менее читабельными и более громоздкими
2. Нечитабельное оформление: проверки сплошной простынёй, без разделов, без нумерации, вперемешку, или с разделами, но без выделения заголовков каким-то видным шрифтом или заливкой. Такие работы просто сложно читать, старайтесь при выполнении тестового задания всегда думать о том, что читать это будет совершенно другой человек и надо сделать так, чтобы читать было комфортно и понятно.
3. Проверки полностью дублируют имеющиеся формализованные требования, т.е. не был проведен анализ, нет проработки серых зон и неявных требований. Не забывайте проводить тест-анализ, это наша основная работа!
4. Не хватает проверок особенностей мобильных девайсов. Если вы пишете проверки для мобильного приложения, подумайте как оно будет работать на самом девайсе.
5. Слишком много проверок особенностей мобильных девайсов, без оглядки на специфичность указанного в требованиях девайса (плеер iPod). Не стоит перечислять "всё, чему учили на курсе", надо продумать что применимо в каждом конкретном случае.
6. Тест-кейсы вместо чек-листа. Если в задании написано "составить чек-лист", не стоит переусердствовать и писать тест-кейсы, это никто не оценит 🤪
7. Отсутствуют додумки требований в части серых зон и/или отсутствуют комментарии к таким додумкам. В задании я специально указала в явном виде, что вопросы задавать нельзя, а можно и нужно додумать все неясности самостоятельно (проявить креативность и применить оракулов и здравый смысл) и при этом обязательно оставить комментарии о том что было додумано и почему.
Самые популярные ошибки в баг-репортах:
1. Составлено несколько баг-репортов, хотя по заданию нужен был один (не самый страшный косяк, конечно)
2. Не хватает некоторых полей баг-репорта, в основном это критичность/приоритет, вложения и иногда даже шаги 😱
3. В описании/шагах/результатах написано что система НЕ делает. Правильно писать только то, что система делает, это дает больше информации
4. Не хватает анализа происходящего. Из-за чего баг появился (предположения), на что баг влияет, что за собой влечёт, т.е. локализовать баг, ведь именно из этого и выявляется критичность
5. Выбран низкоприоритетный, косметический баг. Для таких заданий лучше выбирать критичный баг, это покажет то, что вы проанализировали доработку и продумали, что может пойти не так.
6. Оформление бага оставляет желать лучшего: вырвиглазные цвета выделяющие текст или наоборот вообще без выделений заголовков, сплошным текстом.
Надеюсь эти антипаттерны помогут вам в выполнении тестовых заданий, удачи! 😇
🔥5
#API
На моём ютуб-канале уже целых два видео и это не потому что я записала-таки еще одну познавательную пятиминутку 😅
Наткнулась на запись экскурса в граф куэль, который нам проводил разработчик на прошлой работе, с его разрешения выложила, наслаждайтесь 😊
https://www.youtube.com/watch?v=NaXWW9_w2pQ
На моём ютуб-канале уже целых два видео и это не потому что я записала-таки еще одну познавательную пятиминутку 😅
Наткнулась на запись экскурса в граф куэль, который нам проводил разработчик на прошлой работе, с его разрешения выложила, наслаждайтесь 😊
https://www.youtube.com/watch?v=NaXWW9_w2pQ
YouTube
GraphQL - как писать запросы
Экскурс в основы GraphQL от Димы Коробкова (@KorobOK) для нас, тестировщиков :)
🔥12👏2
Справочник QA.pdf
1.4 MB
#общее #саморазвитие
Други, в этот прекрасный день хочу поделиться с вами своей поделкой: сборником терминов и определений в области обеспечения качества. Я составила его совместно с коллегами как внутренний документ в Спортмастер Лаб и хочу поделиться с вами 🤗
Други, в этот прекрасный день хочу поделиться с вами своей поделкой: сборником терминов и определений в области обеспечения качества. Я составила его совместно с коллегами как внутренний документ в Спортмастер Лаб и хочу поделиться с вами 🤗
🔥100❤12👍3👏1🤩1
Други, на ближайшей Подлодке я буду выступать с докладом про мой любимый ленивый рационализм. И в целом в этом запуске Подлодки темы все очень классные, не пропустите! 🤗
https://podlodka.io/qacrew
https://podlodka.io/qacrew
podlodka.io
Онлайн-конференция Podlodka QA Crew, сезон #15
Недельное мероприятие от команды Podlodka: ежедневные интерактивные сессии в Zoom по актуальным проблемам QA-индустрии, нон-стоп общение с экспертами и звёздами индустрии, закрытое профессиональное сообщество в Telegram.
🔥18❤1👍1
Други, для подготовки моего доклада на Подлодке прошу пройти анонимный мини-опрос - буквально от 1 до 3 вопросов в зависимости от ваших ответов: https://forms.gle/oBjyRBFcu83RCmeC6.
Опрос только для тех, кто сейчас работает тестировщиком. Пожалуйста, не тестируйте форму опроса, а, отвечайте честно как есть 😅 Будет очень интересно посмотреть на статистику.
Результаты обязательно опубликую здесь же 🤓
Опрос только для тех, кто сейчас работает тестировщиком. Пожалуйста, не тестируйте форму опроса, а, отвечайте честно как есть 😅 Будет очень интересно посмотреть на статистику.
Результаты обязательно опубликую здесь же 🤓
Google Docs
Ведение тестовой документации
Опрос про документирование тестов
👍17
Спасибо всем, кто поучаствовал в опросе! Всего собрано данных от 277 тестировщиков. По ссылке можно посмотреть результаты: https://drive.google.com/file/d/1-_pRThfcm7mr911ta4SuCJ9EJ_TTy3Ze/view?usp=sharing
🔥14
#общее
#рабочийпроцесс
Сегодня крутой день! Делюсь с вами, мои дорогие!
Моё первое выступление на Подлодке, поговорили про мой любимый ленивый рационализм: https://youtu.be/FIz4uX1LfIM
И сегодня же замечательная https://Fidelina.ru выложила наше интервью, где мы поговорили про ручное тестирование: https://youtu.be/oL-r4dR0krI
#рабочийпроцесс
Сегодня крутой день! Делюсь с вами, мои дорогие!
Моё первое выступление на Подлодке, поговорили про мой любимый ленивый рационализм: https://youtu.be/FIz4uX1LfIM
И сегодня же замечательная https://Fidelina.ru выложила наше интервью, где мы поговорили про ручное тестирование: https://youtu.be/oL-r4dR0krI
YouTube
Доклад: Ленивый рационализм при написании тестовой документации / Ольга Ермолаева (Sportmaster Lab)
Рациональная оптимизация во всём и в создании тестовой документации в частности. Как я сократила затраты времени на создание тестовой документации для себя и команды.
Понравилось видео и хочешь узнать что-то еще про QA Crew? Забирай весь плейлист на ht…
Понравилось видео и хочешь узнать что-то еще про QA Crew? Забирай весь плейлист на ht…
👍42🔥20
#общее
Как я вписалась в Подлодку и успешно провела плаванье.
Давно была мысль выступить на конференции, еще тогда, когда конференции были только офлайновыми и фактически единственной для тестировщиков была SQA Days. Но всё как-то не хватало уверенности, все темы казались высосанными из пальца и не стоящими...
Как-то более осязаемо желание выступить проявилось, когда у нас в Спортмастере эйчары попросили составить список в каких конференциях мы будем участвовать в качестве спонсоров - со стендами, докладами и т.д. В ходе обсуждений я вызвалась участвовать с докладом на той самой SQA Days и в декабре 22-го надеюсь таки там появиться 😊
И примерно в это же время в нашем уютном чатике QA Sisters девочки стали обсуждать предстоящую Подлодку и как попасть туда в качестве спикера. А я возьми да и впишись тоже. Когда узнала, что тема запуска – оптимизация процессов тестирования я сразу подумала о своём любимом ленивом рационализме и, порассуждав, придумала тему про его применение для оптимизации ведения тестовой документации.
Замечательные Аня Принц и Марина Куликова из программного комитета Подлодки безумно помогли мне в подготовке – поддерживали, подсказывали как сделать лучше, что добавить, что убрать, в каком ключе лучше рассказывать. Была проделана огромная работа! Спасибо, девчонки! Без вас я бы не справилась! 😍
За месяц с небольшим мы вместе отточили презенташку, провели пару прогонов, которые придали мне уверенности. И всё равно я очень нервничала, это моё первое публичное выступление. До этого я выступала только для своих и вела вебинары для студентов Практикума 🤪
Доклад прошел, на мой взгляд, отлично! Я получила массу интересных вопросов и классных отзывов, аудитория была просто огонь! Очень дружелюбная и поддерживающая! Спасибо всем, кто смотрел, комментировал, задавал вопросы и поддерживал! Вы лучшие! 🤗
Что хочу сказать в итоге: мне всё очень понравилось, надеюсь получится поучаствовать еще, буду рада! И главное: если вы задумываетесь выступить с докладом, но никогда раньше этого не делали, то Подлодка точно для вас! Дерзайте! 🦸♀️
Помимо прочего это еще и возможность посмотреть остальные доклады и поучаствовать в комьюнити 😉
Как я вписалась в Подлодку и успешно провела плаванье.
Давно была мысль выступить на конференции, еще тогда, когда конференции были только офлайновыми и фактически единственной для тестировщиков была SQA Days. Но всё как-то не хватало уверенности, все темы казались высосанными из пальца и не стоящими...
Как-то более осязаемо желание выступить проявилось, когда у нас в Спортмастере эйчары попросили составить список в каких конференциях мы будем участвовать в качестве спонсоров - со стендами, докладами и т.д. В ходе обсуждений я вызвалась участвовать с докладом на той самой SQA Days и в декабре 22-го надеюсь таки там появиться 😊
И примерно в это же время в нашем уютном чатике QA Sisters девочки стали обсуждать предстоящую Подлодку и как попасть туда в качестве спикера. А я возьми да и впишись тоже. Когда узнала, что тема запуска – оптимизация процессов тестирования я сразу подумала о своём любимом ленивом рационализме и, порассуждав, придумала тему про его применение для оптимизации ведения тестовой документации.
Замечательные Аня Принц и Марина Куликова из программного комитета Подлодки безумно помогли мне в подготовке – поддерживали, подсказывали как сделать лучше, что добавить, что убрать, в каком ключе лучше рассказывать. Была проделана огромная работа! Спасибо, девчонки! Без вас я бы не справилась! 😍
За месяц с небольшим мы вместе отточили презенташку, провели пару прогонов, которые придали мне уверенности. И всё равно я очень нервничала, это моё первое публичное выступление. До этого я выступала только для своих и вела вебинары для студентов Практикума 🤪
Доклад прошел, на мой взгляд, отлично! Я получила массу интересных вопросов и классных отзывов, аудитория была просто огонь! Очень дружелюбная и поддерживающая! Спасибо всем, кто смотрел, комментировал, задавал вопросы и поддерживал! Вы лучшие! 🤗
Что хочу сказать в итоге: мне всё очень понравилось, надеюсь получится поучаствовать еще, буду рада! И главное: если вы задумываетесь выступить с докладом, но никогда раньше этого не делали, то Подлодка точно для вас! Дерзайте! 🦸♀️
Помимо прочего это еще и возможность посмотреть остальные доклады и поучаствовать в комьюнити 😉
podlodka.io
Онлайн-конференция Podlodka QA Crew, сезон #15
Недельное мероприятие от команды Podlodka: ежедневные интерактивные сессии в Zoom по актуальным проблемам QA-индустрии, нон-стоп общение с экспертами и звёздами индустрии, закрытое профессиональное сообщество в Telegram.
🔥33❤5👍4
Други, готовлюсь к следующему выступлению, на этот раз оффлайновому, на SQA days. Нужна ваша помощь, пройдите, пожалуйста, небольшой опрос: https://forms.gle/R9kqTUAyiS7XWTaA7
Google Docs
Использование тест-анализа и тест-дизайна в работе тестировщика
Спасибо, что согласились пройти этот небольшой опрос, он займет не больше 2 минут вашего времени.
Опрос только для работающих сейчас тестировщиков, у которых есть задачи мануального тестирования. Т.е. если ты только автоматизируешь готовые тесты или только…
Опрос только для работающих сейчас тестировщиков, у которых есть задачи мануального тестирования. Т.е. если ты только автоматизируешь готовые тесты или только…
👍16
И еще малюсенький, но очень важный опросик! https://forms.gle/dc5NZVPa7QJvR72L9
Лайк-шер, всем плюсов в карму! 😊
Лайк-шер, всем плюсов в карму! 😊
Google Docs
Локализация дефектов
Спасибо, что согласились пройти этот небольшой опрос, он займет не больше минуты вашего времени.
Опрос только для работающих сейчас тестировщиков, которые работают с дефектами Т.е. если ты только автоматизируешь готовые тесты или только менеджеришь команду…
Опрос только для работающих сейчас тестировщиков, которые работают с дефектами Т.е. если ты только автоматизируешь готовые тесты или только менеджеришь команду…
👍9
QA FAQ
Други, готовлюсь к следующему выступлению, на этот раз оффлайновому, на SQA days. Нужна ваша помощь, пройдите, пожалуйста, небольшой опрос: https://forms.gle/R9kqTUAyiS7XWTaA7
Спасибо всем, кто поучаствовал в опросе! Обобщенные результаты доступны по ссылке
👍11
QA FAQ
И еще малюсенький, но очень важный опросик! https://forms.gle/dc5NZVPa7QJvR72L9 Лайк-шер, всем плюсов в карму! 😊
Спасибо всем, кто поучаствовал в опросах! Результаты опроса про техники тест-анализа и тест-дизайна обновлены ☝️
Результаты опроса по локализации багов доступны по ссылке
Данные результаты будут использованы в моём докладе на ближайшей SQA days в Питере, не пропустите 😊
Результаты опроса по локализации багов доступны по ссылке
Данные результаты будут использованы в моём докладе на ближайшей SQA days в Питере, не пропустите 😊
👍6
#общее #бесплатное
Вышла статья, в которой я участвовала в качестве эксперта! Получилось, на мой взгляд, интересно и полезно для начинающих!
https://practicum.yandex.ru/blog/chto-takoe-bug-report-kak-ego-sostavit/
Вышла статья, в которой я участвовала в качестве эксперта! Получилось, на мой взгляд, интересно и полезно для начинающих!
https://practicum.yandex.ru/blog/chto-takoe-bug-report-kak-ego-sostavit/
Баг-репорт: что это, виды багов и приоритеты - шаблон и правила оформления баг-репорта в тестировании
Что такое баг-репорт и как правильно составить отчёт об ошибке? Рассказываем о том, что такое баги, их видах, приоритетах и жизненных циклах. Составляющие bug report, обязательные и необязательные поля, заголовок, шаблон и примеры отчетов об ошибках.
👍14