#общее #бесплатное
Вышла статья, в которой я участвовала в качестве эксперта! Получилось, на мой взгляд, интересно и полезно для начинающих!
https://practicum.yandex.ru/blog/chto-takoe-bug-report-kak-ego-sostavit/

Первое выступление на SQA days, да и вообще на оффлайн конференции, считаю, прошло успешно! 🥳
Спасибо всем, кто поддерживал и верил, спасибо всем, кто пришел очно или онлайн, спасибо всем, кто задавал вопросы и подошел поболтать в кулуарах после доклада! 🤗
Когда будет запись, обязательно поделюсь 😊

#общее #рабочийпроцесс
Опыт выступления на SQA days был незабываемый! При подготовке доклада я прошла все стадии принятия, в какой-то момент хотела отказаться, но увидела, что меня уже вписали в программу 😅
И вот она заветная запись моего доклада! Смотрю и умиляюсь, даже самой нравится.
Доклад "Тестируем головой, а не руками!" посвящен мануальным тестировщикам, рассказала о том, что и тестировщики делают в ходе своей работы и почему это не так просто, как кажется со стороны.

Пишите в комментариях ваши впечатления, что понравилось, что нет, какие темы еще хотели бы увидеть на конференциях в моём исполнении 😊
Ну и - подписывайтесь, ставьте лайки, делайте репосты и всё такое 😂
Приходите на следующую SQA days в Москве, тоже очень надеюсь там быть 😊

UPD: выложен ролик-интервью с SQA days про SM Lab: https://www.youtube.com/watch?v=EeIQ0cDPV6E

Поздравляю всех моих подписчиков с наступающим Новым годом! Пусть новый год принесёт нам всем радость и счастье! Лёгких релизов и прод без багов! 🥳🎄🥂🤗

Этот год был в целом довольно хорошим с точки зрения моей профессиональной деятельности и я решила поделиться своими профессиональными итогами года:
1. Устроилась в Спортмастер и это оказалась работа мечты! Те рабочие обязанности, которые я и хотела, отличнейшие люди, много интересных команд и продуктов!
2. Ушла из Я.Практикума по ряду причин и с текущей рабочей загрузкой ни разу об этом не пожалела 🤪
3. Сейчас я курирую QA в 6-ти командах (в новом году будет 7), в этих командах у меня 16 тестировщиков разных профилей (в начале нового года их будет уже 19). Среди моих команд есть, наверное, всё: 1С, десктоп на дельфях с ораклом, веб, мобилки, апишки, кассовый специфический десктоп.
4. Из моих 16 тестировщиков 10 собеседовала и нанимала я (+ 3, которые присоединятся к нам в январе)
5. В числе нанятых есть два джуна, про то, как их искала написала тут
6. Создала внутренний справочник QA и с одобрения руководства (да-да, руководитель у меня тоже очень классный!) расшарила его на всех
7. Была в составе рабочих групп для решения ряда методологических задач для всех наших команд
8. Очень неожиданно приняла участие в интервью с прекрасной Fidelina, поговорили с ней про мануальное тестирование
9. Впервые выступила с докладом в Подлодке с моим любимым ленивым рационализмом
10. Участвовала в организации стендов и активностей СпортмастерЛаб для конференций Heisenbug и SQA Days.
11. Была на Heisenbug в качестве стендиста, это был мой первый опыт стендистом 😊
12. Отдельным пунктом хочу отметить своё первое оффлайн выступление: доклад про мануальное тестирование на SQA Days
13. Участвовала в написании двух статей для блога Я.Практикума в качестве эксперта: "Что такое баг-репорт и как его составить" и вторая статья про таблицу принятия решений, она скоро выйдет, следите за новостями 😉
14. Провела несколько тестовых собеседований с развёрнутой обратной связью, надеюсь, моя помощь пригодилась ☺️

А какие у вас профессиональные итоги года? Был ли этот год, несмотря ни на что, хорошим для вас?

