Andrey Ivanov - Quality First (QA)

Теперь, плюсы: 1) Можно быстро вырасти. Вопрос спорный: в целом чем больше ты работаешь, чем больше ты интересуешься разными аспектами профессии, чем больше ты используешь на практике, тем быстрее ты учишься. Такое возможно не только в аутсорс компаниях, хотя возможностей больше именно в ним, из-за разнообразия и уже готовых решений и подходов, а так же за счет разнообразия людей и проектов. 2) Можно попробовать себя в разных ролях. Самая важная оговорка, если ты сам проявишь инициативу. Людей, которые сидят "ровно на попе" и ничем не интересуются и ничего не предлагают сами, никто не продвигает и крайне редко дают возможности попробовать что-то новое. Мой личный опыт показывает, что даже в продуктовых компаниях такой подход возможен. Для примера: в моем горячо любимом aheadWorks я успел поработать и мануальщиком, и специалистом в поддержке, и стать автоматизатором. А также и попробовать себя в создании маркетинг материалов, консультации клиентов, а также получить опыт публичных выступлений. Неплохо звучит? 3) Интересные проекты. Очередной стереотип, большинство проектов - обычная работа, которая часто перетекает в рутину. Важно, как ты сам относишься к своей работе и к своим проектам. Если тебе интересна профессия, то тебе любой проект будет интересным. А если ты пришел работать работу и зарабатывать стотыщмильенов денег, то и проекты для тебя будут такие же скучные и однообразные. 4) Социальные плюшки. Опять же сейчас почти во всех компаниях есть "свои" плюшки. Вопрос в том, что нужно именно тебе. Если твой уровень желания остановился на попить чаю с печеньками в офисе, то тебе подойдет почти любая компания, а если ты ищешь что-то специфическое - то всегда думай своей головой и выбирай "под себя". Для примера, я знаю компании у которых в отдельном помещении были бар и кальянная, а у других коллективные спорт активности, тренажерные залы и теннисные столы. Кто-то предоставляет классную медицинскую страховку, а кто-то оплачивает больничные 100% вместо государства. Ищите для себя и под себя, думайте своей головой, не осуждайте что-то даже не попробовав, не доверяйте слухам, определитесь для себя "чего вы хотите, где ваш личный уровень комфорта, какой у вас порог принятия оффера" - только тогда у вас все будет хорошо. Цените себя в первую очередь! но не забывайте спуститься к реальности и заглянуть в нее сами, чтобы не отставать от нее. Всем добра!

Итак начнем с минусов из поста: 1) Тебе крутят опыт и продают за большие деньги. А в чем собственно минус для специалиста лично? Душит жаба, что на тебе зарабатывают? если ты не можешь продать свои услуги, а такая компания может - это скорее плюс для обеих сторон. 2) Тебе платят меньше на порядок, а на разнице компания и зарабатывает. Порядок - это минимум 10 раз, что звучит абсурдно само по себе. Если тебя не устраивает оффер, его всегда можно отклонить или попытаться договориться на другую сумму. Если ты сам принял такой оффер, то чего жаловаться. При это если сравниться уровни оплаты, хорошим специалистам платят не меньше, чем в любой другой компании, а чаще даже больше (потому что могут позволить себе). Единственная большая разница в зп будет только, если сравнивать с зп, когда ты работаешь напрямую с заказчиком (причем иностранным) как частник. 3) Для стажеров есть ученические договора и обязательства по отработке со штрафами при досрочном расторжении. Такое есть не только в аутсорсе и аутстафе, продуктовые компании тоже "грешат" этим. Опять же, почему это плохо, это честный контракт с прозрачными условиями, компания берется тебе учить, находить проекты, показывать "взрослую" жизнь, а ты со своей стороны не хочешь ничего вкладывать. 4) Работа на нескольких проектах одновременно, но зарплата только одна. Если это работа по стандартному графику согласно трудового кодекса - вопросов ровно ноль. Конечно фокус размывается, эффективность может падать. С другой стороны это особенный интересный опыт для тебя, как специалиста. Если мы говорим про то, что у тебя 2 парт тайма как фул тайм, то у меня возникает резоныый вопрос: а где твой язык? почему ты про это не говоришь с работодателем? почему ты не требуешь к себе достойного отношения? если ты так не делаешь - значит тебя схема устраивает. 5) Часто: разные команды. Если ты "прикипаешь" к людям и хочешь стабильно и долго работать именно с ними, то да, это явный минус. Но с другой стороны, работая с разными проектами и разными командами у тебя появляется больше полезных связей и разных мнений, которые повлияют на твое видение. Опять же, у продуктовых компаний довольно часто бывает не один продукт внутри, который пилят разные команды, а тестировщики шарятся между ними.

