Войти в IT: что нужно знать и где изучать

 Публичный пост
17 ноября 2022  1242

Поехали!

Этот пост рассчитан на людей, которые далёкие от этой темы, но хотели бы попробовать и не знают с чего начать. Так вот, начать можно прям от сюда 😻

Меня часто спрашивают "Как войти в IT?". И я догадываюсь почему 🙈. Решил собрать всё в одном месте, исходя из своего собственного опыта.

В IT есть масса профессий. Я расскажу о минимуме знаний для успешного прохождения собеседования на позиции Junior Software Engineer или Junior Quality Assurance Engineer. Короче, что нужно знать, чтоб начать работать Программистом или Тестировщиком QA, QE (инженером по качеству).

Про программистов, вроде как, всё понятно. Сидят пишут код, чинят баги, занимаются автоматизацией какого-нить процесса.

Тестировщики бывают разные. Одни занимаются ручным (мануальным) тестированием, другие автоматизированным.

Здесь сделаю уклон больше на тех, которые занимаются автоматизированным тестированием. Мне кажется, так проще найти работу. Есть масса проектов, где есть всё кроме тестов. Поэтому, постоянно требуются люди для написания автоматических тестов.

Люди, которые занимаются ручным тестированием тоже нужны. В основном это сложные проекты, где очень сложно реализовать автоматическое тестирование. У меня знакомый устроился работать в контору, которая занимается интеграцией нескольких систем логистики судов в одну большую систему. Им как раз требовались мануальные QA потому что автоматизировать всё было бы очень долго и дорого.

Для начала нужно понять, что необходимо знать для удачного прохождения собеседования и с чем, непосредственно прийдется работать на работе.

Итак, что нужно знать:

  • Git - система контроля версий. Это такая штука, с помощью которой можно посмотреть какие изменения вносились в код, когда и кем. В общем, вещь нужная и интересная.
  • Какой-нить язык программирования. Можно выбрать абсолютно любой, в зависимости, что хотите разрабатывать и что, так сказать, ближе к телу. Например, хотите делать красивые сайты - Javascript, для игр - С++, программировать железяки, контроллеры, IOT - Cи и так далее, подробнее для чего какие языки используются можно почитать тут или тут. Я рекомендую начать с Python, так как сам с него начинал 😎. Много туториалов, видео, книг, курсов, почти всё можно скачать и смотреть бесплатно!
  • Теория тестирования. Для QA без этого вообще никуда. Скажем так, даже если вас устроили на работу по-блату всё равно её - теорию прийдётся выучить. Это знание позволит вам работать меньше, а зарабатывать больше! Ну и жизнь будет спокойнее, меньше всяких 🐛 🐞🦟🪲 в продакшине.
  • Базы данных Это важно знать как для программистов, так и для QA. Если сильно упростить, можете себе представить таблицу Excel. Так вот программист автоматизирует работу с этой таблицей, создание, добавление, обновление и удаление данных, а также фильтрация в зависимости от запроса.
  • Aлгоритмы и структуры данных. Для программистов это да! Чтоб программа работала быстро, не падала и вы вызывали уважение у коллег по опасному бизнесу в офисе. Для ознакомления, что это такое и как оно работает, есть небольшая книга Грокаем алгоритмы причем, не нужно знать высшую математику, чтобы начать изучать алгоритмы, для начала хватит этого.
  • Linux и работа в терминале. Если вы будете работать в Windows, наверное, вам это не нужно. Если нет, прийдется выучить несколько команд, перемещение по папкам, копирование и удаление файлов, в принципе, для начала, и всё.

Ресурсы для изучения:

👨‍💻🐞Learn Git Branching это как игра, всё доступно и понятно. Если ее полностью пройти несколько раз, этого более чем достаточно для прохождения собеседования и нормальной работы в 99% всех существующих проектов.

👨‍💻🐞GIT - проще некуда Смотрим и сразу повторяем, автор очень просто и подробно всё объясняет, действительно - проще некуда!

👨‍💻🐞Python-koans Python Koans — это интерактивный учебник для изучения языка программирования Python путем прохождения тестов.
После прохождения Learn Git Branching скачиваете себе в git репозиторий и можно пробовать проходить.

