#анонс
И снова про конференции! Скоро май, а значит и весенние SQA days и мой доклад про анализ дефектов!
https://sqadays.com/ru/talk/106447

#рабочийпроцесс #саморазвитие
Статья, в написании которой я приняла активное участие в качестве эксперта: https://practicum.yandex.ru/blog/chto-takoe-tablica-prinyatiya-resheniy/
В статье подробно раскрывается тема одной из техник тест-дизайна - таблицы принятия решений. Техника в целом применяется довольно редко (результаты опроса по применяемым техникам можно посмотреть тут), т.к. она довольно специфична и, к тому же, мало кто понимает в каких случаях её применять и, соответственно, забывают про неё 😊

#общее #собеседование

Еще статья с моей экспертизой, на этот раз про зарплаты начинающих специалистов по тестированию и с реальными историями повышений: https://practicum.yandex.ru/blog/skolko-zarabatyvayut-testirovschiki/

P.S. не спрашивайте про картинку, я не знаю 😅

#анонс #опрос
Други, пройдите, плиз, небольшой опрос (только для тех, кто работает в ИТ проектах): https://forms.gle/bHQ79x83AyrN6GXw9
Результаты будут использованы в моём докладе на SQA days, который я анонсировала тут
Заранее спасибо!! 🤗

#анонс #вакансия
Други, если тут есть автоматизаторы, велкам к нам 😊

🚀 Weekend Offer для Java/Kotlin QA Automation.

17 июня 2023 года SM Lab проводит Weekend Offer для специалистов по автоматизации тестирования.

Weekend Offer от SM Lab — это отличная возможность пройти все этапы отбора и получить от SM Lab приглашение на работу за один день.

🔎 Мы ищем автоматизаторов:

• Опыт от 2-х лет в автоматизации тестирования на Java/Kotlin. Мы готовы рассмотреть кандидатов с коммерческим опытом работы от 1 года при наличии желания развиваться и успешного прохождения собеседования
• с опытом написания UI и/или API тестов,
• с опытом построения эффективного автоматизированного тестового покрытия,
• с опытом работы с REST, SQL.


👐 Будем рады видеть вас частью нашей команды SM Lab — заполняйте форму участника по ссылке https://qa-weekend-offer.smlab.site/ до 15 июня 2023 года.

Как обещала, результаты опроса тут
Самое интересное - в последнем вопросе, читала с удовольствием! Спасибо всем, кто оставил там свой ответ, это правда круто! 💪

#общее #бесплатное #саморазвитие

В прошлом году я выкладывала список каналов и чатов в ТГ, которые я почитываю, но всё течёт, всё меняется, поэтому решила поделиться дополнениями к этому списку. На эту мысль меня натолкнул прекрасный пост в одном из таких каналов - https://t.iss.one/testerofqa, захотелось поделиться шедевром, спасибо автору! 😊

И еще несколько чатов и каналов, которых не было в предыдущем списке:
https://t.iss.one/qa_mentors - чат, где можно найти ментора/менти по любым вопросам, связанным с QA
https://t.iss.one/courses_it - сообщество про IT курсы в целом
https://t.iss.one/qa_memes - еще мемчики про QA
https://t.iss.one/notes_about_QA - QA заметки и полезные ссылки
https://t.iss.one/qaevents - анонсы QA митапов и прочих активностей
https://t.iss.one/degrsquad - канал с очень годными мемасами на любые темы
https://t.iss.one/ITMeeting - канал с анонсами IT мероприятий
https://t.iss.one/devopslove - канал про девопс
https://t.iss.one/Remoteit - IT вакансии на удаленку
https://t.iss.one/testspro1c - сообщество тестировщиков 1С, обсуждаются в основном вопросы автоматизации
https://t.iss.one/meetup_today - еще анонсы IT митапов
https://t.iss.one/itdustmonkey - стишки-пирожки-порошки и прочие приколюшки про работу в IT

Делитесь в комментах, какие еще интересные чаты и каналы вы знаете 😊

#общее #бесплатное #саморазвитие

По следам предыдущего поста делюсь еще полезным и прекрасным:
Подборка бесплатных курсов по тестированию: https://t.iss.one/it_and_balance/69
Отличное интервью про корпоративные культуры: https://t.iss.one/ask_catwomenko/109

#рабочийпроцесс #релиз
Релиз менеджмент или управление релизами.
В каждой команде рано или поздно встаёт вопрос о том, как лучше релизиться - лучше и для команды и для пользователей и для бизнеса. Почему я решила об этом написать в канале про тестирование? Тестировщики, как правило, принимают непосредственное участие в релизных процессах и нередко берут на себя роль релиз-менеджера.
Расскажу об основных подходах, с которыми сталкивалась в работе или слышала от коллег и накопала материалов. Это будет серия постов с тегом #релиз, в каждом посте будет рассказано про один из подходов. Пишите в комментах про какие релизные подходы и практики вы слышали и/или хотели бы узнать подробнее.

#рабочийпроцесс #релиз

