Импакт от профессионального сообщества

Небольшой дисклеймер. Я люблю думать и писать “про вообще”, так как имею мнение, что работа с идеями и ценностями в долговременной перспективе приносят больший профит, чем навыки работы с техническими инструментами.
Так что постов “про вообще” тут будет намного больше, чем чего-то другого. Вот и сейчас простите за неровный почерк.

Навеяло обсуждением в сообществе. Допустим, есть локальное соо с определенными мнениями, идеями, ценностями. Может ли это сообщество влиять на мнения, идеи, ценности на более системном уровне? И если может, то в какой степени и каким способом?

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

1) Значительно выросла уверенность, я стала смелее предлагать какие-то решения на работе и показывать свои результаты в явном виде

2) Отрастила себе дополнительные амбиции и начала делать то, что раньше не делала. Например, я никогда не рассматривала себя как спикерку, однако…
… Примерно год назад я наконец выступила публично на оффлайн митапе с 15-минутным докладом на английском
… Весной приняла участие в круглом столе на конференции Podlodka QA Crew
… Летом (вот прямо сейчас!) в числе команды админок организовала онлайн конференцию для профессионального сообщества (про нее напишу отдельно после 15 июля). Более того, подготовила и представила свой собственный доклад для нее.

3) Стала гораздо более широко смотреть на профессиональный рост и видеть больше возможностей, чем раньше (когда я думала, что рост = узнать 100500 новых инструментов и выучить java)

4) Чуть менее, чем полностью поменяла свое взаимодействие с командой (об этом потом отдельно напишу)

С другой стороны, мы растем профессионально. Чем дальше, тем больше у нас возможностей менять ситуацию "наверху". Мы можем транслировать наши идеи коллегам, на конференциях, в неформальном общении. Увы, если вы джуниня, вряд ли будет много людей, которые будут вас слушать (пока). Но когда вы сеньорка, тим лидиня или лидиня лидов, нанимающая менеджерка - возможность повлиять на что-то возрастает многократно. А сегодняшние джунини через N лет будут в числе тех, кто привносит изменения "сверху":)

Кажется, что “низовые” изменения в рамках соо создают предпосылки и фундамент для изменений "наверху". Даже если сейчас большого эффекта не видно - верю, что он будет рано или поздно. Штош, посмотрим:)

Работа с командой

Хочется докрутить тему с положительным импактом от сообщества и пойти уже наконец спать.

Что я делаю (что не делала раньше):

- В явном виде говорю, что я ожидаю 4-6 часов сфокусированной работы в день, в остальное время ожидаю, что сотрудник условно on call (диффузно думает про что-то рабочее, переключается на статью, которая показалась интересной в данный момент, и т п). Если у коллеги много glue work и коммуникаций, эта цифра может быть еще меньше
- Помогаю людям авторизовать их работу
- Праздную с ними результат ("ура! ты это сделала!")
- Подсвечиваю моменты/риски, связанные с glue work
- Нормализую фрустрацию от неопределенности (в определенных пределах)
- Поощряю проявлять смелость и говорить об ошибках. Сама говорю о своих ошибках и тех выводах, которые сделала из них
- Признаю их экспертизу в тех границах, в которых я им делегировала обязанности. Позволяю им принять их собственное решение, даже если не уверена на 100% что оно верное
- Борюсь с кодоцентричностью и нормализую рост в сторону "просто QA инженера" (но мы-то знаем, что это ничуть не просто)
- Помогаю коллегам справиться с трепетом перед более опытными людьми и разработкой; доношу, что они тут работают, а не "помогают" Умным Дядям И Тетям
- Учу говорить "нет". Однажды моя коллега заметила: “Нельзя опереться на тех, кто не может сказать “нет” и я полностью с этим согласна.

Очень понравилось, как Оля сформулировала, так что вынесу из комментов

Контроль качества в FinTech - 1

Несколько месяцев назад я сделала доклад про FinTech на локальном митапе и с чем его едят с точки зрения QA.
Времени было мало, всего минут 15, а надо было успеть еще и про нашу компанию рассказать:) Хочу немного дораскрыть тему именно контроля качества.

Что такое FinTech? Если точнее - тот FinTech, который биржи и все, что вокруг них. Общая идея кажется исключительно простой.
Кто-то хочет что-то купить (желательно подешевле), кто-то хочет что-то продать (желательно подороже).
Ну вроде все.