Всем привет! Давно не писал своих мыслей сюда. Но в очередной раз встречая обсуждения в линкедине, решил-таки высказаться. Оригинальный пост тут - https://www.linkedin.com/posts/artsiomrusau_%D1%83-%D0%BC%D0%B5%D0%BD%D1%8F-%D0%B2-%D0%B3%D1%80%D1%83%D0%BF%D0%BF%D0%B0%D1%85-%D0%B0%D0%BA%D1%82%D0%B8%D0%B2%D0%B8%D0%B7%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BB%D0%B0%D1%81%D1%8C-%D0%B4%D0%B5%D0%BC%D0%BE%D0%BD%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F-activity-7328363163966398465-2Mxg?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAjjtr4BMTWyuFm2DGHD4zVN_Qi19N4_ad4 Собственно далее будут мои мысли

Всем привет! Я обещал вам крутую, а главное бесплатную конференцию⁉️ Вот она! - https://cutt.ly/JrgXH2EJ 📆 В течении недели со 2 по 6 июня пройдет #ProQuality #Conference #2025. ☀️ 🌙 Доклады утром и вечером, чтобы не отвлекать вас от работы. 🚀 Крутые спикеры и супер доклады. 💻 Темы для инженеров уровня #middle - #senior - #lead, как для #manual, так и для #automation. Ну и не без трендового #AI (куда же без него в наше время). Залетайте и регайтесь, чтобы не пропустить! - https://cutt.ly/JrgXH2EJ Напоминаю -#Конференция #Бесплатная! 🎩 За #репосты, #комментарии и шаринг с коллегами - плюсик в карму и огромное #спасибо от нашей крутейшей команды организаторов! Всем добра!

Всем привет! #ProQuality ищет спикеров для предстоящей ProQuality #Conference #2025. Если вы – увлеченный #Quality #Engineer 🤓 и применяете лучшие практики тестирования, автоматизацию или #AI в своей ежедневной работе, то вы точно станете желанным гостем нашей конференции, где мы будем общаться на эти темы и не только. 📆 h#ProQuality h#Conference состоится в конце мая – начале июня. Заполните форму, если вы заинтересованы стать спикером, чтобы поделиться своими знаниями и пообщаться с коллегами. ✏️ https://lnkd.in/g8Rn7PiH А как прошла предыдущая конференция, на которой выступили более 40 докладчиков и собралось более 1000 участников, можно посмотреть на странице конференции. 🔎 https://lnkd.in/d4KEjtGa За подробностями стучитесь к мне в личку, Andrey Ivanov. #callforspeakers #speakers#event#global#online#free#en#qa#testing#automation#quality

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