Возможно, для старта Python-koans покажутся немного сложными. Можно поискать что-то попроще, чтобы ознакомиться с базовым синтаксисом языка. Можно посмотреть несколько видео на YouTube.
Настоятельно рекомендую книги:

  • Простой Python, Билл Любанович, 2 издание
  • Начинаем программировать на Python, Гэддис Тони, 5 издание

Также, параллельно можно проходить задания на CheckiO есть русский язык, задачи от простых к сложным, даже можно самому добавлять задачи. Вообщем одни плюсы.

👨‍💻🐞Тестирование Дот Ком Это прям классика. Книга небольшая и читается очень легко. Самое важное, она дает понять, нужно Вам это или нет. Не нужно прям прорабатывать каждую страницу, можно прочитать один раз и понять, стоит продолжать двигаться в этом направлении или нет. Будущим программистам это поможет в написании юнит-тестов.

🐞Теория тестирования Для тех кто осилил книгу Тестирование Дот Ком. Берем и учим наизусть, что такое баг, тест-кейс, какие виды тестирования бывают, какие уровни и так далее. На собеседовании на позицию QA 80% вопросов будут как раз по теории тестирования.

🐞 Тестовые фреймворки. Их несколько в Python, я бы смотрел в сторону PyTest. Используется в большинстве проектов, интуитивно простой. Тут можно почитать на русском языке.

👨‍💻🐞Базы данных только самое необходимое тот же автор, что и GIT - проще некуда, кстати, он написал несколько книг и у него есть сайт.

👨‍💻Aлгоритмы и структуры данных python Наверное, лучшее, что можно найти на русском языке и бесплатно. Смотрим лекции Тимофея Хирьянова, делаем задания, осознаём, запоминаем.

👨‍💻🐞Linux для Начинающих Этот курс прям для самых-самых начинающих, лично я рекомендую Вводный курс по администрированию Linux этот курс в первую очередь нацелен на подготовку к сдаче экзамена LPIC, но здесь важно то, что в этом курсе рассматриваются практически все темы, которые будут нужны в работе.

На самом деле, здесь не так много материалов для изучения, как кажется на первый взгляд. Если уделять час в день, всё это можно осознать за 6-9 месяцев. Некоторые вещи прийдется прорабатывать параллельно, что увеличит скорость изучения 🍻. Например, решение алгоритмов, тестирование, сохранение кода в Git репозитории.

Резюме

Итак, после прохождения всего этого нужно написать резюме. Какое должно быть резюме и что туда писать можно посмотреть тут
Также можно полистать клубные записи по этому поводу, есть куча годного контента:

Светлая сторона

Всё это, конечно, супер, но что же писать в резюме?
Заводим аккаунт на Github или Gitlab (это такие сайтики, где программисты хранят свой код) создаем там проекты и сохраняете там все ваши програмки с детальными пояснениями, которые писали во время обучения. Это плюсик на собеседовании.
По-хорошему, нужно придумать свой небольшой проектик, программу которая что-то автоматизирует. Например, каждое утро присылает вам в телеграм канал погоду на день (согласен, тупо, но суть не в самом смысле программы, а в ее компонентах).
Что для этого нужно:

  • Написать программу
  • Написать тесты
  • Добавить GitLab CI/CD или GitHub Actions - это чтобы каждое утро она сама присылала сообщение.
  • Каждый раз, когда вы сохраняете код после редактирования, автоматически должны запуститься ваши же тесты, дабы проверить код на вшивость

Последние два пункта кажутся сложными, но на самом деле нужно немного знаний и времени чтоб их реализовать. Есть очень много материалов по этой теме на разных языках и в разном качестве, с примерами и плюшками.

Второй вариант, делать вклад в опенсорс проекты.
Находите проект по душе и начинаете наносить непоправимую пользу. Если вы начинающий разработчик, можете начать чинить баги. Если вы начинающий QA, можете начать баги находить или писать тесты. Обычно большинство опенсорс проектов страдают от наличия отсутствия тестов. Скажем так, я не встречал ни одного опенсорс проекта, где бы не нужет был QA.
Кстати, вот - vas3k.club и далеко ходить не нужно, уверен, если предложите свою помощь в развитии, все будут безумно счастливы 🤗!