Что спрятано за этой простой идеей?

- Финансовые инструменты (опционы, акции, фьючерсы, форекс и т д). Сотни, тысячи, десятки, сотни тысяч. Иногда миллионы. Сделки для этих инструментов обрабатываются по-разному и должны тестироваться отдельно. Плюс управление инструментов сама по себе отдельная огромная функциональная область, они могут попадать в систему из самых разных источников - интеграций, каждая интеграция это отдельный контракт, который нужно оттестировать, и т. д.

- Интерфейсы - desktop / web/ mobile. Это не только те приложения, которые используются конечными пользователями для инвестирования или спекуляций, но и бэкофис приложения, и приложения для дилеров. Уровень сложности тут может быть любой, вплоть до десктопа для удовлетворения всех желаний пользователя уровня “гуру”

- Репортинг. Банковские выписки 100500 видов и вот это все

- Котировки по всем инструментам и различные источники котировок. На одной и той же системе пользователи могут получать котировки через совершенно разные интеграции. Технологии, которые используются для передачи котировок, тоже могут сильно отличаться

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

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

- Локализации. Один и тот же брокер может работать в десятках стран, отсюда требования, связанные с локализацией. Мне сейчас кажется, что просто перевод штук на 20 языков это плюс-минус минимум, с которым я сталкивалась. Максимум, с которым лично я работала - это около 20 языков, около 60 вендоров. У нас была отдельная команда, которая занималась исключительно локализациями. Количество QA инженеров там варьировалось от 1 до 4. За примерно 4,5 лет работы мы написали (и поддерживали) 12 000 тестов исключительно для локализаций (на эту тему будет отдельный пост)

- Внутренняя логика, которая еще более сложна, чем внешняя. Даже если у QA инженера есть опыт работы в конкретной компании, при смене проекта с ненулевой вероятностью все равно будет сложно. Лично я сменила несколько проектов, и каждый раз новый проект первое время вызывал некоторый священный ужас ступор. Потом все налаживалось, конечно)

- Бэкенд, состоящий из множества компонентов. Про архитектуру приходится думать часто, много, и, конечно, учитывать ее при тестировании.

- Перформанс. Представляете, какая должна быть производительность у системы, поддерживающей сотни тысяч или даже миллионы финансовых инструментов? При этом по каждому инструменту капают котировки (которые могут меняться несколько раз в секунду). Пользователи, конечно, на эти инструменты не только смотрят, но и торгуют ими, поэтому система должна обрабатывать сотни сделок в секунду (желательно максимально быстро)

Контроль качества в FinTech - 2

- Легаси - обратная сторона эпичности:) Если у вас эпичный проект, то он или уже сейчас имеет многолетние культурные слои, или будет их иметь через некоторое время (если не загнется). FinTech не исключение. Проекты могут длиться годами и десятилетиями. Некоторые брокеры в принципе нацелены на работу с пользователями вдолгую. Им важно не только привлечь новых клиентов, но и удержать старых, которые пришли 5-15-20 лет назад

- Поддержка: исследование инцидентов, отработка фейловер процессов, миграции с систему на систему…

- Интеграции как с третьими сторонами, так и в качестве третьей стороны. Обработка сделок, подписка на котировки, логин, настройки пользователей и групп пользователей, сервисы аналитики, пуш уведомления - список можно продолжать.

То есть можно сформулировать следующие челленджи:

- Очень Много Всего:)
- Это “Много Всего” еще и сложно устроено

Контроль качества в FinTech - 3

Как с этим можно справиться? Если очень коротко, то примерно так.

На стадии работы с требованиями и тест-анализа:

Подходим как со стороны пользовательских сценариев и ценности для пользователя, так и со стороны ценности для бизнеса (эти две ценности могут отличаться:) . Обязательно лезем под капот. Помогают вопросы для самопроверки: могу ли я определить, какие риски могут сработать после доставки на продакшен? Как это будет проявляться? Если что-то случится, как я буду это исследовать? Как эти риски можно закрыть или смягчить?

На стадии тестирования:

Фичи в типовом случае тестируются ин-бранч и мержатся только после подтверждения со стороны QA. Это, позволяет взять фичу в тестирование максимально быстро. Также это помогает избегать возни с откатыванием изменений, если фича оказалась совсем уж плохо сделанной или вообще все сломала.