"#Синдром #самозванца" : тянет назад или помогает достичь успеха? Синдром самозванца — это психологический #феномен, при котором человек сомневается в своих силах и чувствует себя «мошенником», несмотря на #доказательства своих достижений и навыков. Его не покидает ощущение, что та точка, где он оказался, — это случайность, и его вот-вот разоблачат и осудят. Так вот вам моя #история. Мне вообще в жизни с этим везет и каждый раз, когда я начинаю заниматься чем-то новым для себя или расширяю свои #полномочия, которые я возможно "заслужил", я чувствую сомнения в себе и своих силах. Первый раз я с ним столкнулся, когда после 1го месяца работы в #айти отделе в банке, мой текущий руководитель взял да и уволился. Меня вызвал директор к себе и говорит: "Ну привет! Теперь ты начальник службы автоматизации". И понеслась... Я не знал ровным счет ничего, учился программировать во время профессионального обучения, но тут это нафиг не нужно, кроме мелких скриптов на #python и #perl. Linux я в глаза не видел, а тут целый сервер. Про вообще экономику и банковское дело я не знал вообще ничего. Когда-то проходил базовый курс экономике, но дальше непонятных цифр-кодов счетов типа 1030 мое понимание не ушло. Cверху еще легла банковская АТСка, которую я даже на картинках, в отличии от линухи, не видел. И добивкой стал банковский аудит по ПО и безопасности, который я "просрал" даже не поняв что это было. Меня сразу порвало от неожиданности всего свалившегося на меня. Кто начальник отдела? Я? Я ж них*ра не умею. Даже словил панику: "А! Куда бежать? Че делать? может уволиться нафиг вслед за начальником? Меня этому не учили? Я вообще тупой! ". Ручки дрожали, мысли путались между собой, а мозг судорожно пытался придумать решение этой проблемы. Ну и что? Пришлось рвать "мягкое место", найти самому себе коллегу в помощь(из бывших одногруппников), обрывать телефоны коллег из других отделений и головного офиса, а по вечерам читать проф литературу. И через год, все было настроено, софт обновлен, АТС перенастроена по отделам и коротким номерам, сервер перестал падать каждую неделю, файлы по крону перекладывались в нужные папки и дальше уходили покорять просторы FIDO.net, а следующий аудит прошел так, что они упрашивали меня дать им записать хоть какое-то нарушение (которых не было). В целом отпустило меня именно после второго аудита, потому как до него я все еще сомневался в каждом кусочке проделанной работы и в каждой крупице знаний, которую я получил за это время. Вот таким было первое знакомство у меня с этим "страшным синдромом". Выводы пока писать не буду, напишу позже про другие случаи. А вы поделитесь в комментариях о своем опыте в "синдроме самозванца", если таковой имеется? Всем добра!

Последний год очень много встречаю историй-жалоб на новое поколение. Особенно, впечатляют истории про людей, которые прошли кучу собесов, получили оффер, а потом, поработав полдня, уходят из офиса на обед и не возвращаются. С одной стороны тут действует наш любимый испытательный срок, который на самом деле очень хороший инструмент не только для работодателя, но и для самого сотрудника. Но вот называемые причины меня вводят часто в ступор: типа что-то я уже устал, погода хорошая - пойду погуляю, и т.п. Выглядит максимально инфантильно, не так ли? Конечно, человек может заботиться о себе сколько угодно, и я скорее даже "за" такой подход. Но что меня в данной ситуации удручает, так это обесценивание труда самого человека и всех людей вовлеченных в процесс найма таких людей. В то время, когда огромное количество людей пытается вылезти "из шкуры" и войти в АйТи, находятся вот такие уникальные "снежинки", которые пройдя весь этот ад, решаю для себя - а ну его нафиг! И опять же, работа в АйТи не простая, люди "рвут" себе все возможные места, перерабатывают по много часов и выгорают. Я знаю лично людей, которые зашли в айти исключительно из финансовых соображений и из них получились отличные специалисты своего дела, но так же знаю и людей, которые послали все на... и уехали в деревню разводить кур. И к тем, и к другим я очень хорошо отношусь. Но такое поведение не понимаю даже я. Я конечно сам скорее трудоголик, люблю свою работу и делаю ее хорошо. И даже не смотря на то, что я в последние несколько лет выстроил четкие границы между работой и личной жизнью\психическим и физиологическим здоровьем. Так вот я к чему? Как вы сами относитесь к таким ситуациям? Это современная норма или все же исключение из правил?

А у вас такие же мысли?

