Это моя настоящая майка, которую мне когда подарил друг, когда я только еще учился на тестировщика - это было почти 5 лет назад. на ней надпись IN GOD WE TRUST REST ALL WE TEST Это международный и широко известный слоган сообщества тестировщиков. Поэтому я бы назвал статью Мы доверяем ТОЛЬКО БОГУ, а остальное тестируем. ВЕРА (религ.) = ДОВЕРИЕ БОГУ. То что вы предложили как определение ДОВЕРИЕ я бы назвал НАДЕЖДА. С теми же тормозами, ты надеешься , что тормоза тебя не подведут, потому что опираешься на свой опыт. надежда - это доверие опирающееся на прошлый опыт. Если у тебе не было какого-то опыта ранее, то и надеяться не будешь. Это факт. Бывает еще УВЕРЕННОСТЬ - это глубокая ВЕРА основанная на "ПРОКАЧЕННОЙ" НАДЕЖДЕ. Ну как бы там ни было само направление статьи верное. А то что БОГ есть - это ФАКТ. Тестировщик же не ставит под сомнение существования Разработчика, который когда-то писал код, даже если его никогда не видел и с ним лично не встречался. Программа же не появляется в твоем компьютере путем каких-то непонятных стечений обстоятельств при которых клавиатура вдруг сама написала код, который тебе потом пришлось тестировать. Мир который существует вокруг нас, слишком продуман и сложен, чтобы принять ВЕРОЙ ЭВОЛЮЦИЮ.
Если это подать как 1-й этап отбора, того чтобы отсеять нерелевантных кандидатов, то цирка здесь не увидел. Сам использую такую модель в найме и очень доволен результатами. На живые собесы берем только тех кто набрал определенный нами минимум баллов по ключевым метрикам.
Очень странная идея. По-моему это абсурд. Для отбора кандидата по резюме можно конечно ИИ использовать - все сейчас так делают, но и кандидаты используют ИИ для составления резюме. Получается если мой агент прокачан лучше вашего, то я составлю себе профиль супермена и сразу попаду к вам на техничку. Получается, что на первое место в любом случае выходит навык владения ИИ как с одной так и с другой стороны. А я бы предложил в этой схеме проведение собеседований с ИИ агентом, вот это тема. Когда ИИ модель опрашивает кандидата, собирает ответы на вопросы и кейсы и дает фидбэк по кандидату на основании заложенной оценочной шкалы. Такой подход как по мне помогает лучше и качественнее проводить первичку отсеивая тех, кто накрутил опыт. Но здесь важна проверка, что на собес придет именно человек, а не ИИ на обратной стороне. Короче дожились ...
Так а зачем учиться тому, что потом приведет ко всем проблемам, описанным в этой статье ? В статье откуда-то взята цифра в 80% , а это очень серьезное заявление. Это значит, что 80% кода, создаваемого под руководством опытных автоматизаторов также не окупается, и значит многие SDET и Senior AQA также попадают в эту выборку. Выходит, что они все тупни, которые не знали как надо было в самом начале проект сроить по автоматизации, потом попробовали все переделать, но и это не помогло. И тут приходит автор статьи и предлагает лиду автоматизации Amazon пройти курс, который спасет экономику. ВОТ это КРУТО. Настоящий блокбастер просто! Ой, простите, пожалуйста. Может я не правильно понял содержание статьи?
Промты интересные! Спасибо. Только что делать с безопасностью, если нельзя ИИ-шке показывать большей половины того, что требуют приведенный в статье промты? А локальная модель, достаточно слабая, чтобы эффективно справиться с задачами. На хорошую железо стоит как космический корабль.
Интересно, а насколько можно доверять таким расчетам экономики вложений? Ведь мы же не знаем на самом деле помог ли сотруднику запрос и на сколько много времени он ему на самом деле сэкономил. И потом важно понять как фактически выросла производительность труда. Увеличилась скорость написания кода и запуска новых фич реально? И еще код пишется быстрее, возможно, а обеспечение качества? Удобство, экономия времени общая - это безусловный плюс - это вообще не обсуждается. Просто также мечтаю о внедрении ИИ в процессы и хотелось бы для себя найти доказательную базу эффективности, которую реально можно показать инвестору.
Ну вопрос нормальный, на самом деле. Но это все бытовые вопросы. Их море на самом деле. Где кухня у вас? Как под охрану сдавать помещение правильно при уходе и др. вопросы.
Спасибо за комментарий. Да я единственный QA на проекте, с опытом около 4 лет, поэтому реализую и автоматизацию, и нагрузочное и, разумеется, ручное тестирование. Когда углублялся в нагрузочное, то там без DevOps штучек было никак.
Спасибо за статью. Мне о на лично показалась полезной. Закинул +1 в карму и +1 в рейтинг. Таких статей на подобную тему раньше не встречал на Хабре. В любом случае видно, что автор старался, вкладывал душу в сое детище. Это всегда похвально. Понимаю это не по наслышке. Успехов!
Как-то слишком далеко все описанное от реальности найма. В нормальные компании продолжают нанимать ручных тестировщиков и автоматизаторов раздельно, есть правда и Full stack варианты. Потом от грейдов очень все зависит. Согласен с тестированием БД - прям важнейший скилл, но он в статье не указан. В общем если ты Junior QA, то от тебя по большому счету на собесах могут спросить то же что и у мидла, но только если нет опыта, то кто тебе доверит задачи мидла в здравом уме. Кроме того требуется и Kafka и Мобилки. Про это вообще ничего не сказано. А если финтех. то там вообще много чего от GraphQL и Docker, до зания Mock инструментов. В общем по-разному везде. Всё очень сильно зависит от проекта и компании. Всем добра!
Не согласен на счет джуна. Если сеньор или мидл придет новенький на проект, то тоже найдет не меньше аналогичных багов. Здесь речь идет именно о привыкании к продукту. А грейд здесь не играет на стороне джуна никак. А так статья мне понравилась, только помарок много как уже писали выше.
Да я посмотрел ваш ответ и несмотря на это посчитал нелишним закинуть ответ LLM Это было не упреком вам или попыткой указать на неправоту, а просто дополнение. Не думал что это не понравится. Как по мне полезный ответ. Хорошего дня!
Нужно было написать быстрый ответ по возражению человека на счет того? что все есть в Devtools/ Знал что не все, а сидеть выбирать точно жалко времени.
Это моя настоящая майка, которую мне когда подарил друг, когда я только еще учился на тестировщика - это было почти 5 лет назад. на ней надпись IN GOD WE TRUST REST ALL WE TEST Это международный и широко известный слоган сообщества тестировщиков. Поэтому я бы назвал статью Мы доверяем ТОЛЬКО БОГУ, а остальное тестируем. ВЕРА (религ.) = ДОВЕРИЕ БОГУ. То что вы предложили как определение ДОВЕРИЕ я бы назвал НАДЕЖДА.
С теми же тормозами, ты надеешься , что тормоза тебя не подведут, потому что опираешься на свой опыт. надежда - это доверие опирающееся на прошлый опыт. Если у тебе не было какого-то опыта ранее, то и надеяться не будешь. Это факт. Бывает еще УВЕРЕННОСТЬ - это глубокая ВЕРА основанная на "ПРОКАЧЕННОЙ" НАДЕЖДЕ. Ну как бы там ни было само направление статьи верное. А то что БОГ есть - это ФАКТ. Тестировщик же не ставит под сомнение существования Разработчика, который когда-то писал код, даже если его никогда не видел и с ним лично не встречался. Программа же не появляется в твоем компьютере путем каких-то непонятных стечений обстоятельств при которых клавиатура вдруг сама написала код, который тебе потом пришлось тестировать. Мир который существует вокруг нас, слишком продуман и сложен, чтобы принять ВЕРОЙ ЭВОЛЮЦИЮ.
Если это подать как 1-й этап отбора, того чтобы отсеять нерелевантных кандидатов, то цирка здесь не увидел. Сам использую такую модель в найме и очень доволен результатами. На живые собесы берем только тех кто набрал определенный нами минимум баллов по ключевым метрикам.
Очень странная идея. По-моему это абсурд. Для отбора кандидата по резюме можно конечно ИИ использовать - все сейчас так делают, но и кандидаты используют ИИ для составления резюме. Получается если мой агент прокачан лучше вашего, то я составлю себе профиль супермена и сразу попаду к вам на техничку. Получается, что на первое место в любом случае выходит навык владения ИИ как с одной так и с другой стороны. А я бы предложил в этой схеме проведение собеседований с ИИ агентом, вот это тема. Когда ИИ модель опрашивает кандидата, собирает ответы на вопросы и кейсы и дает фидбэк по кандидату на основании заложенной оценочной шкалы. Такой подход как по мне помогает лучше и качественнее проводить первичку отсеивая тех, кто накрутил опыт. Но здесь важна проверка, что на собес придет именно человек, а не ИИ на обратной стороне. Короче дожились ...
А все эти все рекомендации и саму статью точно не писал Иван Иванович (ИИ) ?
Ого! Спасибо за такую высокую оценку моих стараний!
Так а зачем учиться тому, что потом приведет ко всем проблемам, описанным в этой статье ? В статье откуда-то взята цифра в 80% , а это очень серьезное заявление. Это значит, что 80% кода, создаваемого под руководством опытных автоматизаторов также не окупается, и значит многие SDET и Senior AQA также попадают в эту выборку. Выходит, что они все тупни, которые не знали как надо было в самом начале проект сроить по автоматизации, потом попробовали все переделать, но и это не помогло. И тут приходит автор статьи и предлагает лиду автоматизации Amazon пройти курс, который спасет экономику. ВОТ это КРУТО. Настоящий блокбастер просто! Ой, простите, пожалуйста. Может я не правильно понял содержание статьи?
Благодарю за полезную статью и позитивные картинки с котиками !
Промты интересные! Спасибо. Только что делать с безопасностью, если нельзя ИИ-шке показывать большей половины того, что требуют приведенный в статье промты? А локальная модель, достаточно слабая, чтобы эффективно справиться с задачами. На хорошую железо стоит как космический корабль.
Интересно, а насколько можно доверять таким расчетам экономики вложений? Ведь мы же не знаем на самом деле помог ли сотруднику запрос и на сколько много времени он ему на самом деле сэкономил. И потом важно понять как фактически выросла производительность труда. Увеличилась скорость написания кода и запуска новых фич реально? И еще код пишется быстрее, возможно, а обеспечение качества? Удобство, экономия времени общая - это безусловный плюс - это вообще не обсуждается. Просто также мечтаю о внедрении ИИ в процессы и хотелось бы для себя найти доказательную базу эффективности, которую реально можно показать инвестору.
Онбординг везде разный, а эти вопросы помогут быть максимально эффективным в первые дни работы.
Ну вопрос нормальный, на самом деле. Но это все бытовые вопросы. Их море на самом деле. Где кухня у вас? Как под охрану сдавать помещение правильно при уходе и др. вопросы.
А еще я руковожу IT-отделом из 50 человек в социальном проекте "Дышите свободно"
Спасибо за комментарий. Да я единственный QA на проекте, с опытом около 4 лет, поэтому реализую и автоматизацию, и нагрузочное и, разумеется, ручное тестирование. Когда углублялся в нагрузочное, то там без DevOps штучек было никак.
Спасибо за статью. Мне о на лично показалась полезной. Закинул +1 в карму и +1 в рейтинг. Таких статей на подобную тему раньше не встречал на Хабре. В любом случае видно, что автор старался, вкладывал душу в сое детище. Это всегда похвально. Понимаю это не по наслышке. Успехов!
Как-то слишком далеко все описанное от реальности найма. В нормальные компании продолжают нанимать ручных тестировщиков и автоматизаторов раздельно, есть правда и Full stack варианты. Потом от грейдов очень все зависит. Согласен с тестированием БД - прям важнейший скилл, но он в статье не указан. В общем если ты Junior QA, то от тебя по большому счету на собесах могут спросить то же что и у мидла, но только если нет опыта, то кто тебе доверит задачи мидла в здравом уме. Кроме того требуется и Kafka и Мобилки. Про это вообще ничего не сказано. А если финтех. то там вообще много чего от GraphQL и Docker, до зания Mock инструментов. В общем по-разному везде. Всё очень сильно зависит от проекта и компании. Всем добра!
Очень интересная статья и опыт. Не знал, что где-то так работает, но знал всегда, что это рабочая схема. Спасибо что педелились!
Не согласен на счет джуна. Если сеньор или мидл придет новенький на проект, то тоже найдет не меньше аналогичных багов. Здесь речь идет именно о привыкании к продукту. А грейд здесь не играет на стороне джуна никак. А так статья мне понравилась, только помарок много как уже писали выше.
Да я посмотрел ваш ответ и несмотря на это посчитал нелишним закинуть ответ LLM Это было не упреком вам или попыткой указать на неправоту, а просто дополнение. Не думал что это не понравится. Как по мне полезный ответ. Хорошего дня!
Нужно было написать быстрый ответ по возражению человека на счет того? что все есть в Devtools/ Знал что не все, а сидеть выбирать точно жалко времени.
Спасибо за статью! Думаю. Что 5 из 10 расширений действительно могут пополнить арсенал QA!