Если вы с этим справитесь и готовы об этом поболтать на собеседовании, это уже минимум уровень мидл и можно переходить на Темную Сторону

Тёмная сторона

Если вдруг, решили перейти на тёмную сторону и использовать проверенный способ вкатиться в АйТи, настоятельно рекомендую изучить вопрос разработки программного обеспечения, всякие Scrum Agile и т.д. и т.п., а также что такое Jira и зачем она нужна. Тут нужно хоть немного ориентироваться в теме.

Что дальше?

Итого:

Программистам важно знать язык программирования, базы данных, алгоритмы. В меньшей степени, администрирование операционных систем и теорию тестирования.

Для QA инженера в первую очередь теория тестирования, потом всё остальное. Если вы хотите быть QA Automation, стоит выучить язык программирования, базы данных, тестовые фреймворки.

Не нужно стремиться устроится QA потом поменять работу на программиста. Поверьте мне, это сделать гораздо сложнее чем просто устроиться программистом. Мало того, что учить прийдется в два раза больше, так еще и подсознательно работая QA ваша задача находить баги. Это основная работа QA, вы от этого будете получать удовольствие. Поменяв работу на программиста, вы всячески будете избегать этого процесса. Сознание должно переключиться. Вы должны будете писать хороший качественный код. Вы будете думать что ваш код самый лучший, у него не может быть багов, он как ребенок, самый-самый 😌.

Важно понимать, чтобы устроится на первую работу, важно уметь проходить собеседования. А чтобы научиться проходить собеседования, нужно походить на собеседования 😉. Даже если Вы обладаете идеальными знаниями во всех темах и 100% подходите на должность, не факт что вас возьмут с первого раза.

Это не единственный правильный путь войти в IT, это "один из". Нужно пробовать и всё получится 🙂.

Надеюсь, для кого-то статья будет полезной 🤗.

Отзывы и комментарии welcome 🙃.

Связанные посты
34 комментария 👇

Я рекомендую начать с Python, так как сам с него начинал 😎. Много туториалов, видео, книг, курсов, почти всё можно скачать и смотреть бесплатно!

Мне кажется Python один из худших вариантов для начинающих :)

  Развернуть 1 комментарий

@Lewigh, Интересное мнение 🙂
Какой язык по вашему лучший?

  Развернуть 1 комментарий

@sergturi, Golang, имхо конечно

  Развернуть 1 комментарий

@rooty, Как вариант :)

  Развернуть 1 комментарий

@sergturi, Ada или Rust /s

  Развернуть 1 комментарий

@nakopylov, для выпускников физмат Haskell подойдёт как первый язык :)

  Развернуть 1 комментарий

@sergturi, а чего не лисп? ))))))))

  Развернуть 1 комментарий
  Развернуть 1 комментарий

@rooty, не надо голанг новичкам

  Развернуть 1 комментарий

@sergturi, по моему мнение самый лучший начальный яп это Java. Причем я не буду говорить для кого. Ну например если хочется вкатиться в конкретную область то понятное дело там есть свой набор яп для этих целей. А если хочется с чего то начать именно попробовать покодить то Java вне конкуренции по ряду причин:

  • строгость. ЯП бьет по рукам и не дает делать откровенную дичь.
  • статическая типизация. Новичку в десятки раз проще понять что вернет функция или что лежит в переменной, если это явно написано.

-компиляция. Не валидный код не собирается.

  • золотая середина между сложными более низкоуровневыми языками и чрезмерно сахарными более высокоуровневыми.
  • возможностей ровно столько сколько нужно. Есть в принципе все что нужно.
  • отличная стандартная библиотека
  • наверное одни из топовых возможностей легко изучать исходный код в процессе. В подавляющее большинство функций и классов можно провалиться и просто посмотреть как оно сделано, причем все это работает быстро в IDE, исходными очень хорошо документированы. Нативные функции редки.

