История про благие начинания
Вместо подведения каких-то формальных итогов, хочу рассказать одну историю, связанную с тем, о чем здесь писалось ранее. Если кто помнит, канал изначально был создан, чтобы помочь бегущим от войны тестерам с full remote вакансиями. Через год я создал бесплатный курс, чтобы обучить сбежавших ручных тестеров автоматизации, менторски помогая переломить барьер входа. Сколько-то человек прошло до конца, и я надеюсь, что эти знания действительно им помогли на практике.
В этом же году я с помощью того курса очно помог человеку, натаскав почти с нуля на автоматизацию ровно к тому моменту, когда внезапно существенную часть компании сократили, и он остался в трудный момент одновременно и с критическими семейными проблемами, и без денег. Но с приобретенными знаниями.
В итоге каким-то непостижимым для меня образом его буквально через пару недель после сокращения взяли на новую работу вообще без тестового задания, просто по уверенному разговору за автотесты. Я-то знаю его уровень, поэтому всё до конца сомневался, скамеры это или просто нет шарящего человека. Оказалось, второе, и сотрудник нужен был еще вчера, поэтому и сидит вот, пилит свой фреймворк с нуля. А я консультирую :)
И это всё к тому, что ты никогда не знаешь, когда, кому и насколько твои благие начинания могут помочь. Поэтому, будучи сеньоритами и сеньорами, не забывайте вносить свой вклад в сообщества, это действительно пригождается.
Мой же собственный план на следующий год — доучить фронт на уровень, чтобы стать full stack в плане фикса мелких и средних по сложности багов. То есть, сам нашел, сам написал тест, сам починил. Это и интересно попробовать, и в перспективе повысит ценность как специалиста. Посмотрим, как пойдет. А пока всех с праздниками!
Вместо подведения каких-то формальных итогов, хочу рассказать одну историю, связанную с тем, о чем здесь писалось ранее. Если кто помнит, канал изначально был создан, чтобы помочь бегущим от войны тестерам с full remote вакансиями. Через год я создал бесплатный курс, чтобы обучить сбежавших ручных тестеров автоматизации, менторски помогая переломить барьер входа. Сколько-то человек прошло до конца, и я надеюсь, что эти знания действительно им помогли на практике.
В этом же году я с помощью того курса очно помог человеку, натаскав почти с нуля на автоматизацию ровно к тому моменту, когда внезапно существенную часть компании сократили, и он остался в трудный момент одновременно и с критическими семейными проблемами, и без денег. Но с приобретенными знаниями.
В итоге каким-то непостижимым для меня образом его буквально через пару недель после сокращения взяли на новую работу вообще без тестового задания, просто по уверенному разговору за автотесты. Я-то знаю его уровень, поэтому всё до конца сомневался, скамеры это или просто нет шарящего человека. Оказалось, второе, и сотрудник нужен был еще вчера, поэтому и сидит вот, пилит свой фреймворк с нуля. А я консультирую :)
И это всё к тому, что ты никогда не знаешь, когда, кому и насколько твои благие начинания могут помочь. Поэтому, будучи сеньоритами и сеньорами, не забывайте вносить свой вклад в сообщества, это действительно пригождается.
Мой же собственный план на следующий год — доучить фронт на уровень, чтобы стать full stack в плане фикса мелких и средних по сложности багов. То есть, сам нашел, сам написал тест, сам починил. Это и интересно попробовать, и в перспективе повысит ценность как специалиста. Посмотрим, как пойдет. А пока всех с праздниками!
👍12🔥6
Про инициативу
В этом году я планирую дорассказать детали того, как мы тестируем в команде, а также почему и как при всём этом богатстве мы пропускаем баги. А, и еще я буду нанимающим менеджером для позиции в Дании, надо нанять сеньорного сеньора, но в Копенгагене.
Но пока начну с примера инициативности в качестве одной из сфер, куда QA еще может приложить свои усилия.
У Unity есть форум, на котором пользователи могут оставлять в нужных разделах свои лестные и вообще не очень: вопросы, комментарии и, что ближе для нашей роли, сообщения об ошибках. Это отчасти заимствует функционал условного stackoverflow, где можно отмечать ответы как решения, тем самым показывая, что место живое, фидбек принимается, ошибки мониторятся и в идеале исправляются.
У каждого публично доступного продукта есть свой раздел, и в коммьюнити департаменте составили подробную инструкцию как правильно отвечать и участвовать в дискуссиях, а как лучше не стоит этого делать.
В нашем направлении получилось так, что этот момент подвис — отчасти из-за корпоративной бюрократии, отчасти из-за отсутствия четких зон ответственности, отчасти из-за того, что разработчики и менеджеры в целом предпочитают не погружаться в любящие пользовательские объятия. Я пытался пингануть то тут, то там, но кто работал в крупных компаниях, тот поймет.
Короче, уже несколько месяцев у нас это было похоже на унылую заброшку, где очень изредка какие-то пользователи могли что-то ответить. В итоге я психанул, выделил несколько часов во время затишья рождественских дней и вычистил эти авгиевы конюшни, ответив на вопросы или решив чьи-то проблемы. Как видно на скриншоте, теперь это для пользователя выглядит как место, где действительно можно получить помощь.
Для того, чтобы это не было разовой акцией, я подписался на обновления нашей ветки и теперь трачу минут десять на ответ или передачу фидбека продактам (благо у нас не супер активный раздел).
Зачем это нужно, ведь я и так делаю свое тестировочное тестирование с тестами?
Первое — как-то так получилось, что я переживаю за продукт, причем, вне зависимости от профессии (на радио было то же самое). Кто-то работает с 9 до 5, мне же всегда было интересно сделать больше.
Второе — в некоторых случаях был очень крутой и детальный фидбек от пользователей, когда ты можешь понять, как именно они используют те или иные фичи. И это может сильно отличаться от того, как команда прогнозировала и предполагала при разработке.
Третье — пользователи ценят, что их слушают. Напомню, что один из драйверов Unity это Users First, и да, пусть это может толковаться десятью разными способами и невозможно угодить всем, но людей, которые нашли время написать вам о косяке, стоит отметить, и это как раз оно. Ну и заодно можно и нужно адаптировать свои тесты, так как это самый непосредственный и прямой feedback loop, который помогает совершенствовать процессы, что собственно и есть часть Quality Assurance, а не простого тестинга (оправдываю, знаете ли, название канала).
Четвертое — это одна из вещей, которая выделяет вас на фоне других. Мое мнение, такое можно и нужно постить в общий чат команды или департамента, подчеркивая мотивацию, действия и результат.
В адекватных компаниях это способствует росту авторитета, добавляет в копилку достижений для performance review и роста грейда, ну и мотивирует других на инициативу. А если вспоминать о менее приятных вещах, то в моменты выбора, кого сокращать, а кого оставить, (хорошие, адекватные) менеджеры принимают решения на основе пользы от каждого члена команды, и инициатива с публичностью в этом помогают, особенно, когда многие вообще до сих пор(!) слабо понимают, что QA делают.
Всё это на основе моего личного опыта, если есть желание пообщаться на тему, традиционно зову в комментарии(традиционно никто не идет) .
В этом году я планирую дорассказать детали того, как мы тестируем в команде, а также почему и как при всём этом богатстве мы пропускаем баги. А, и еще я буду нанимающим менеджером для позиции в Дании, надо нанять сеньорного сеньора, но в Копенгагене.
Но пока начну с примера инициативности в качестве одной из сфер, куда QA еще может приложить свои усилия.
У Unity есть форум, на котором пользователи могут оставлять в нужных разделах свои лестные и вообще не очень: вопросы, комментарии и, что ближе для нашей роли, сообщения об ошибках. Это отчасти заимствует функционал условного stackoverflow, где можно отмечать ответы как решения, тем самым показывая, что место живое, фидбек принимается, ошибки мониторятся и в идеале исправляются.
У каждого публично доступного продукта есть свой раздел, и в коммьюнити департаменте составили подробную инструкцию как правильно отвечать и участвовать в дискуссиях, а как лучше не стоит этого делать.
В нашем направлении получилось так, что этот момент подвис — отчасти из-за корпоративной бюрократии, отчасти из-за отсутствия четких зон ответственности, отчасти из-за того, что разработчики и менеджеры в целом предпочитают не погружаться в любящие пользовательские объятия. Я пытался пингануть то тут, то там, но кто работал в крупных компаниях, тот поймет.
Короче, уже несколько месяцев у нас это было похоже на унылую заброшку, где очень изредка какие-то пользователи могли что-то ответить. В итоге я психанул, выделил несколько часов во время затишья рождественских дней и вычистил эти авгиевы конюшни, ответив на вопросы или решив чьи-то проблемы. Как видно на скриншоте, теперь это для пользователя выглядит как место, где действительно можно получить помощь.
Для того, чтобы это не было разовой акцией, я подписался на обновления нашей ветки и теперь трачу минут десять на ответ или передачу фидбека продактам (благо у нас не супер активный раздел).
Зачем это нужно, ведь я и так делаю свое тестировочное тестирование с тестами?
Первое — как-то так получилось, что я переживаю за продукт, причем, вне зависимости от профессии (на радио было то же самое). Кто-то работает с 9 до 5, мне же всегда было интересно сделать больше.
Второе — в некоторых случаях был очень крутой и детальный фидбек от пользователей, когда ты можешь понять, как именно они используют те или иные фичи. И это может сильно отличаться от того, как команда прогнозировала и предполагала при разработке.
Третье — пользователи ценят, что их слушают. Напомню, что один из драйверов Unity это Users First, и да, пусть это может толковаться десятью разными способами и невозможно угодить всем, но людей, которые нашли время написать вам о косяке, стоит отметить, и это как раз оно. Ну и заодно можно и нужно адаптировать свои тесты, так как это самый непосредственный и прямой feedback loop, который помогает совершенствовать процессы, что собственно и есть часть Quality Assurance, а не простого тестинга (оправдываю, знаете ли, название канала).
Четвертое — это одна из вещей, которая выделяет вас на фоне других. Мое мнение, такое можно и нужно постить в общий чат команды или департамента, подчеркивая мотивацию, действия и результат.
В адекватных компаниях это способствует росту авторитета, добавляет в копилку достижений для performance review и роста грейда, ну и мотивирует других на инициативу. А если вспоминать о менее приятных вещах, то в моменты выбора, кого сокращать, а кого оставить, (хорошие, адекватные) менеджеры принимают решения на основе пользы от каждого члена команды, и инициатива с публичностью в этом помогают, особенно, когда многие вообще до сих пор(!) слабо понимают, что QA делают.
Всё это на основе моего личного опыта, если есть желание пообщаться на тему, традиционно зову в комментарии
👍4❤2🔥1
360 review
В комментариях спросили, как у нас проходит годовое ревью, сегодня об этом и поговорим. В принципе во всех канадских и американских компаниях, где я работал, практика примерно одинакова, поэтому если вы уже где-то читали, как это тут организовано, можно скипнуть, если нет, поехали.
[Ревью VS Повышение]
Для начала разделю ежегодное ревью и работу над повышением, хотя они и весьма взаимосвязаны. Ревью ставит своей целью оценить, все еще соответсвует ли конкретный работник своей должности, есть ли проблемы с производительностью/поведением или наоборот, не пора ли задуматься о повышении по лестнице.
Если у менеджеров есть бюджет на инфляционные поправки к зарплате, то тут в зависимости от успехов кому-то может перепасть чуть больше, кому-то, как всем.
На мой субъективный взгляд, получить повышение в стандартном североамериканском корпоративе, просто самостоятельно втихаря решив фигачить больше, пожалуй, можно, но вообще не просто. А просто за выслугу лет добиться следующего грейда, может, где-то и можно, но это не кажется массовой практикой.
Повышение, особенно на более сеньорных позициях, это такая специальная карьерная операция, где весьма значимую роль играет собственно ваш менеджер, который и будет подавать пакет достижений выше, то есть он в первую очередь должен быть уверен в том, что подает правильную кандидатуру. Поэтому с ним заранее обговаривается четкий план действий, уточняются пункты, которые стоит усилить-улучшить и понять, что будет служить подтверждением успехов и самое главное — регулярные чекины по прогрессу.
Для того, чтобы это все сработало, я рекомендую собирать все подтверждения вашей клевости в один файл, где описывать все основные детали, чтобы потом в нужный момент можно было вспомнить нюансы. Я себе поставил еженедельную напоминалку, так как дальше с этой вечной рутиной уже забываю, что там было хорошего.
Для прохождения ревью, каждый человек сначала сам ставит себе оценку вида "тут я молодец, тут вообще супер, а здесь надо бы подтянуть". Далее анонимный фидбек дают коллеги, это распихивается по нужным пунктам, и в завершении менеджер делает собственное саммари, где сводит все к тому, что либо все ок, либо есть проблемы, или же ура, можно думать в сторону повышения. А так как и ревью, и повышение базируются на матрице компетенций, об этом и поговорим далее.
[Матрица компетенций]
В ней показан набор и прогрессия хард и софт скиллов для каждого уровня от миддлов IC5 до принципалов IC10. То есть, заранее можно увидеть, что требуется для следующего. Ну а когда вас нанимают, то оценивают по этой же шкале: по прошлым заслугам, тестовому и живому общению дают соответствующий грейд.
Примеры хард скиллов для разработчиков и SDET: Code quality & testing, Debugging, Software design & architecture, Security.
Примеры софт скиллов: Self-organization, Feedback, Communication, Collaboration.
Лидерство: Decision making, Driving alignment, Process thinking, Mentoring.
Для каждого пункта даются свои пояснения и примеры.
Понятно, что чем сеньорнее, тем больше ответственности, лучше код, тесты и прочее. Но не менее важно становится и взаимодействие - сначала внутри команды, потом все шире и шире. Ну и упомянутая публичность тоже необходима, так как вы уже не просто сам по себе молодец, но и должны оказывать положительное влияние на других. Например, IC 9 и 10 это "всего лишь" про facilitating, guiding, mentoring, но вы понимаете, какой экспертизой должны обладать люди, которые это могут делать в рамках той же Unity.
Если мы говорим про ветку QA, то это про построение и постоянное улучшение процессов, менторинг разработчиков, культура ответственности за продукт, lead by example и прочее. Это сложно достичь без постоянной коммуникации, презентаций и митингов. В особенности, когда вы все разбросаны по миру. Можно быть супер мега тестером и ловить множество багов самому, но всего всё равно не поймать, а если вы ушли в долгий отпуск или же вообще, то без одного сенсея с неправильной культурой, всё очень быстро деградирует.
Наверняка что-то упустил, и, если есть вопросы, welcome.
В комментариях спросили, как у нас проходит годовое ревью, сегодня об этом и поговорим. В принципе во всех канадских и американских компаниях, где я работал, практика примерно одинакова, поэтому если вы уже где-то читали, как это тут организовано, можно скипнуть, если нет, поехали.
[Ревью VS Повышение]
Для начала разделю ежегодное ревью и работу над повышением, хотя они и весьма взаимосвязаны. Ревью ставит своей целью оценить, все еще соответсвует ли конкретный работник своей должности, есть ли проблемы с производительностью/поведением или наоборот, не пора ли задуматься о повышении по лестнице.
Если у менеджеров есть бюджет на инфляционные поправки к зарплате, то тут в зависимости от успехов кому-то может перепасть чуть больше, кому-то, как всем.
На мой субъективный взгляд, получить повышение в стандартном североамериканском корпоративе, просто самостоятельно втихаря решив фигачить больше, пожалуй, можно, но вообще не просто. А просто за выслугу лет добиться следующего грейда, может, где-то и можно, но это не кажется массовой практикой.
Повышение, особенно на более сеньорных позициях, это такая специальная карьерная операция, где весьма значимую роль играет собственно ваш менеджер, который и будет подавать пакет достижений выше, то есть он в первую очередь должен быть уверен в том, что подает правильную кандидатуру. Поэтому с ним заранее обговаривается четкий план действий, уточняются пункты, которые стоит усилить-улучшить и понять, что будет служить подтверждением успехов и самое главное — регулярные чекины по прогрессу.
Для того, чтобы это все сработало, я рекомендую собирать все подтверждения вашей клевости в один файл, где описывать все основные детали, чтобы потом в нужный момент можно было вспомнить нюансы. Я себе поставил еженедельную напоминалку, так как дальше с этой вечной рутиной уже забываю, что там было хорошего.
Для прохождения ревью, каждый человек сначала сам ставит себе оценку вида "тут я молодец, тут вообще супер, а здесь надо бы подтянуть". Далее анонимный фидбек дают коллеги, это распихивается по нужным пунктам, и в завершении менеджер делает собственное саммари, где сводит все к тому, что либо все ок, либо есть проблемы, или же ура, можно думать в сторону повышения. А так как и ревью, и повышение базируются на матрице компетенций, об этом и поговорим далее.
[Матрица компетенций]
В ней показан набор и прогрессия хард и софт скиллов для каждого уровня от миддлов IC5 до принципалов IC10. То есть, заранее можно увидеть, что требуется для следующего. Ну а когда вас нанимают, то оценивают по этой же шкале: по прошлым заслугам, тестовому и живому общению дают соответствующий грейд.
Примеры хард скиллов для разработчиков и SDET: Code quality & testing, Debugging, Software design & architecture, Security.
Примеры софт скиллов: Self-organization, Feedback, Communication, Collaboration.
Лидерство: Decision making, Driving alignment, Process thinking, Mentoring.
Для каждого пункта даются свои пояснения и примеры.
Понятно, что чем сеньорнее, тем больше ответственности, лучше код, тесты и прочее. Но не менее важно становится и взаимодействие - сначала внутри команды, потом все шире и шире. Ну и упомянутая публичность тоже необходима, так как вы уже не просто сам по себе молодец, но и должны оказывать положительное влияние на других. Например, IC 9 и 10 это "всего лишь" про facilitating, guiding, mentoring, но вы понимаете, какой экспертизой должны обладать люди, которые это могут делать в рамках той же Unity.
Если мы говорим про ветку QA, то это про построение и постоянное улучшение процессов, менторинг разработчиков, культура ответственности за продукт, lead by example и прочее. Это сложно достичь без постоянной коммуникации, презентаций и митингов. В особенности, когда вы все разбросаны по миру. Можно быть супер мега тестером и ловить множество багов самому, но всего всё равно не поймать, а если вы ушли в долгий отпуск или же вообще, то без одного сенсея с неправильной культурой, всё очень быстро деградирует.
Наверняка что-то упустил, и, если есть вопросы, welcome.
50 оттенков синего
На днях напарница скинула скрины инсты, и я поржал над очередным подтверждением, что сейчас многие в темпе вальса готовятся к июню 2025-го, когда наступит дедлайн по accessibility, и европейцы вновь впереди планеты всей будут начинать драть за публичные сайты, которые не успели адаптироваться (как до этого с куками). И забавно, что мы вместе с инстой, у которых тоже бренд цвета включали ярко синий, почти одновременно выкатили такие же новые accessible цвета.
Кто меня читает давно, знает, что я могу в словесную эквилибристку, но вот долго искал подходящее выражение к тому, как все годы подавляющее большинство компаний относилось к accessibility, и лучше чем “всем было насрать” не нашел, потому что остальные эпитеты не отражают отношения менеджеров к малому сегменту пользователей, которые, по их мнению, не приносят много денег, а денег на оплату разработчикам требуют. Поэтому пока ко всем не пришли юристы и не сказали, что иски за несоблюдение правил могут превысить их профиты от фич, никто и не шевелился, кроме, пожалуй, каких-то государственных сайтов.
Раз такая тема, то расскажу про процессы тестирования accessibility, благо на новом стеке мы стали этим заниматься задолго до того, как это стало авральным.
На днях напарница скинула скрины инсты, и я поржал над очередным подтверждением, что сейчас многие в темпе вальса готовятся к июню 2025-го, когда наступит дедлайн по accessibility, и европейцы вновь впереди планеты всей будут начинать драть за публичные сайты, которые не успели адаптироваться (как до этого с куками). И забавно, что мы вместе с инстой, у которых тоже бренд цвета включали ярко синий, почти одновременно выкатили такие же новые accessible цвета.
Кто меня читает давно, знает, что я могу в словесную эквилибристку, но вот долго искал подходящее выражение к тому, как все годы подавляющее большинство компаний относилось к accessibility, и лучше чем “всем было насрать” не нашел, потому что остальные эпитеты не отражают отношения менеджеров к малому сегменту пользователей, которые, по их мнению, не приносят много денег, а денег на оплату разработчикам требуют. Поэтому пока ко всем не пришли юристы и не сказали, что иски за несоблюдение правил могут превысить их профиты от фич, никто и не шевелился, кроме, пожалуй, каких-то государственных сайтов.
Раз такая тема, то расскажу про процессы тестирования accessibility, благо на новом стеке мы стали этим заниматься задолго до того, как это стало авральным.
Тестирование accessibility
Сначала пару слов зачем это всё, вдруг кто не в курсе. Для группы людей, у которых есть физиологические различия в восприятии контента, есть специальные правила и рекомендации к разработчикам, которые помогают таким клиентам пользоваться вашим приложением наравне с остальными. Если очень упрощенно то цвета должны быть контрастными, навигация с клавиатуры доступной, подсказки voice over логичными и так далее.
Сейчас все будут адаптировать свои сайты под минимальный стандарт WCAG 2.1 AA, но вроде как планка будет со временем подниматься.
[Как мы тестируем]
У Unity был заключен контракт с одним из крупных провайдеров, которые занимаются всем, что связано с accessibility, а наша команда была в пилотном проекте по внедрению, который я курировал, поэтому могу в доступных для публичного шаринга деталях рассказать об основных процессах. И да, тут немало ручных телодвижений, потому что эта сфера, где пока невозможно на 100% всё автоматизировать.
Основные проблемы с контрастами лучше всего находить на самой ранней стадии, поэтому провайдер сделал плагин для Figma, в которой у нас орудуют дизайнеры. С ним были некоторые загвоздки, поэтому понадобился не один раунд, чтобы всё же их подружить друг с другом, хотя такие штуки, конечно, надо бы форсить с самого начала.
Далее при разработке UI фич у нас идет требование по скану контента с помощью их плагина для браузера, навигации с помощью клавиатуры и voice over. Это отдается на откуп самим разработчкам, они это проверяют или локально, или на их PR окружении, но до вливания в любые другие общие ветки.
Когда фича готова для широкой публики, мы добавляем нужные страницы в автоматический мониторинг, который по расписанию присылает отчеты и тренды.
Параллельно запрашиваем ручное ревью, когда их человек проходится с нужными инструментами и дает подробный баг репорт на каждую хреновину. На деле этих хреновин несметное количество, и вообще, по моим наблюдениям, исправить все-все баги вряд ли возможно и целесообразно.
Когда отчет готов, я завожу таски на исправление всех critical и отобранных high priority проблем. Наша основная цель — сфокусироваться на том, чтобы таким реальным пользователям была точно доступна основная функциональность, а не на соблюдении всех возможных правил, что, как понятно по практике, практически невозможно.
Важный нюанс: не всё можно покрыть автоматическим сканом статического html, поэтому провайдер добавил плагины к популярным E2E фреймворкам, которые в нужных местах флоу делают сканы и отправляют репорт на сервер. Мы таким пока не балуемся, но это один из вариантов.
В итоге новый проект изначально разрабатывался со всеми нужными проверками, и да, его тоже нужно будет еще раз отправить на ревью перед днем Д, но большинство типичных вещей уже было найдено и исправлено сразу, что круто.
Сначала пару слов зачем это всё, вдруг кто не в курсе. Для группы людей, у которых есть физиологические различия в восприятии контента, есть специальные правила и рекомендации к разработчикам, которые помогают таким клиентам пользоваться вашим приложением наравне с остальными. Если очень упрощенно то цвета должны быть контрастными, навигация с клавиатуры доступной, подсказки voice over логичными и так далее.
Сейчас все будут адаптировать свои сайты под минимальный стандарт WCAG 2.1 AA, но вроде как планка будет со временем подниматься.
[Как мы тестируем]
У Unity был заключен контракт с одним из крупных провайдеров, которые занимаются всем, что связано с accessibility, а наша команда была в пилотном проекте по внедрению, который я курировал, поэтому могу в доступных для публичного шаринга деталях рассказать об основных процессах. И да, тут немало ручных телодвижений, потому что эта сфера, где пока невозможно на 100% всё автоматизировать.
Основные проблемы с контрастами лучше всего находить на самой ранней стадии, поэтому провайдер сделал плагин для Figma, в которой у нас орудуют дизайнеры. С ним были некоторые загвоздки, поэтому понадобился не один раунд, чтобы всё же их подружить друг с другом, хотя такие штуки, конечно, надо бы форсить с самого начала.
Далее при разработке UI фич у нас идет требование по скану контента с помощью их плагина для браузера, навигации с помощью клавиатуры и voice over. Это отдается на откуп самим разработчкам, они это проверяют или локально, или на их PR окружении, но до вливания в любые другие общие ветки.
Когда фича готова для широкой публики, мы добавляем нужные страницы в автоматический мониторинг, который по расписанию присылает отчеты и тренды.
Параллельно запрашиваем ручное ревью, когда их человек проходится с нужными инструментами и дает подробный баг репорт на каждую хреновину. На деле этих хреновин несметное количество, и вообще, по моим наблюдениям, исправить все-все баги вряд ли возможно и целесообразно.
Когда отчет готов, я завожу таски на исправление всех critical и отобранных high priority проблем. Наша основная цель — сфокусироваться на том, чтобы таким реальным пользователям была точно доступна основная функциональность, а не на соблюдении всех возможных правил, что, как понятно по практике, практически невозможно.
Важный нюанс: не всё можно покрыть автоматическим сканом статического html, поэтому провайдер добавил плагины к популярным E2E фреймворкам, которые в нужных местах флоу делают сканы и отправляют репорт на сервер. Мы таким пока не балуемся, но это один из вариантов.
В итоге новый проект изначально разрабатывался со всеми нужными проверками, и да, его тоже нужно будет еще раз отправить на ревью перед днем Д, но большинство типичных вещей уже было найдено и исправлено сразу, что круто.
www.w3.org
Web Content Accessibility Guidelines (WCAG) 2.1
Web Content Accessibility Guidelines (WCAG) 2.1 covers a wide range of recommendations for making web content more accessible. Following these guidelines will make content more accessible to a wider range of people with disabilities, including accommodations…
🔥3
Accessibility и легаси
А вот самый ад начинается, когда вам нужно фиксить чей-то легаси код, а тогда, много лет назад, вообще народ не думал про такие штуки, поэтому всякие кнопки, ссылки, меню, таблицы это всё — просто div! И когда начинается исправление, нередко вылезают проблемы с css, то есть любые правки надо проверять в разных браузерах, на разных брейкпойтах и еще светлых/темных темах. То есть, фиксы accessibility могут вылиться в неожиданные человеко-часы для тех менеджеров, которые были не в курсе всего этого веселья.
Напоследок расскажу о подобном фиксе легаси кода, который поломал одну из ключевых фич в проде.
В компонент аккордеона можно передать таблицу, которая собственно и была представлена дивами вместо стандартных табличных элементов. И после фикса уже в проде оказалось, что у некоторых продуктов, на странице которых была таблица совместимости с версиями Unity, вылетал консольный exception, говорящий о том, что js код не может получить доступ к нужным элементам таблицы. А раз эта часть крашнулась, то последующий код, который влияет на отображение главной CTA на странице не работал, и пользователи не могли перейти к следующему шагу.
То есть, еще раз: легаси код, всего лишь поправили div на table, ик хренам полетела основная функциональность!
А нашли мы это благодаря мониторингу крашей в проде, который делается с помощью Sentry, и который же шлет ошибки в Slack, поэтому получилось быстро это отловить, откатить и исправить, но о мониторингах как-нибудь в следующий раз.
А вот самый ад начинается, когда вам нужно фиксить чей-то легаси код, а тогда, много лет назад, вообще народ не думал про такие штуки, поэтому всякие кнопки, ссылки, меню, таблицы это всё — просто div! И когда начинается исправление, нередко вылезают проблемы с css, то есть любые правки надо проверять в разных браузерах, на разных брейкпойтах и еще светлых/темных темах. То есть, фиксы accessibility могут вылиться в неожиданные человеко-часы для тех менеджеров, которые были не в курсе всего этого веселья.
Напоследок расскажу о подобном фиксе легаси кода, который поломал одну из ключевых фич в проде.
В компонент аккордеона можно передать таблицу, которая собственно и была представлена дивами вместо стандартных табличных элементов. И после фикса уже в проде оказалось, что у некоторых продуктов, на странице которых была таблица совместимости с версиями Unity, вылетал консольный exception, говорящий о том, что js код не может получить доступ к нужным элементам таблицы. А раз эта часть крашнулась, то последующий код, который влияет на отображение главной CTA на странице не работал, и пользователи не могли перейти к следующему шагу.
То есть, еще раз: легаси код, всего лишь поправили div на table, и
А нашли мы это благодаря мониторингу крашей в проде, который делается с помощью Sentry, и который же шлет ошибки в Slack, поэтому получилось быстро это отловить, откатить и исправить, но о мониторингах как-нибудь в следующий раз.
Что с рынком?
В этот раз коротенько, 2 события в один день. Unity анонсировала очередной раунд увольнений, а я пообщался с рекрутером из Lyft.
После золотого ковидного времени, когда люди не хотели работать, а работодатели щедро поливали всех деньгами и удаленкой, мы все еще, судя по всему, находимся в стадии, когда компании ищут способы затянуть пояса. В статье пишут, что у нас это 6й раунд, я уже сам запутался, честно говоря, но оптимизма не добавляет, разумеется.
Позицию, на которую я выступал нанимающим менеджером, тоже убрали, так что рассказывать особо нечего. Для подавшихся кандидатов это, пожалуй, выглядит как ghost jobs, что не так, но внешние симптомы те же.
С другой стороны, Lyft предложил пообщаться насчет их сеньорской позиции в Монреале. 3 дня в офисе, и на многие десятки тысяч(!) меньше их базовая зарплата, что фантастика, конечно. В целом за 2024 год мне написало несколько рекрутеров, что сильно больше ~0 в 2023, но все же очень глухо в сравнении с 2021, когда у меня было новое релеватное письмо в линкеде каждые 2 дня.
Если у вас есть, чем поделиться по поводу опыта по своему рынку, напишите, пожалуйста, в комментариях.
В этот раз коротенько, 2 события в один день. Unity анонсировала очередной раунд увольнений, а я пообщался с рекрутером из Lyft.
После золотого ковидного времени, когда люди не хотели работать, а работодатели щедро поливали всех деньгами и удаленкой, мы все еще, судя по всему, находимся в стадии, когда компании ищут способы затянуть пояса. В статье пишут, что у нас это 6й раунд, я уже сам запутался, честно говоря, но оптимизма не добавляет, разумеется.
Позицию, на которую я выступал нанимающим менеджером, тоже убрали, так что рассказывать особо нечего. Для подавшихся кандидатов это, пожалуй, выглядит как ghost jobs, что не так, но внешние симптомы те же.
С другой стороны, Lyft предложил пообщаться насчет их сеньорской позиции в Монреале. 3 дня в офисе, и на многие десятки тысяч(!) меньше их базовая зарплата, что фантастика, конечно. В целом за 2024 год мне написало несколько рекрутеров, что сильно больше ~0 в 2023, но все же очень глухо в сравнении с 2021, когда у меня было новое релеватное письмо в линкеде каждые 2 дня.
Если у вас есть, чем поделиться по поводу опыта по своему рынку, напишите, пожалуйста, в комментариях.
80LV
Breaking: Unity Suddenly Lays Off Numerous Developers With a 5 AM Email
Apparently, the entire Unity Behavior team was cut, alongside many other employees.
Тестирование ≠ QA pinned «Что с рынком? В этот раз коротенько, 2 события в один день. Unity анонсировала очередной раунд увольнений, а я пообщался с рекрутером из Lyft. После золотого ковидного времени, когда люди не хотели работать, а работодатели щедро поливали всех деньгами и…»
Наткнулся сейчас на айтишечный график в продолжение предыдущей темы
https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE
https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE
Я уже как-то кидал ссылку на экс принципала из Амазон, сегодня хочу пошарить его новое видео про повышения. Отчасти благодаря его советам я в прошлом году получил своё.
https://youtu.be/RUlvn0dbA0k?si=82iAbbDuKFSekR4c
https://youtu.be/RUlvn0dbA0k?si=82iAbbDuKFSekR4c
🔥2👍1
Как мы автотестируем: общее
Сегодня о том, как мы подходили к автотестам для нашего (тогда) нового web-проекта, когда можно было выбирать все подходы с нуля. Будет не менее трех частей, эта - про общую философию и подходы, в следующие разы про нюансы на фронте и сервере.
[Один QA/SDET в поле не воин]
Один QA (эт я) не масштабируется, поэтому мы посовещались и решили, что мне важнее заняться строительством собственно культуры, фреймворками, воркшопами, исследовательским тестированием, нагрузкой и в целом быть эдаким "сторожевым псом" по качеству. Разумеется, и самому писать тесты, когда разработчикам требуется помощь.
Соответственно, первое правило, которое я пушил с самого начала - мы все одинаково отвечаем за фичу с самого начала до выкатки и успешного мониторинга в проде. То есть, у нас не будет перекидывания ответственности через забор, и, что еще важнее, мы будем учиться на своих ошибках, которые все же смогли пробраться.
Забегая вперед, оно действительно так и работает, и мне пора бояться сокращений, ибо, откровенно говоря, я уже не так нужен этой команде, так как они уже вышли на достаточный уровень самостоятельности. Собственно по этой причине я сейчас и учу React, чтобы начать фиксить некоторые ошибки самостоятельно. Но давайте по порядку.
[Пишут все]
Если я отвечаю за все вышеперечисленное, то это автоматом означает, что разработчики пишут тесты на всё, что имеет смысл покрывать. Я понимаю, что это больной момент для многих, и это один из самых частых вопросов ко мне - как сделать так, чтобы девелоперы стали писать тесты да еще и не из-под палки. Простого ответа нет, и эти рассуждения потянут еще на один отдельный пост, поэтому кратко - осознанность старших разработчиков, ваш опыт и авторитет, удобные инструменты, непрерывная работа вашими софт скиллами и один на один, и в команде. Но все же я надеюсь, что текущий тренд на то, что не писать тесты на свой код это сейчас всё более моветон.
[Уровни покрытия]
Основной посыл был в том, чтобы с достаточной уверенностью покрыть бизнес-логику самым быстрым видом тестов. То есть, функции покрываются юнит-тестами, компоненты в сборе/middleware - компонентными/интеграционными, и если уже точно никак без системы в сборе, то уже в этом случае идут наши слоняры E2E тесты. Да, мы смотрели в сторону тестирования контрактов, но пока не решились в это нырять.
[CI/CD: must be green]
Я уже писал, что при открытии
[Кто всё поломал]
Одна из находок, которая сильно помогла сильно ускорить фидбек на падающие тесты, оказалась в персонализированных уведомлениях в общий чат: автор последнего коммита в
[Автотесты на баги из прода]
Баги из прода, серьезно влияющие на ревеню или на имидж - это лучший симптом того, что должно быть покрыто автотестами или мониторингом. Отсюда правило, если был такой косяк в проде - ищем какой-либо способ избежать этого в будущем. Да, не всё можно и нужно автоматизировать, но ошибки такого рода должны рассматриваться как первые кандидаты.
[Заключение]
Понятно, что не всё работает идеально, и всегда есть человеческий фактор, но что важно: не конкретные люди, а процессы, культура и постоянное улучшение. И это то, что я подразумеваю под Quality Assurance, которое ≠ тестированию 🙂
Сегодня о том, как мы подходили к автотестам для нашего (тогда) нового web-проекта, когда можно было выбирать все подходы с нуля. Будет не менее трех частей, эта - про общую философию и подходы, в следующие разы про нюансы на фронте и сервере.
[Один QA/SDET в поле не воин]
Один QA (эт я) не масштабируется, поэтому мы посовещались и решили, что мне важнее заняться строительством собственно культуры, фреймворками, воркшопами, исследовательским тестированием, нагрузкой и в целом быть эдаким "сторожевым псом" по качеству. Разумеется, и самому писать тесты, когда разработчикам требуется помощь.
Соответственно, первое правило, которое я пушил с самого начала - мы все одинаково отвечаем за фичу с самого начала до выкатки и успешного мониторинга в проде. То есть, у нас не будет перекидывания ответственности через забор, и, что еще важнее, мы будем учиться на своих ошибках, которые все же смогли пробраться.
Забегая вперед, оно действительно так и работает, и мне пора бояться сокращений, ибо, откровенно говоря, я уже не так нужен этой команде, так как они уже вышли на достаточный уровень самостоятельности. Собственно по этой причине я сейчас и учу React, чтобы начать фиксить некоторые ошибки самостоятельно. Но давайте по порядку.
[Пишут все]
Если я отвечаю за все вышеперечисленное, то это автоматом означает, что разработчики пишут тесты на всё, что имеет смысл покрывать. Я понимаю, что это больной момент для многих, и это один из самых частых вопросов ко мне - как сделать так, чтобы девелоперы стали писать тесты да еще и не из-под палки. Простого ответа нет, и эти рассуждения потянут еще на один отдельный пост, поэтому кратко - осознанность старших разработчиков, ваш опыт и авторитет, удобные инструменты, непрерывная работа вашими софт скиллами и один на один, и в команде. Но все же я надеюсь, что текущий тренд на то, что не писать тесты на свой код это сейчас всё более моветон.
[Уровни покрытия]
Основной посыл был в том, чтобы с достаточной уверенностью покрыть бизнес-логику самым быстрым видом тестов. То есть, функции покрываются юнит-тестами, компоненты в сборе/middleware - компонентными/интеграционными, и если уже точно никак без системы в сборе, то уже в этом случае идут наши слоняры E2E тесты. Да, мы смотрели в сторону тестирования контрактов, но пока не решились в это нырять.
[CI/CD: must be green]
Я уже писал, что при открытии
Pull Request создается эфемерное окружение, где на каждый коммит в ветку запускаются все проверки, включая статические анализаторы кода. Непрошедшие тесты или проверки блокируют дальнейшие шаги, и это одна из вещей, которая заставляет команду следить за тестами не менее, чем за основным кодом. Если мы видим, что какие-то тесты сбоят и дело именно в коде самих тестов, то оно либо сразу фиксится, либо убирается из набора, но точно не существует состояния, когда команда видит отчет и думает "а, да это опять те несколько flaky тестов". Кстати, об отчетах. [Кто всё поломал]
Одна из находок, которая сильно помогла сильно ускорить фидбек на падающие тесты, оказалась в персонализированных уведомлениях в общий чат: автор последнего коммита в
main получает @mention себя со списком упавших тестов и меня в СС в придачу. Это может показаться что-то типа finger pointing, чего в западных компаниях не любят, но вся команда одобрила это еще на берегу, поэтому часто разработчики сами первые начают писать в тред, что они увидели из отчетов.[Автотесты на баги из прода]
Баги из прода, серьезно влияющие на ревеню или на имидж - это лучший симптом того, что должно быть покрыто автотестами или мониторингом. Отсюда правило, если был такой косяк в проде - ищем какой-либо способ избежать этого в будущем. Да, не всё можно и нужно автоматизировать, но ошибки такого рода должны рассматриваться как первые кандидаты.
[Заключение]
Понятно, что не всё работает идеально, и всегда есть человеческий фактор, но что важно: не конкретные люди, а процессы, культура и постоянное улучшение. И это то, что я подразумеваю под Quality Assurance, которое ≠ тестированию 🙂
🔥4❤2👏1
Реактивный прогресс
В конце прошлого года я писал о том, что хочу доучить фронт на уровень, чтобы лучше понимать детали имплементации и делать более осознанные ревью PR, а также, чтобы самому начать фиксить хотя бы несложные функциональные баги. Я не планирую переходить в разработку, цель здесь - поднять свою ценность в этот период глобальной нестабильности. Ну и более приземленно - нашу команду разделили на несколько подов, и я оказался один на один с единственным разработчиком, то есть, непосредственно тестирования у нас будет не так, чтобы прямо много.
Написать этот пост я решил, вспомнив о том, что большинство предновогодних обещаний остается предновогодними из-за того, что в течение года на эти благие хотелки еще надо будет найти силы, время и мотивацию. И да, это весьма непросто с рабочей текучкой, домом, тремя детьми и возрастом (блин!).
Но все же хочу поделиться тем, что уже есть: на Хекслете (почему он) я прошел курс
Разумеется, необходимо знать всю эту базу самому, иначе можно пропустить косяки, без которых AIство всё равно не обходится, но многие штуки действительно очень легко решаются, если знать что и как спрашивать. Но мой пойнт, скорее, в том, что AI не нужно бояться, а уже давно осёдлывать, так как без этого уже, видимо, никак.
В конце прошлого года я писал о том, что хочу доучить фронт на уровень, чтобы лучше понимать детали имплементации и делать более осознанные ревью PR, а также, чтобы самому начать фиксить хотя бы несложные функциональные баги. Я не планирую переходить в разработку, цель здесь - поднять свою ценность в этот период глобальной нестабильности. Ну и более приземленно - нашу команду разделили на несколько подов, и я оказался один на один с единственным разработчиком, то есть, непосредственно тестирования у нас будет не так, чтобы прямо много.
Написать этот пост я решил, вспомнив о том, что большинство предновогодних обещаний остается предновогодними из-за того, что в течение года на эти благие хотелки еще надо будет найти силы, время и мотивацию. И да, это весьма непросто с рабочей текучкой, домом, тремя детьми и возрастом (блин!).
Но все же хочу поделиться тем, что уже есть: на Хекслете (почему он) я прошел курс
JS: React https://ru.hexlet.io/courses/js-react и сейчас добиваю React: Redux Toolkit https://ru.hexlet.io/courses/js-redux-toolkit (остальные модули профессии я прошел ранее). На некоторых уроках я активно пробовал Copilot, чтобы понять, насколько могу частично или полностью реализовывать те требования, что даны в упражнениях. И (неудивительно) AI достаточно быстро схватывает то, что от него требуется, и некоторые не самые простые задачи делаются вообще за один промт. Разумеется, необходимо знать всю эту базу самому, иначе можно пропустить косяки, без которых AIство всё равно не обходится, но многие штуки действительно очень легко решаются, если знать что и как спрашивать. Но мой пойнт, скорее, в том, что AI не нужно бояться, а уже давно осёдлывать, так как без этого уже, видимо, никак.
Telegram
Тестирование ≠ QA
История про благие начинания
Вместо подведения каких-то формальных итогов, хочу рассказать одну историю, связанную с тем, о чем здесь писалось ранее. Если кто помнит, канал изначально был создан, чтобы помочь бегущим от войны тестерам с full remote вакансиями.…
Вместо подведения каких-то формальных итогов, хочу рассказать одну историю, связанную с тем, о чем здесь писалось ранее. Если кто помнит, канал изначально был создан, чтобы помочь бегущим от войны тестерам с full remote вакансиями.…
👍5💯1
Forwarded from Организованное программирование | Кирилл Мокевнин (Кирилл Мокевнин (Бот))
Заменит ли ИИ программистов? Вокруг себя вижу много панических настроений на эту тему, поэтому пост. Начну с анекдота
Клиент вызывает мастера починить сломавшийся станок.
Мастер приходит, осматривает станок, берет молоток, слегка ударяет в одном месте — станок снова работает.
Мастер выписывает счет на $500.
Клиент возмущается:
— За что $500? Вы же только один раз молотком ударили!
Мастер спокойно отвечает:
— За удар молотком — $5. За то, чтобы знать, куда ударить — $495.
ИИ действительно может генерировать куски кода, но написать код != создать работающую систему. Программирование это не только набор символов в редакторе. Это анализ требований, архитектура, проектирование системных взаимодействий, поддержка, развитие. ИИ не умеет брать на себя всю полноту инженерной ответственности: понимать зачем, почему и в каком контексте разрабатывается продукт.
Кроме того, задача программиста - не просто написать решение, а проанализировать его стоимость: насколько оно сложно в поддержке, сколько ресурсов потребует в будущем, сколько будет стоить исправление ошибок и адаптация под изменения. Иногда работа специалиста не в том, чтобы реализовать то, что попросили, а в том, чтобы предложить более дешевую, простую и надежную альтернативу.
Еще один важный момент: ИИ в своей природе в основном "копипастит" уже существующие паттерны кода, но не создает новых абстракций. Создание абстракций требует понимания сути задачи, компромиссов между сложностью и гибкостью, предвидения будущих изменений. Это работа мышления, а не перебора вариантов. Создание правильных абстракций определяет, насколько система будет масштабируемой, понятной и живучей. ИИ пока остается на уровне механического исполнения без глубокого понимания задач.
И наконец: реальные проекты - это не изолированные кусочки кода. Это сложные системы с множеством взаимосвязанных компонентов: базы данных, кэш-сервисы, очереди, микросервисы, балансировщики нагрузки, десятки или сотни серверов. Ошибки в таких системах проявляются не там, где был написан код, а на стыках между частями, под нагрузкой, в редких пограничных случаях. Диагностика и исправление таких ошибок требуют системного мышления, опыта и понимания работы всей инфраструктуры целиком. Пока ИИ не способен взять на себя такую ответственность.
Миф: ИИ сделает всех равными
Кажется, что с ИИ теперь каждый сможет делать то же самое, что и крутой разработчик. Но на практике ИИ становится инструментом в руках человека. Чем опытнее человек, тем лучше он ставит задачи ИИ, проверяет результаты и направляет процесс. Это усиливает разницу между сильными и слабыми разработчиками: кто умеет думать становится еще продуктивнее, кто не умеет, тонет в посредственных результатах.
Миф: ИИ заменит джунов
В этом утверждении зашито представление, что джуны нужны для выполнения каких-то базовых задач с которыми справится любой дурак. Поэтому без ии нам приходилось их нанимать, а вот с ии они больше будут не нужны. Компании нанимают джунов по другим причинам. Они готовы вкладываться в людей, чтобы вырастить из них квалифицированных специалистов. То есть никто не нанимает джуна, для того, чтобы он остался джуном. Тогда это был бы не джун, а вполне себе опытный, но очень низкоквалицированный специалист на низковалифицированную задачу.
Миф: Нужно срочно менять профессию
Как и с любой новой технологией, реальный сценарий это не исчезновение профессии, а её изменение. Появится больше задач по интеграции ИИ в продукты, по проектированию взаимодействия между человеком и машиной, по валидации и контролю качества того, что делает ИИ. Уйдут рутинные задачи, вырастет ценность проектирования, системного мышления и креативности.
Что действительно меняется
* Рутинные задачи действительно будут автоматизироваться.
* Навыки работы с ИИ становятся частью базового набора разработчика.
* Возрастет ценность знаний о системах, архитектуре, бизнесе.
Что вы об этом думаете?
Ссылки: Телеграм | Youtube | VK
Клиент вызывает мастера починить сломавшийся станок.
Мастер приходит, осматривает станок, берет молоток, слегка ударяет в одном месте — станок снова работает.
Мастер выписывает счет на $500.
Клиент возмущается:
— За что $500? Вы же только один раз молотком ударили!
Мастер спокойно отвечает:
— За удар молотком — $5. За то, чтобы знать, куда ударить — $495.
ИИ действительно может генерировать куски кода, но написать код != создать работающую систему. Программирование это не только набор символов в редакторе. Это анализ требований, архитектура, проектирование системных взаимодействий, поддержка, развитие. ИИ не умеет брать на себя всю полноту инженерной ответственности: понимать зачем, почему и в каком контексте разрабатывается продукт.
Кроме того, задача программиста - не просто написать решение, а проанализировать его стоимость: насколько оно сложно в поддержке, сколько ресурсов потребует в будущем, сколько будет стоить исправление ошибок и адаптация под изменения. Иногда работа специалиста не в том, чтобы реализовать то, что попросили, а в том, чтобы предложить более дешевую, простую и надежную альтернативу.
Еще один важный момент: ИИ в своей природе в основном "копипастит" уже существующие паттерны кода, но не создает новых абстракций. Создание абстракций требует понимания сути задачи, компромиссов между сложностью и гибкостью, предвидения будущих изменений. Это работа мышления, а не перебора вариантов. Создание правильных абстракций определяет, насколько система будет масштабируемой, понятной и живучей. ИИ пока остается на уровне механического исполнения без глубокого понимания задач.
И наконец: реальные проекты - это не изолированные кусочки кода. Это сложные системы с множеством взаимосвязанных компонентов: базы данных, кэш-сервисы, очереди, микросервисы, балансировщики нагрузки, десятки или сотни серверов. Ошибки в таких системах проявляются не там, где был написан код, а на стыках между частями, под нагрузкой, в редких пограничных случаях. Диагностика и исправление таких ошибок требуют системного мышления, опыта и понимания работы всей инфраструктуры целиком. Пока ИИ не способен взять на себя такую ответственность.
Миф: ИИ сделает всех равными
Кажется, что с ИИ теперь каждый сможет делать то же самое, что и крутой разработчик. Но на практике ИИ становится инструментом в руках человека. Чем опытнее человек, тем лучше он ставит задачи ИИ, проверяет результаты и направляет процесс. Это усиливает разницу между сильными и слабыми разработчиками: кто умеет думать становится еще продуктивнее, кто не умеет, тонет в посредственных результатах.
Миф: ИИ заменит джунов
В этом утверждении зашито представление, что джуны нужны для выполнения каких-то базовых задач с которыми справится любой дурак. Поэтому без ии нам приходилось их нанимать, а вот с ии они больше будут не нужны. Компании нанимают джунов по другим причинам. Они готовы вкладываться в людей, чтобы вырастить из них квалифицированных специалистов. То есть никто не нанимает джуна, для того, чтобы он остался джуном. Тогда это был бы не джун, а вполне себе опытный, но очень низкоквалицированный специалист на низковалифицированную задачу.
Миф: Нужно срочно менять профессию
Как и с любой новой технологией, реальный сценарий это не исчезновение профессии, а её изменение. Появится больше задач по интеграции ИИ в продукты, по проектированию взаимодействия между человеком и машиной, по валидации и контролю качества того, что делает ИИ. Уйдут рутинные задачи, вырастет ценность проектирования, системного мышления и креативности.
Что действительно меняется
* Рутинные задачи действительно будут автоматизироваться.
* Навыки работы с ИИ становятся частью базового набора разработчика.
* Возрастет ценность знаний о системах, архитектуре, бизнесе.
Что вы об этом думаете?
Ссылки: Телеграм | Youtube | VK
👍3
В комментариях к предыдущему репосту про, видимо, вечный теперь вопрос AI vs программисты (и тестеры), мы обменивались мнениями, и я подумал, что все же сейчас излишне некоторые пытаются фокусироваться на фишках всех этих копайлотов, не обращая внимания на то, где реальное бутылочное горлышко у бизнеса. Давайте об этом сегодня поговорим.
Возьмем какую-то продуктовую компанию, которая сражается с конкурентами за долю рынка. Мы тут все нааджайлены, что важно часто и быстро выпускать новые фичи, снижать time to market, fail fast, и вот это вот за всё хорошее.
То есть, чем быстрее разработка доставит нужные фичи или фиксы, тем в теории больше клиентов привлечет/удержит бизнес. И обычно backlog такой компании забит под завязку, то есть, у бизнеса — куча хотелок, но разработчики физически не могут всё это переварить по разным причинам, поэтому именно они, в основном, являются бутылочным горлышком. Но ведь было бы круто, если бы мы увеличили пропускную способность?
Теперь же вот этим ребятам дали экзоскелеты, с которыми многое (но не всё) делается быстрее. То есть, оставив ту же команду, которая научилась в GPT, в теории бизнес получит более быстрый time to market и прочие плюшки. Тогда и backlog должен был бы прийти в равновесие или вообще разработчики сидели бы в ожидании следующих тасков а-ля «свободная касса». Но у нас такого нет, и у вас вряд ли тоже.
Компании вместо этого берут и увольняют людей, некоторые приговаривая, что «AI всё порешает». Но здесь кроется загвоздка. ROI в айти это нанять немного людей (в сравнении с заводом), платить им хорошие зарплаты и генерировать себе в свою стотыщ миллионов в секунду, отжимая рынок у конкурентов.
И вот на этом фоне главная причина сокращения штатов, на мой взгляд — текущая экономическая жопа, снижение потребления, общее туманное будущее и как следствие спад инвестиций, которые для айтишного мира весьма критичны, и на которые этот бизнес достаточно быстро реагирует по сравнении с теми же заводами. Потому что достаточно очевидно, что перегретый ковидный рынок и дикий рост найма в тот период были реакцией на внезапно изменившуюся экономику и полившиеся рекой инвестиции, но все быстро закончилось. То есть, откат на предыдущие позиции в партнерстве с поломанной экономикой привели к снижению (роста) клиентской базы и увольнению «излишне» набранных людей на проекты, которые компании не приносят ожидавшейся в период кисельных берегов прибыли.
Поэтому мое мнение, что AI, разумеется, оказывает влияние на рынок, но его реальную величину, приводящую к снижению количества разработчиков стоит оценить тогда, когда (и, блин, если) мы вернемся в экономику хотя бы по типу той, что была до ковида.
Это лишь мои мысли. Как всегда, открыт к обсуждению, если есть, что дополнить.
Возьмем какую-то продуктовую компанию, которая сражается с конкурентами за долю рынка. Мы тут все нааджайлены, что важно часто и быстро выпускать новые фичи, снижать time to market, fail fast, и вот это вот за всё хорошее.
То есть, чем быстрее разработка доставит нужные фичи или фиксы, тем в теории больше клиентов привлечет/удержит бизнес. И обычно backlog такой компании забит под завязку, то есть, у бизнеса — куча хотелок, но разработчики физически не могут всё это переварить по разным причинам, поэтому именно они, в основном, являются бутылочным горлышком. Но ведь было бы круто, если бы мы увеличили пропускную способность?
Теперь же вот этим ребятам дали экзоскелеты, с которыми многое (но не всё) делается быстрее. То есть, оставив ту же команду, которая научилась в GPT, в теории бизнес получит более быстрый time to market и прочие плюшки. Тогда и backlog должен был бы прийти в равновесие или вообще разработчики сидели бы в ожидании следующих тасков а-ля «свободная касса». Но у нас такого нет, и у вас вряд ли тоже.
Компании вместо этого берут и увольняют людей, некоторые приговаривая, что «AI всё порешает». Но здесь кроется загвоздка. ROI в айти это нанять немного людей (в сравнении с заводом), платить им хорошие зарплаты и генерировать себе в свою стотыщ миллионов в секунду, отжимая рынок у конкурентов.
И вот на этом фоне главная причина сокращения штатов, на мой взгляд — текущая экономическая жопа, снижение потребления, общее туманное будущее и как следствие спад инвестиций, которые для айтишного мира весьма критичны, и на которые этот бизнес достаточно быстро реагирует по сравнении с теми же заводами. Потому что достаточно очевидно, что перегретый ковидный рынок и дикий рост найма в тот период были реакцией на внезапно изменившуюся экономику и полившиеся рекой инвестиции, но все быстро закончилось. То есть, откат на предыдущие позиции в партнерстве с поломанной экономикой привели к снижению (роста) клиентской базы и увольнению «излишне» набранных людей на проекты, которые компании не приносят ожидавшейся в период кисельных берегов прибыли.
Поэтому мое мнение, что AI, разумеется, оказывает влияние на рынок, но его реальную величину, приводящую к снижению количества разработчиков стоит оценить тогда, когда (и, блин, если) мы вернемся в экономику хотя бы по типу той, что была до ковида.
Это лишь мои мысли. Как всегда, открыт к обсуждению, если есть, что дополнить.
Telegram
Тестирование ≠ QA
Заменит ли ИИ программистов? Вокруг себя вижу много панических настроений на эту тему, поэтому пост. Начну с анекдота
Клиент вызывает мастера починить сломавшийся станок.
Мастер приходит, осматривает станок, берет молоток, слегка ударяет в одном месте —…
Клиент вызывает мастера починить сломавшийся станок.
Мастер приходит, осматривает станок, берет молоток, слегка ударяет в одном месте —…
👍5
Copilot для PR ревью
Конкретно этот скрин с PR, где девелопер фиксит небольшую accessibility штуку, но общий принцип такой - тестировщик даже без знания кода может поучаствовать в ревью до собственно самих тестов.
Для этого нужно скормить контекст Copilot в виде "вот так не работало, вот так должно работать, оно как надо теперь работает или надо идти пинать кожаных мешков?" На что получается достаточно хороший и развернутый ответ, по которому уже можно начинать предметно разговаривать с разработчиком.
И можно вставлять в резюме "Уверенный пользователь GPT".
Конкретно этот скрин с PR, где девелопер фиксит небольшую accessibility штуку, но общий принцип такой - тестировщик даже без знания кода может поучаствовать в ревью до собственно самих тестов.
Для этого нужно скормить контекст Copilot в виде "вот так не работало, вот так должно работать, оно как надо теперь работает или надо идти пинать кожаных мешков?" На что получается достаточно хороший и развернутый ответ, по которому уже можно начинать предметно разговаривать с разработчиком.
И можно вставлять в резюме "Уверенный пользователь GPT".
👍4
Могу порекомендовать вот этот выпуск про тестирование: https://www.youtube.com/watch?v=SEfAGnQURQs
Там, правда, взгляд на тесты со стороны BE разработчиков, и уровень дискуссии явно не для начинающих, но есть интересные мысли, поэтому рекомендую для общего развития.
Выделю интересные таймкоды:
05:40 — Как нейросети и личный опыт влияют на качество тестов
10:24 — Пирамида тестирования, стратегии и интеграционные тесты
14:11 — Библиотеки, транзакции и альтернативные подходы
18:56 — Критика пирамиды, микросервисы и сила интеграционных тестов
23:38 — Мифы, сложности написания и важность интеграционного подхода
31:14 — Дебаггинг, логирование и тесты для сложных кейсов
40:41 — Тесты пользователей, репозитории и события
47:18 — Проблемы с интеграцией Spring Boot и различия между моками и стабами
53:58 — Оптимизация, контекст и TDD в действии
01:10:07 — Фикстуры: от введения до организации данных
01:16:44 — Оверкил, дизайн и тестирование в разных языках
01:40:38 — Плагины, история тестов и рефакторинг
01:49:03 — Моки, стабы и влияние на архитектуру
02:15:34 — Прагматичный подход, TDD и архитектурные выводы
Там, правда, взгляд на тесты со стороны BE разработчиков, и уровень дискуссии явно не для начинающих, но есть интересные мысли, поэтому рекомендую для общего развития.
Выделю интересные таймкоды:
05:40 — Как нейросети и личный опыт влияют на качество тестов
10:24 — Пирамида тестирования, стратегии и интеграционные тесты
14:11 — Библиотеки, транзакции и альтернативные подходы
18:56 — Критика пирамиды, микросервисы и сила интеграционных тестов
23:38 — Мифы, сложности написания и важность интеграционного подхода
31:14 — Дебаггинг, логирование и тесты для сложных кейсов
40:41 — Тесты пользователей, репозитории и события
47:18 — Проблемы с интеграцией Spring Boot и различия между моками и стабами
53:58 — Оптимизация, контекст и TDD в действии
01:10:07 — Фикстуры: от введения до организации данных
01:16:44 — Оверкил, дизайн и тестирование в разных языках
01:40:38 — Плагины, история тестов и рефакторинг
01:49:03 — Моки, стабы и влияние на архитектуру
02:15:34 — Прагматичный подход, TDD и архитектурные выводы
YouTube
Все об интеграционном и модульном тестировании. TDD и Моки | Илья Ильиных | #45
В этом выпуске мы поговорили с Ильёй Ильиных , автором канала «Куда войти», и вместе выяснили, что на самом деле скрывается за трёхбуквием TDD. Обсудили бережливое тестирование, разобрали плюсы и минусы diamond-подхода, поспорили о юнит-тестах, интеграционных…
👍5