Ну... Меня взяли с неполным соответствием и по знаниям. Притом, сами написали, там было всего так много, что сама бы я даже не откликнулась, т.к. обычно откликаюсь на вакансии которым соответствую хотя бы на 80%. И тут уже выбор за работодателем - готов он меня доучивать (или подождать пока доучусь) или нет. Я сама готова, в случае несоответствия потратить часть личного времени, но так же ожидаю, что от меня не станут в таком случае ждать мгновенных результатов.
Бывшего коллегу, кстати, взяли на должность автоматизатора (точнее искали мануальщика + джава), хотя он автоматизацию не знал, но готов был учиться. Да, взяли на более низкую оплату, чем попросил бы такой же человек со знанием, но тем не менее. Кстати, как он мне говорил, взяли в т.ч. из-за денег - его ожидания показались более адекватными тому, что он умеет.
Насчёт фильтров не уверена. Почти везде дается совет откликаться, если хотя бы на 60-80% соответствуешь вакансии. И тут встаёт вопрос - как понять какой фильтр обязательный? Ежу понятно, что новичку не стоит откликаться на вакансии с 3+ годами работы, но как поняла на своем опыте 1+ при небольшой доработке такой человек потянуть может (искали мидла, а взяли меня с несколькими месяцами работы на волонтерских проектах).
Более того - после 3 месяцев работы там я уверена, что спокойно сошла бы за 1+, т.к. опыт получился весьма концентрированным.
Обычно параллелю. Нажимаю кнопку и смотрю в консоли куда что отправляется и что приходит - все-равно без работающего UI смысла в API здесь никакого, хотя проверка эндпоинтов, конечно, сжирает какое-то количество времени. За исключением пары негативных кейсов, которые через UI не проверишь. Если говорить о смоуке, конечно.
Я пока новичок в этом. И, к моему сожалению, боюсь, что опять практически откатилась к тому состоянию, что была до всей этой истории. Хотя, думаю, вспомнить всё-таки проще, чем с нуля начинать.
У нас в основном по АПИ автоматизация + кафка для интеграционного тестирования. Хотелось бы ещё UI, но наша платформа слабо приспособлена под нее + ещё ряд кейсов с длительным периодом ожидания - от часа до суток - тут тоже, насколько понимаю, нужны заглушки от разработчиков. Обещали в конце прошлого квартала, но воз и ныне там.
Это я к тому, что я прекрасно это понимаю, но пока руководство не готово это понять - я не готова тратить свои собственные ресурсы на обеспечение их хотелок (и так потратила, когда изучала автотесты, чтобы как можно скорее включиться в процесс (меня брали ручником изначально)).
Ну до недавнего времени я вообще одна была в команде и, когда начались все эти телодвижения в сторону автоматизации, то оказалось (внезапно) что даже при уделении автоматизации 10-15% времени задач стало уходить меньше. А если ставить на задачи высокий приоритет и уменьшать количество часов на автоматизацию в 3-4 раза, да ещё и с большими перерывами, то автоматизация резко замедляется (тоже очень внезапно). В итоге решили взять второго человека и отложить автоматизацию на месяц, что уже вылилось в полгода.
Ну а мне захотелось поделиться) Это действительно бывает проблемой для новичков, особенно если они попадают в стартап и оказываются в гордом одиночестве. Я хоть и не была одна, но второй тестировщик был как правильно слишком загружен, да и воспринимали меня уже как миддла практически. Разбиралась-думала сама, если моя статья поможет хотя бы одному человеку - значит не зря старалась.
Я работаю, например, на очень большом проекте. Минимальное время смоука - 10 часов - это основная пользовательская функциональность, без которой вся бизнес ценность программы стремится к нулю. Это без негативных сценариев, второстепенных функциональностей и т.д.
Сейчас мы обсуждаем тимлида, хотя, конечно, это должно работать в обе стороны=) Как по мне, как лицо заинтересованное в результате, он должен быть последователен в своих решениях. Если у нас договоренность 1 час в день (допускаю, что это может быть, с небольшим +-), а у меня задач и так с перелимитом, то я спрошу, что в приоритете ибо делать в рабочее время задачи, а потом ещё ежедневно этот час дорабатывать я не готова. В общем лично меня эта ситуация довольно сильно демотивировала, потому что для своего тогдашнего уровня я пожертвовала в т.ч. и личными ресурсами, т.к. брали меня изначально вообще как ручника и автоматизацию я хоть и знала, но на очень слабом уровне.
Придерживаться договоренностей с команды. Был случай когда тимлид хотел автоматизацию и у меня даже что-то начало получаться, и вроде даже неплохо (порядка 16 автотестов за 1,5 месяца из которых треть ушла на ликвидацию пробелов в доке для новичка по-моему неплохо). Потом резко посыпалось большое количество задач, постоянно менялись приорииетов и всесто оговоренного часа в день у меня за квартал дай бог часов 20 вышло и то урывками, часть из которых съело очередное корпоративное обновление из-за которого автотесты пришлось ещё и чинить. По итогу - 4 автотеста за квартал. В итоге от автотестов вообще отказались до лучших времён.
Доля правды в тексте есть (хотя меня не покидает чувство, что писал джун, хотящий зп синьора), но:
1) джун, чтобы приносить пользу уже через несколько недель должен уже на старте что-то уметь. Допускаю, что есть гении, которые уже через день-два начнут кодить как боги, но в большинстве случаев джун-нулевик уйдет в плюс хорошо, если через полгода.
2) джуна кто-то должен учить, а в некоторых случаях и контролировать. не во всех командах есть запас прочности на это. когда работала на первой работе нашим джуном мы занимались вдвоём - я учила человека писать тест-кейсы и баг-репорты, а наш миддл рассказывала о продукте (там было довольно сложно джуну разобраться) - вышли в плюс через пару недель, но во-первых нас было двое, во-вторых там был человек хорошо знавший теорию тестирования и очень быстро схватывающий, в-третьих это всё-таки тестирование, здесь порог входа ниже, но для дальнейшего развития уже придется потрудиться.
Даже не поспорить. С такими кадрами тоже пришлось поработать. Особенно вызывает недоумение, когда точно знаешь какие бывают джуны (видела перспективных ребят, когда "хомячков" на прошлой работе вела), а тебе дают нечто, что не знает чем смоук от регресса отличается...
Я тестировщик и я учусь говорить работодателю "нет". Первые полгода работала в хроническом овертайме, что сильно сказалось на моем настроении, что вызвало ворчание со стороны начальства.
Потом поговорили, овергрузить почти перестали, стала больше участвовать в планировании и в целом если и задерживаюсь, то намного реже. Не знаю как отразится этот разговор в дальнейшем, но пока работать стало намного приятнее.
Не понимаю проблемы. Человек же выполняет свои непосредственные обязанности? Выполняет. Если человек хочет повышения, то он работает чуть больше ожидаемого (в рамках разумного берет дополнительные обязанности, учится чему-то и т.д.), если ему это не надо и за это ему не доплатят - зачем делать больше?
Я сама отношусь к тому поколению, в котором перерабатывать считается нормой и мне сложно сказать начальнику "нет" - сейчас работаю над этой проблемой.
Последний пункт с жонглированием и эффективностью очень спорный. Мало кто действительно может справиться с многозадачностью. Скорее всего человек где-то проседает - или в качестве (как часто тестировщики делают ретест его задач?), или в количестве.
Если мы не говорим о звёздном игроке, который львиную долю задач проекта делает в 2-3 раза быстрее коллег, да ещё и делает те задачи, на которые у тех не хватает компетенций, то ценность такого жонглирования сомнительна.
Подписываюсь под каждым словом. Даже если в целом работа сотрудника меня устраивала, будь я на месте начальника у меня бы была такая математика:
Предположим сотрудник отдает работе все оплаченные 8 часов (ну ладно, мало кто работает ровно столько, с учётом мини-перерывов хотя бы 6-7). Остальное меня действительно не касается. Но сколько продержится в таком ритме сотрудник? Нет ли у него признаков выгорания? Возможно пора присматривать замену?
Сотрудник не додает время, оплаченное компанией. При планировании называет время в 2-3 раза больше, чем ему надо (даже с учётом того запаса, что должен учитывать любой человек) и в итоге команда успевает сделать меньше, пользователи дольше мучаются с багом и компания позже получает возможность заработать на классной фиче (а то и вовсе та потеряла актуальность).
То же что и в п.2, но в обратную сторону. Стоит пересмотреть нагруженность сотрудников. Мб у них у всех в день есть 3-4 часа, которые хоть и оплачиваются, но никак не используются.Почему бы тогда действительно кого-то не уволить, переложив часть нагрузки на оставшихся сотрудников (и получив возможность повысить им зарплату)?
Ну... Меня взяли с неполным соответствием и по знаниям. Притом, сами написали, там было всего так много, что сама бы я даже не откликнулась, т.к. обычно откликаюсь на вакансии которым соответствую хотя бы на 80%. И тут уже выбор за работодателем - готов он меня доучивать (или подождать пока доучусь) или нет. Я сама готова, в случае несоответствия потратить часть личного времени, но так же ожидаю, что от меня не станут в таком случае ждать мгновенных результатов.
Бывшего коллегу, кстати, взяли на должность автоматизатора (точнее искали мануальщика + джава), хотя он автоматизацию не знал, но готов был учиться. Да, взяли на более низкую оплату, чем попросил бы такой же человек со знанием, но тем не менее. Кстати, как он мне говорил, взяли в т.ч. из-за денег - его ожидания показались более адекватными тому, что он умеет.
Насчёт фильтров не уверена. Почти везде дается совет откликаться, если хотя бы на 60-80% соответствуешь вакансии. И тут встаёт вопрос - как понять какой фильтр обязательный? Ежу понятно, что новичку не стоит откликаться на вакансии с 3+ годами работы, но как поняла на своем опыте 1+ при небольшой доработке такой человек потянуть может (искали мидла, а взяли меня с несколькими месяцами работы на волонтерских проектах).
Более того - после 3 месяцев работы там я уверена, что спокойно сошла бы за 1+, т.к. опыт получился весьма концентрированным.
Обычно параллелю. Нажимаю кнопку и смотрю в консоли куда что отправляется и что приходит - все-равно без работающего UI смысла в API здесь никакого, хотя проверка эндпоинтов, конечно, сжирает какое-то количество времени. За исключением пары негативных кейсов, которые через UI не проверишь. Если говорить о смоуке, конечно.
Я пока новичок в этом. И, к моему сожалению, боюсь, что опять практически откатилась к тому состоянию, что была до всей этой истории. Хотя, думаю, вспомнить всё-таки проще, чем с нуля начинать.
У нас в основном по АПИ автоматизация + кафка для интеграционного тестирования. Хотелось бы ещё UI, но наша платформа слабо приспособлена под нее + ещё ряд кейсов с длительным периодом ожидания - от часа до суток - тут тоже, насколько понимаю, нужны заглушки от разработчиков. Обещали в конце прошлого квартала, но воз и ныне там.
Это я к тому, что я прекрасно это понимаю, но пока руководство не готово это понять - я не готова тратить свои собственные ресурсы на обеспечение их хотелок (и так потратила, когда изучала автотесты, чтобы как можно скорее включиться в процесс (меня брали ручником изначально)).
Ну до недавнего времени я вообще одна была в команде и, когда начались все эти телодвижения в сторону автоматизации, то оказалось (внезапно) что даже при уделении автоматизации 10-15% времени задач стало уходить меньше. А если ставить на задачи высокий приоритет и уменьшать количество часов на автоматизацию в 3-4 раза, да ещё и с большими перерывами, то автоматизация резко замедляется (тоже очень внезапно). В итоге решили взять второго человека и отложить автоматизацию на месяц, что уже вылилось в полгода.
Минимальная. У начальства в приоритете новые фичи и фикс багов. Не ночью же ей теперь заниматься.
Ну а мне захотелось поделиться) Это действительно бывает проблемой для новичков, особенно если они попадают в стартап и оказываются в гордом одиночестве. Я хоть и не была одна, но второй тестировщик был как правильно слишком загружен, да и воспринимали меня уже как миддла практически. Разбиралась-думала сама, если моя статья поможет хотя бы одному человеку - значит не зря старалась.
Привет!Да, я поэтому и указала это первым пунктом) Для маленьких-средних проектов допустимо использовать что-то одно, для больших - удобнее оба.![]()
Я работаю, например, на очень большом проекте. Минимальное время смоука - 10 часов - это основная пользовательская функциональность, без которой вся бизнес ценность программы стремится к нулю. Это без негативных сценариев, второстепенных функциональностей и т.д.
Сейчас мы обсуждаем тимлида, хотя, конечно, это должно работать в обе стороны=) Как по мне, как лицо заинтересованное в результате, он должен быть последователен в своих решениях. Если у нас договоренность 1 час в день (допускаю, что это может быть, с небольшим +-), а у меня задач и так с перелимитом, то я спрошу, что в приоритете ибо делать в рабочее время задачи, а потом ещё ежедневно этот час дорабатывать я не готова. В общем лично меня эта ситуация довольно сильно демотивировала, потому что для своего тогдашнего уровня я пожертвовала в т.ч. и личными ресурсами, т.к. брали меня изначально вообще как ручника и автоматизацию я хоть и знала, но на очень слабом уровне.
Придерживаться договоренностей с команды. Был случай когда тимлид хотел автоматизацию и у меня даже что-то начало получаться, и вроде даже неплохо (порядка 16 автотестов за 1,5 месяца из которых треть ушла на ликвидацию пробелов в доке для новичка по-моему неплохо). Потом резко посыпалось большое количество задач, постоянно менялись приорииетов и всесто оговоренного часа в день у меня за квартал дай бог часов 20 вышло и то урывками, часть из которых съело очередное корпоративное обновление из-за которого автотесты пришлось ещё и чинить. По итогу - 4 автотеста за квартал. В итоге от автотестов вообще отказались до лучших времён.
Доля правды в тексте есть (хотя меня не покидает чувство, что писал джун, хотящий зп синьора), но:
1) джун, чтобы приносить пользу уже через несколько недель должен уже на старте что-то уметь. Допускаю, что есть гении, которые уже через день-два начнут кодить как боги, но в большинстве случаев джун-нулевик уйдет в плюс хорошо, если через полгода.
2) джуна кто-то должен учить, а в некоторых случаях и контролировать. не во всех командах есть запас прочности на это. когда работала на первой работе нашим джуном мы занимались вдвоём - я учила человека писать тест-кейсы и баг-репорты, а наш миддл рассказывала о продукте (там было довольно сложно джуну разобраться) - вышли в плюс через пару недель, но во-первых нас было двое, во-вторых там был человек хорошо знавший теорию тестирования и очень быстро схватывающий, в-третьих это всё-таки тестирование, здесь порог входа ниже, но для дальнейшего развития уже придется потрудиться.
Даже не поспорить. С такими кадрами тоже пришлось поработать. Особенно вызывает недоумение, когда точно знаешь какие бывают джуны (видела перспективных ребят, когда "хомячков" на прошлой работе вела), а тебе дают нечто, что не знает чем смоук от регресса отличается...
Не вижу смысла спорить, очевидно вы из тех людей у которых начальник всегда прав ибо это первая мысль, которая пришла к вам в голову.
Если вы не сталкивались с ситуациями когда задач явно больше, чем их можно сделать - я очень за вас рада.
Я тестировщик и я учусь говорить работодателю "нет". Первые полгода работала в хроническом овертайме, что сильно сказалось на моем настроении, что вызвало ворчание со стороны начальства.
Потом поговорили, овергрузить почти перестали, стала больше участвовать в планировании и в целом если и задерживаюсь, то намного реже. Не знаю как отразится этот разговор в дальнейшем, но пока работать стало намного приятнее.
Не понимаю проблемы. Человек же выполняет свои непосредственные обязанности? Выполняет. Если человек хочет повышения, то он работает чуть больше ожидаемого (в рамках разумного берет дополнительные обязанности, учится чему-то и т.д.), если ему это не надо и за это ему не доплатят - зачем делать больше?
Я сама отношусь к тому поколению, в котором перерабатывать считается нормой и мне сложно сказать начальнику "нет" - сейчас работаю над этой проблемой.
Последний пункт с жонглированием и эффективностью очень спорный. Мало кто действительно может справиться с многозадачностью. Скорее всего человек где-то проседает - или в качестве (как часто тестировщики делают ретест его задач?), или в количестве.
Если мы не говорим о звёздном игроке, который львиную долю задач проекта делает в 2-3 раза быстрее коллег, да ещё и делает те задачи, на которые у тех не хватает компетенций, то ценность такого жонглирования сомнительна.
Подписываюсь под каждым словом. Даже если в целом работа сотрудника меня устраивала, будь я на месте начальника у меня бы была такая математика:
Предположим сотрудник отдает работе все оплаченные 8 часов (ну ладно, мало кто работает ровно столько, с учётом мини-перерывов хотя бы 6-7). Остальное меня действительно не касается. Но сколько продержится в таком ритме сотрудник? Нет ли у него признаков выгорания? Возможно пора присматривать замену?
Сотрудник не додает время, оплаченное компанией. При планировании называет время в 2-3 раза больше, чем ему надо (даже с учётом того запаса, что должен учитывать любой человек) и в итоге команда успевает сделать меньше, пользователи дольше мучаются с багом и компания позже получает возможность заработать на классной фиче (а то и вовсе та потеряла актуальность).
То же что и в п.2, но в обратную сторону. Стоит пересмотреть нагруженность сотрудников. Мб у них у всех в день есть 3-4 часа, которые хоть и оплачиваются, но никак не используются.Почему бы тогда действительно кого-то не уволить, переложив часть нагрузки на оставшихся сотрудников (и получив возможность повысить им зарплату)?