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