Идеальный “сдвиг влево” может не получиться в конкретном контексте. Например, если по каким-то причинам накопилась большая очередь задач. Но это то, к чему мы фоново стремимся.

Регрессионное тестирование строится на анализе рисков. На моем текущем проекте, например, около 20 000 тестов. Гонять полный регресс для каждого релиза просто невозможно, поэтому сначала оцениваем риски, затем выбираем тесты для регрессионного тестирования, которые эти риски покрывают. Автоматизированного тестирования это тоже касается. Коллега в прошлом году делал доклад на эту тему Switchboard: QAOps Swiss Knife in Action!

Обычно во время тестирования вскрываются дополнительные риски, которые могут сработать на продакшен системе - соответственно, с этими новыми рисками тоже надо что-то делать. Подсвечивать, обсуждать и в итоге закрывать / смягчать.

Когда релиз готов к доставке?

- Тестирование завершено, блокеры для доставки найдены и пофикшены
- Есть список рисков для продакшен системы
- Есть план, что делать, если тот или иной риск сработает

Конечно, это еще не все. Дальше наступает фаза саппорта, и лично я считаю ее самым большим вызовом. Только после доставки становится ясно, насколько мы действительно сделали хорошую работу. Во время анализа инцидентов наступает понимание, насколько глубоким и точным был тест-анализ, все ли мы поняли про фичу или упустили что-то важное.

Это осознание может быть довольно болезненным, но я предпочитаю смотреть это как на боли роста:)

Контроль качества в FinTech - 4

Технологии: когда-нибудь (но это не точно) я принесу сюда красивую картинку с логотипами технологий/подходов, которые используются конкретно в нашей компании. Но, если честно, мне самой не кажется, что это самое важное.

Картинка очень красивая и производит впечатление, но без тест-анализа этими технологиями можно будет подтереться эти технологии помогут примерно никак.

Приведу максимально простой пример.

Допустим, есть окошко продажи чего-то там, ну не знаю, яблок.
Пользователь может поставить цену, по которой он хочет продать свои яблоки пакетами по 10 шт.

Правило валидации цены такое: Market price - D ≤ Price ≤ Market price + D
Где Market price - текущая рыночная цена пакета яблок (котировка)
D - некая дистанция.
То есть пользователь может поставить цену продажи в пределах текущей котировки +/- D.

Все это выглядит как задача с курсов для начинающих тестировщиков) Классы эквивалентности, анализ граничных значений, вот это все.

Действительно, задача тут сводится к применению простейших техник тест дизайна. Но с нюансами:

- котировки постоянно меняются, то есть нужно проверить валидацию цены при условии, что критерии валидации в каждый момент времени разные
- на коридор допустимых значений цены влияет параметр D, который приходит с бэкенда
- …а на наш бэкенд этот параметр приходит из двух разных источников (внешних интеграций)

Это в целом простая задача. Она покрывается тестами часа за 3-4 более-менее сфокусированной работы и тестируется примерно за такое же время. Еще пару часов я обычно накидываю на проверку багфиксов. Тем не менее, даже тут есть моменты, об которые можно споткнуться. Примеры:

- Не задать вопрос “что конкретно сделано” и неправильно оценить скоуп тестирования. Представим, что были обновлены контракты для обеих двух интеграций, а протестирован только UI для одной интеграций. Или наоборот - было маленькое изменение на фронтенде, а протестированы обе интеграционные цепочки
- Не захотеть возиться с проверкой точных граничных значений. Проверить валидацию на глазок, вместо того, чтобы задать вопрос “а не могу ли я как-нибудь так остановить котировки или/или посылать нужные значения котировок?”

Если эти вопросы не были дожаты до конца, может оказаться, что протестировано совсем не то, что нужно.

Мораль:

- Технологии это хорошо, но недостаточно. Нужны суперсилы в области тест-анализа
- Сдвиг влево и анализ рисков при планировании регресса - наши друзья

Вот доклад, с которого все началось: How we work in QA team (на английском)
Различия: в докладе меньше подробностей, но есть картинки.

Контроль качества в FinTech - 5

Возможные опасения насчет работы в FinTech (прокомментирую, опираясь на свой опыт):

1) Бюрократия

Очень зависит от контекста. На части проектов была только типовая документация (тесты, тест раны, тест планы, отчеты о тестировании). Где-то была более сложная система документов, необходимых для допуска релиза к доставке, но этими документами занималась не я, а менеджеры уровнем выше.

