Други, поздравляю вас с днём тестировщика! 🥳
Мы — меч в цифровой тьме!
Мы — дозорные на Стене перед Продом!
Мы — щит, охраняющий царство ПО от полчищ жуков! 🥷

Желаю вам побольше багов, отловленных до прода и чтоб ни один крит не просочился за наши заслоны 👻

И еще! Мои друзья из Moscow QA приглашают всех желающих на юбилейный Moscow QA #5 x X5 Tech! 5️⃣

Куда: Москва, Варшавское шоссе, 33c12
Когда: 19 сентября 18:30
Ссылка на регистрацию:
https://moscowqa.timepad.ru/event/3023660/

И присоединяйтесь в сообщество в ВК, там будут сохранятся все записи митапов:
https://vk.com/moscow_qa

#рабочийпроцесс
С большим отрывом победил вариант про декомпозицию задач, хотя я добавляла его скорее для видимости выбора, но чтош 😅
Стоит осветить тему декомпозиции с двух сторон: декомпозиция задач на разработку внутри команды и декомпозиция задачи на тестирование самим тестировщиком. Сегодня поговорим про первое.

Часто встречалась и встречаюсь с ситуацией, когда декомпозиция задач внутри команды происходит с целью удобства написания кода. При этом удобство тестирования не учитывается и могут возникать проблемы. Зачастую тестировщики не знают как донести до менеджера/команды информацию про проблемы тестирования таких задач и продолжают есть кактус, думая, что так и должно быть.
В этом посте постараюсь охватить какие могут быть проблемы и как аргументировано донести информацию до тех, кто принимает решения.
1️⃣ Отсутствие ясности в границах задачи -> замедление процесса тестирования.
Если декомпозиция сделана скорее с технической точки зрения, т.е. задача разбита на разработку отдельных программных модулей/компонентов, то на выходе тестировщик получает разрозненные куски функционала, которые трудно, невозможно и/или бессмысленно проверять по отдельности. Это сильно замедляет процесс тестирования: приходится самостоятельно собирать «кучки» задач, которые вместе образуют что-то целостное, собирать по ним контекст, документацию, нащупывать границы (это всё еще относится к этой задаче или это уже другая?).
2️⃣ Пропущенные зависимости -> не найденные (поздно найденные) баги.
Если декомпозиция не учитывает весь контекст системы и её зависимости, тестировщик может не получить достаточной информации о том, как разработанные компоненты взаимодействуют с другими частями приложения. В таких случаях могут возникнуть следующие проблемы:
👁 Неявные зависимости: тестировщик может не знать о существовании каких-либо связей между компонентами. Например, дорабатывали модуль, который явным образом работает в процессе А, но еще неявным образом проявляется в процессе B.
🔗 Ошибки на стыке компонентов: если доработка ведется по компонентам, то интеграции между компонентами/модулями могут быть отложены на конец, а как раз там обычно кроется больше всего багов. Один из принципов тестирования гласит: «Раннее тестирование сохраняет время и деньги». Соответственно, чем позже будут обнаружены дефекты, особенно критические, тем дороже будет их исправление.
3️⃣ Проблемы с коммуникацией внутри команды из-за вышеперечисленного -> ухудшение климата в команде
Для прояснения вопросов, вызванных неудобной декомпозицией тестировщикам приходится часто обращаться к разработчикам за помощью и разъяснениями. Зачастую у разработчиков это начинает вызывать негатив и мысли типа «все тестировщики тупые, ничего сами не могут сделать». В совокупности с тем, что зачастую разработчики очень мало знают о том, что делают тестировщики, могут складываться очень напряженные отношения, что крайне негативно влияет на продуктивность команды в целом. Так же это может спровоцировать увольнения людей из команды.

Подводя итоги, скажу, что декомпозиция задач исключительно для удобства разработчиков может значительно усложнить процесс тестирования и негативно отразиться на продуктивности и эффективности работы команды. Чтобы избежать этих проблем, важно наладить тесное взаимодействие между разработчиками и тестировщиками на этапе планирования. Совместная работа над декомпозицией задач позволит учесть все аспекты, критически важные как для разработки, так и для тестирования, обеспечивая высокое качество продукта и эффективный рабочий процесс.
Если видите еще какие-то аспекты проблем, связанных с такой декомпозицией, пишите в комментах 👇

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

Други, мы тут с великолепным @NeonAether поучаствовали в подкасте Деплой, поговорили про обеспечение качества, процессы тестирования, автоматизацию и просто лампово поболтали. Посмотреть, поставить лайки и написать комменты можно тут:
📱 Деплой
📱 Деплой (время такое 😅)
И конечно буду рада вашим впечатлениям, вопросам и комментам здесь 😊

Пользуясь случаем, рекомендую всем интересующимся присоединиться к полезному каналу Грамота от Кузьмича, где Саша ака @NeonAether делится опытом автоматизатора-джависта 🤖

Минутка родственной рекламы 😊
Моя замечательная сестра в поисках нового места работы, если в вашей компании нужен продакт, проджект и иже с ними, закиньте резюмешку, мы будем признательны. Так же ссылочка на её 📱 linkedin

Вкратце от сестры:

Работаю в сфере управления проектами в IT.
Последние несколько лет я занимаюсь следующим:
· создаю лендинги/ мобильные приложения для ивентов
· придумываю и реализовываю функции геймификации и взаимодействия с аудиторией
· подключаю платежные системы, сервисы рассылки, платформы для онлайн-трансляций
· создаю аккредитационные центры деловых форумов (доработка и настройка ПО, создание личных кабинетов, администрирование баз данных, автоматизация рассылок, использование RFID технологий для систем контроля доступа)
· организовываю обучения по использованию ПО

Меня увлекло создание IT продуктов, потому что они делают бизнес-процессы более эффективными и упрощают организацию работы.

Мои сильные стороны:
· Опыт работы с Заказчиками: сотрудничала с компаниями (Авито, Philip Morris, ИКЕА, Adidas, Минфин и многими другими)
· Управление командами: распределенные проектные группы до 20 человек
· Финансовое управление: бюджеты до 100 млн. руб.
· Работа с подрядчиками: поиск, мотивация, контроль
· Проектная документация: составление брифов, планов работ, смет, требований, фич-листов, прототипов (Figma), Use Case и других артефактов.
· Методологии: Agile, Waterfall
· Английский язык: уровень B1.

Я люблю решать сложные задачи и работать с командой, чтобы достигать общих целей. Внимание к деталям и стремление к самосовершенствованию — это часть меня.

Я открыта новым знакомствам и возможностям.
Со мной можно связаться в телеграмм: https://t.iss.one/polonskaya_n.

#общее #саморазвитие #рабочийпроцесс #яжменеджер

Привет, други!
Сейчас, в период поиска нового прекрасного места приложения своих сил (спасибо всем, кто откликнулся на предыдущий пост!!), появилось время порефлексировать. А тут еще и на Пикабу поднялась волна «Что я узнал за энцать лет в профессии» (привет пикабушникам). Вот я и задумалась – а что я узнала за свои 17 лет в QA и получился довольно объёмный, аж на два поста, мой топ 10 (даже 11) 😎

1. Терпение — это когда ты уже не орёшь чаечкой, а идёшь заваривать чаёк ☕️
Потому что баг, о котором говорила три спринта назад, что он критичный, а его посчитали минорным и пустили в прод, всплыл у пользователя и теперь вся команда на ушах.
Потому что три созвона наложившихся на время обеда – не беда.
Потому что твой тестировщик хочет повышения, но ничего для этого не делает и только ноет, а ты спокойно выслушиваешь и рекомендуешь что делать и так по кругу.
Потому что на собесы приходят недоджуны с не очень горящими глазами и запросами сеньоров, но не все ведь такие!

2. Детали — это ловушка для перфекционистов, в которой кроется дьявол.
Поехала вёрстка? Ссылка не того цвета? Реальность абсолютно расходится с макетом и требованиями? И вот ты уже три часа доказываешь, что это баг, а не фича, чтобы не получилось, как в п.1. Внимание к мелочам — это когда ты видишь баг там, где остальные видят "нормально же". А еще сюда же бонус – профдеформация! У тебя теперь есть суперспособность видеть баги вообще везде так, что создаётся впечатление, как будто они тебя преследуют 🪲

