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