2) Ограничения, связанные с безопасностью

Действительно, бывает, что нужно работать строго из офиса (после ковида таких ограничений стало меньше). Бывает, что нужно использовать виртуальный десктоп. Бывает, что нужно ждать неделю - месяц всех доступов.
А бывает и наоборот. Тебя добавляют в проект, сразу подхватываются примерно все основные настройки доступов и можно начинать работать. В процессе работы может обнаружится, что пары доступов все же не хватает, но в целом за 1-5 дней все эти проблемы разруливаются.

3) Сроки, спускающиеся сверху

Опять же важен контекст. Но в моей практике не было случаев, чтобы команду вообще не слушали. Команда может упустить момент и не вовремя сказать “нет”, или может быть мучительный процесс переговоров, что оставить в скоупе, что выкинуть. Результат этих переговоров опять же может быть неидеален.
Но в целом не было такого, что спустили задачу и делай что хочешь, но успей за месяц.

4) Плохое качество тестовых сред (нестабильность, пропажа тестовых данных).

Опять же сильно зависит от контекста.
Если это личная on demand environment, то она может быть очень нестабильна.
Если это QA платформа, на которую доставили релиз - там обычно все неплохо.
Если это QA платформа с кучей внешних интеграций - вероятность шатаний увеличится.

5) Проблемы с коммуникациями между отделами/командами, зависимость от доброй воли людей

Бывает, что сложно порешать вопросики просто потому, что много людей вовлечено в проект. Или потому, что не понятно на 100%, к кому идти с конкретным вопросов. Но чтобы было завязано именно на добрую волю - нет, не сталкивалась с таким. Или сталкивалась, но не заметила:)

6) Максимально механистическое отношение к людям

Такого, что прямо слова хорошего не скажут, иди работай как робот или сдохни - с таким я не сталкивалась, к счастью:)

На мой взгляд, перечисленные риски скорее про проекты / команды, а не про предметную область.
Возьмем менеджера из FinTech, который относится к людям как к ресурсу. Вынем менеджера из FinTech и поместим, допустим, в E-commerce. Что произойдет с его стилем менеджмента? Что-то мне подсказывает, что ничего.

Так, может, не в FinTech дело-то?...

Коротко о производственном оптимизме

Небольшое дополнение к посту про рост

Возможно, там не считывается ирония по отношению к вопросам вроде

- Я работаю уже год, почему я все еще не миддл?
- Полгода в профессии, делаю задачи на уровне старших коллег, но получаю зарплату как джун. Как показать менеджменту, что я заслуживаю более высокой оплаты?
- Уже несколько месяцев в тестировании, уже все понятно, расти некуда:(

Что я имею тут сказать. Бывают случаи, когда за год кто-то вырастает в полноценного миддла. Но это скорее исключение, чем правило.

Думаю, если в самом начале профессионального пути возникают вопросы типа тех, которые я привела - скорее всего, упущено что-то важное, но текущий уровень компетентности не позволяет это увидеть.

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

* Это нормально, что новичок в профессии не может адекватно оценить себя. Было бы странно, если бы было наоборот!

Что тут можно сделать - закрыть слепое пятно с помощью других людей.

1) Взять список вопросов

2) Подробно ответить на каждый (если хочется ответить просто "да" - аргументировать, почему именно "да")

3) Принести этот список на валидацию тим лиду, старшим коллегам, ментору и т. п.

Конечно, ключевой момент тут не "взять список вопросов из такого-то канала", а использовать любой понравившийся способ описать положительный импакт, который вы привносите в проект/команду.

Podlodka QA Crew начинает подготовку к десятому сезону!

Наверняка большинство из вас знает о существовании онлайн-конференции Podlodka.
Искренне рекомендую эту конференцию всем, кто интересуется вопросами контроля качества. Я принимала участие в Podlodka QA Crew как слушательница и как участница круглого стола. Все очень понравилось)

К чему это я?

Во-первых, я вошла в состав программного комитета Подлодки:) Очень этому рада, уверена, это будет ценнейший опыт!

Во-вторых, в настоящий момент мы обсуждаем, какую область выбрать в качестве темы сезона. Мы сузили выбор до 4 опций, определили приблизительный контент и теперь интересуемся, какая тема наиболее привлекательна для потенциальных участниц и участников.

