Мне кажется HR нынче совсем обленились ((( выложила резюме - половина откликнувшихся ищет людей с Java, у меня коммерческий опыт с JavaScript и только в паре мест были готовы рассматривать альтернативу. И хорошо ещё, что спрашивала на подходе, а если бы до собеседования дошли?(((
Насчёт фуллстека не соглашусь, но тут вопрос насколько фуллстек. Например ручник с навыком автоматизатора на одном языке выглядит вполне реализуемо, хотя конечно времязатраты на ручные автотесты будет тормозить развитие в авто. А вот полиглоты меня напрягают))) я за время обучения в Нетологии успела пощупать 3 языка и к концу обучения один из них уже почти полностью забыла. мне кажется язык программирования это та вещь с которой надо практиковаться постоянно, по крайней мере большинству.
Ну не совсем. Как раз всё что выше юнит тестов делает тестировщик - он продумывает сценарий и реализует его в коде. А юнит тесты как раз должны писать в идеальной картине мира разработчики.
Тут большой вопрос - нанимают в отдел QA или обычного тестировщика. Второй момент - это ограничения в полномочиях. Например меня в команду наняли как классического тестировщика и мои полномочия при выстраивании процессов сильно ограничены. Я могу предложить идею, но заставить ее применять у меня полномочий никаких.
У меня создалось такое впечатление, что у автора или проблемы с процессами в команде, или нехватка ресурсов. Например - почему у тестировщика уходит 3 дня на проверку задачи? Конечно, бывают сложные задачи, но в моем понимании если на проверку задачи (без учёта тест-анализа) уходит больше 1,5-2 дней, то её явно стоит декомпозировать, если это возможно.
Кратковременный результат может быть неплох, но как уже писали выше разработчик как правило смотрит на продукт через призму кода и выдергивать его из этого состояния означает притормаживать его развитие как разработчика.
"Тихо-тихо подкидывают" - а вы не берите. Или требуйте пересмотра приоритетов. Если у вас есть объем работ на какой-то промежуток времени, то для вас он должен стать константой. Ну или какой-то объем должен быть необязательным, так сказать полезной нагрузкой если останется время.
Тут единственный выход - разговаривать с тимлидом, продактом и, если не слышат, идти выше. Спрашивать о приоритетах, обрезать регресс где нанесет меньше вреда и т.д. Что я поняла пока была одна на пятерых - пока не откроешь рот - всем на тебя пофиг и даже больше - видя как "хорошо" ты справляешься от тебя будут хотеть всё больше притом без существенных изменений условий.
Ни разу не пробовала на практике, но метод по 3 точкам всегда нравился больше, всё ещё эпизодически пытаюсь убедить начальство в его пользе. Для меня оптимистично - это количество минимального времени, которое я затрачу на задачу - т.е. прохождение кейсов которые придумала в моменте (у нас не дают долго думать на планировании даже с требованиями сейчас с трудом знакомимся до взятия в работу), без перерыва, оптимально - это время на "подумать" + мелкие перерывы на чай-кофе-туалет - прибавляю 5-10% на мелкий задачах и до 30 на крупных, пессимистично - это та же оптимальность только с починкой мелких дефектов при условии что разработчик оперативно возьмётся чинить это 20-50%, в зависимости от сложности, но здесь стоит хотя бы немного поработать в команде чтобы оценить как быстро работают разработчики.
Хм... Ну я могу понять работодателей, подсовывающих тестовые до собеседования, особенно если речь идёт о популярных направлениях. Другое дело, что объем таких работ, как справедливо заметил автор, не должен быть слишком большим (для меня приемлемо не больше 2-3 часов, для кого-то этот промежуток больше или меньше может быть).
Кто-то проводит техсобес, другой выдаст тестовое - лично мне больше тестовые нрявятся - мне нужно посидеть и подумать, сразу ответить бывает сложно, да и подсмотреть как правило нельзя (вот какой смысл таких ограничений, если в интернете, если забыл, всё находится за пару секунд (я сейчас про всякие лайфкодинги)???)
Думаю у джунов с большим опытом может быть ещё мотив - нет твердой уверенности в своих силах или переход из другой области (например, тестировал геймдев, а решил перейти в финтех). Правда у таких "джунов" запросы всё равно будут выше, чем у тех, у кого нет опыта вовсе.
Справедливости ради некоторые галеры сами просят "придумать" опыт. На старте карьеры мне дважды поступало такое предложение - первое от моего однокурсника из Нетологии, второе к сожалению уже не вспомню название, поступило чуть позже - надо было мои 3 месяца дотянуть до 6. В обоих случаях отказалась. Не люблю и не умею врать, да и репутация дороже. Как справедливо отметил автор - мир ИТ тесен. Я бы сама не хотела видеть врунишку у себя в команде - во-первых именно от тестировщика ожидаю честности больше чем от кого бы то ни было, во-вторых - где гарантия, что после устройства такой человек не станет врать (или ещё хуже - подставлять коллег), чтобы продвинуться дальше?
Меня больше всего выводит из себя тот факт, что НИГДЕ не пишут о необходимости англоязычного документа. Ну, точнее, мб где и пишут, но там где я сдавала информации не было, на курсе, когда рассказывали об онлайн/оффлайн экзамене об этом тоже никто ничего не говорил. Они реально думают, что подобные документы есть у всех?
А ведь это может стать решающим фактором для сдачи экзамена оффлайн (там его никто не просит).
Как ни печально, но в экзамене действительно встречаются спорные моменты. Думаю, частично в этом виноват не слишком корректный перевод. Это хорошо показывает тот факт, что вместе со мной сдавали двое моих знакомых коллег, но та, которая сдавала на английском сдала на 95% (или даже выше, не помню точную цифру).
Не факт))) Когда пришла на свою первую работу мне примерно такими же словами объясняли роли))) даже удивительно какое совпадение)))
Кстати, когда меня спросили что такое фронтенд и бэкенд я привела пример книги, что фронт - это обложка книги, ее оформление и т.д., а бэк - это само её содержание.
Ну хз... Я ожидаю от руководителя, что он будет фасилицировать подобные моменты, в идеале - подобные случаи должны быть единичными и не должны выходить за пределы команды. Если дело идет дальше, то это это ставит в невыгодном свете в первую очередь руководителя.
Меня как раз девочка разработчик не удивила - по мне одно из главных качеств для тестировщика - аналитическое мышление и, в целом, тест-дизайн на нем и основан. Когда училась на курсе у нас были люди, которые ещё на модуле с ручным тестированием жаловались на его чрезмерную сложность - как по мне - это был самый простой модуль, к тому же преподаватели всё достойно объясняли.
Это я к тому, что, к сожалению, тестирование все ещё считается "легким входом в ИТ" - и кто-то сшибается сразу, а кто-то, уже устроившись, понимает, что тут тоже что-то надо знать.
Мне кажется HR нынче совсем обленились ((( выложила резюме - половина откликнувшихся ищет людей с Java, у меня коммерческий опыт с JavaScript и только в паре мест были готовы рассматривать альтернативу. И хорошо ещё, что спрашивала на подходе, а если бы до собеседования дошли?(((
Тогда надо говорить "я возьму задачу Б, но тогда не сделаю задачу А"
Насчёт фуллстека не соглашусь, но тут вопрос насколько фуллстек. Например ручник с навыком автоматизатора на одном языке выглядит вполне реализуемо, хотя конечно времязатраты на ручные автотесты будет тормозить развитие в авто. А вот полиглоты меня напрягают))) я за время обучения в Нетологии успела пощупать 3 языка и к концу обучения один из них уже почти полностью забыла. мне кажется язык программирования это та вещь с которой надо практиковаться постоянно, по крайней мере большинству.
Ну не совсем. Как раз всё что выше юнит тестов делает тестировщик - он продумывает сценарий и реализует его в коде. А юнит тесты как раз должны писать в идеальной картине мира разработчики.
Тут большой вопрос - нанимают в отдел QA или обычного тестировщика. Второй момент - это ограничения в полномочиях. Например меня в команду наняли как классического тестировщика и мои полномочия при выстраивании процессов сильно ограничены. Я могу предложить идею, но заставить ее применять у меня полномочий никаких.
У меня создалось такое впечатление, что у автора или проблемы с процессами в команде, или нехватка ресурсов. Например - почему у тестировщика уходит 3 дня на проверку задачи? Конечно, бывают сложные задачи, но в моем понимании если на проверку задачи (без учёта тест-анализа) уходит больше 1,5-2 дней, то её явно стоит декомпозировать, если это возможно.
Кратковременный результат может быть неплох, но как уже писали выше разработчик как правило смотрит на продукт через призму кода и выдергивать его из этого состояния означает притормаживать его развитие как разработчика.
"Тихо-тихо подкидывают" - а вы не берите. Или требуйте пересмотра приоритетов. Если у вас есть объем работ на какой-то промежуток времени, то для вас он должен стать константой. Ну или какой-то объем должен быть необязательным, так сказать полезной нагрузкой если останется время.
Тут единственный выход - разговаривать с тимлидом, продактом и, если не слышат, идти выше. Спрашивать о приоритетах, обрезать регресс где нанесет меньше вреда и т.д. Что я поняла пока была одна на пятерых - пока не откроешь рот - всем на тебя пофиг и даже больше - видя как "хорошо" ты справляешься от тебя будут хотеть всё больше притом без существенных изменений условий.
Мне кажется, 1 тестировщик на 9 разрабов это вообще на грани фантастики. Я сама долгое время была одна на пятерых - и это был ад.
Ни разу не пробовала на практике, но метод по 3 точкам всегда нравился больше, всё ещё эпизодически пытаюсь убедить начальство в его пользе. Для меня оптимистично - это количество минимального времени, которое я затрачу на задачу - т.е. прохождение кейсов которые придумала в моменте (у нас не дают долго думать на планировании даже с требованиями сейчас с трудом знакомимся до взятия в работу), без перерыва, оптимально - это время на "подумать" + мелкие перерывы на чай-кофе-туалет - прибавляю 5-10% на мелкий задачах и до 30 на крупных, пессимистично - это та же оптимальность только с починкой мелких дефектов при условии что разработчик оперативно возьмётся чинить это 20-50%, в зависимости от сложности, но здесь стоит хотя бы немного поработать в команде чтобы оценить как быстро работают разработчики.
Хм... Ну я могу понять работодателей, подсовывающих тестовые до собеседования, особенно если речь идёт о популярных направлениях. Другое дело, что объем таких работ, как справедливо заметил автор, не должен быть слишком большим (для меня приемлемо не больше 2-3 часов, для кого-то этот промежуток больше или меньше может быть).
Кто-то проводит техсобес, другой выдаст тестовое - лично мне больше тестовые нрявятся - мне нужно посидеть и подумать, сразу ответить бывает сложно, да и подсмотреть как правило нельзя (вот какой смысл таких ограничений, если в интернете, если забыл, всё находится за пару секунд (я сейчас про всякие лайфкодинги)???)
Ну тестовое это не бесплатная работа же... По крайней мере мне ни разу не попадалось что-то похожее на реальную работу.
Я знаю, что могут и такое подсунуть, но часто это заметно.
Думаю у джунов с большим опытом может быть ещё мотив - нет твердой уверенности в своих силах или переход из другой области (например, тестировал геймдев, а решил перейти в финтех). Правда у таких "джунов" запросы всё равно будут выше, чем у тех, у кого нет опыта вовсе.
Справедливости ради некоторые галеры сами просят "придумать" опыт. На старте карьеры мне дважды поступало такое предложение - первое от моего однокурсника из Нетологии, второе к сожалению уже не вспомню название, поступило чуть позже - надо было мои 3 месяца дотянуть до 6. В обоих случаях отказалась. Не люблю и не умею врать, да и репутация дороже. Как справедливо отметил автор - мир ИТ тесен. Я бы сама не хотела видеть врунишку у себя в команде - во-первых именно от тестировщика ожидаю честности больше чем от кого бы то ни было, во-вторых - где гарантия, что после устройства такой человек не станет врать (или ещё хуже - подставлять коллег), чтобы продвинуться дальше?
Меня больше всего выводит из себя тот факт, что НИГДЕ не пишут о необходимости англоязычного документа. Ну, точнее, мб где и пишут, но там где я сдавала информации не было, на курсе, когда рассказывали об онлайн/оффлайн экзамене об этом тоже никто ничего не говорил. Они реально думают, что подобные документы есть у всех?
А ведь это может стать решающим фактором для сдачи экзамена оффлайн (там его никто не просит).
Как ни печально, но в экзамене действительно встречаются спорные моменты. Думаю, частично в этом виноват не слишком корректный перевод. Это хорошо показывает тот факт, что вместе со мной сдавали двое моих знакомых коллег, но та, которая сдавала на английском сдала на 95% (или даже выше, не помню точную цифру).
Я осознаю, что это очень обобщенный пример)) Но он же показался самым удачным для объяснения людям, которые вообще с айти не связаны.
Не факт))) Когда пришла на свою первую работу мне примерно такими же словами объясняли роли))) даже удивительно какое совпадение)))
Кстати, когда меня спросили что такое фронтенд и бэкенд я привела пример книги, что фронт - это обложка книги, ее оформление и т.д., а бэк - это само её содержание.
Ну хз... Я ожидаю от руководителя, что он будет фасилицировать подобные моменты, в идеале - подобные случаи должны быть единичными и не должны выходить за пределы команды. Если дело идет дальше, то это это ставит в невыгодном свете в первую очередь руководителя.
Меня как раз девочка разработчик не удивила - по мне одно из главных качеств для тестировщика - аналитическое мышление и, в целом, тест-дизайн на нем и основан. Когда училась на курсе у нас были люди, которые ещё на модуле с ручным тестированием жаловались на его чрезмерную сложность - как по мне - это был самый простой модуль, к тому же преподаватели всё достойно объясняли.
Это я к тому, что, к сожалению, тестирование все ещё считается "легким входом в ИТ" - и кто-то сшибается сразу, а кто-то, уже устроившись, понимает, что тут тоже что-то надо знать.