Релиз по расписанию.
Основной принцип: есть согласованный командой и бизнесом релизный календарь с определенной периодичностью релизов (раз в две недели, например). Задачи, которые войдут в релиз могут заранее планироваться с определенной вероятностью, но финальное решение по вхождению определенных задач в релиз принимается в день отсечки релизной ветки исходя из готовности задач.
Как выглядит процесс: есть определенные даты-отсечки (согласно тому же календарю), в которые решается, какой скоуп задач войдет в ближайший релиз, т.е. что уже готово к регрессу. В эти даты отсекается релизная ветка и туда больше никакие новые задачи не вносятся (даже если очень хочется, даже если прям очень-очень хочется, ну ладно, только маленькую срочную багулечку, так и быть). На этой ветке проводится регрессионное тестирование и если всё хорошо, в условленную дату ветка льётся в прод.
Подводные камни: бывает, что возникают какие-то неурядицы и релиз задерживается на день-два-неделю и тут нужны договорённости в команде что с такими ситуациями делать. Могут быть, например, такие варианты:
1. релиз во вторник, если не успеваем, то максимум в четверг. Если не успели к четвергу, то релиз сгорает и к следующей календарной релизной дате готовится уже новый релиз согласно релизному календарю
2. релиз во вторник, максимум в четверг. Если возникли сложности, то ищется задача, из-за которой они возникли и выпиливается из релиза, после чего проводится смоук и релиз едет в прод, а проблемная задача едет в следующий релиз
Задача тестировщика: вовремя давать обратную связь по задачам, которые планируются в релиз и вовремя давать обратную связь по регрессу
Задача релиз-менеджера (не технического):
1. следить, чтобы на запланированных в релиз задачах был проставлен соответствующий релиз
2. следить, чтобы задачи, выпадающие из релиза лишались отметки релиза/переносились в следующий релиз
3. следить, чтобы в назначенный день все готовые к релизу задачи были слиты в релизную ветку, а не готовые НЕ слиты!!
4. следить, чтобы в релизную ветку не добавлялись новые задачи после отсечки
5. отслеживать степень готовности релизной ветки к выпуску и вовремя предпринимать нужные действия, чтобы выпустить релиз в срок
6. при необходимости готовит материалы для оповещения бизнесу по релизнутым задачам и релиз ноутс для пользователей

P.S. привела примеры, когда релиз во вторник, потому что считаю этот день наиболее приемлемым по нескольким причинам:
1. до пятницы еще далеко, так что если релиз не получится во вторник, можно релизнуть в среду или даже в четверг
2. уже не понедельник, так что схема в идеале такая: регресс заканчивается в пятницу, в понедельник проводятся подготовительные тех.работы (и заканчиваются последние проверки, которые не успели в пятницу) и во вторник релиз
4. почему не стоит релизить в пятницу - думаю не надо объяснять, но если надо - напишите в комментариях 😊

#общее #собеседование

И снова статья с моим участием, на этот раз про собеседования джунов-тестировщиков: https://practicum.yandex.ru/blog/kak-proyti-sobesedovanie-na-testirovschika/

Есть вопросы-пожелания-предложения? Пиши в комменты! 😊

P.S. картинка традиционно странная 😅

#рабочийпроцесс #релиз

Релиз по скоупу задач.
Основной принцип: после/перед/во время каждого релиза происходит планирование следующего. Со всеми сторонами согласовывается чёткий список задач, которые будут выпущены в следующем релизе и очень примерные сроки этого релиза. Когда оговоренные задачи готовы, происходит отсечка релизной ветки и никакие другие задачи в неё не входят.
Как выглядит процесс: во время планирования релиза задачи набираются из беклога команды, обсуждаются, примерно оцениваются, исходя из этого даётся примерный срок выпуска релиза (тут лучше всего оговаривать три варианта: оптимистичный, пессимистичный и нормальный). Ко времени, когда все задачи готовы (разработаны и протестированы), отсекается релизная ветка. Важно, чтобы новые, не оговоренные задачи, не входили в релиз, чтобы не происходило раздувание скоупа и усложнение регресса. На релизной ветке проводится регресс, вносятся правки обнаруженных багов и если всё хорошо, ветка льётся в прод (тут хорошо бы проводить ретро по релизу и смотреть попали ли мы в оценки и сроки и если нет, то почему и как в следущий раз оценивать точнее).
Подводные камни: бывает, что возникают какие-то срочные задачи, которые не вошли в релиз и такие моменты стоит заранее проговорить и зафиксировать правила, например, золотое правило: "впихивая невпихуемое выпихивается ранее впихнутое", т.е если надо добавить срочную задачу, то какую-то другую, аналогичную по оценке задачу мы из скоупа убираем.
У этого подхода довольно высокий риск скатиться к хаотичным релизам (про них напишу позже).
Задача тестировщика: примерно такая же, как и всегда - вовремя давать обратную связь по задачам, которые планируются в релиз и вовремя давать обратную связь по регрессу.
Задача релиз-менеджера (не технического):
1. следить, чтобы на запланированных в релиз задачах был проставлен соответствующий релиз
2. следить, чтобы команда занималась только релизными задачами или техническими, если релизные закончились
3. договариваться с заказчиками про "внезапные срочные" задачи и вовремя выпихивать ещё не начатые задачи, добавляя на их место "срочные"
4. следить, чтобы в нужное время все релизные задачи были слиты в релизную ветку, а не релизные НЕ слиты!!
5. отслеживать степень готовности релизной ветки к выпуску и работать с рисками, угрожающими затянуть релиз.
6. при необходимости готовить материалы для оповещения бизнесу по релизнутым задачам и релиз ноутс для пользователей.

P.S. ещё раз напомню, что в пятницу и перед праздниками лучше не релизиться 😅
Ну и моё мнение - релизы по скоупу задач чаще всего превращаются в хаотичные, мне приятнее работать либо с календарными релизными, либо без релизов (позадачный выпуск в прод).