Какие варианты мы рассматриваем?

1. Планирование, метрики, оценка результата
2. Новые тренды в тестировании
3. Тестирование на разных этапах разработки
4. Тестирование веб-приложений

Осталось определиться, какая тема - лучшая.

Так что если вы работаете в QA и пожелаете поделиться своим мнением о том, какие темы считаете важными и нужными - можно пройти опрос тут https://forms.gle/uPKDpfqTABmyERHdA

Когда онбординг “снизу” встречает онбординг “сверху” - 1

Осенью 2022 я сменила проект и первой задачей был онбординг.

1. Онбординг “снизу”: все то, что делаю я сама, чтобы адаптироваться к проекту и узнать, как тут все работает
2. Онбординг “сверху”: обучение новых сотрудников, которых мы наняли за предыдущие несколько месяцев и продолжили нанимать, когда я присоединилась к проекту

Немного контекста.

Предыдущий проект существует ~ 5 лет, команда проекта: ~ 30 человек, общение внутри команды проекта: в основном на русском. Команда тестирования: 5-6 человек. Моя команда: 3 человека (младший инженер, миддл, тим лид/тех лид). Команда полностью закрывает потребности в контроле качества бэкенда и веб приложений (десктопное и мобильное)

Текущий проект существует ~ 15-20 лет, команда проекта: ~ 120 человек. Общение внутри команды проекта в основном на английском. Команда тестирования: ~ 20 человек. Моя команда: 4 человека (3 младших инженера + тим лид). Это только одна из нескольких команд, отвечающих за тестирование бэкенда. Кроме того, у меня есть дополнительные задачи. Например, курировать некоторых инженеров, у которых в командах нет выделенного QA тим лида; ответственность за процессы, связанные с ISTQB сертификацией.

То есть, одновременно совпали несколько факторов, каждый из которых по отдельности ощутимо увеличивает ментальную нагрузку:
- смена проекта сама по себе
- возросшая сложность проекта (он сложный даже с учетом того, что у меня есть 15 лет опыта на как будто бы похожих проектах)
- смена основного языка коммуникации на английский
- много людей, которых нужно ввести в курс дела, причем уровень их экспертизы в основном невысокий

Что можно сделать в этой ситуации?

Позже напишу, как подошла к этой задаче и что в итоге вышло.

Когда онбординг “снизу” встречает онбординг “сверху” - 2

Лирическое отступление.

Конечно, очень хочется быть Идеальным Тим Лидом!
Идеальный Тим Лид не устает больше обычного, когда говорит весь день на неродном языке.
Идеальный Тим Лид умеет сфокусировано работать по 8 часов в день.
Идеальный Тим Лид тратит 4 часа на инженерную работу (постигает глубины проекта) и 4 часа в день проводит в беседах с младшими коллегами, делясь вселенской мудростью.
Идеальный Тим Лид через несколько месяцев такого режима совершенно не устанет и не начнет ненавидеть людей, а, наоборот, будет работать еще быстрее и лучше.

Как жаль, что я не он.

Впрочем, было некоторое искушение ожидать от себя именно такой работы. Тут помогла проверка ожиданий на реалистичность.
Много ли людей, которые в принципе могут так работать? Они вообще бывают? А если бывают - как часто встречаются?
Я сама верю, что такие люди бывают, но очень сомневаюсь, что это типовой случай, на который стоит ориентироваться.

Какие есть реалистичные альтернативы Идеальному Тим Лиду?
- человек, который все будет делать прекрасно… и выгорит в угли через 2-6 месяцев
- человек, который будет делать “на отвяжись”
- человек, который в принципе не станет брать себе эту задачу - слишком уж рискованная
- человек, который… (предлагайте ваши варианты)
- человек, который что-то сделает хорошо, что-то менее хорошо, что-то - плохо, но дотащит задачу до приемлемого (не идеального!) результата

Когда онбординг “снизу” встречает онбординг “сверху” - 3

Что я сделала дальше: проанализировала нагрузку и признала, что нельзя одновременно хорошо узнать проект самой и инвестировать силы в рост младших коллег.

Во-первых, скорректировала план:

1. Онбординг “снизу”
2. Онбординг “сверху”

Во-вторых, сразу смирилась, что идеально не получится и заранее простила себе ошибки.

Почти сразу проявились неприятные побочные эффекты:

- Немедленно активизировался внутренний кодоцентризм / инженерный шовинизм - идея “чем что-то ближе к коду, тем ценнее”. В соответствии с этой идеей, инженер по определению ценнее менеджера
- Возникли тревоги: а как понять, что команда хорошо работает, если не проверяешь продукт сама руками? А что, если я вообще забуду, как работать руками? И тогда все пропало

Кажется, это более-менее типовые проблемы человека, который какое-то время сидел на двух стульях (инженерском и менеджерском) и в какой-то момент понял, что два стула это уже многовато, пора выбирать.

Тут мне очень помогла мысль, что, если я вложусь в себя и буду классно делать инженерные задачи - мы как команда в целом будем работать плохо (конечно же, я этого не хочу).
Если же команда работает хорошо, релизы доставляются вовремя, проблем с продакшена прилетает мало - какая разница, сколько инженерных задач сделано тим лидом собственноручно? А вопрос контроля качества работы можно решить с помощью ревью (как тестов, так и тестового покрытия).

Конечно, важно не перепутать идею “инвестировать усилия в младших коллег” и “бебиситтинг”, когда буквально водишь людей за ручку.

Меня от бебиситтинга защищала очень простая вещь: это было было просто невозможно. Например, на прошлом проекте на одного новичка у меня уходило до полутора часов в день (это нормальное обучение, не бебиситтинг). На новом проекте нужно было вести 5-10 человек, причем часть времени там еще параллельно найм шел. Какие там полтора часа в день на человека или тем более бебиситтинг:)

К тому же, если бы я занималась только обучением новичков по 8 часов в день, через пару недель я бы устала до острой ненависти к людям. И силой этой ненависти можно было бы валить деревья!

То есть когда я говорю “инвестировала максимум в обучение”, это надо понимать как “инвестировала максимум сил из того бюджета сил на общение, что у меня был”.

Я отслеживала моменты, когда бюджет сил на общение как-то иссяк и тянет на кого-нибудь нарычать. Отменяла те митинги, которые можно отменить, переносила те, которые отменить нельзя.
Что еще очень поддержало: рабочие задачи из категории “несрочное/некритичное, но приносящее радость”. Это может быть не очень интуитивно - делать что-то не очень срочное и как будто необязательное, когда есть более актуальные задачи. Но выполнение таких задач помогало выдохнуть, снизить уровень напряжения и просто порадоваться тому, что я делала что-то понятное, что даст быстрый результат.

Когда онбординг “снизу” встречает онбординг “сверху” - 4

Чем дело кончилось?

Новички распределились по командам. Собственно, моя команда состоит из трех новичков (которые уже не совсем новички) и меня.
Я продолжаю проводить ревью всех тестов и тестового покрытия задач. Это мой основной способ понять, как работает система.
Первый релиз, который мы готовили текущим составом, доставлен без особых приключений. Все новые тесты, которые мы готовили к релизу, прошли ревью у меня, ничего не оставлено на потом.
Я успела сходить в отпуск два раза и за это время в команде ничего ужасного не произошло.

Был один случай, когда кое-что сделали неоптимально и пришлось посидеть с коллегой до ночи, но это разовый инцидент, а не системное явление.

Так что, думаю, все у нас хорошо:)

QA Sisters Conference - 1

Кто-то из подписчиков знает, что я состою в сообществе QA Sisters. Я не только участвую, но и администрирую его (в составе команды из 12 человек).

Это русскоязычное сообщество для женщин, работающих в QA/QC или интересующихся этой сферой. Сообщество было создано в 2019 году. Сейчас там почти 3700 участниц - и сообщество все еще растет.

Весной этого года мы подумали и решили, что хочется вывести наши разговоры о контроле качества и смежных темах на новый уровень.

Так появилась идея QA Sisters Conference: онлайн конференции, организованной женщинами в QA для женщин из QA.

В марте мы начали подготовку к конференции, а в в конце июня - первой половине июля мы ее провели. Сегодня был последний круглый стол и закрытие конференции, и, конечно, руки уже тянутся написать пост по ее итогам:)

Что хочу подсветить: это полностью горизонтальная инициатива. У нас не было спонсоров. Внешних менеджеров, которые бы драйвили активности, тоже не было. То есть конференция была чем-то, что мы делали для себя - просто потому, что мы хотели такое мероприятие для себя:) Все планирование, решение технических вопросов, работа со спикерами - все ехало на нашей способности к самоорганизации.

Думаю, это важная веха для сообщества: ивентов, подобных этому, у нас еще не было. Это новый уровень, без шуток.

Это также важная веха для меня лично. Я уже писала, что еще пару лет назад я с трудом представляла себя рассказывающей что-то на публику. А теперь я одна из тех, кто организовал и провел онлайн конференцию! Еще месяц назад я бы написала - “интересно, что будет дальше”, но я уже знаю, что будет дальше: подготовка Podlodka QA Crew.

Итак - что получилось в итоге?...

#qasisconf

QA Sisters Conference - 2

Итоги:

- 440 участниц
- 18 спикерок
- 20+ часов презентаций, круглых столов, воркшопов и мастер-классов

Какие вопросы мы успели обсудить за это время:

Тест-анализ
- Работа с требованиями (Дарья Теплова)

Автоматизация
- Postman: легкий способ упростить работу с API и настроить автоматизацию (Валерия Калашникова, Александра Климанова)
- Зачем архитектура в автотестах (Диана Верикова)
- Как я строила (строю) автоматизацию проекта с нуля без опыта автоматизации (Мария Карташева)

Геймдев
- Из Fintech в Gamedev (Полина Шахнова)
- Что такое игровые движки и как они помогают тестировать (Елена Скрипаль)

Тестирование мобильных приложений
- Что стоит уметь мобильной тестировщице в 2023 году? (Мария Осина)

Тестирование локализаций
- Как я перестала волноваться и протестировала арабский (Дарья Супрунова. Ну, я:)

Мониторинг
- Поднятие мониторинга с нуля (Елена Васильева)

Софт-скиллы
- Круглый стол: Одна в поле - воительница (Айгуль Аржан, Валерия Калашникова, Дарья Теплова)
- Техники конструктивной коммуникации для улучшения процессов в команде (Юлия Коротаева)
- Искусство задавать хорошие вопросы: Важность правильных вопросов в QA (Полина Рейнер)
- Self-Onboarding: что делать, если в новой компании нужно адаптироваться самостоятельно (Татьяна Шестопалова)

Вопросы на стыке тестирования и "как жить эту жизнь?"
- Почему я ничего не делала, но так устала? (Людмила Данилова)
- Как работать работу в современном мире (Ольга Артемьева)
- Адаптация к эмиграции (Евгения Вдовкина)
- Круглый стол "Как понять, что тестирование - это не твоё" или "Выйди и зайди нормально" (Евгения Вдовкина, Анастасия Копова, Ольга Артемьева)
- Воркшопы IAmRemarkable
- Мастер-класс для спикерок

#qasisconf

QA Sisters Conference - 3

Все это, конечно же, невозможно сделать в одиночку. Это - результат огромной командной работы оргкомитета. И я искренне считаю, что как команда мы отработали на 5+. А если учесть, что мы занимались этим в свое свободное от работы время - то на 6+. Для меня огромная радость быть в такой команде, где люди, с одной стороны, бережно относятся к себе и друг другу, а с другой - хотят получить максимально качественный результат. Мне кажется, это отличный баланс, который создает плодотворную почву для подвигов и свершений:)

Но конференция - это не только усилия одного лишь оргкомитета. У нас была группа волонтерок из сообщества, которые помогали отбирать темы и готовить доклады. А кое-кто даже провела мастер-классы (для спикерок и IAmRemarkable).

Кто готовила конференцию:

Валерия Калашникова (Отбор тем, кураторство докладов, ведущая тренинга IAmRemarkable)
Ольга Артемьева (Оргкомитет, отбор тем, кураторство докладов)
Анастасия Копова (Оргкомитет, отбор тем, кураторство докладов, ведущая круглого стола)
Евгения Вдовкина (Оргкомитет)
Мария Гончарова (Кураторство докладов)
Эльвира Нагуманова (Отбор тем, кураторство докладов, ведущая лекции для спикерок)
Юлия Титова (Кураторство докладов)
Юлия Горохова (Отбор тем, кураторство докладов)
Юлия Унжакова (Отбор тем)
Надя Ершова (Оргкомитет, финкураторка)
Ирина Твердохлебова (Отбор тем, кураторство докладов)
Юлия Бажанова (Отбор тем, кураторство докладов, ведущая лекции для спикерок)
Виолетта Кильдюшева (Отбор тем, кураторство докладов)
Валерия Смирнова (Оргкомитет, кураторство докладов)
Наталья Петровская (Главная по делегированию и ответственная за конференцию)
Дарья Супрунова (я) (Оргкомитет, отбор тем, кураторство докладов, ведущая круглого стола)

