#рабочийпроцесс #релиз
Еще один подход к релизу:
релиз по требованию, инициируемый ЛПР (лицом, принимающим решение).
Основной принцип: есть ЛПР и договоренность в команде, что релиз инициируется его требованием, при этом, чем руководствуется ЛПР может и не обсуждаться. Задачи, которые войдут в релиз определяются ЛПР в день принятия решения исходя из готовности задач и мотивов необходимости релиза.
Как выглядит процесс:
Команда заранее договаривается, сколько времени займут приготовления к релизу (сливания, регрессы и т.д.). ЛПР, зная про эти сроки, планирует релиз: даёт отмашку команде, что надо начинать подготовку релиза, может оговорить какие задачи в него должны войти или по умолчанию туда входят все задачи, которые к этому времени готовы.
Таким образом отсекается релизная ветка и туда больше никакие новые задачи не вносятся. На этой ветке проводится регрессионное тестирование и если всё хорошо, в условленную дату ветка льётся в прод.
Подводные камни:
1. подготовительные работы для выпуска релиза могут задержаться дольше, чем планировали
2. на середине подготовки релиза ЛПР может сказать, что появилась острая необходимость в еще одной/-тцати задачах, которые просто обязаны войти в этот релиз и значит надо начинать всё если не сначала, то почти сначала.
Как можно нивелировать риск "подводных камней":
1. после каждого релиза проводить ретро и заново оценивать время на подготовку релиза, учитывать нововыявленные риски, если такие были.
2. ЛПР должен договориться с бизнесом, что если докидываются задачи уже после отмашки, то это повлияет на сроки (тут стоит обговорить либо конкретные сроки в общем случае для любых задач, либо то, что сроки будут зависеть от докидываемой задачи)
Задача тестировщика: здраво оценивать трудозатраты на тестирование задач и на проведение регресса, учитывая возможные риски и своевременно сигнализировать о проблемах и состоянии релиз-кандидата.
Задача релиз-менеджера, в данной ситуации скорее всего он же ЛПР:
1. своевременно размечать запланированные в релиз задачи
2. следить, чтобы задачи, не вошедшие в релиз не имели отметки текущего релиза
3. следить, чтобы релизные задачи были слиты в релизную ветку, а не релизные НЕ слиты!!
4. следить, чтобы в релизную ветку не добавлялись новые задачи без соответствующей отмашки
5. отслеживать степень готовности релизной ветки к выпуску и вовремя предпринимать нужные действия, чтобы выпустить релиз в обозначенный заранее срок или своевременно предупреждать бизнес о задержке.
6. при необходимости готовит материалы для оповещения бизнесу по задачам и релиз ноутс для пользователей
P.S.
Если у вас остались вопросы, пишите в чатике.
Если вам нужна консультация по конкретному вашему кейсу, пишите в личку, за определенную оплату могу провести консультацию или серию консультаций.
P.P.S. Про какие еще подходы к релизам вы слышали? Или разбор каких вопросов вы хотели бы тут еще увидеть? Накидывайте в чатик 😊
Еще один подход к релизу:
релиз по требованию, инициируемый ЛПР (лицом, принимающим решение).
Основной принцип: есть ЛПР и договоренность в команде, что релиз инициируется его требованием, при этом, чем руководствуется ЛПР может и не обсуждаться. Задачи, которые войдут в релиз определяются ЛПР в день принятия решения исходя из готовности задач и мотивов необходимости релиза.
Как выглядит процесс:
Команда заранее договаривается, сколько времени займут приготовления к релизу (сливания, регрессы и т.д.). ЛПР, зная про эти сроки, планирует релиз: даёт отмашку команде, что надо начинать подготовку релиза, может оговорить какие задачи в него должны войти или по умолчанию туда входят все задачи, которые к этому времени готовы.
Таким образом отсекается релизная ветка и туда больше никакие новые задачи не вносятся. На этой ветке проводится регрессионное тестирование и если всё хорошо, в условленную дату ветка льётся в прод.
Подводные камни:
1. подготовительные работы для выпуска релиза могут задержаться дольше, чем планировали
2. на середине подготовки релиза ЛПР может сказать, что появилась острая необходимость в еще одной/-тцати задачах, которые просто обязаны войти в этот релиз и значит надо начинать всё если не сначала, то почти сначала.
Как можно нивелировать риск "подводных камней":
1. после каждого релиза проводить ретро и заново оценивать время на подготовку релиза, учитывать нововыявленные риски, если такие были.
2. ЛПР должен договориться с бизнесом, что если докидываются задачи уже после отмашки, то это повлияет на сроки (тут стоит обговорить либо конкретные сроки в общем случае для любых задач, либо то, что сроки будут зависеть от докидываемой задачи)
Задача тестировщика: здраво оценивать трудозатраты на тестирование задач и на проведение регресса, учитывая возможные риски и своевременно сигнализировать о проблемах и состоянии релиз-кандидата.
Задача релиз-менеджера, в данной ситуации скорее всего он же ЛПР:
1. своевременно размечать запланированные в релиз задачи
2. следить, чтобы задачи, не вошедшие в релиз не имели отметки текущего релиза
3. следить, чтобы релизные задачи были слиты в релизную ветку, а не релизные НЕ слиты!!
4. следить, чтобы в релизную ветку не добавлялись новые задачи без соответствующей отмашки
5. отслеживать степень готовности релизной ветки к выпуску и вовремя предпринимать нужные действия, чтобы выпустить релиз в обозначенный заранее срок или своевременно предупреждать бизнес о задержке.
6. при необходимости готовит материалы для оповещения бизнесу по задачам и релиз ноутс для пользователей
P.S.
Если у вас остались вопросы, пишите в чатике.
Если вам нужна консультация по конкретному вашему кейсу, пишите в личку, за определенную оплату могу провести консультацию или серию консультаций.
P.P.S. Про какие еще подходы к релизам вы слышали? Или разбор каких вопросов вы хотели бы тут еще увидеть? Накидывайте в чатик 😊
👍8
#анонс
Други, уже завтра начинается наша любимая SQA days, впервые устраиваю круглый стол, кто будет, заходите! 😊
https://sqadays.com/ru/talk/112207
И, конечно, приходите на наш стенд SM Lab, у нас в этот раз будет очень крутой движ, еще круче, чем раньше! Не пропустите! 😉
https://t.iss.one/sqadays/13095
И еще пушка-бомба новость! Мы выпустили ролик про наше QA в SM Lab, я непосредственно приложила руки к этой поделке! https://www.youtube.com/watch?v=ghJhQpaOPAo
Други, уже завтра начинается наша любимая SQA days, впервые устраиваю круглый стол, кто будет, заходите! 😊
https://sqadays.com/ru/talk/112207
И, конечно, приходите на наш стенд SM Lab, у нас в этот раз будет очень крутой движ, еще круче, чем раньше! Не пропустите! 😉
https://t.iss.one/sqadays/13095
И еще пушка-бомба новость! Мы выпустили ролик про наше QA в SM Lab, я непосредственно приложила руки к этой поделке! https://www.youtube.com/watch?v=ghJhQpaOPAo
Sqadays
Круглый стол: факапы найма тестировщиков
У всех нанимающих менеджеров случаются ошибки найма. Поделимся опытом своих провалов, ретроспективно обсудим их причины и что можно было сделать, чтобы их предусмотреть и предотвратить.С другой стороны и у соискателей бывают провалы при поиске работы - обычное…
🔥12👍3
#собеседование
Помните одну из самых популярных задач для собеседования про тестирование лифта?
Столкнулась я тут в одном отеле с весьма необычным лифтом и стало интересно как можно протестировать его нестандартные функции.
Особенности работы такие:
1. Просто нажать на этаж, кнопка подсветится белым и через пару секунд погаснет, лифт не поедет
2. Приложить карточку, в которой прошита информация об этаже, тогда кнопка этажа загорится белым и через пару секунд погаснет, лифт всё равно не поедет
3. Приложить карточку, загоревшуюся белым кнопку нажать, она загорится красным и через пару секунд погаснет. Лифт поедет!
Какие тут могут быть кейсы? Что может пойти не так? Что бы вы предусмотрели при тестировании?
Накидывайте вариантов в комментарии 😉
Помните одну из самых популярных задач для собеседования про тестирование лифта?
Столкнулась я тут в одном отеле с весьма необычным лифтом и стало интересно как можно протестировать его нестандартные функции.
Особенности работы такие:
1. Просто нажать на этаж, кнопка подсветится белым и через пару секунд погаснет, лифт не поедет
2. Приложить карточку, в которой прошита информация об этаже, тогда кнопка этажа загорится белым и через пару секунд погаснет, лифт всё равно не поедет
3. Приложить карточку, загоревшуюся белым кнопку нажать, она загорится красным и через пару секунд погаснет. Лифт поедет!
Какие тут могут быть кейсы? Что может пойти не так? Что бы вы предусмотрели при тестировании?
Накидывайте вариантов в комментарии 😉
👍8🔥3
#вакансия
Други, у нас в SM Lab снова Weekend Offer и в этот раз не только для автоматизаторов, а вообще для всех QA инженеров! 🚀
Weekend Offer от SM Lab — это отличная возможность пройти все этапы отбора и получить от SM Lab приглашение на работу за один день.
Вилка: от 150k до 300k в зависимости от уровня кандидата
Когда: 22-23 марта 2024 года
🔎 Мы ищем QA инженеров:
❕с опытом от 2-х лет в тестировании мобильных приложений, веб-сервисов или desktop-приложений. Мы готовы рассмотреть кандидатов с коммерческим опытом работы от 1 года при наличии желания развиваться и успешного прохождения собеседования
❕с опытом тестирования API и работы с соответствующими инструментами (Postman, Insomnia и т.д.)
❕с опытом работы со сниферами трафика (Charles, Fiddler и т.д.)
❕с опытом работы с REST API, HTTP|HTTPS, JSON, SQL
❕опыт разработки автотестов на Java будет большим плюсом
Наши бонусы 😎
In-house разработка в продуктовых командах
✅ Удаленная работа в пределах РФ (возможно трудоустройство в Казахстане и в Беларуси)
✅ ЗП по рынку + полугодовые премии;
✅Скидка 30 % в наших магазинах (Sportmaster, Ostin, Funday)
✅Кафетерий льгот (ДМС, фитнес, английский)
👐 Будем рады видеть вас частью нашей команды SM Lab, заполняйте анкету по ссылке: https://bighiringday.ru
Други, у нас в SM Lab снова Weekend Offer и в этот раз не только для автоматизаторов, а вообще для всех QA инженеров! 🚀
Weekend Offer от SM Lab — это отличная возможность пройти все этапы отбора и получить от SM Lab приглашение на работу за один день.
Вилка: от 150k до 300k в зависимости от уровня кандидата
Когда: 22-23 марта 2024 года
🔎 Мы ищем QA инженеров:
❕с опытом от 2-х лет в тестировании мобильных приложений, веб-сервисов или desktop-приложений. Мы готовы рассмотреть кандидатов с коммерческим опытом работы от 1 года при наличии желания развиваться и успешного прохождения собеседования
❕с опытом тестирования API и работы с соответствующими инструментами (Postman, Insomnia и т.д.)
❕с опытом работы со сниферами трафика (Charles, Fiddler и т.д.)
❕с опытом работы с REST API, HTTP|HTTPS, JSON, SQL
❕опыт разработки автотестов на Java будет большим плюсом
Наши бонусы 😎
In-house разработка в продуктовых командах
✅ Удаленная работа в пределах РФ (возможно трудоустройство в Казахстане и в Беларуси)
✅ ЗП по рынку + полугодовые премии;
✅Скидка 30 % в наших магазинах (Sportmaster, Ostin, Funday)
✅Кафетерий льгот (ДМС, фитнес, английский)
👐 Будем рады видеть вас частью нашей команды SM Lab, заполняйте анкету по ссылке: https://bighiringday.ru
🔥13👍7❤2
#бесплатное #подборка
Други, хочу напомнить, что в описании канала есть ссылка на табличку полезностей. Я стараюсь поддерживать её в актуальном состоянии и дополняю свежатинкой 😊
Из последнего приобретения:
Систематическое исследовательское тестирование с YATTIE - кто попробует в деле, пишите свои впечатления
Зачем тестировщику CJM - статья от одного из наших QA-кураторов
Границы без границ от М.Болтона в переводе О.Алифановой - это Болтон, без комментариев :)
Экзотические баги и их устранение - всегда полезно изучить чужой опыт локализации сложных багов
Особенности тестирования десктопных приложений - свежая статья на такую редкую тему
И бонусом не про тестирование: Инженер данных открытый курс - мнение, почему надо входить в ИТ инженером данных и курс по азам этой науки
Пишите в комментариях, что было вам полезно, возможно удастся пополнить общественные полезности с вашей подачи 😊
Други, хочу напомнить, что в описании канала есть ссылка на табличку полезностей. Я стараюсь поддерживать её в актуальном состоянии и дополняю свежатинкой 😊
Из последнего приобретения:
Систематическое исследовательское тестирование с YATTIE - кто попробует в деле, пишите свои впечатления
Зачем тестировщику CJM - статья от одного из наших QA-кураторов
Границы без границ от М.Болтона в переводе О.Алифановой - это Болтон, без комментариев :)
Экзотические баги и их устранение - всегда полезно изучить чужой опыт локализации сложных багов
Особенности тестирования десктопных приложений - свежая статья на такую редкую тему
И бонусом не про тестирование: Инженер данных открытый курс - мнение, почему надо входить в ИТ инженером данных и курс по азам этой науки
Пишите в комментариях, что было вам полезно, возможно удастся пополнить общественные полезности с вашей подачи 😊
Google Docs
Public QA Knowledge Base
🔥14🤡8🗿6👍2👎2🙉2
#анонс #мемопауза
Други, после майских планирую начать серию постов про лидов/менеджеров.
А пока что немного прекрасного от Спортмастера 😊
https://t.iss.one/sportmaster_digital/87
Други, после майских планирую начать серию постов про лидов/менеджеров.
А пока что немного прекрасного от Спортмастера 😊
https://t.iss.one/sportmaster_digital/87
Telegram
Спортмастер Digital
Планы на майские: быть счастливыми 😎
Чтобы они точно реализовались, предлагаем воспользоваться нашими аватарками для мессенджеров.
Просто поставьте их на время мини-каникул, чтобы обеспечить себе защиту от прилетающих рабочих сообщений.
Сохраняйте аватарки…
Чтобы они точно реализовались, предлагаем воспользоваться нашими аватарками для мессенджеров.
Просто поставьте их на время мини-каникул, чтобы обеспечить себе защиту от прилетающих рабочих сообщений.
Сохраняйте аватарки…
🔥8
#рабочийпроцесс #яжменеджер
Други, я периодически мыслями возвращаюсь куда-то в прошлое и перевариваю свой опыт через призму накопленного. Кстати, очень полезно так поразмышлять - что сделала тогда хорошо, что можно было сделать по другому, а что вообще не было сделано, а надо было или наоборот - сделала, а не надо было. Не самобичевания для, а рефлексии ради :)
Из таких размышлизмов родилась идея серии постов про лидство/менеджерство под кодовым названием #яжменеджер, поехали!
Допустим работаешь ты такой тестировщиком/разработчиком/аналитиком/etc. И думаешь не пойти ли мне в лиды, что вообще эти лиды делают, вот сидит целый день и только по встречам "ходит" и задачи раздаёт, а денег получает уж наверняка больше, я тоже так хочу!
Для начала важно поверхностно изучить кто же такие лиды и что же они реально делают. От компании к компании, конечно, обязанности и ожидания от лида/менеджера разнятся, но есть у всех что-то общее.
Году в 11-12 меня расстроило, что на место уволившегося начальника не взяли меня, хотя я предлагала свою кандидатуру, а взяли менеджера с рынка. Поняла, что дело, видимо, во мне и начала искать информацию про менеджерство. Нашла Панкратова и Орлова (ныне компания Стратоплан), которые сами выходцы из ИТ и учат людей как быть менеджерами в ИТ. Оказалось, что менеджеру, как и инженеру, надо дофига всего знать и уметь! Спойлер: официально менеджером я стала в итоге только в 2018-м :)
Для тех из вас, кто думает податься в менеджерство рекомендую книжку "Как стать менеджером в ИТ", теперь она входит в белую книжную полку менеджера и канал Стратоплана на ютубе.
Ещё отличная лёгкая книжка - "Мама, я тимлид"
Одна из главных задач менеджера - люди. Найм, обучение, увольнения. Сделать всё возможное для того, чтобы хорошие спецы не уволились и продуктивно работали. Организовать для людей нужные технику, доступы, лицензии. Отстоять для своих людей какие-то плюшки. Обосновать повышения зп. Оградить своих людей от внешних помех (иногда и от своего лишнего вмешательства), чтобы они спокойно работали. И т.д.
Еще одна основная задача менеджера - сделать работу своего подразделения эффективной. Это бесконечное стремление к совершенству: тюнинг процессов, использование практик, подходов и инструментов, создание и отслеживание метрик для мониторинга состояния команды и своевременное уместное реагирование на всплески и просадки.
Надо быть готовым к тому, что начинающий менеджер зачастую "играющий тренер", поэтому, помимо прочего он еще и выполняет продуктовые задачи, а это две разных нагрузки, которые довольно сложно разграничить и уложить в рабочее время.
Во всех книгах про менеджмент пишут, что одна из главных проблем начинающего менеджера - неумение делегировать. Это вызывает примерно такую цепочку событий: "эту задачу могу сделать только я потому что "если хочешь сделать хорошо, сделай сам" (буквально каждую мало-мальски сложную задачу) -> у меня не хватает времени на всё -> адовые переработки -> неизбежное выгорание". К этому примешивается синдром самозванца (я не справляюсь с новыми обязанностями), что вызывает еще и неловкость при необходимости попросить помощи или совета у старших коллег и в результате начинающий менеджер остаётся один на один со своими проблемами и тонет в них. А ещё сюда примешивается недовольство твоей команды, что мол лид себе забирает самое вкусное, а мы только рутину делаем. Такая ситуация, если её вовремя не исправить, повлечёт за собой увольнения сотрудников, желающих развиваться.
Поэтому нужно заранее быть морально готовым, что задачи можно и нужно передавать, но при этом не бросать в воду, а контролировать выполнение заранее выбранным образом в зависимости от исполнителя, испорченности, важности и ситуации.
У Орлова и Панкратова мне очень запомнилась правильная мысль: "чтобы стать менеджером надо к этому подготовиться заранее". Когда вас назначают лидом, а хотя бы теоретической подготовки у вас нет, это очень тяжело. Лучше подготовиться и в итоге не стать менеджером, чем стать менеджером без подготовки.
Други, я периодически мыслями возвращаюсь куда-то в прошлое и перевариваю свой опыт через призму накопленного. Кстати, очень полезно так поразмышлять - что сделала тогда хорошо, что можно было сделать по другому, а что вообще не было сделано, а надо было или наоборот - сделала, а не надо было. Не самобичевания для, а рефлексии ради :)
Из таких размышлизмов родилась идея серии постов про лидство/менеджерство под кодовым названием #яжменеджер, поехали!
Допустим работаешь ты такой тестировщиком/разработчиком/аналитиком/etc. И думаешь не пойти ли мне в лиды, что вообще эти лиды делают, вот сидит целый день и только по встречам "ходит" и задачи раздаёт, а денег получает уж наверняка больше, я тоже так хочу!
Для начала важно поверхностно изучить кто же такие лиды и что же они реально делают. От компании к компании, конечно, обязанности и ожидания от лида/менеджера разнятся, но есть у всех что-то общее.
Году в 11-12 меня расстроило, что на место уволившегося начальника не взяли меня, хотя я предлагала свою кандидатуру, а взяли менеджера с рынка. Поняла, что дело, видимо, во мне и начала искать информацию про менеджерство. Нашла Панкратова и Орлова (ныне компания Стратоплан), которые сами выходцы из ИТ и учат людей как быть менеджерами в ИТ. Оказалось, что менеджеру, как и инженеру, надо дофига всего знать и уметь! Спойлер: официально менеджером я стала в итоге только в 2018-м :)
Для тех из вас, кто думает податься в менеджерство рекомендую книжку "Как стать менеджером в ИТ", теперь она входит в белую книжную полку менеджера и канал Стратоплана на ютубе.
Ещё отличная лёгкая книжка - "Мама, я тимлид"
Одна из главных задач менеджера - люди. Найм, обучение, увольнения. Сделать всё возможное для того, чтобы хорошие спецы не уволились и продуктивно работали. Организовать для людей нужные технику, доступы, лицензии. Отстоять для своих людей какие-то плюшки. Обосновать повышения зп. Оградить своих людей от внешних помех (иногда и от своего лишнего вмешательства), чтобы они спокойно работали. И т.д.
Еще одна основная задача менеджера - сделать работу своего подразделения эффективной. Это бесконечное стремление к совершенству: тюнинг процессов, использование практик, подходов и инструментов, создание и отслеживание метрик для мониторинга состояния команды и своевременное уместное реагирование на всплески и просадки.
Надо быть готовым к тому, что начинающий менеджер зачастую "играющий тренер", поэтому, помимо прочего он еще и выполняет продуктовые задачи, а это две разных нагрузки, которые довольно сложно разграничить и уложить в рабочее время.
Во всех книгах про менеджмент пишут, что одна из главных проблем начинающего менеджера - неумение делегировать. Это вызывает примерно такую цепочку событий: "эту задачу могу сделать только я потому что "если хочешь сделать хорошо, сделай сам" (буквально каждую мало-мальски сложную задачу) -> у меня не хватает времени на всё -> адовые переработки -> неизбежное выгорание". К этому примешивается синдром самозванца (я не справляюсь с новыми обязанностями), что вызывает еще и неловкость при необходимости попросить помощи или совета у старших коллег и в результате начинающий менеджер остаётся один на один со своими проблемами и тонет в них. А ещё сюда примешивается недовольство твоей команды, что мол лид себе забирает самое вкусное, а мы только рутину делаем. Такая ситуация, если её вовремя не исправить, повлечёт за собой увольнения сотрудников, желающих развиваться.
Поэтому нужно заранее быть морально готовым, что задачи можно и нужно передавать, но при этом не бросать в воду, а контролировать выполнение заранее выбранным образом в зависимости от исполнителя, испорченности, важности и ситуации.
У Орлова и Панкратова мне очень запомнилась правильная мысль: "чтобы стать менеджером надо к этому подготовиться заранее". Когда вас назначают лидом, а хотя бы теоретической подготовки у вас нет, это очень тяжело. Лучше подготовиться и в итоге не стать менеджером, чем стать менеджером без подготовки.
Stratoplan-School
Полезности Стратоплана
Школа Менеджеров Стратоплан
👍23🔥9👏2
#анонс #мероприятия
Други, 6-7 июля пройдёт Pro IT фест и я снова буду в нём участвовать в качестве спикера.
На этой конфе меня очень привлекают форматы выступлений: там нет уже поднадоевших докладов, где спикер вещает в режиме говорящей головы. Это очень интерактивная конференция, где каждое выступление - живой диалог спикеров и зрителей и именно в таких диалогах рождается истина! 💪
Только для вас мой специальный промокод на 10% скидки: ErmOlka, использовать его можно при покупке билетов. Учитывайте, что с 1-го июля будет повышение цен, так что успейте и до встреч 😊
Други, 6-7 июля пройдёт Pro IT фест и я снова буду в нём участвовать в качестве спикера.
На этой конфе меня очень привлекают форматы выступлений: там нет уже поднадоевших докладов, где спикер вещает в режиме говорящей головы. Это очень интерактивная конференция, где каждое выступление - живой диалог спикеров и зрителей и именно в таких диалогах рождается истина! 💪
Только для вас мой специальный промокод на 10% скидки: ErmOlka, использовать его можно при покупке билетов. Учитывайте, что с 1-го июля будет повышение цен, так что успейте и до встреч 😊
🔥9❤1
#мероприятия #анонс
Пролетели два ярких дня шикарной #TeamLeadConf
Еду домой, вспоминаю что было, что понравилось, что впечатлило и, конечно, делюсь с вами 😊
Были любопытные доклады про рост лида и в лида, а наиболее яркий для меня был доклад Эрика Бурыгина про нетворкинг. Эрик яркими примерами из своего опыта напомнил нам, что такое нетворкинг и почему он важен и нужен.
Ещё меня очень впечатлил размах мероприятия и количество и качество стендов. Спасибо всем стендистам, было круто, интересно и весело ☺️
А самое вкусное - это встречи со старыми знакомыми, с которыми не виделись очень давно - Лёша Петров, Денис Рященко, Макс Дорофеев и многие другие. Было круто встретиться и пообщаться 😊
Кстати, теперь ещё больше жду третью книгу Макса и вдохновилась дочитать сложную вторую 😅
До встреч через неделю на #ProITFest 🤗
Пролетели два ярких дня шикарной #TeamLeadConf
Еду домой, вспоминаю что было, что понравилось, что впечатлило и, конечно, делюсь с вами 😊
Были любопытные доклады про рост лида и в лида, а наиболее яркий для меня был доклад Эрика Бурыгина про нетворкинг. Эрик яркими примерами из своего опыта напомнил нам, что такое нетворкинг и почему он важен и нужен.
Ещё меня очень впечатлил размах мероприятия и количество и качество стендов. Спасибо всем стендистам, было круто, интересно и весело ☺️
А самое вкусное - это встречи со старыми знакомыми, с которыми не виделись очень давно - Лёша Петров, Денис Рященко, Макс Дорофеев и многие другие. Было круто встретиться и пообщаться 😊
Кстати, теперь ещё больше жду третью книгу Макса и вдохновилась дочитать сложную вторую 😅
До встреч через неделю на #ProITFest 🤗
👍19❤3
Други, поздравляю вас с днём тестировщика! 🥳
Мы — меч в цифровой тьме!
Мы — дозорные на Стене перед Продом!
Мы — щит, охраняющий царство ПО от полчищ жуков! 🥷
Желаю вам побольше багов, отловленных до прода и чтоб ни один крит не просочился за наши заслоны👻
И еще! Мои друзья из Moscow QA приглашают всех желающих на юбилейный Moscow QA #5 x X5 Tech!5️⃣
Куда: Москва, Варшавское шоссе, 33c12
Когда: 19 сентября 18:30
Ссылка на регистрацию:
https://moscowqa.timepad.ru/event/3023660/
И присоединяйтесь в сообщество в ВК, там будут сохранятся все записи митапов:
https://vk.com/moscow_qa
Мы — меч в цифровой тьме!
Мы — дозорные на Стене перед Продом!
Мы — щит, охраняющий царство ПО от полчищ жуков! 🥷
Желаю вам побольше багов, отловленных до прода и чтоб ни один крит не просочился за наши заслоны
И еще! Мои друзья из Moscow QA приглашают всех желающих на юбилейный Moscow QA #5 x X5 Tech!
Куда: Москва, Варшавское шоссе, 33c12
Когда: 19 сентября 18:30
Ссылка на регистрацию:
https://moscowqa.timepad.ru/event/3023660/
И присоединяйтесь в сообщество в ВК, там будут сохранятся все записи митапов:
https://vk.com/moscow_qa
Please open Telegram to view this post
VIEW IN TELEGRAM
🥰19🎉9❤2🔥1
#анонс
Други, 25-26 октября пройдёт SQA days 35, на котором я буду впервые пробовать свои силы в проведении мастер-класса.
А еще там будет наш стенд SM Lab с крутыми активностями, в разработке которых я так же принимаю участие 😊
В общем, приходите, буду рада увидеться и пообщаться!
Други, 25-26 октября пройдёт SQA days 35, на котором я буду впервые пробовать свои силы в проведении мастер-класса.
А еще там будет наш стенд SM Lab с крутыми активностями, в разработке которых я так же принимаю участие 😊
В общем, приходите, буду рада увидеться и пообщаться!
Sqadays
Мастер-класс: По ту сторону найма: мастер-класс по проведению собеседований
Приглашаю вас на мастер-класс для QA-менеджеров по найму тестировщиков, где вы получите практическое понимание процесса подбора специалистов в сфере QA. Мы базово разберем все ключевые этапы найма: от составления профиля идеального кандидата до фильтрации…
🔥13❤3
#мемопауза
Компании и их слоганы, выдуманные нейросеткой. Вы их узнаете! Пишите, какие еще забавные пародии вы бы добавили или заменили 😎
На мировом рынке:
1. Microhard — "Жёсткие решения для мягких проблем"
2. Googleplex — "Поиск бесконечных вопросов"
3. Snapcrap — "Мгновенно делимся, и все пропадает"
4. ByteDanceOff — "Танцуем с данными и уходим в тень"
5. Finstagram — "Фальшивый мир через объектив"
6. Amazoom — "Торговля скоростью света (иногда не доставляется)"
7. Twatter — "Все говорят, никто не слушает"
8. SlackOff — "Чат, в котором можно работать или не работать"
9. InstaGrim — "Ваши мрачные моменты — наша фишка"
10. Netflux — "Стримим что угодно, лишь бы был интернет"
На Российском рынке:
1. Я.Лекс — "Ваш личный голосовой советчик (и шутник)"
2. Рутек — "Технологии для тех, кто еще не заблудился"
3. Вездекарты — "Навигация везде, но не всегда туда"
4. Мэйл.радище — "Письма, которые вас найдут (или нет)"
5. Сберотека — "Здесь экономим всё: деньги, время и нервы"
6. ВКашель — "Социальная сеть, которой не хватает воздуха"
7. Озомаго — "Доставка чудес (может быть и завтра)"
8. АльфаНет — "Ваш надёжный проводник в мир неопределенности"
9. ТелеБит — "Интернет, который чувствует, когда вам не нужно"
10. Касперский Лабиринт — "Безопасность, из которой сложно выбраться"
Компании и их слоганы, выдуманные нейросеткой. Вы их узнаете! Пишите, какие еще забавные пародии вы бы добавили или заменили 😎
На мировом рынке:
1. Microhard — "Жёсткие решения для мягких проблем"
2. Googleplex — "Поиск бесконечных вопросов"
3. Snapcrap — "Мгновенно делимся, и все пропадает"
4. ByteDanceOff — "Танцуем с данными и уходим в тень"
5. Finstagram — "Фальшивый мир через объектив"
6. Amazoom — "Торговля скоростью света (иногда не доставляется)"
7. Twatter — "Все говорят, никто не слушает"
8. SlackOff — "Чат, в котором можно работать или не работать"
9. InstaGrim — "Ваши мрачные моменты — наша фишка"
10. Netflux — "Стримим что угодно, лишь бы был интернет"
На Российском рынке:
1. Я.Лекс — "Ваш личный голосовой советчик (и шутник)"
2. Рутек — "Технологии для тех, кто еще не заблудился"
3. Вездекарты — "Навигация везде, но не всегда туда"
4. Мэйл.радище — "Письма, которые вас найдут (или нет)"
5. Сберотека — "Здесь экономим всё: деньги, время и нервы"
6. ВКашель — "Социальная сеть, которой не хватает воздуха"
7. Озомаго — "Доставка чудес (может быть и завтра)"
8. АльфаНет — "Ваш надёжный проводник в мир неопределенности"
9. ТелеБит — "Интернет, который чувствует, когда вам не нужно"
10. Касперский Лабиринт — "Безопасность, из которой сложно выбраться"
🔥7👍1
#опрос
Други, нужно ваше мнение, не проходите мимо, можно в комменты писать какие-то дополнения к голосованию 😊
На какую тему писать дальше?
Други, нужно ваше мнение, не проходите мимо, можно в комменты писать какие-то дополнения к голосованию 😊
На какую тему писать дальше?
Anonymous Poll
22%
Продолжить тему про начинающего менеджера
72%
Про декомпозицию задач с точки зрения тестировщика
43%
Темы про найм с разных сторон (собесы, курьёзы и т.д.)
2%
Что-то еще, напишу в комментах
#рабочийпроцесс
С большим отрывом победил вариант про декомпозицию задач, хотя я добавляла его скорее для видимости выбора, но чтош 😅
Стоит осветить тему декомпозиции с двух сторон: декомпозиция задач на разработку внутри команды и декомпозиция задачи на тестирование самим тестировщиком. Сегодня поговорим про первое.
Часто встречалась и встречаюсь с ситуацией, когда декомпозиция задач внутри команды происходит с целью удобства написания кода. При этом удобство тестирования не учитывается и могут возникать проблемы. Зачастую тестировщики не знают как донести до менеджера/команды информацию про проблемы тестирования таких задач и продолжают есть кактус, думая, что так и должно быть.
В этом посте постараюсь охватить какие могут быть проблемы и как аргументировано донести информацию до тех, кто принимает решения.
1️⃣ Отсутствие ясности в границах задачи -> замедление процесса тестирования.
Если декомпозиция сделана скорее с технической точки зрения, т.е. задача разбита на разработку отдельных программных модулей/компонентов, то на выходе тестировщик получает разрозненные куски функционала, которые трудно, невозможно и/или бессмысленно проверять по отдельности. Это сильно замедляет процесс тестирования: приходится самостоятельно собирать «кучки» задач, которые вместе образуют что-то целостное, собирать по ним контекст, документацию, нащупывать границы (это всё еще относится к этой задаче или это уже другая?).
2️⃣ Пропущенные зависимости -> не найденные (поздно найденные) баги.
Если декомпозиция не учитывает весь контекст системы и её зависимости, тестировщик может не получить достаточной информации о том, как разработанные компоненты взаимодействуют с другими частями приложения. В таких случаях могут возникнуть следующие проблемы:
👁 Неявные зависимости: тестировщик может не знать о существовании каких-либо связей между компонентами. Например, дорабатывали модуль, который явным образом работает в процессе А, но еще неявным образом проявляется в процессе B.
🔗 Ошибки на стыке компонентов: если доработка ведется по компонентам, то интеграции между компонентами/модулями могут быть отложены на конец, а как раз там обычно кроется больше всего багов. Один из принципов тестирования гласит: «Раннее тестирование сохраняет время и деньги». Соответственно, чем позже будут обнаружены дефекты, особенно критические, тем дороже будет их исправление.
3️⃣ Проблемы с коммуникацией внутри команды из-за вышеперечисленного -> ухудшение климата в команде
Для прояснения вопросов, вызванных неудобной декомпозицией тестировщикам приходится часто обращаться к разработчикам за помощью и разъяснениями. Зачастую у разработчиков это начинает вызывать негатив и мысли типа «все тестировщики тупые, ничего сами не могут сделать». В совокупности с тем, что зачастую разработчики очень мало знают о том, что делают тестировщики, могут складываться очень напряженные отношения, что крайне негативно влияет на продуктивность команды в целом. Так же это может спровоцировать увольнения людей из команды.
Подводя итоги, скажу, что декомпозиция задач исключительно для удобства разработчиков может значительно усложнить процесс тестирования и негативно отразиться на продуктивности и эффективности работы команды. Чтобы избежать этих проблем, важно наладить тесное взаимодействие между разработчиками и тестировщиками на этапе планирования. Совместная работа над декомпозицией задач позволит учесть все аспекты, критически важные как для разработки, так и для тестирования, обеспечивая высокое качество продукта и эффективный рабочий процесс.
Если видите еще какие-то аспекты проблем, связанных с такой декомпозицией, пишите в комментах 👇
С большим отрывом победил вариант про декомпозицию задач, хотя я добавляла его скорее для видимости выбора, но чтош 😅
Стоит осветить тему декомпозиции с двух сторон: декомпозиция задач на разработку внутри команды и декомпозиция задачи на тестирование самим тестировщиком. Сегодня поговорим про первое.
Часто встречалась и встречаюсь с ситуацией, когда декомпозиция задач внутри команды происходит с целью удобства написания кода. При этом удобство тестирования не учитывается и могут возникать проблемы. Зачастую тестировщики не знают как донести до менеджера/команды информацию про проблемы тестирования таких задач и продолжают есть кактус, думая, что так и должно быть.
В этом посте постараюсь охватить какие могут быть проблемы и как аргументировано донести информацию до тех, кто принимает решения.
Если декомпозиция сделана скорее с технической точки зрения, т.е. задача разбита на разработку отдельных программных модулей/компонентов, то на выходе тестировщик получает разрозненные куски функционала, которые трудно, невозможно и/или бессмысленно проверять по отдельности. Это сильно замедляет процесс тестирования: приходится самостоятельно собирать «кучки» задач, которые вместе образуют что-то целостное, собирать по ним контекст, документацию, нащупывать границы (это всё еще относится к этой задаче или это уже другая?).
Если декомпозиция не учитывает весь контекст системы и её зависимости, тестировщик может не получить достаточной информации о том, как разработанные компоненты взаимодействуют с другими частями приложения. В таких случаях могут возникнуть следующие проблемы:
Для прояснения вопросов, вызванных неудобной декомпозицией тестировщикам приходится часто обращаться к разработчикам за помощью и разъяснениями. Зачастую у разработчиков это начинает вызывать негатив и мысли типа «все тестировщики тупые, ничего сами не могут сделать». В совокупности с тем, что зачастую разработчики очень мало знают о том, что делают тестировщики, могут складываться очень напряженные отношения, что крайне негативно влияет на продуктивность команды в целом. Так же это может спровоцировать увольнения людей из команды.
Подводя итоги, скажу, что декомпозиция задач исключительно для удобства разработчиков может значительно усложнить процесс тестирования и негативно отразиться на продуктивности и эффективности работы команды. Чтобы избежать этих проблем, важно наладить тесное взаимодействие между разработчиками и тестировщиками на этапе планирования. Совместная работа над декомпозицией задач позволит учесть все аспекты, критически важные как для разработки, так и для тестирования, обеспечивая высокое качество продукта и эффективный рабочий процесс.
Если видите еще какие-то аспекты проблем, связанных с такой декомпозицией, пишите в комментах 👇
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16👍5
#мероприятия #анонс #собеседование
Други, сегодня и завтра увидимся на прекрасной SQA Days!
Приходите на наш стенд SM Lab, на сегодня у нас шикарный квест, вам точно понравится! А завтра будет тоже кое что интересное, не пропустите 😊
Так же приглашаю вас завтра принять участие в моём мастер-классе про проведение собеседований. Будет немного теории и много практики!
Други, сегодня и завтра увидимся на прекрасной SQA Days!
Приходите на наш стенд SM Lab, на сегодня у нас шикарный квест, вам точно понравится! А завтра будет тоже кое что интересное, не пропустите 😊
Так же приглашаю вас завтра принять участие в моём мастер-классе про проведение собеседований. Будет немного теории и много практики!
🔥19❤🔥2