Прощу заметить что в данном коменте я имею ввиду Java не как ЯП(который в принципе не плох) а как ЯП для обучения(в чем он топ). Проверял на определенном количестве людей в контексте: Java vs С#, Java vs JS, Java vs Python.

PS
С# - отличный ЯП но очень переусложненный и неудачно засахаренный.
Golang - отвратительный ЯП, в плане обучения из-за своей простоты одновременно и хорош но и также имеет много сложностей в силу грубости и примитивности. Все такки не советовал бы.
JS - как первый ЯП == сломанное нормальное представление о правильности.
Python - из-за своей динамической природы допускает огромное число ошибок. Во многом вопреки своей репутации очень непредсказуем. Нет сборщика из коробки. Половина кишок написаны на С в силу чего невозможно нормальное изучение по исходникам.
PHP - божеупаси :)

  Развернуть 1 комментарий

@sergturi, Turbo Pascal

  Развернуть 1 комментарий

@Lewigh, Спасибо за развернутый ответ.

С технической точки зрения я согласен на 100%. Безусловно, можно начать с Java, но порог входа будет выше чем в Python. На Java разработка и отладка занимает больше времени чем на Python. Я не говорю о качестве конечного продукта (на Java оно, конечно, выше) но есть business needs. Практики показывают, что на Python разработка дешевле.

То что Python допускает много ошибок, для новичков это плюс. По началу можно писать откровенную дичь, развиваться и осознать что есть Java, Kotlin, Swift.

  Развернуть 1 комментарий

@sergturi,

Практики показывают, что на Python разработка дешевле.

А давайте посчитаем сколько по времени занимает разработка фичи. В это время входит:

  1. Время на разработку задачи аналитиком и утверждения разработкой.
  2. Время на разработку.
  3. Время на написание тестов и проверку перед передачей на кодревью.
  4. Время на кодревью и передача в тестирование.
  5. Время на тестирование задачи.
  6. Время на исправление багов из текущей фичи.
  7. Время на перепроверку задачи.
  8. Этому всему прибавим время на общение с аналитиком/заказчиком.

Как можно заметить, разработка - это только 1 пункт из 8.

Теперь разберем от чего зависит время непосредственной разработки:
-архитектура проекта. Чем качественнее написан проект, тем дешевле добавление фич. Чем нестабильнее проект тем добавление бага или фичи затрачивает больше времени.
-наличие нормальных тестов
-наличие отлаженных процессов
-наличие хорошей коммуникации
-наличия документации

И уже теперь давайте сравним насколько яп помогают или мешают скорости разработки.
В чем Python сейчас может дать лучшие результаты по скорости?

  • не нужно объявлять типы - сомнительная экономия, темболее что в современном питоне как я понимаю типы добавлять все-таки рекомендуют.
  • объем и читабельность кода- аргумент был бы актуальным лет 10-15 назад. Сейчас уже не так.
  • отладка через REPL? Ну тоже какие преимущества по сравнению с нормальным дебагом?

А теперь Java. Нужно писать чуть больше кода за счет типов и тратим время на компиляцию.
Но за счет статической системы типов и проверки на этапе компиляции мы получаем:

  • отсутствие необходимости писать тесты на типы
  • отлов огромного числа ошибок во время компиляции, за счет чего сокращаем как время разработки так и пункты 5,6,7. Так как вероятность в более строгом языке передать на тестирование дефектную фичу - меньше.

Если подытожить то помимо времени непосредственной разработки есть огромное число факторов не привязынных к ЯП.

Мнимая экономия на времени передачи задачи в тест часто будет с лихвой проседать на тестировании и багах.

Там где одно выигрывает другое проигрывает. Про выигрышь или проигрышь на дистанции на больших проектах и говорить не буду.

То что Python допускает много ошибок, для новичков это плюс.

Если человек сразу научился не правильно его потом чертовски трудно переучивать на нормально. В любом деле поначалу нужно страдать чтобы потом преуспеть.

  Развернуть 1 комментарий

@Lewigh, на вкус и цвет все фломастеры разные. Пытался учить Java - в итоге забил и потерял 5 лет.