3. Коммуникация — это искусство не прибить никого и сделать так, чтобы команда работала слажено и на одной волне.
Суметь объяснить разработчику, что его код сломал критичную функциональность, несмотря на его "у меня же всё работает" – это порой виртуозное искусство.
А в качестве лида надо поддерживать мотивацию команды даже в условиях полной жопы вокруг — мой новый уровень дипломатии. Я теперь не просто переговорщик, а еще иногда и террорист, и заложник в одном лице 🥷
А ведь еще и собеседования, и 1-1 и еще много видов коммуникаций и все разные и интересные! И каждый раз что-то новенькое, не соскучишься!

4. Технологии новые, а люди одинаковые и в то же время разные!
Flash умер, React родился, а кнопка "Купить" всё равно не работает, если кликнуть дважды. А разработчику всё еще надо доказать, что это баг (см. предыдущий пункт)!
Вообще в качестве лида я не очень успеваю следить за новыми технологиями и некоторые вещи узнаю от своих тестировщиков. И на встречах помимо прочего мы обсуждаем новинки: что-то я рассказываю, чем-то делятся инженеры. Это очень круто, когда твои тестировщики такие умнички! 🫶

5. Автотесты всё сами сделают, пока ты посидишь на шезлонге с коктейлем? Ха-ха и еще раз ха!
На заре своей карьеры, когда я узнала про существование автоматизации, я была уверена, что автотесты спасут мир. А потом поняла: пока ты пишешь автотест, другие 10 автотестов устаревают и их надо поддерживать. Абсолютно всё не автоматизируешь. Ручное тестирование никуда не денется в любом случае. Нужен правильный баланс, а для каждого проекта и команды этот баланс свой и надо его нащупывать. При чём баланс не статичен, он постоянно меняется в зависимости от миллиона параметров. Особенно важно думать про баланс, когда ты лид и надо и рыбку съесть…и косточкой не подавиться 😅

6. Ошибки — лучший учитель, но непростой… И чем больше людей под твоей ответственностью, тем выше цена ошибки.
Когда ты тестировщик, то самая большая ошибка - пропустить баг в прод. И вот твой баг уже звезда ретро!
Когда ты лид, то ошибки будут и в найме, и в построении процессов, и во внедрении изменений и в коммуникациях с командой/другими лидами. Последствия ошибок будут в потерях денег/времени/сил/хороших кадров.
Но, как и раньше — каждый косяк — это урок, за который хочется сказать "спасибо", но почему-то через зубы 😬

#ментор #наставник

Други! Предлагаю желающим свою консультационно-менторскую помощь. Это могут быть разовые консультации или серия менторских встреч по темам:
1️⃣ Мануальное тестирование для начинающих: обзор всё-обо-всём, конкретные темы по запросу, практическое применение теории и т.д.
2️⃣ Мок-собеседование для мануального тестировщика любого уровня: если вы не уверены в успехе прохождения собеседований, нужна развернутая обратная связь по итогам, чтобы подтянуть слабые места и т.д.
3️⃣ Процессы мануального и автоматизированного тестирования - построение с нуля, поддержка и обновление, обоснование для руководства и т.д.
4️⃣Начинающие лиды: разберем ваши проблемы и затыки, дам развернутую обратную связь, рекомендации и материалы.
5️⃣Другие темы по запросу (кроме технической стороны автоматизации) - пишите, обсудим.

💵Цена вопроса разовой консультации для моих дорогих подписчиков 5000 4000 за час. Обычно одна такая консультация занимает 2-3 часа.

Для серии менторских встреч цена договорная, пишите, обсудим.

💡 Так же могу оказать консультации юридическим лицам по договору ГПХ, если вам нужно провести, например, аудит процессов и дать рекомендации по улучшению и решению проблем или провести технические собеседования для найма хороших тестировщиков.

👉 По вопросам и за подробностями пишите в комменты или в личку: @OlkaEr.