У нас как-то само так и получилось. Нам долго приходилось искать джунов "да, да, за дешево и чтобы сразу мидл(шутка)", поэтому перешли к стажировкам и выросту внутри. И все стажировки закрывались обычно практикантами, а не выпускниками.
А когда не было практикантов, то чаще всего набирали 4х после 20 собеседований, выбранных из 200 резюме. Больше уже невозможно было провести, работе мешало. И чаще всего это были люди после курсов, а не выпускники.
В Самаре набирали по 10 человек с универа на практику каждый год, но набирали тех, кого советовал знакомый хороший преподаватель. Это всегда были крутые студенты, нам экономило кучу времени. Другие конторы набирали после собеседования, они были довольно серьёзные, сродни собесу на джуна, но они все были забиты, поэтому могли себе позволить.
Пришли на день открытых дверей в 3 универа года 2 назад, 200 студентов оставили свои контакты. Скинули им сделать тестовое размером с 1 лабораторку "положи по папкам файлики". Прислали ответ 4 человека, троих взяли на стажировку, зп как стажеров, доучили, они начали работать - стали джунами, зп стала как у джунов, кто посильнее через год уже были мидлами. Думаю, сейчас бы пришло больше ответов, потому что всё написал бы ChatGPT.
Смотря как описаны тест-кейсы, можно переработать тест-кейсы. Иногда они довольно атомарны и подробны на этапе разработки фич и хорошо подходят для полного регресса джунами. Но для постоянного прохождения частичного регресса становятся избыточны. Их можно уложить последовательно. Минус, что цепочки тестов блочатся, но в регрессе в идеале такого должно быть минимум. Если багов в регрессе много, то это уже качество кода и не время думать про сокращение регресса, это довольно быстро приведёт к пропуску на прод.
Не шёл через рефлексию, шёл через обучение по чуть-чуть каждый год.
Я для себя завёл список статей и видео, которые посмотрел и стоит посмотреть, с годами он наполнялся по технологиям, управлению и психологии. Так виден был путь за год/за карьеру, это вдохновляет.
Чтобы понять как что-то тестировать лучше, просто читал про это. Проходил курсы по сетям, как работает та или иная технология, например. Вначале сложно и тарабарщина, потом становится меньше магии в профессии, больше идей и уверенности, разговариваешь на одном языке и с программистами и директорами
Читал книги, не останавливался на "тестирование .com", хотя бы пару книг в год. Больше всего размышлений для меня принесла книга "Шаблоны тестирования xUnit: рефакторинг кода тестов". Вроде бы для разработчиков книга, но в ней про ошибки и тесты написано больше, чем 100 статьях "про виды тестирования".
Я был ручной тестировщик, и в фирме нагрузкой занимались разработчики абы как. Прошёл курс, прочёл статьи, начал пробовать, показал результаты, посмотрел ещё десяток видео, сделал лучше, обучил других. И спустя года в фирме накопилась квалификация по разным видам тестирования, мы уже не были ни в чьих глазах перекладывальщиками "черного ящика".
Научился программировать и начал смотреть на логи уже не как English magic, а что-то что с тобой говорит на понятном языке. Увидел, что я точно так же делаю ошибки на ровном месте, откуда эти ошибки появляются, и абсолютно по другому начала работать голова в предугадывании ошибок.
Чтобы показать другим в фирме, что делается в отделе публиковали статьи, отчеты за месяц, делали доклады как пользоваться jmeter, soapui, postman, fiddler.
Как у нас процессы построены для найма джунов-мидлов тестеров. HR делает первичный отсев людей "я видел фильм про тестирование, 8 лет опыта забойщика скота, хочу 200к". После этого остаются почти все резюме одинаковые, выбрасываем только совсем уж странных, остаётся процентов 80%. Не работал с какими-то технологиями? Мало опыта. Доучишься/доучим. Жестких условий по годам опыта и технологиям перед HR не ставлю. Что за человек с той стороны резюме понять сложно.
Чтобы отсеить врунов и просто зазуривших ответы, я просто не задаю такие вопросы. Всё собеседование строится от ситуации:
- Вы пришли в фирму, от заказчика пришло задание "реализовать 2 поля", немного вводных, что будете делать? Что уточнит, что будет делать. Намекну на то, что забыл. Что-то расскажет, уточню область применения.
- Сделали сервер, вот так работает, что будете делать?
- "Посмотрю А, Б, В". А что такое Б? А что будете смотреть в В. Слышали про Г? Как тут сделать Г?
- Вот такая ошибка? Как будете разбираться?(обычно 4+ разных ситуации прям про эти 2 поля)
- Сделали клиент, какие дальнейшие действия? И так далее.
Не жду что расскажут всё, если человек начинает воду лить, то переспрашиваю про прикладные вещи.
И вот по такому плану все придумавшие опыт почти ничего сказать кроме стандартных фраз сказать не могут. Все кто выучил, хорошо расскажут как это делается в теории. Все кто с опытом расскажут из своего опыта. И видно у кого какие дыры в знаниях и подойдёт ли мне этот человек с такими дырами на искомую должность.
Мигрировали из googledocs, техподдержка Test-IT скинула скрипты для импорта из Excel. Выгрузили из гугла тест-кейсы. Поправили скрипт под нашу структуру, и за несколько часов подкладывания файликов перенесли 6000 тест-кейсов. Вышло почти без боли.
Если не получается делегировать, то делегировать всё равно надо. Надо научиться это делать, надо научить сотрудников выполнять новые обязанности. Если обжёгся, всё равно надо пытаться и учиться, другого пути нет.
Статья уже не про тестирование, а про утопание в новых процессах. Герою статьи надо брать книги по менеджменту и учиться работать менеджером, а не играть в пинг-понг в Outlook с печалью в душе.
Когда к вам ещё раз приходят, вы перевешиваете эту задачу на 2-ой крючок и тоже не обращаете внимания.
Как это будет выглядеть со стороны проактивного сотрудника, если менеджер не понимает какие задачи можно вешать на крючок. Сотрудник решается поговорить со своим руководителем, дело это не для всех простое. Уходит дальше работать, и ничего не происходит какое-то время. Проблема не исчезает или повторяется. Уже начинают закрадываться плохие мысли о своём менеджере. Решает сам напомнить о проблеме или узнать фидбек о данной задаче. Его опять менеджерят, и он уходит работать. И опять тишина, у менеджера второй крючок только. А если проблем не одна от данного сотрудника, то на втором и третьем крючке висит уже связка проблем. И вот сотрудник понимает, что перед ним балабол, который ничего не делает, с ним бесполезно что-то обсуждать, и в этой компании ничего невозможно изменить.
Мы чтобы уменьшить количество кода и читаемость оборачивали в одну процедуру element.SetText(text);
element.Focus();element.Text = text;У нас как-то само так и получилось. Нам долго приходилось искать джунов "да, да, за дешево и чтобы сразу мидл(шутка)", поэтому перешли к стажировкам и выросту внутри. И все стажировки закрывались обычно практикантами, а не выпускниками.
А когда не было практикантов, то чаще всего набирали 4х после 20 собеседований, выбранных из 200 резюме. Больше уже невозможно было провести, работе мешало. И чаще всего это были люди после курсов, а не выпускники.
В Самаре набирали по 10 человек с универа на практику каждый год, но набирали тех, кого советовал знакомый хороший преподаватель. Это всегда были крутые студенты, нам экономило кучу времени. Другие конторы набирали после собеседования, они были довольно серьёзные, сродни собесу на джуна, но они все были забиты, поэтому могли себе позволить.
Пришли на день открытых дверей в 3 универа года 2 назад, 200 студентов оставили свои контакты. Скинули им сделать тестовое размером с 1 лабораторку "положи по папкам файлики". Прислали ответ 4 человека, троих взяли на стажировку, зп как стажеров, доучили, они начали работать - стали джунами, зп стала как у джунов, кто посильнее через год уже были мидлами. Думаю, сейчас бы пришло больше ответов, потому что всё написал бы ChatGPT.
Смотря как описаны тест-кейсы, можно переработать тест-кейсы. Иногда они довольно атомарны и подробны на этапе разработки фич и хорошо подходят для полного регресса джунами. Но для постоянного прохождения частичного регресса становятся избыточны. Их можно уложить последовательно. Минус, что цепочки тестов блочатся, но в регрессе в идеале такого должно быть минимум. Если багов в регрессе много, то это уже качество кода и не время думать про сокращение регресса, это довольно быстро приведёт к пропуску на прод.
Не шёл через рефлексию, шёл через обучение по чуть-чуть каждый год.
Я для себя завёл список статей и видео, которые посмотрел и стоит посмотреть, с годами он наполнялся по технологиям, управлению и психологии. Так виден был путь за год/за карьеру, это вдохновляет.
Чтобы понять как что-то тестировать лучше, просто читал про это. Проходил курсы по сетям, как работает та или иная технология, например. Вначале сложно и тарабарщина, потом становится меньше магии в профессии, больше идей и уверенности, разговариваешь на одном языке и с программистами и директорами
Читал книги, не останавливался на "тестирование .com", хотя бы пару книг в год. Больше всего размышлений для меня принесла книга "Шаблоны тестирования xUnit: рефакторинг кода тестов". Вроде бы для разработчиков книга, но в ней про ошибки и тесты написано больше, чем 100 статьях "про виды тестирования".
Я был ручной тестировщик, и в фирме нагрузкой занимались разработчики абы как. Прошёл курс, прочёл статьи, начал пробовать, показал результаты, посмотрел ещё десяток видео, сделал лучше, обучил других. И спустя года в фирме накопилась квалификация по разным видам тестирования, мы уже не были ни в чьих глазах перекладывальщиками "черного ящика".
Научился программировать и начал смотреть на логи уже не как English magic, а что-то что с тобой говорит на понятном языке. Увидел, что я точно так же делаю ошибки на ровном месте, откуда эти ошибки появляются, и абсолютно по другому начала работать голова в предугадывании ошибок.
Чтобы показать другим в фирме, что делается в отделе публиковали статьи, отчеты за месяц, делали доклады как пользоваться jmeter, soapui, postman, fiddler.
А потом в какой-то момент мерилом успеха в компании становится усталость
Как у нас процессы построены для найма джунов-мидлов тестеров. HR делает первичный отсев людей "я видел фильм про тестирование, 8 лет опыта забойщика скота, хочу 200к". После этого остаются почти все резюме одинаковые, выбрасываем только совсем уж странных, остаётся процентов 80%. Не работал с какими-то технологиями? Мало опыта. Доучишься/доучим. Жестких условий по годам опыта и технологиям перед HR не ставлю. Что за человек с той стороны резюме понять сложно.
Чтобы отсеить врунов и просто зазуривших ответы, я просто не задаю такие вопросы. Всё собеседование строится от ситуации:
- Вы пришли в фирму, от заказчика пришло задание "реализовать 2 поля", немного вводных, что будете делать? Что уточнит, что будет делать. Намекну на то, что забыл. Что-то расскажет, уточню область применения.
- Сделали сервер, вот так работает, что будете делать?
- "Посмотрю А, Б, В". А что такое Б? А что будете смотреть в В. Слышали про Г? Как тут сделать Г?
- Вот такая ошибка? Как будете разбираться?(обычно 4+ разных ситуации прям про эти 2 поля)
- Сделали клиент, какие дальнейшие действия? И так далее.
Не жду что расскажут всё, если человек начинает воду лить, то переспрашиваю про прикладные вещи.
И вот по такому плану все придумавшие опыт почти ничего сказать кроме стандартных фраз сказать не могут. Все кто выучил, хорошо расскажут как это делается в теории. Все кто с опытом расскажут из своего опыта. И видно у кого какие дыры в знаниях и подойдёт ли мне этот человек с такими дырами на искомую должность.
Мигрировали из googledocs, техподдержка Test-IT скинула скрипты для импорта из Excel. Выгрузили из гугла тест-кейсы. Поправили скрипт под нашу структуру, и за несколько часов подкладывания файликов перенесли 6000 тест-кейсов. Вышло почти без боли.
Если не получается делегировать, то делегировать всё равно надо. Надо научиться это делать, надо научить сотрудников выполнять новые обязанности. Если обжёгся, всё равно надо пытаться и учиться, другого пути нет.
Статья уже не про тестирование, а про утопание в новых процессах. Герою статьи надо брать книги по менеджменту и учиться работать менеджером, а не играть в пинг-понг в Outlook с печалью в душе.
Как это будет выглядеть со стороны проактивного сотрудника, если менеджер не понимает какие задачи можно вешать на крючок. Сотрудник решается поговорить со своим руководителем, дело это не для всех простое. Уходит дальше работать, и ничего не происходит какое-то время. Проблема не исчезает или повторяется. Уже начинают закрадываться плохие мысли о своём менеджере. Решает сам напомнить о проблеме или узнать фидбек о данной задаче. Его опять менеджерят, и он уходит работать. И опять тишина, у менеджера второй крючок только. А если проблем не одна от данного сотрудника, то на втором и третьем крючке висит уже связка проблем. И вот сотрудник понимает, что перед ним балабол, который ничего не делает, с ним бесполезно что-то обсуждать, и в этой компании ничего невозможно изменить.