Начал учить Python - второй год пишу, полет прекрасный.

Новичкам полезно научится пользоваться тайпхинтами и дебажить код. Да и врятли они будут писать настолько большие проекты, где статическая типизация критична.

  Развернуть 1 комментарий

@Lewigh,

С# - отличный ЯП но очень переусложненный и неудачно засахаренный.

triggered

Имхо, нормально он насахарен. Когда в мир JVM принесли шарповый сахар и назвали это Kotlin - этим стало возможно пользоваться.

Java сама по себе же очень многословна и заставляет тебя писать кучу ненужно бойлерплейта.

По поводу обучения с Java vs обучения с C#.

На своём опыте могу описать. Я пытался начать с Java, т.к. более распространена и найти работу проще. Но в итоге не осилил стартануть с неё. В мире Java как будто бы обязательно СНАЧАЛА знать кишки, а потом уже писать простейший хелло ворлд.

Если консольное приложение написать ещё более менее (хотя я помню, как в своё время гуглил кучу готовых хелловорлдов из интернетов и они у меня банально не компилились и я не мог понять почему), то вот Spring без понимания кишок можно замучаться отлаживать. Может с развитием Spring Boot это стало чуть проще, хотя всё ещё (имхо) очень неинтуитивно.

В итоге я стартанул с шарпа. И что консольные приложения, что WinForm, что WPF, что ASP.Net - в инетренет было тонны пошаговых инструкций для тупых, да и сам процесс написания кода казался более интуитивным и очевидным. Казалось я мог нажать точку и предположить название метода и он и правда там оказывался и было интуитивно понятно как этим пользоваться. В итоге в качестве диплома я написал полноценный сайт аля онлайн платформа для оценки фильмов и прикрутил туда рекомендателку нейросеть и всё это на шарпе.

P.S.: В мир Java я перекатился только спустя 3 года работы на шарпе и только потому что бОльшая часть продуктовых приложений всё ещё пишется на Java и мир JVM как будто бы игнорирует тот файт, что Шарп уже 100 лет как кросплатформенный и не завязан более на винду :(

  Развернуть 1 комментарий

@MrModest,

Имхо, нормально он насахарен.

Нет не нормально. Можно красиво встраивать новые фичи в какую никакую философию использования языка, строить вокруг определенных идей и пытаться сделать интуитивно понятными и связанными(привет Kotlin). А можно делать как разработчики языка C# - просто пихать максимальное количество фич каждый релиз на похрен, нужны они или нет. Посидеть подумать как это встроить так чтобы людям было очевиднее и проще запомнить? Пфф, зачем им это, будем на право и налево добавлять новые ключевые слова и комбинировать в миллионе вариантов старые. И получается - помойка фич. Вроде круто, можно из этого чемодана что угодно достать для своей задачи, но вот только все это добро разрозненное в голове держать - такое себе, молчу про новичков, которым с каждым годом все веселее и веселее этот яп учить из-за его бесконечного набухания.

Когда в мир JVM принесли шарповый сахар и назвали это Kotlin - этим стало возможно пользоваться.

Слава богам, Kotlin это именно что не "шарповый сахар" а идеи, в том числе в большем числе из C#, оформленные в тот самый "сахар" нормальным образом.

Java сама по себе же очень многословна и заставляет тебя писать кучу ненужно бойлерплейта.

Не нужно транслировать мифы 20 века. Подключаем библиотеку Lombok и Java становиться во многих местах даже стройнее C#.

В мире Java как будто бы обязательно СНАЧАЛА знать кишки, а потом уже писать простейший хелло ворлд.

Удивительно такое слышать в сравнении с близкородственным яп C#, который построен в большинстве своем на тех же рельсах из виртуальной машины, С-подобного синтаксиса и вплоть до идентичных названий классов в stdlib. Почему в Java нужно знать кишки а в C# нет, загадка.

Spring без понимания кишок можно замучаться отлаживать
WinForm, что WPF, что ASP.Net

Ну это конечно очень объективно сравнивая яп сравнивать не сами яп а библиотеки.
Ну давайте пойдем дальше - Unreal engine лучше подходит для серьезных проектов чем Unity, следовательно - C++ лучше C#. Все же логично, да?. :)

мир JVM как будто бы игнорирует тот файт, что Шарп уже 100 лет как кросплатформенный и не завязан более на винду

Как Вы правильно заметили, мир JVM как то не особо замечает мир .Net. В реалиях жизни под Java уже давно все процессы заточены, джуна вырастить быстрее в силу того что Java более просто яп при этом позволяющий выполнять те же задачи.
Зачем кому-то переходить на .Net если он не дает каких то критических преимуществ? Не нравиться отставание и многословность Java, есть альтернатива Kotlin/Scala. Все инструменты и подходы уже есть. (это я если что Java не хвалю а объясняю текущее положение дел)

Ну за это можно спасибо сказать умным ребятам из Майкрософт, которые из-за своей жадности и наплевательского отношения к пользователям их продуктов, до последнего толкали винду в качестве единственной безальтернативной платформы. Какие там 100 лет, проснулись , если не ошибаюсь только в 2016 году, а это по меркам IT - вчера.

  Развернуть 1 комментарий

вот тут есть что-то похожее, если еще не видели: https://roadmap.sh/
Вот, например, для QA https://roadmap.sh/qa

  Развернуть 1 комментарий

Почитал, подумал и понял, что хоть сам в айти 20+ лет, но как туда вкатываться - без понятия, тем более что сейчас явно иначе чем раньше, и чем потом)
Поэтому статью не напишу)

  Развернуть 1 комментарий