Чем занималась лично я, если быть более точной:

- Разрабатывала программу, планировала выступлений, координация со спикерками и т. п. - словом, решала вопросики
- Обеспечила хостинг и техподдержку для 9 докладов
- Выступила с презентацией "Как я перестала волноваться и протестировала арабский" (вообще хотела рассказать про тестирование локализаций в целом, но в итоге решила сузить тему)
- Курировала три доклада (организовала тестовые прогоны, предоставила фидбэк по презентациям - предложения, как улучшить текст или оформление)
- Выступила в роли ведущей на круглом столе "Как понять, что тестирование - это не твоё" или "Выйди и зайди нормально". Это мой первый опыт модерации под запись, было волнительно, но результат получился вполне хорош)

Самая активная фаза подготовки совпала с моим отпуском. Это было удобно, с одной стороны - я могла готовиться в спокойном темпе. С другой стороны, после такого отпуска хочется отпуск от отпуска.
Но ни о чем не жалею:)

#qasisconf

Тестирование переводов

Доклад про тестирование переводов, который я подготовила для QA Sisters Conf, доступен на youtube.
Почему только переводов, а не локализаций вообще? Потому что все остальное просто не влезло в установленные 20-30 минут. Когда-нибудь я сделаю доклад-продолжение (но это не точно).

Краткое содержание:
- С точки зрения функциональности важно помнить про определение дефолтного языка и про переключение языков
- Если есть интеграции - уделяем внимание контракту между ними
- Проверки строк текста и right-to-left интерфейса можно сделать с помощью неатомарных тестов на окна (или отдельные состояния конкретных окон)
- В целом все довольно нестрашно, джуны с небольшим опытом справляются. Особенно если на проекте нет неочевидных интеграций

У аудитории были вопросы про автоматизацию, про взаимодействие с программами автоматического перевода и про экономию денег на переводчиках.

Вопрос: пробовали ли автоматизировать?

Я сама не автоматизатор, так что лично не пробовала. Но мнение имею!

- выбор языка по умолчанию - да, имеет смысл автоматизировать. Это тот сценарий, который точно будет использоваться каждым пользователем, и он (почти) точно будет в смоук/санити проверках
- переключение языков - под большим вопросом. Пользователи переключают языки редко или вообще никогда
- переводы строк - нет, нет и еще раз нет. Это будут огромные затраты ради тестов, которые полностью прогоняются не так уж часто и могут устареть между прогонами

Вопрос: проверяли ли вы, как приложение работает с автоматическими переводчиками?

Нет, не проверяли.
Были ли баги?
Да, иногда были. Иногда даже функциональные (например, поле переставало обновляться).

Думаю, если возникает острое желание проверить взаимодействие приложения с автоматическим переводчиком, имеет смысл спросить - а мы это делаем чтобы что? Почему это важно?
С ненулевой вероятностью окажется, что бизнесу важны пользователи, говорящие на определенных языках, и что проще добавить дополнительный язык в приложение и проверить его как обычно, чем ввязываться в тестирование взаимодействия с тем же Google Translate.
Стоимость добавления нового языка (если только это не арабский + RTL с нуля) - максимально понятная трата, в отличие от проверки на совместимость с автоматическими переводчиками.

Вопрос: а что, если использовать неуникальные ключи и таким образом сэкономить на переводчиках (им же платят за количество слов)?

Получается, что тут выбор: экономия на переводах vs экономия времени разработки/тестирования.

Мне самой кажется более предпочтительным потратить дополнительную (понятную, заранее известную) сумму в самом начале применения переводов, чем иметь риск получить затраты неизвестного объема когда-нибудь потом.
Аргументировать метриками не могу:) Чтобы точно это знать, нужно одну и ту же фичу (или две очень похожих) обработать разными способами: для одной сделать максимально неуникальные ключи, для другой - уникальные. В процессе максимально точно затрекать время и потом сравнить затраты. Мы не пробовали так делать, если честно. Если вдруг кто-то пробовала/пробовал, делитесь опытом:)

#qasisconf