Как-то слишком далеко все описанное от реальности найма. В нормальные компании продолжают нанимать ручных тестировщиков и автоматизаторов раздельно, есть правда и Full stack варианты. Потом от грейдов очень все зависит. Согласен с тестированием БД - прям важнейший скилл, но он в статье не указан. В общем если ты Junior QA, то от тебя по большому счету на собесах могут спросить то же что и у мидла, но только если нет опыта, то кто тебе доверит задачи мидла в здравом уме. Кроме того требуется и Kafka и Мобилки. Про это вообще ничего не сказано. А если финтех. то там вообще много чего от GraphQL и Docker, до зания Mock инструментов. В общем по-разному везде. Всё очень сильно зависит от проекта и компании. Всем добра!
Не согласен на счет джуна. Если сеньор или мидл придет новенький на проект, то тоже найдет не меньше аналогичных багов. Здесь речь идет именно о привыкании к продукту. А грейд здесь не играет на стороне джуна никак. А так статья мне понравилась, только помарок много как уже писали выше.
Да я посмотрел ваш ответ и несмотря на это посчитал нелишним закинуть ответ LLM Это было не упреком вам или попыткой указать на неправоту, а просто дополнение. Не думал что это не понравится. Как по мне полезный ответ. Хорошего дня!
Нужно было написать быстрый ответ по возражению человека на счет того? что все есть в Devtools/ Знал что не все, а сидеть выбирать точно жалко времени.
Ответ Perplexity PRO на вопрос чего из всего перечисленного нет в Devtools
Расширения из статьи, которых НЕТ в стандартном DevTools
1. Quick Char Count
Подсчет символов и слов в выделенном тексте. В DevTools нет встроенного инструмента для быстрого подсчета символов в выделенном тексте на странице.
2. Awesome Screenshot
Инструмент для создания скриншотов с аннотациями. DevTools имеет базовую функцию скриншотов (Capture screenshot), но без возможностей аннотаций и записи видео.
3. Wappalyzer
Определение технологического стека сайта (CMS, фреймворки, аналитика). DevTools не показывает используемые технологии и фреймворки автоматически.
4. Bug Magnet
Вставка тестовых данных для проверки граничных значений (SQL-инъекции, невалидные email, длинные строки). В DevTools такой функциональности нет.
5. Exploratory Testing Chrome Extension
Документирование сессий исследовательского тестирования с автоматической записью шагов и экспортом в Jira/Azure DevTools. DevTools не имеет функции структурированного документирования тестовых сессий.
Расширения, функциональность которых ЕСТЬ в DevTools
6. Lighthouse
Встроен в DevTools. Доступен через панель Lighthouse для аудита производительности, доступности, SEO и PWA.
7. Clear Cache
Функция очистки кэша доступна в DevTools через Network → правый клик → Clear browser cache или через настройки DevTools.
8. Dimensions
Измерение размеров элементов доступно в Elements панели DevTools при наведении на элементы (показываются размеры, отступы, margins).
9. WhatFont
Информация о шрифтах доступна в Elements → Computed → раздел Font (показывает семейство шрифта, размер, вес, цвет).
10. EditThisCookie
Управление cookies доступно в Application → Storage → Cookies (можно просматривать, редактировать, удалять).
Итого: из 10 расширений 5 требуют установки отдельных расширений (Quick Char Count, Awesome Screenshot, Wappalyzer, Bug Magnet, Exploratory Testing), а 5 имеют аналогичную функциональность встроенную в DevTools
Спасибо, что поделилась! Лично мне было интересно прочитать о твоем опыте, т.к. сам когда-то учился и несколько лет преподавал тестирование в одном IT университете :)) Успехов в работе. + тебе в карму и в рейтинг !
Есть несколько вариантов использования нейронок через VSCode расширения - тот же KiloCode, например. Пользуюсь сам им давно - супер вариант. GPT бесплатный давно проигрывает Gemini от Google и Qwen. Так что пересмотрите выбор нейронок для решения подобных задач.
Так уже существует огромное количество IDE систем на подобие Cursor или CLI-агенты на подобие Gemini -CLI или Qwen-CLI с которыми все это делать гораздо удобнее.
Здравствуйте! Я старался дать максимально развернутый ответ. Видимо перестарался. Сказывается академическое прошлое :)) https://scholar.google.com/citations?user=_ibB59AAAAAJ&hl=ru До 2021 года активно занимался научной деятельностью, а в 2022 уже ушел в IT на графиках видно.
Спасибо за такой честный и жизненный комментарий! Вы указали на реальное больное место: на собеседовании любая компания – продавец, а кандидат – покупатель. И, конечно, продавец будет показывать свой товар с лучшей стороны.
Считаю, что Вы абсолютно правы как минимум в двух ключевых вещах:
Никто не признается в хаосе. Фразы «у нас тут бардак, процессы только на бумаге, а менеджмент некомпетентен» вы никогда не услышите.
Сотрудники могут искренне не осознавать проблем. Человек, работающий внутри системы, привыкает к её недостаткам и может считать их нормой.
Именно поэтому цель вопросов из статьи – не получить простой ответ «да/нет», а вскрыть второй слой и научиться «читать между строк». Это не аудит, а скорее диагностика по косвенным признакам.
Как превратить общий вопрос в острый инструмент:
Вместо: «У вас есть процессы?» Стоит спросить: «Можете рассказать на примере последней реализованной фичи, как она прошла путь от идеи до продакшена? В какой момент подключился QA, какие были трудности, как принималось решение о релизе?»
Такой вопрос вынуждает рассказывать историю, а не ставить галочку. И в этой истории вы услышите всё: реальную роль QA, наличие тестов, взаимодействие в команде, отношение к проблемам.
Вместо: «Вы используете метрики качества?» Спросите: «Какой инцидент на проде за последний квартал был самым болезненным? Как вы его разбирали и какие системные выводы сделали, чтобы такое не повторилось?»
Ответ на этот вопрос покажет больше, чем любые слова о метриках. Вы увидите, есть ли в команде культура анализа (RCA, post-mortem) или просто «починили и забыли».
Главное — не что вы спрашиваете, а как вы слушаете ответ:
Кто отвечает? Техлид, который «в полях», даст конкретику. HR или менеджер, далекий от процессов, будет говорить общими фразами.
Насколько уверенно и детально звучит ответ? Если человек «плавает» в деталях, скорее всего, процесс либо отсутствует, либо работает не так, как на бумаге.
Есть ли противоречия? Спросите на разных этапах интервью один и тот же вопрос (в разной формулировке) разным людям. Расхождения в ответах – лучший индикатор проблем.
Ваш скепсис абсолютно оправдан. Ни одно собеседование не даст 100% гарантии. Но умение задавать глубокие, открытые вопросы и анализировать ответы на них – это тот самый фильтр, который помогает отсеять большинство «шляп» еще на подлете.
Благодарю еще раз, что поделились своим опытом. Он очень ценен и отлично дополняет статью!
Как-то слишком далеко все описанное от реальности найма. В нормальные компании продолжают нанимать ручных тестировщиков и автоматизаторов раздельно, есть правда и Full stack варианты. Потом от грейдов очень все зависит. Согласен с тестированием БД - прям важнейший скилл, но он в статье не указан. В общем если ты Junior QA, то от тебя по большому счету на собесах могут спросить то же что и у мидла, но только если нет опыта, то кто тебе доверит задачи мидла в здравом уме. Кроме того требуется и Kafka и Мобилки. Про это вообще ничего не сказано. А если финтех. то там вообще много чего от GraphQL и Docker, до зания Mock инструментов. В общем по-разному везде. Всё очень сильно зависит от проекта и компании. Всем добра!
Очень интересная статья и опыт. Не знал, что где-то так работает, но знал всегда, что это рабочая схема. Спасибо что педелились!
Не согласен на счет джуна. Если сеньор или мидл придет новенький на проект, то тоже найдет не меньше аналогичных багов. Здесь речь идет именно о привыкании к продукту. А грейд здесь не играет на стороне джуна никак. А так статья мне понравилась, только помарок много как уже писали выше.
Да я посмотрел ваш ответ и несмотря на это посчитал нелишним закинуть ответ LLM Это было не упреком вам или попыткой указать на неправоту, а просто дополнение. Не думал что это не понравится. Как по мне полезный ответ. Хорошего дня!
Нужно было написать быстрый ответ по возражению человека на счет того? что все есть в Devtools/ Знал что не все, а сидеть выбирать точно жалко времени.
Спасибо за статью! Думаю. Что 5 из 10 расширений действительно могут пополнить арсенал QA!
Ответ Perplexity PRO на вопрос чего из всего перечисленного нет в Devtools
Расширения из статьи, которых НЕТ в стандартном DevTools
1. Quick Char Count
Подсчет символов и слов в выделенном тексте. В DevTools нет встроенного инструмента для быстрого подсчета символов в выделенном тексте на странице.
2. Awesome Screenshot
Инструмент для создания скриншотов с аннотациями. DevTools имеет базовую функцию скриншотов (Capture screenshot), но без возможностей аннотаций и записи видео.
3. Wappalyzer
Определение технологического стека сайта (CMS, фреймворки, аналитика). DevTools не показывает используемые технологии и фреймворки автоматически.
4. Bug Magnet
Вставка тестовых данных для проверки граничных значений (SQL-инъекции, невалидные email, длинные строки). В DevTools такой функциональности нет.
5. Exploratory Testing Chrome Extension
Документирование сессий исследовательского тестирования с автоматической записью шагов и экспортом в Jira/Azure DevTools. DevTools не имеет функции структурированного документирования тестовых сессий.
Расширения, функциональность которых ЕСТЬ в DevTools
6. Lighthouse
Встроен в DevTools. Доступен через панель Lighthouse для аудита производительности, доступности, SEO и PWA.
7. Clear Cache
Функция очистки кэша доступна в DevTools через Network → правый клик → Clear browser cache или через настройки DevTools.
8. Dimensions
Измерение размеров элементов доступно в Elements панели DevTools при наведении на элементы (показываются размеры, отступы, margins).
9. WhatFont
Информация о шрифтах доступна в Elements → Computed → раздел Font (показывает семейство шрифта, размер, вес, цвет).
10. EditThisCookie
Управление cookies доступно в Application → Storage → Cookies (можно просматривать, редактировать, удалять).
Итого: из 10 расширений 5 требуют установки отдельных расширений (Quick Char Count, Awesome Screenshot, Wappalyzer, Bug Magnet, Exploratory Testing), а 5 имеют аналогичную функциональность встроенную в DevTools
Спасибо, что поделилась! Лично мне было интересно прочитать о твоем опыте, т.к. сам когда-то учился и несколько лет преподавал тестирование в одном IT университете :)) Успехов в работе. + тебе в карму и в рейтинг !
Сервис добавлен в подборку. Огромное спасибо за рекомендацию еще одного достойного тренажера!
Огромное спасибо за рекомендацию! Обязательно добавлю его в список тренажёров, если это действительно работающий инструмент!
Замечательно, ваша рекомендация только усилит эту подборку!
3 из 4 работающих песочниц добавил в раздел песочницы! Еще раз спасибо за подсказку!
О, благодарю за комментарии! Спасибо, огромное, что поделились ссылками! Завтра посмотрю эти песочницы и добавлю в подборку.
Есть несколько вариантов использования нейронок через VSCode расширения - тот же KiloCode, например. Пользуюсь сам им давно - супер вариант. GPT бесплатный давно проигрывает Gemini от Google и Qwen. Так что пересмотрите выбор нейронок для решения подобных задач.
Так уже существует огромное количество IDE систем на подобие Cursor или CLI-агенты на подобие Gemini -CLI или Qwen-CLI с которыми все это делать гораздо удобнее.
Здравствуйте! Я старался дать максимально развернутый ответ. Видимо перестарался. Сказывается академическое прошлое :)) https://scholar.google.com/citations?user=_ibB59AAAAAJ&hl=ru До 2021 года активно занимался научной деятельностью, а в 2022 уже ушел в IT на графиках видно.
Спасибо за такой честный и жизненный комментарий! Вы указали на реальное больное место: на собеседовании любая компания – продавец, а кандидат – покупатель. И, конечно, продавец будет показывать свой товар с лучшей стороны.
Считаю, что Вы абсолютно правы как минимум в двух ключевых вещах:
Никто не признается в хаосе. Фразы «у нас тут бардак, процессы только на бумаге, а менеджмент некомпетентен» вы никогда не услышите.
Сотрудники могут искренне не осознавать проблем. Человек, работающий внутри системы, привыкает к её недостаткам и может считать их нормой.
Именно поэтому цель вопросов из статьи – не получить простой ответ «да/нет», а вскрыть второй слой и научиться «читать между строк». Это не аудит, а скорее диагностика по косвенным признакам.
Как превратить общий вопрос в острый инструмент:
Вместо: «У вас есть процессы?» Стоит спросить : «Можете рассказать на примере последней реализованной фичи, как она прошла путь от идеи до продакшена? В какой момент подключился QA, какие были трудности, как принималось решение о релизе?»
Такой вопрос вынуждает рассказывать историю, а не ставить галочку. И в этой истории вы услышите всё: реальную роль QA, наличие тестов, взаимодействие в команде, отношение к проблемам.
Вместо: «Вы используете метрики качества?» Спросите: «Какой инцидент на проде за последний квартал был самым болезненным? Как вы его разбирали и какие системные выводы сделали, чтобы такое не повторилось?»
Ответ на этот вопрос покажет больше, чем любые слова о метриках. Вы увидите, есть ли в команде культура анализа (RCA, post-mortem) или просто «починили и забыли».
Главное — не что вы спрашиваете, а как вы слушаете ответ:
Кто отвечает? Техлид, который «в полях», даст конкретику. HR или менеджер, далекий от процессов, будет говорить общими фразами.
Насколько уверенно и детально звучит ответ? Если человек «плавает» в деталях, скорее всего, процесс либо отсутствует, либо работает не так, как на бумаге.
Есть ли противоречия? Спросите на разных этапах интервью один и тот же вопрос (в разной формулировке) разным людям. Расхождения в ответах – лучший индикатор проблем.
Ваш скепсис абсолютно оправдан. Ни одно собеседование не даст 100% гарантии. Но умение задавать глубокие, открытые вопросы и анализировать ответы на них – это тот самый фильтр, который помогает отсеять большинство «шляп» еще на подлете.
Благодарю еще раз, что поделились своим опытом. Он очень ценен и отлично дополняет статью!
Желаю вам успехов и развития !
Супер! Очень рад, что мой труд помогает начинающим QA развиваться в выбранной профессии
Да, интересно, что взяли в работу? Какая модель и на каком железе покорилась?