@rooty, У меня есть небольшой опыт по вкатыванию нескольких человек в IT. Вот, решил поделиться :D

  Развернуть 1 комментарий

По sql добавлю свой проект.
Собрал все актуальные материалы, что то есть платное, по мере возможности помогаю, всегда можете писать в личку!

https://vndv.github.io/LearningSQL/#/

  Развернуть 1 комментарий
Руслан Сабитов , Эксперт по кибербезопасности 22 ноября в 21:32

Ждем поста "Как выйти из IT"...

(я бы почитал)

  Развернуть 1 комментарий

@sumerki, 😂😂😂

  Развернуть 1 комментарий
Олег Смирнов , Тимлид всея разработки 21 ноября в 12:12

Добавлю свои пять копеек для собирающихся в программисты. На основе годового опыта преподавания JavaScript для вкатывающихся в IT.

Начать нужно с того, что определить зачем вы хотите в IT. Я видел довольно много примеров, когда люди успешно находили работу, работали год, два, а после этого уходили из профессии. Таких, конечно, не большинство, но нужно чётко понимать свою цель и соотносить её с реальностью. IT это не только про "много платят", это ещё часто и про переработку, постоянную необходимость что-то изучать, постоянную работу в условиях высокой неопределенности. Не то чтоб в других местах было сильно иначе, но люди часто видят фразу "много платят" и не видят всё остальное.

Если говорить про самообучение, первая самая главная вещь — нужно очень много практики. Представьте объем практики, который вам кажется большим, а затем умножьте его на три. Это будет примерно половина того, что вам надо.

Несмотря на то, что теорию тоже надо знать — для вкатывания практика в несколько раз важнее. За каждый теоретический час у вас должно быть 4 часа практики, а то и больше. По опыту для начинающих соотношение должно быть 80% практики, 20% теории, и это соотношение будет постепенно изменяться в сторону увеличения теории по мере набора опыта. А потом уменьшаться. А потом снова увеличиваться. Через какое-то время практика будет уже "в пальцах" как говорила моя преподавательница по фортепиано, и на это будет гораздо легче накладывать теорию, чем наоборот.

Если вы застряли с какой-то конкретной задачей дольше, чем на 10 часов, значит вам нужна помощь. Ищите более опытных ребят, нет смысла долбиться в стену, которая не поддаётся так долго. Если вы застряли с какой-то теоретической частью —пробуйте делать практику, даже если не до конца понимаете. Гуглите задачи, благо от недостатка задач интернет сейчас не страдает.

