Спасибо! Выбора языка для покрытия нижней части пирамиды, зависит от проекта и целей, но чаще действительно используют тот же стек, это проще и логичнее для поддержки
Спасибо, очень приятно! Надеюсь, что статья может быть полезна и тем, кто только начинает с Go, и тем, кто пришёл из других языков. Именно такую цель и ставил - сделать материал понятным и прикладным.
Да, это правда. Часто осознание ценности тестов приходит через боль. А ещё многим командам тесты кажутся рутиной - на них жаль времени, особенно когда поджимают сроки и давят менеджеры. В такие моменты хочется просто успеть вовремя - даже если без тестов.
Странная логика. То есть уровень компетентности человека теперь определяется исключительно размером зарплаты? Получается, собеседования можно отменить и просто просить справку о доходах. А самые компетентные специалисты - это те, кто в списке Forbes?
Я подчеркиваю, что статья не про мой уровень жизни за границей, не про NDA и даже не про условия работы за рубежом. Она про другой аспект - про обучение, путь, профессиональные вызовы. Добавление справки о доходах по месту жительства вряд ли добавило бы смысловой ценности, особенно в статье, где речь не об этом.
Вы говорите, что QA должен уметь всё - от тестов до процессов. Согласен частично, знать - да. Но когда он вынужден быть человеком-оркестром, страдает качество проектов: релизы редкие, регресс долгий, баги на проде. Я видел такие команды. Толку от такого специалиста широкого профита не больше чем от отсутствие полностью процессов.
И наоборот - когда процессы выстроены, фичи выкатываются по готовности, тестирование параллельное, нет узких мест. Это не теория, это практика, которую я внедрял и видел как работает в реальности. Инженерность - не в том, чтобы всё делать самому, а в том, чтобы делать это эффективно.
Спасибо, да, я понимаю, у автоматизаторов часто меняется стек технологий, и сложно развиваться в одном, когда другая компания использует совершенно другой стек. Лично для себя я понял, что выбирать нужно по 3 критериям:
1 Какой стек вам интересен
2 Количество вакансий на этом языке, где вы собираетесь работать
3 Опыт работы на любом из них, проще подучить что-то, чем начинать с 0 изучать новый стек
Если выбирать из python, c#, java, то они все популярны, последнее время python мне был бы более интереснее, с учетом развития AI.
Согласен с вами - на практике пирамида тестирования далеко не всегда применима в "чистом виде". Я тоже сталкивался с тем, что когда говоришь об этом на собеседованиях, натыкаешься на непонимание. Видно, когда интервьюер ждёт "правильный" ответ из чек-листа и не готов обсуждать реальные кейсы. Это, конечно, печально, потому что гибкость мышления и адаптация подходов к проекту - важнее, чем прохождение устаревших вопросов на собеседованиях.
Образование - это основа, но, как и в любой профессии, многое зависит от саморазвития. Я изучал Go на практике, решая реальные задачи в компании и в собственных pet-проектах - а не только на курсах. В то же время язык программирования - это всего лишь инструмент, а не профессия. Поэтому курсы, которые помогают освоить инструмент, вполне уместны.
Если человек купил камеру Nikon, а потом решил пройти курс по Sony - это не делает его свадебным фотографом. Но это шаг в сторону освоения нового инструмента. Всё решает то, как он этим инструментом пользуется на деле.
Возможно мы немного не поняли друг друга. Цель статьи вовсе не в том, чтобы показать пессимизм сферы или кого-то отговорить от входа в IT. Наоборот - я хотел показать, что даже у тех, кто уже давно в профессии, бывают сомнения, сложности и разочарования. Это не слабость, а часть реальности. Я сам меняю направление и знаю, как это сложно.
И если хоть кто-то после статьи решит, что он хочет не "сдаться", а изменить профессию, компанию или подход к работе - значит, текст сработал. Я точно не хотел оттолкнуть тех, кто только идёт в IT.
То, что вы сами берёте инициативу, учитесь, согласовываете развитие - большой плюс вам как специалисту и вашему руководству. Это и есть здоровый пример работы, где у команды есть структура, поддержка и внятные ожидания.
Но важно понимать, что у всех опыт разный. То, что у вас всё устроено прозрачно и без перегруза - это круто, но, к сожалению, далеко не везде так.
Я не хотел принизить чей-то опыт, а лишь показать тренды, с которыми сталкиваются многие. Хорошо, если вам повезло работать в сильной структуре. Именно такие команды и формируют позитивный пример профессии.
Спасибо за комментарий, очень ценен реальный опыт.
Действительно, есть компании, где процессы чётко структурированы, и это может работать хорошо. Но даже в вашем примере вы упоминаете, что формально остаетесь ручным тестировщиком, а при этом пишете автотесты - значит, разделения труда как такового уже нет. Возникает вопрос: почему это делаете вы, а не выделенный автоматизатор? И правильно ли, что это на вас? Кто выбирает технологию и кто ее будет потом поддерживать, с вашим уходом останется ли это в процессах компании или нет.
Важно понимать: QA и ручное тестирование - не одно и то же. QA - это про качество в целом: стратегии, метрики, процессы, автоматизация, аналитика рисков и даже влияние на бизнес-решения.
Моя цель - показать стратегическую роль QA и обозначить ключевые векторы развития, а не выдать универсальный чек-лист. Реализация практик всегда зависит от продукта, команды и специфики бизнеса.
Считать "конкретикой" QA лишь алгоритм "делай А, Б и В" - значит упускать главное. Ознакомьтесь с Quality Engineering и примерами из крупных организаций: там эти методы давно приносят измеримый эффект.
Это особенность соглашений NDA: в странах, где они используются, детали зарплат остаются конфиденциальными, но тема этой статьи - не зарплата. Я понимаю, что люди, не имеющие опыта работы с NDA или малым опытом, могут воспринимать это по-другому.
Спасибо, да, иногда инициатору изменений проще внедрить их, чем просить команду следовать за изменениями. Но до тех пор, пока команда или проект не начнут расти и нагрузка на исполнителя соответственно не увеличится. Однако многое зависит от спецификации проекта и состава команды.
QA - не «недо-разработчики»: вместо навыков кодирования, важны системное мышление, тест-стратегии и поиск «слепых» зон. Если считать QA новичками ИТ сферы, люди будут уходить из профессии.
В некоторых компаниях, например финтехе и e-commerce, где любой баг может обойтись в миллионы, QA платят на уровне разработчиков, а порой и выше - тестирование там считают стратегическим активом, а не расходом. Но тут зависит от инженерной культуры
Спасибо! Выбора языка для покрытия нижней части пирамиды, зависит от проекта и целей, но чаще действительно используют тот же стек, это проще и логичнее для поддержки
Спасибо, очень приятно! Надеюсь, что статья может быть полезна и тем, кто только начинает с Go, и тем, кто пришёл из других языков. Именно такую цель и ставил - сделать материал понятным и прикладным.
Да, это правда. Часто осознание ценности тестов приходит через боль. А ещё многим командам тесты кажутся рутиной - на них жаль времени, особенно когда поджимают сроки и давят менеджеры. В такие моменты хочется просто успеть вовремя - даже если без тестов.
Спасибо, согласен - часто тоже такое встречаю. Но потом, когда команда поймет, сэкономит много времени.
Странная логика. То есть уровень компетентности человека теперь определяется исключительно размером зарплаты? Получается, собеседования можно отменить и просто просить справку о доходах. А самые компетентные специалисты - это те, кто в списке Forbes?
Я подчеркиваю, что статья не про мой уровень жизни за границей, не про NDA и даже не про условия работы за рубежом. Она про другой аспект - про обучение, путь, профессиональные вызовы. Добавление справки о доходах по месту жительства вряд ли добавило бы смысловой ценности, особенно в статье, где речь не об этом.
Вы говорите, что QA должен уметь всё - от тестов до процессов. Согласен частично, знать - да. Но когда он вынужден быть человеком-оркестром, страдает качество проектов: релизы редкие, регресс долгий, баги на проде. Я видел такие команды. Толку от такого специалиста широкого профита не больше чем от отсутствие полностью процессов.
И наоборот - когда процессы выстроены, фичи выкатываются по готовности, тестирование параллельное, нет узких мест. Это не теория, это практика, которую я внедрял и видел как работает в реальности. Инженерность - не в том, чтобы всё делать самому, а в том, чтобы делать это эффективно.
Спасибо, да, я понимаю, у автоматизаторов часто меняется стек технологий, и сложно развиваться в одном, когда другая компания использует совершенно другой стек.
Лично для себя я понял, что выбирать нужно по 3 критериям:
1 Какой стек вам интересен
2 Количество вакансий на этом языке, где вы собираетесь работать
3 Опыт работы на любом из них, проще подучить что-то, чем начинать с 0 изучать новый стек
Если выбирать из python, c#, java, то они все популярны, последнее время python мне был бы более интереснее, с учетом развития AI.
Согласен с вами - на практике пирамида тестирования далеко не всегда применима в "чистом виде". Я тоже сталкивался с тем, что когда говоришь об этом на собеседованиях, натыкаешься на непонимание. Видно, когда интервьюер ждёт "правильный" ответ из чек-листа и не готов обсуждать реальные кейсы. Это, конечно, печально, потому что гибкость мышления и адаптация подходов к проекту - важнее, чем прохождение устаревших вопросов на собеседованиях.
Образование - это основа, но, как и в любой профессии, многое зависит от саморазвития. Я изучал Go на практике, решая реальные задачи в компании и в собственных pet-проектах - а не только на курсах. В то же время язык программирования - это всего лишь инструмент, а не профессия. Поэтому курсы, которые помогают освоить инструмент, вполне уместны.
Если человек купил камеру Nikon, а потом решил пройти курс по Sony - это не делает его свадебным фотографом. Но это шаг в сторону освоения нового инструмента. Всё решает то, как он этим инструментом пользуется на деле.
Возможно мы немного не поняли друг друга. Цель статьи вовсе не в том, чтобы показать пессимизм сферы или кого-то отговорить от входа в IT. Наоборот - я хотел показать, что даже у тех, кто уже давно в профессии, бывают сомнения, сложности и разочарования. Это не слабость, а часть реальности. Я сам меняю направление и знаю, как это сложно.
И если хоть кто-то после статьи решит, что он хочет не "сдаться", а изменить профессию, компанию или подход к работе - значит, текст сработал. Я точно не хотел оттолкнуть тех, кто только идёт в IT.
Удачи и вам - и пусть у вас всё получится!
То, что вы сами берёте инициативу, учитесь, согласовываете развитие - большой плюс вам как специалисту и вашему руководству. Это и есть здоровый пример работы, где у команды есть структура, поддержка и внятные ожидания.
Но важно понимать, что у всех опыт разный. То, что у вас всё устроено прозрачно и без перегруза - это круто, но, к сожалению, далеко не везде так.
Я не хотел принизить чей-то опыт, а лишь показать тренды, с которыми сталкиваются многие. Хорошо, если вам повезло работать в сильной структуре. Именно такие команды и формируют позитивный пример профессии.
Спасибо за комментарий, очень ценен реальный опыт.
Действительно, есть компании, где процессы чётко структурированы, и это может работать хорошо. Но даже в вашем примере вы упоминаете, что формально остаетесь ручным тестировщиком, а при этом пишете автотесты - значит, разделения труда как такового уже нет. Возникает вопрос: почему это делаете вы, а не выделенный автоматизатор? И правильно ли, что это на вас? Кто выбирает технологию и кто ее будет потом поддерживать, с вашим уходом останется ли это в процессах компании или нет.
Важно понимать: QA и ручное тестирование - не одно и то же. QA - это про качество в целом: стратегии, метрики, процессы, автоматизация, аналитика рисков и даже влияние на бизнес-решения.
Спасибо за обратную связь.
Моя цель - показать стратегическую роль QA и обозначить ключевые векторы развития, а не выдать универсальный чек-лист. Реализация практик всегда зависит от продукта, команды и специфики бизнеса.
Считать "конкретикой" QA лишь алгоритм "делай А, Б и В" - значит упускать главное. Ознакомьтесь с Quality Engineering и примерами из крупных организаций: там эти методы давно приносят измеримый эффект.
Это особенность соглашений NDA: в странах, где они используются, детали зарплат остаются конфиденциальными, но тема этой статьи - не зарплата. Я понимаю, что люди, не имеющие опыта работы с NDA или малым опытом, могут воспринимать это по-другому.
Спасибо, да, иногда инициатору изменений проще внедрить их, чем просить команду следовать за изменениями. Но до тех пор, пока команда или проект не начнут расти и нагрузка на исполнителя соответственно не увеличится. Однако многое зависит от спецификации проекта и состава команды.
QA - не «недо-разработчики»: вместо навыков кодирования, важны системное мышление, тест-стратегии и поиск «слепых» зон. Если считать QA новичками ИТ сферы, люди будут уходить из профессии.
В некоторых компаниях, например финтехе и e-commerce, где любой баг может обойтись в миллионы, QA платят на уровне разработчиков, а порой и выше - тестирование там считают стратегическим активом, а не расходом. Но тут зависит от инженерной культуры
Это скорее условный "миллион" - будь то доллары, рубли или евро - для драматичности. Реальные цифры под NDA, к сожалению, не могу их озвучивать.
Спасибо я рад, что моя статья пересеклась с вашим опытом. Переход из QA в разработку, это действительно непростой, но интересный способ развитие в ИТ.