Метрики. Часть 3. Метрики выполнения тестов. На мой взгляд самые простые #метрики, которые реально помогают понять ситуацию с качеством приложения и качеством самих тестов. 1. Количество пройденных тестов/ отношение к общему количеству тестов (#Pass#rate) Я обычно пользуюсь именно относительной величиной, потому что количество само по себе в отрыве дает меньше информации. Можно и даже нужно использовать в #автоматизации тестирования, то есть для авто тестов. В целом эта метрика уже давно стала золотым стандартом метрик: узнать качество сборки - pass rate, проверить состояние приложения - pass rate, проверить стабильность энвов после переезда на новый клауд - #passrate. А на исторических данных можно понимать какие изменения и к чему привели. Выкатили новую фичу с новыми тестам и pass rate упал на 10% - толи фича "сыровата", толи сломали смежную функциональность. Увеличился pass rate после спринта стабилизации (#Stabilization #sprint) - команда отработала хорошо по багфиксу да и тесты мы сами подлатали. 2. Количество проваленных тестов/ отношение к общему количеству. По сути та же метрика, что и в пункте 1, только в реверсивном или негативном(хз как правильно) отображении, то есть наоборот. Используется так же, показывает тоже, только анализ идет от обратного, как и выводы. 3. Среднее время выполнения теста (#average #speed) Вот эту годноту использую почти всегда. Из нее обычно можно вывести 2 вещи: неоптимальность написанных тестов, то есть простор для улучшения, избавление от лишнего, запутанное описание степов и т.п., а также скорость работы. Вы можете спросить "чья скорость работы?" и будете правы. Таких объектов или субъектов (расскажите, кто шарит как правильно в комментариях) несколько: a. Скорость работы автотестов - тут все просто, чем быстрее проходят, тем лучше + больше денег экономим на тестировщиках. б. Скорость работы приложения - вкорячили очень долгий запутанный кол с кучей вызовов под капотом - позор разработчикам и архитекторам. в. Скорость работы окружения - переехали в новый клауд, открыли новый энв, запилили новую реализацию балансировщика - наши клиенты. г. Скорость работы каждого отдельно взятого тестировщика - самый спорный пункт, я предпочитаю мерить общими задачами в бэклоге, хотя можно и по этой метрике, но тут будет куча погрешностей из-за пунктов выше + часто #тестировщик не только "прогоняет" #тесты, но и улучшает, и обновляет их в процессе, что очень сильно затрудняет качественную оценку по этой метрике.

Может быть видели уже, но я не могу проржаться: "У самурая нет оффера, только собесы!"

Продолжаю пост по метрикам. Тут будет по короче, но зато я закончу с метриками по багам. Часть 2. 1) Общее распределение багов по окружению. Эта метрика даст нам отличное понимание того, где и как мы отлавливаем баги. Это поможет нам правильно сформировать тестовые наборы и укомплектовать их "правильными" тестами. Как правило чем ближе окружение к проду, тем обширнее тесты. Хотя встречаются и случаи, где всегда набор тестов одинаковый для всех окружений. 2) Распределение багов по приоритетам (Priority). К этому списку можно добавить Важность (Severity), но уж очень часто я встречаю случаи, когда используется в трекере только один из этих параметров. Сама по себе не принесет большой пользы, а вот посмотрев эту метрику в разрезе окружений, мы еще лучше сможем разобраться в том, как происходит наш текущий процесс, затюнить сами тесты и тестовые наборы, а также получить сигналы по необходимости улучшения сбора и описания требований или даже вмешательству третьих лиц в приоритеты. Часто бывает, когда представители заказчика начинают менять приоритезацию без видимых на то причин, хотя для этого упражнения на проектах лучше вводить отдельный регулярный звонок. 3) Время "жизни" багов Аналогично, лучше смотреть по приоритетам и на разных окружениях. Нужна эта метрика для оценки скорости исправления дефектов и определения эффективности команды для багов разных приоритетов. Разберем ситуацию на примере продакшена. В идеале мы увидим следующую картину: для багов с высоким приоритетом - время мало, с низким приоритетом - тоже мало, но может быть выше, чем у высокоприоритетных. Что нам даст эта метрика? В первую очередь она поможет найти "узкие места" в нашем процессе, там где у нас происходят задержки, тем самым открыв огромный простор для улучшений. Далее, мы снова сможем оценить эффективность команды на срезе багов с разными приоритетами. Ну и в конце концов, получить пищу для размышлений по улучшению и оптимизации процессов тестирования и исправления багов, тем самым улучшая качество всего продукта в целом.