По поводу выбора языка, с которого начинать: со всех сторон вам будут рекомендовать совершенно разные языки, приводить миллион аргументов за и против, поэтому сделать взвешенный выбор будет сложно. Мой совет, берите тот язык, эксперт по которому есть у вас в прямом доступе. Выше в комментариях предлагают много разных вариантов: Python, Java, Golang. Все они с точки зрения количества вакансий плюс-минус похожи, с точки зрения базовых концепций хороши и в будущем при необходимости перейти с одного языка на другой будет проще, чем учить с нуля. Конечно, между этими языками есть и большая разница, но вам-то надо набрать достаточный уровень чтобы войти в профессию, а не чтобы стать в ней экспертом.

Я знаю примеры, когда программистами становились повара, водители и няни. Может быть, конечно, не великими гипер-синьорами, но уверенными миддлами — вполне. Помните, получилось у них — значит получится и у вас :)

  Развернуть 1 комментарий

а куда сейчас берут qa? по ощущениям в европаx/америкаx популярен девопс поxод, а по девопсу qa не нужны (и даже вредны)

  Развернуть 1 комментарий

@ngalaiko, Девопс это отдельно. Они как правило строят инфраструктуру для автоматического запуска тестов, мониторинга, предоставления результатов и т.д. QA это обычно отдельная команда, пишут тесты, находят баги.

  Развернуть 1 комментарий

@sergturi, девопс это майндсет

  Развернуть 1 комментарий

@ngalaiko, 👍
Ага, однострочники на баше, без документации, ммм...

  Развернуть 1 комментарий

@ngalaiko, в Яндекс, например

  Развернуть 1 комментарий

Статья хорошая и ссылки полезные. Но кажется в названии стоило уточнить, что основная информация для QA (хотя согласен, в общем и целом подходит всем)

  Развернуть 1 комментарий

@DmitryTikhomirov, Спасибо!
Как мне кажется, на начальном этапе разница между QA Automative и девелоперами совсем небольшая. Она есть, но при небольшой подготовке QA может пройти собеседование на программиста и наоборот.

  Развернуть 1 комментарий

@sergturi, очень смелое заявление. И много людей сходу в автоматизацию заходит?) Чаще всего заходят как обычные QA manual, а потом учатся писать тестики. Хотя снова же написание автотестов и написание программ стоят не так чтобы близко. На джуна QA automative пройти возможно и сможет, но это будет сильный даунгрейд по ЗП

  Развернуть 1 комментарий

@ApoloSeR, У меня сейчас в команде несколько джунов, всё, почему то, как один говорят что зарплата не важна, главное опыт ☝️.

У джунов зарплаты примерно одинаковые. Есть конечно небольшая разница, но +/- одинаково.

  Развернуть 1 комментарий

@sergturi, опыт, который ты будучи QA automate получаешь не сильно релевантный относительно опыта разработчика. Что они скажут что-то другое я кстати сильно сомневаюсь) Слушать конечно важно, особенно когда ты их растишь, и на старте опыт важен, это так.
Проблема в том что опыт на хлеб не намажешь и вопрос компенсации так или иначе всплывет (как часто в айтишечке любят зпшчки апать, особенно с ростом грейда, думаю напоминать не стоит))
Главное чтобы вектор был верный и не было иллюзий вроде - "я сейчас стану QA automate, а потом сразу software engineer"

  Развернуть 1 комментарий

@ApoloSeR, Ну я зашел. Вначале искал работу программистом (питон/js/java - одинаково их знал, точнее не знал). Свою первую работу в it искал, отмечу. Предложили вначале актуализировать старые тесты, а потом уже сам с нуля внедрял автотестирование в проекты. теорию тестирования изучал уже по ходу работы. Платили мне поначалу как и ручникам, потом больше, потому что перерос понятие "тестировщик". В прошлой конторе и в текущей моя ЗП не отличается от программистов.
Вообще, мысль что QA-инженер должен зарабатывать меньше программиста - очень странная и явно устаревшая. Тестировщик - да, он зарабатывает меньше, но только тестировщиком я считаю человека, который просто проходит тесты. А как только его в обязанность начинает входить "обеспечение качества", то и его полезность, а также ЗП, существенно растут

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб