Комментарии 12
Мне кажется, самостоятельность не является таким уж существенным критерием для разграничения. Более того, для меня, миддл - это самостоятельная "рабочая лошадка", которая может решать успешно типовые задачи в проекте. Вот просто брать и делать с приемлимым уровнем брака.
Сеньор дополнительно обладает техническими навыками, которые позволяют:
учить молодняк, т.е. сеньор уже не просто знает, но уже и достаточно отрефлексировал, чтобы пояснить то, что он знает
возможность решить сложную задачу, сделать PoC новой технологии, т.е. банально широкий кругозор и больший технический опыт
Дело не в том, что миддл будет просить помощи, или сидеть на опке ровно, пока рак на горе свистнет. Он просто не знает "как" или потратит много времени.
-------------
Также важным моментом является понимание разницы между рядовым QA и лидом. Задачи, которые вы относите к сеньору, как мне кажется, находятся в компетенции лида. Просто миддл, в силу своих меньших знаний, банально не может прийти к лиду с рацухой, а сеньор - может. Но если сеньор начнет "строить свое отдельное королевство", игнорируя команду и лида - это вряд ли будет хорошо
А вот если лида нет - тогда сорян, просто его роль выполняет сеньор и все :) Но это именно совмещение. Сеньор - уровень технической компетенции. Лид - организационные обязаности.
------------
Про пассивность. Да вообще, полный джун может отлично бегать за задачами. Это просто отношение к работе и все. Ну блин
В ситуации с автотестами Мидл Андрюшка сталкивается с проблемой: тест сломался. Его первая реакция — обратиться за помощью к Сеньору Васе или Разработчику Пете, объясняя ситуацию и предоставляя необходимые детали, такие как описание ошибки и стектрейс
Блин, тут мне кажется зарыт трешак. Ты либо автоматизатор, либо "никто". Если твой тест сломался а ты не знаешь почему - ты даже не миддл. Ты просто недо джун :) Ну серьезно. А-а-а-а, у меня ошибка, помогите ... тут либо в табло (можно вербально), либо с ноги под зад из команды.
Нну кому нужен "автоматизатор", который просит помощи в таком случае?
Сеньор дополнительно обладает техническими навыками, которые позволяют:
учить молодняк, т.е. сеньор уже не просто знает, но уже и достаточно отрефлексировал, чтобы пояснить то, что он знает
возможность решить сложную задачу, сделать PoC новой технологии, т.е. банально широкий кругозор и больший технический опыт
Учить молодняк может любой. Наставничество никак не связано с позицией, оно целиком зависит от твоего опыта и понимания проекта. Я будучи мидлом менторил новых сотрудников как раз потому того, что пришел позже, лучше и свежее понимал какие инструменты и какие вещи требуются для более успешного и быстрого анбординга. (А возможно и потому что сеньору было просто лень)
Насчет сложной задачи опять же есть пример, как у нас приходил человек, который на собеседовании доказал, что он готов решать сложные задачи, обладает очень большим техническим опытом. Ему сходу дали сеньора. Через полгода он все еще делал задачи с большим количеством брака и очень долго. Тут надо понимать, что большой технический опыт не равно моментальному пониманию всех внутренних процессов на проекте и того, как устроен вверенный ему компонент. Да, это должно помогать, но не всегда является гарантией.
Дело не в том, что миддл будет просить помощи, или сидеть на опке ровно, пока рак на горе свистнет. Он просто не знает "как" или потратит много времени.
Все дело в том, что сеньор тоже не знает сходу "как" и так же потратит много времени, особенно в первые разы. Странно от сеньора для первых месяцев работы требовать полного понимания проекта и внутренних процессов и того, что он сходу начнет щелкать задачки.
Блин, тут мне кажется зарыт трешак. Ты либо автоматизатор, либо "никто". Если твой тест сломался а ты не знаешь почему - ты даже не миддл. Ты просто недо джун :) Ну серьезно. А-а-а-а, у меня ошибка, помогите ... тут либо в табло (можно вербально), либо с ноги под зад из команды.
У вас на проекте сотни или даже тысячи тестов, вы с ходу разберетесь в чем проблема, если условный разработчик что-то потрогал в коде? Даже если хорошо и подробно выведена ошибка и правильно ловятся все экспешены. Ну да, условный локатор в селениуме, я уверен, вы быстро заметите. Но почему вдруг резко перестал проходить платеж в условном Paypal, вы быстро разберетесь? Учитывая что могут быть проблемы со стороны аггрегатора? А есть проекты еще сложнее и комплекснее с еще более невнятными ошибками. У меня похожее было в прошлом опыте кибербезопасности, когда малварные аналитики из другой команды могли немного потрогать у себя определение новых угроз и их отрисовку на основе новой классификации, что влияло на неправильный ответ по запросу из автотеста. А ты пол дня мучаешься с тестом и не понимаешь, почему он перестал выдавать неправильный ответ, хотя никто из твоей команды ничего даже близко не трогал.
Странно от сеньора для первых месяцев работы требовать полного понимания проекта и внутренних процессов и того, что он сходу начнет щелкать задачки.
Честно говоря, если кому-то нужны месяцы для вкатывания в проект - это уже клиника и однозначная рекомендация "на выход с вещами".
Учить молодняк может любой.
Учить да, научить - нет :) Но тривиальные вещи вроде, "где здесь туалет", и вот тут набирать воду для чайника действительно показать может любой
Ему сходу дали сеньора. Через полгода он все еще делал задачи с большим количеством брака и очень долго.
Ничего удивительного, многие сеньоры на проверку и миддлами не являются. Вот недели две назад как раз такого собеседовал :)
Но я не мешают разным организациям раздавать условные лычки :)
У вас на проекте сотни или даже тысячи тестов, вы с ходу разберетесь в чем проблема, если условный разработчик что-то потрогал в коде?
А в чем проблема? Ну правда, если я писал эти тесты. Хотя ... когда-то давно, когда собеседовали QA, задавали простые вопросы вроде "диагностики отвалившегося соединения на ноуте". Я вам так скажу, большинство - реально "опасные" люди. Их и на 100 бакосв на позиции эникейшика брать нельзя. Понятно, что такие спецы, увидев ошибку, даже F12 тыцнуть не могут, а уже прочитать что там происходит ...
Что касается интеграционных тестов, обычно "прикладные" тесты предваряются тестами "интеграционными", чтобы проверить, что "с той стороны" вообще кто-то есть и он в адеквате.
Хотя опять же из опыта, был реальный случай, придя на проект в роли "тех. лида / архитектоура", увидел, что система на тесте ходит в один карточный бэк, а QA - в другой. Естественно тестовые результаты отличаются. Вот теперь вопрос, эти все QA были миддлы, сеньоры, либо просто банальные недоучки?
А это не единичный случай.
Поэтому давайте разграничивать спецов, или просто тех, кому выдали лычки, а в реальности человек сидел на типовых задачах и ни шагу в сторону. Если речь о второых - там градация не имеет смысла, так как человек просто в принципе не соответствует позиции
А ты пол дня мучаешься с тестом и не понимаешь, почему он перестал выдавать неправильный ответ, хотя никто из твоей команды ничего даже близко не трогал.
На самом деле, на нормальном проекте у QA своя среда, где "чужие" не ходят, а то и несколько. Они сами себе все ставят и сами отвечают за конфиг. Если это нет так - прямой вопрос к лиду/сеньору на таком проекте. Ну серьезно, если QA чего-то тестируют, а паралельно кто-то чего-то на среде меняет - тут вопрос к базовым компетенциям тех, кто такое допускает.
Честно говоря, если кому-то нужны месяцы для вкатывания в проект - это уже клиника и однозначная рекомендация "на выход с вещами".
Как же вы интересно интерпретируете написанное. Я пишу про "странно от сеньора для первых месяцев работы требовать полного понимания проекта", вы мне про "вкатиться в проект". Я говорю про более глубокое и полное понимание процессов все же. Я предполагаю, что для особого крупного и комплексного проекта на это уходит больше времени, чем пара месяцев. Хотя я не знаю, что у вас там за компания и проект, где вы через пару месяцев увольняете людей, потому что они не познали все аспекты, возможно мы изначально с вами говорим о разных вещах.
Учить да, научить - нет :) Но тривиальные вещи вроде, "где здесь туалет", и вот тут набирать воду для чайника действительно показать может любой
Ого, да вы совсем недооцениваете своих сотрудников, в особенности Мидлов. Мидл - не безмозглая обезьянка, тыкающая на кнопки. Они могут и смогут научить. Мидлом можно быть и с 10-ти летним опытом и экспертизой, с хорошими знаниями и пониманием проекта. Я как раз пытаюсь донести, что они хорошо выполняют поставленные задачи. Просто они не смотрят на многие вещи с позиции Сеньора и как Сеньор. Их подход больше похож на то, как поезд катается по рельсам по одному и тому же маршруту, который они знают отлично и могут объяснить отлично, но при этом не пытаются понять, как устроены другие маршруты.
А в чем проблема? Ну правда, если я писал эти тесты.
Я как раз описываю ситуацию, когда вы приходите на проект и видите сотни и тысячи тестов (написанных не вами) и пытаетесь разобраться, вы же мне сразу начинаете писать обратное. Пожалуйста, не интерпретируете написанное, как вам удобно.
На самом деле, на нормальном проекте у QA своя среда, где "чужие" не ходят, а то и несколько. Они сами себе все ставят и сами отвечают за конфиг. Если это нет так - прямой вопрос к лиду/сеньору на таком проекте. Ну серьезно, если QA чего-то тестируют, а паралельно кто-то чего-то на среде меняет - тут вопрос к базовым компетенциям тех, кто такое допускает.
Ну вот опять же, зависит от проекта. Вы говорите явно про небольшой проект, а не про комплексный, разделенные на многие компоненты, еще и с ежедневными релизами. Как там не разграничивай, там много зависимостей и один может потрогать свое, что затронет другие компоненты, и от этого никуда не денешься и не изолируешься. И разобраться в том, кто и как задел - та еще наука, еще и за ограниченное время.
По проекту ...интернет банкинг подойдет? С одновременным написанием интеграционный шины, DWH, доработки недостающих API. Я про размер. На одном из таким проектов было 10 команд, из них больше половины - внешние контракторы
Даа месяца - пойдет для организации социального типа. В реальной жизни да, два месяца - овер до фига.
Про процессы - это вообще несерьезно. Сеньор уже столько всего повидал, что он процессы спинным мозгом ощущает.Понятно, есть нюансы, но не на этой позиции. При всем уважении, у ловному ПМу въехать в "политический/технический проект" кратно сложнее. И то два месяца - это какой-то бред
Про среды ... настройки и организация процесса и есть задача для опытного сеньора. Но как я уже писал, многие "сеньоры" банально фейковые.
Про приход с тысячами тестов ... сорян, но но нет. Тесты, какие бы они ни были, сильно проигрывают коду в взаимных зависимостях.
Про недооценку. Если человека переоценить - можно жестко обосраться всей командой либо обречь всех на переработку. Поэтому да, человек получает щадачи которые может сделать. Миддл - любые типовые задачи.
Про приход с тысячами тестов ... сорян, но но нет. Тесты, какие бы они ни были, сильно проигрывают коду в взаимных зависимостях.
А что это означает? Не совсем понимаю.
Продуктивный код, как народ ее пытается упростить ситуацию, играя в микросервисы, домены и прочее, довольно таки сложен по структуре. И если вы получаете ошибку в коде (условно exception), то ее причина может быть довольно "далеко" от места возникновения. Либо вообще поиск сильно усложнен из-за нюансов использования фреймворка.
К примеру, на одном из проектов заказчик попросил найти причину "плавающего" бага в его legacy коде, который проявлялся как нарушение ссылочной целостности во время работы с реляционной базой. Причину разработчик и я искали довольно долго. В итого, все свелось к нюансам работы Hibernate, когда обновление структуры связных entities в какой-то момент приводило рассинхрону кеша и базы, и попытка запить данные вызывала ошибку
Ну либо на том же проекте в какой-то момент Java-машинка вывалилась с exception по памяти. Только прикол в том, что это было серверлесс решение AWS EMR. И колупание могло начинаться только с того, чтобы/ шаманить в параметрах JVM в попытки найти больше инфы
---------------------
Ну, структура авто-тестов довольно таки простая и однородная. Чисто технически. И базируется на простых вещах
И если что-то упало - довольно таки очевидно где и почему. А дальше конечно надо раскручивать, но суть в том, что раскручивание больше методическое, но не требующее знаний технических.
Абсолютно согласен. Создалось впечатление, что миддл в представлении автора это подсос, который не знает куда себя пристроить, а увидев задачу в джире начинает потеть и трястись. Ещё и имя уничижительное выбрал. Такое описание может подойти, только если на собеседовании проморгали "волчару-вкатуна", а на рабочем месте тот начинает спрашивать как дышать и как какать.
Не совсем правильное представление. Как раз Мидл абсолютно нормальная рабочая единица, знает куда себя пристроить и ответственно выполняет поставленные ему цели. Просто несамостоятельная. Дашь ему задачку в джире? Сделает. Скажешь ему починить автотест и напишешь, когда и почему стал ломаться? Починит. Но в целом все. Сеньор посмотрит в историю падения автотеста, найдет, еще причину, почему он иногда падал до этого и вообще перепишет метод, чтобы он стал стабильнее. Или вообще вместо починки заведет новую таску на удаление теста, ведь он уточнил, что он больше не нужен, потому что этот функционал не актуален и нет смысла это проверять, а стейкхолдеры сказали, что больше и не планируют этот функционал включать. Но это как раз пример, как сеньор мыслит за рамками поставленной задачи. Если у вас и Мидл так мыслит, то я считаю, что это уже большой шаг на пути к Сеньору и отличный прогресс, а не стагнация на одном месте.
И имя не уничижительное, а наоборот простецкое что ли, чтобы показать насколько просто и прямо сотрудник подходит к своим обязанностям. Да и вообще тут не надо искать скрытый смысл.
Сеньор Андрей, напротив, воспринимает это как вызов, который только укрепит его профессиональные навыки. Его мысль: «Ну что ж, похоже, придется разбираться самостоятельно. Нет времени жаловаться на устаревшие инструкции. Я найду необходимую информацию, даже если придется обращаться ко всем возможным источникам.
И эта жалоба имеет под собой хорошие основания: фирма обещает одно (рабочая документация), а дает совсем другое.
Кроме того, для фирмы довольно неразумно с финансовой стороны заставлять заниматься этим исследованием при каждой смене разработчика, т.к. никакой новизны и никакого профита из этого получить невозможно.
А без жалобы скорее всего цепочка управленцев никогда и не узнает о проблеме и даже не будет возможности исправить и как-то не допускать в будущем.
У меня стойкое ощущение, что российский бизнес часто использует сеньоров для затыкания дыр в управленческом персонале.
Кстати, могу предложить совершенно простой и очевидный критерий деления
Сеньор - может написать тестовую стратегию и свободно и правильно рассуждать на заданную тему
Тимлид - в дополение, может организовать работу команды QA по этому документы
Миддл - написать не может, не понимает причинно-следственнвх связей, но может по нему работать и выполнять задачи
Джун - я тут чтобы искать баги :)
Вы подняли отличную холиварную тему! Разделение на мидла и синьора в QA - действительно интересный вопрос - с разрабами здесь как будто намного проще обстоит дело) Спасибо за статью!)
Как обрести самостоятельность, перестать быть Мидлом QA и мыслить как Сеньор