Тут недавно просили поделиться инфой по метрикам. Описываю только те метрики, которые собирал сам на практике. Текста будет много, да и метрик тоже. Поэтому... Часть 1. Метрики с участием багов: 1) Открытые/закрытые баги (Open/Closed Bugs). Считается просто, лучше считать большими диапазонами, от спринта и выше(месяц, квартал) , в зависимости от процесса работы на проекте. С одной стороны показывает темп работы команды. Ну как команды?! Типа тестировщики открыли, а девелоперы реально пофиксили(хотя мы, конечно, перепроверили). Ну и куча других людей может быть вовлечено в зависимости от содержимого. С другой стороны является хорошим маркером для определения растущего технического долга (Technical Debt), когда мы делаем кучу нового, но и ничего не фиксим в противовес. Для некоторых этапов разработки - это нормально, но все равно полезно. Также, хочу отметить, что я использую именно статус Closed для этой метрики, потому как плохо настроенный трекер задач, где нет других статусов может очень сильно вводить погрешность в эту метрику, когда баги по итогу оказываются отмененными (Cancelled), или настолько не существенными, что фиксить их никто и не собирается (Rejected, Won't fix, etc.). 2) Количество отмененных дефектов (Canceled bugs). Иногда собирают рейт (Cancellation rate) по отношению к открытым или собирают обе метрики. По сути это цифра отображает количество багов признанных избыточными или несущественными, а высокий уровень этой метрики покажет нам то, что есть проблемы в процессе работы, например слабая техническая документация или бизнес требования, проблемы коммуникации, недостаток знаний у тестировщиков или техподдержки. 3) Рейт дефектов на продакшене (Defect Containment Rate). Одна из самых крутых метрик при регулярных релизах в рамках Скрамов (Scrum), хотя подходит и для других вариантов Agile процессов. Считаем ее, как отношение багов на проде ко всем найденным багам вообще. Чем ниже, тем, соответственно, лучше! Кстати можно считать его не только к продакшену, но и например к UAT, если у вас построен полноценный процесс для этой фазы, а не "просто так называется энвайромент" для тестировщиков или препродакшена. По факту показывает насколько мы "лоханулись", что может говорить о проблемах с регрессией или покрытием тестами. Хотя тоже бывают и "лишние волнения", когда например продакшен имеет очень специфическую конфигурацию, тогда может быть открыто много дефектов в разных местах на проде, а по сути все может свестись к неверной настройке в одном единственном месте, так что будте осторожны и не вводите себя в заблуждение. 4) Количество дубликатов (Duplicated Bugs). Вынес эту метрику отдельно от Сancelled потому, что дубликаты показывают рассинхрон именно в QA команде(если кроме вас баги никто не открывает), особенно, актуально для распределенных больших команд, которые могут работать над одним "монолитом" (это не про архитектуру). Можно также считать рейт, тут уже кому как удобнее. Лично я предпочитаю количество. 5) Соотношение багов к задачам (Bug/Task rate). Считается в основном в разрезе спринтов или релизов. По сути мы оцениваем насколько много или мало багов мы пофиксили за определенный промежуток времени, по сравнению с основной задачей проекта - разработкой приложения. Метрика "капризная", ей нужно соблюдать баланс. Почему спросите вы?! Да потому, что если багов мало - значит мы их не исправляем и накапливаем долг, что при накоплении, только еще больше ухудшит качество продукта. А если много, то скорее всего мы только фиксим и ничего нового не производим, а значит, придет "злой" заказчик/менеджер/продукт/хозяин/хаосит-сланешит(нужное подчеркнуть) и накажет нас. К слову, это тоже может быть не всегда верным, потому что действительно сильная команда разработки может делать хорошо с минимальным количеством проблем, а в "стабилизационные" спринты в составе могут быть только баги. Так что нужно не терять голову, оценивать исторические данные и разумно подходить к любым сигналам от метрик. На сегодня все 😘. До встречи в Части 2. Всем добра!

Сегодня хотел рассказать об использовании такой крутой штуки, как Попарное тестирование, оно же Pairwise testing или All-pairs testing. О таком подходе я узнал совершенно случайно. Передо мной стояла задача протестировать добавление и оплату кастомных продуктов для интернет магазина с кучей настроек самого продукта, вроде цвета, размера, количества, страны производства, с различными дополнительными опциями или без них. Когда я начал писать тест-кейсы, то уже через пару часов понял, что вариантов выходит слишком много и пройти все руками будет крайне трудозатратно. Поэтому я полез в гугл искать как это правильно делать. И о чудо! оказывается при использовании данного метода можно сделать не 400 прогонов, а всего около 30. Для меня это было супер важно. Дальше я полез составлять эти пары вручную, но и тут понял, что мозг подзакипает, а пары начинают повторяться и противоречить методу. Снова гугол и снова готовый ответ - софт для составления пар. Тогда еще не было кучи онлайн приблуд для этого, нужно было скачать архивчик с файлом запуска из командой строки и примеров excel для входных данных. 5 минут разобраться и вуаля - у меня готовый набор данных, которые по сути закрывают все нужные комбинации. По итогу вместо 400+ тестов, один тест и файлик с данными. Ну красота же! Вообще в чем суть данного метода? он строится на теории, что проблема(бага) в подавляющем большинстве случаев возникает при комбинации каких-либо двух параметров, которые не умеют правильно взаимодействовать друг с другом и ломают логику приложения. ISTQB определяет попарное тестирование как технику тест-дизайна методом черного ящика, при которой тест-кейсы создаются таким образом, чтобы выполнить все возможные отдельные комбинации каждой пары входных параметров. То есть для полноценной проверки приложения с функционалом множественных параметром нужно проверить все возможно пары во всех возможных комбинациях. Также учитывается, что если параметров не 2, а скажем 6, то каждый тест будет проверять минимум 3 разных пары, а в идеале больше даже больше. Таким образом можно поймать тест, в котором ломается приложение и останется найти только нужную пару проводя уже более атомарные проверки по параметрам. Опять же для примера: У меня есть например 6 разных параметром для продукта, для каждого из которых есть 2 опции. Значит общее количество тестов при полной переборке будет равняться 2^6 (два в степени 6), то есть 64. Когда как при использовании попарного тестирования кейсов будет значительно меньше - всего 14. То есть в 4.5 раза меньше тест-кейсов. И чем больше у вас параметров и значений, тем более эффективен данный метод. Для примера использовал онлайн тул https://pairwise.teremokgames.com/. Таких тулов очень много, это просто первый попавшийся. Файлик скину в комментарии для примера. Вообщем все советую ознакомиться и попробовать! Всем добра!

Далее последовал список вакансий с позициями уровня мидл-синьор с трудоустройством в России(если что я в Литве живу сейчас) в штат без удаленки. А на мой вопрос о том, действительно ли с моим профилем - я получил полный игнор. Красота!

Не могу не поделиться очередным "эталонным" общением с рекрутерами.

Мем в глаз попал, не могу не поделиться

Сегодня "пост-байка" 📖 . Довелось мне заходить на один #крупный #проект лидом команды + "сам себе автоматизатором" (50/50). Ну как крупный проект? софт функционирует во всех странах Европы, его частично используют по всему миру, но пользователей не так много, так как он внутренний. Под капотом чего только нет, и куча фронта, и бэк, и базы, и онпремис/клауды, всякие там преобразователи данных, распознаватели текста (#OCR) и тому подобное. Писали много, долго, разные люди и разные команды. На старте онбординга меня и команды состоялся следующий диалог: - А сколько лет проекту? - 17 лет уже, много всего наворотили! - Я и вижу. А что у вас из тестовой документации есть на проекте? моей команде и мне это поможет быстрее погрузится в тонкости. - Так ничего нету! - В смысле? - Ну, а зачем нам?! У нас разработчики пишут без багов! Сказать, что я "удивился"(правильно читать, как "ох**л") 👀 , ничего не сказать. Ну что ж? Звучит как достойный #челендж! Принимаем! И что в итоге? За 4х недельный #спринт мы в 3 лица тестируя 2 фронтэнд приложения (#adhoc), опираясь на логику и здравый смысл, открыли 250+ багов. Это приблизительно по 1 багу в час (потому что я еще и фрейм писал в процессе, и основную работу делали 2 прекрасных тестировщицы). Можно новую метрику изобретать: #Bug #Finding #Velocity, считается в баг/часах. Отлично подойдет для эффективных "сов-менеджеров", которые не знают, как измерять качество продукта, но могут "повертев" цифры натянуть себя на глобус. Вот такие дела! 👇 Если у вас были свои "интересные" истории - пишите в комменты. Всем добра! #situation #fun #ithumor #owl #qa #testing #quality #test #bug

Последняя и заключительная часть моих приключений на #интервью. Часть 3: Управленческий #опыт. Тут я смог развернуться на полную катушку: #построение команд с нуля, #адаптация, #найм, персональные планы развития, #стратегии развития отделов, #оценка эффективности, построение процессов, построение процессов коммуникации, #метрики, #достижения. Вообщем было про что поговорить и я говорил. Однако, во всем моем опыте был один явный минус, опыт работы с продуктами у меня довольно небольшой. Хотя лично для меня, каждый из моих проектов все равно #продукт, даже несмотря на работу в аутсорсе. Опять же, на собеседовании не было вопросов-ситуаций, которыми на мой взгляд проще раскрыть навыки собеседуемого. Так что говорили чисто про опыт, я вплетал немного теории + добавлял примеры из своей практики. Кстати, мне помогла задачка с переписыванием своего профиля в #linkedin и #cv. Потому что очень много моментов я освежил в своей памяти и смог приводить много реальных примеров, задач и достижений. Часть 4. Заключительная Это был мой выход. Вопросы теперь задавал я. Они были также и о компании(что-то забыл спросить в части 1 или же пришел к вопросу в дальнейшей беседе), были вопросы о вариантах сотрудничества, видении идеального кандидата, о критериях успешности, о перспективах развития продукта и компании, ну и конечно же о компенсации. Это вообще самая важная часть собеседования для меня, где почти всегда можно уже понять, хочешь ли ты идти дальше с этой компанией или нет. В моем случае остались сомнения, в основном из-за требования релокации. В остальном мой интерес к позиции склонялся к "за". Что в итоге: Как я и писал, #офер мне не сделали, но опыт общения был просто прекрасен. Не было душных вопросов по теории, не было лив кодинг сессий, были конкретные вопросы про опыт и конкретные достижения - что мне очень понравилось. Причиной отказа была названа "мы ищем человека с бОльшим опытом в построении суппорта со стороны качества продукта, а так же - с опытом продуктовой разработки". И если второе чистое #правда, то первый пункт для меня остался под вопросом. Мне кажется, что одна из "незаявленных" причин - это запросы по компенсации и сумме офера. А просил я много, причем по двум причинам: - #Релокейшен станет мне в лишние проблемы с поиском работы для жены - Нет перспектив карьерного роста, а #рост компании и продукта находится под большим вопросом из-за того, что продукт для внутреннего использования, и он монетизируется только в основной компании. В любом случае это был приятный опыт, приятное общение между профессионалами и позитивные ощущения после. Так что не бойтесь своих интервью ("Г-г-главное нн-н-е боятся!"(а)некдот ), готовьтесь к ним тщательнее и вы добьетесь успеха. Всем добра! 😀

Всем привет! Вот продолжение моих похождений на #интервью. В целом все интервью можно поделить на 4 части. Часть 1: Представление. Тут я в основном слушал, иногда задавал уточняющие вопросы. Почему иногда? да потому что мне очень много информации рассказал сам #рекрутер и я был уже довольно сильно подготовлен и вооружен, так сказать. Плюсом для меня стал небольшой ресерч по названию компании, чтобы понять ее деятельность и отзывы со стороны. К слову, отзывы были хорошие. Интервьюверы рассказали мне о себе, своих позициях и ролях, рассказали о компании в целом. Далее последовали детали, а именно положение дел в тестировании, основная #задача для данной позиции, #ожидания и #ответственность. Довольно кратко, но дополнительными вопросами вскрылись нюансы. Например: - малое количество тестировщиков обусловлено тем, что тестирование появилось в целом не так давно. - пропорция мануальщиков к автоматизаторам +\- 50 на 50 - За качество продукта действительно отвечает вся команда (что не может не радовать). Разработкики пишут и модульные тесты, и компонентные, и даже частично интеграционные - Нефункционального тестирования почти нет, были проверки на текущее состояние под нагрузкой ,но не более. - Команда максимально распределена , люди в большинстве своем не знакомы друг с другом и мало представляют, что делает другая #команда. Часть 2: Технический опыт. Не могу назвать это полноценным собеседованием, много говорили за мой #опыт, никаких детальных технических вопросов не было задано, что было для меня плюсом ибо сейчас это моя слабая сторона, особенно , что касается написания кода автоматизации, уж слишком давно я сам ничего не писал толком. Поговорили и про инструменты , и про подходы, и про Continues #Testing, а также и про языки программирования. Тут у меня был сильный плюс , мне с большего нет разницы на чем писать, я уже пробовал себя и в #JavaScript, и в #.NET, и в #Python, несмотря на то , что моей основной специализацией всегда была Java. Что я кстати и рекомендую практически всем автоматизаторам, с которыми общаюсь, консультирую или работаю вместе. Это очень сильная позиция, потому что для автоматизатора язык программирования по сути тоже инструмент, и чем больше ты инструментов можешь использовать, тем более ты ценен как специалист.