#общее #рабочийпроцесс
Други мои! Поговорим сегодня о процессах обеспечения качества.
Обычно всё начинается с того, что команда осознаёт, что им не хватает тестировщика и чего-то магического, что тестировщик привносит в команду для повышения качества выпускаемого продукта. По следам поста https://t.iss.one/QAJuniorFAQ/15 рассмотрим процессы. Напомню, что в посте рассматривался вариант, когда ты джун без опыта и тебя взяли в команду первым и единственным тестировщиком.
Над чем стоит подумать и что встроить в процесс разработки:
1. Самое первое – понять каков текущий процесс разработки, что туда входит и кто за что отвечает:
a. откуда начинается задача, где она заканчивается
b. кто на каком этапе принимает участие
c. где хранятся задачи
d. где лежит документация
e. занимался ли кто-то тестированием раньше, создавал ли он какие-то артефакты для этого
f. есть ли у разработчиков практика написания юнит-тестов
g. настроен ли инструмент для статического анализа кода
h. есть ли CI/CD или всё делается руками
i. какие есть тестовые стенды (если они есть) и что на каждом из них сейчас делается
2. Непосредственно процесс тестирования, т.е. в жизненном цикле разработки должен появиться этап тестирования после этапа написания кода. Что сюда входит (в идеале):
a. Сборка версии, статический анализ кода, прогон юнит-тестов, деплой сборки на тестовый стенд
b. Анализ требований, написание тестов (чек-листы, тест-кейсы – любые виды документирования тестов). Отмечу, однако, что данный этап необходимо будет потихоньку сдвигать влево, т.е. в идеале анализ требований и написание тестов должны происходить после завершения этапа аналитики и ДО написания кода
c. Проверка ПО на соответствие требованиям по написанным тестам, заведение багов, ретест багов, передача задачи дальше по процессу.
3. Процесс тестирования требований – то, о чем писала выше в пункте 2.b. Это вообще отдельная большая тема, вкратце – здесь надо проверить, что то, что написал аналитик одинаково понятно всем участникам задачи – аналитику, разработчику, тестировщику. В этом процессе тестировщику поможет составление верхнеуровневого, а может даже подробного чек-листа.
4. Процессы работы с багами. Как поступать с багами с прода, с багами с регресса и с багами из новых задач. Что делать, если баг оказался не баг и т.д.
5. Процесс выкладки в прод. Как это происходит? Позадачно? Релизами? Как часто? Насколько автоматизирован этот процесс? Много ли возникает обычно проблем при релизе? А сразу после релиза? Исходя из ответов на эти вопросы можно планировать процесс регрессионного тестирования, если он нужен.
6. Другие процессы для обеспечения качества такие, как:
a. Анализ дефектов
b. Определенные DoR и DoD для задач, эпиков, этапов и т.д. – в зависимости от процесса
c. Процессы обеспечения качества на этапе разработки – статический анализ кода, код ревью, юнит-тесты, правила написания кода для команды (нейминг, декомпозиция, оформление и т.д. – всё то, что обеспечивает читаемость кода и взаимозаменяемость разработчиков)
d. Карта функциональности: для понимания границ продукта, связей, покрытия функциональности тестами
e. Импакт анализ или анализ влияния изменений
f. Автоматизированное тестирование – определение стратегии покрытия, определение пользы и окупаемости автоматизации
g. Проведение нефункциональных видов тестирования по необходимости (юзабилити, нагрузка, безопасность и т.д.)

Всё это стоит обсуждать с командой (не сразу, а поэтапно), описывать в правилах работы команды и внедрять в работу.

#анонс #мероприятия
Сегодня и завтра на лучшей конференции для руководителей! 😍

#анонс
И снова про конференции! Скоро май, а значит и весенние 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. ещё раз напомню, что в пятницу и перед праздниками лучше не релизиться 😅
Ну и моё мнение - релизы по скоупу задач чаще всего превращаются в хаотичные, мне приятнее работать либо с календарными релизными, либо без релизов (позадачный выпуск в прод).