Касательно типизации: если бы вы чуть внимательнее прочитали, я использую формулировку: "ЭТО ЛИШЬ НЕСКОЛЬКО ТИПОВ". Существует множество других подходов и методов. Я думаю, вы понимаете, что все зависит от конкретного проекта, и не везде всё применимо. Спасибо за уточнение про Docker, думаю, его тоже действительно стоило включить в статью, но он не является панацеей. Robot Framework, старый инструмент, но многие современные потребности и задачи он покрывает, у него есть свои плюсы и минусы, как и у всех.
Никто не будет спорить с тем, что Agile — это методология разработки программного обеспечения. Просто если мы смотрим на вопрос с функциональной точки зрения, например, для менеджера Agile будет методологией управления проектом, для тестировщика — в том числе методологией тестирования (ведь именно этим он и занимается), для аналитика и разраба - другое, но все вместе они работают по Agile. Гайд написан именно для тестировщика, поэтому использована такая терминология. Возможно, кому-то это будет проще для понимания.
Касательно того, что на реальном проекте не будет легко и ответственности для тестировщика. В большинстве случаев, скорее да. Будет сложно и многое непонятно. Но давайте не будем столь узки в своем видении. Для кого-то будет легко, а кто-то еще и оптимизирует что-то с ходу и внесет изменения. Мы же с вами не можем знать и тыкать пальцем в небо, говоря за всех, у кого какие проекты. Все зависит от конкретной ситуации.
За качество продукта отвечают действительно все, и то, что все виноваты, это и так понятно. Но на этапе обучения мне кажется важным донести до тестировщика его вклад в проект, что от него многое зависит, что сподвигнет его на дальнейшее развитие! Это важно для ребят, которые только вливаются. Когда баг в проде, я не имею в виду, что нужно агриться на тестировщика. Есть кейсы, которые тестировщик не может проверить, и для этого, в том числе, пишутся юнит-тесты. Нужно обсуждать все это в команде и пытаться понять, почему это произошло, и как этого не повторить. Но иногда это зависит от уровня скилла тестировщика. Главное не уходить в крайности с такой позицией, что все виноваты. "А я то что, все виноваты" особенно для начинающих тестировщиков это может быть краеугольным камнем для успешности проекта, а у меня гайд именно для ребят которые только хотят влиться в эту профессию или хотят побольше узнать о ней.
Тоже наслышан не с лучшей стороны про Нетологию, что, якобы, они затягивают лекции и льют много воды. Жаль, что с ними у вас так вышло.
Кроме JMeter, есть еще Gatling, Locust и облачные платформы Loader.io, Flood.io, BlazeMeter. Но на практике сталкиваюсь, в основном, с использованием JMeter для серверной части, Selenium для браузеров и JMH для Java.
Согласен. Ручная проверка по сценариям - это тоже вид тестирования, но в текущих реалиях рынок джунов просто переполнен, и оплата не столь высокая, если вы хотите только этим заниматься. Зачастую хорошим стартапам, проектам сейчас нужно, чтобы тестировщик играл проактивную роль в построении процесса, поскольку они сами развиваются, и скорее на работу возьмут того, кто сможет не только бегать по сценариям, но и помочь скилами и навыками на любых уровнях. Тогда они охотнее уже будут вкладываться в тебя и твое обучение, видя в тебе перспективу. Ведь все компании смотрят в будущее. Отсюда вопрос: если ты тоже хочешь развиваться, то что еще умеешь, в какую сторону смотришь и какие навыки есть?
А если компания имеет устоявшиеся процессы, веб, то она тем более уже покрывает большую часть автотестами. Поэтому, да, жизнь джунов не так легка, как её разукрашивает менеджмент. Есть очень большая конкуренция. Поэтому считаю правильнее сразу говорить о том, что работа тестировщика может быть разной и более сложной, и оплата будет соответствовать вашим навыкам.
Спасибо за интересный отзыв. Безусловно, вы правы. Для джунов не всегда необходимо знание кода (просто хотя бы примерное понимание) и автоматизация. Всё зависит от проекта. Однако, я попытался включить в гайд идею того, какой путь можно пройти и на что обратить внимание, чтобы прогрессировать дальше и становиться, например, мидлами.
Думаю, людям, не разбирающимся в тестировании, могло бы быть интересно увидеть общую картину и какие могут быть пути развития и прогресса, например, в автоматизацию.
Приветствую. Картинки действительно генерировались с помощью Midjourney для атмосферности, а все описание и структура из собственного опыта и практики работы. Хорошего вам дня :)
Спасибо ?
Всё очень индивидуально. Зависит от мотивации и желания обучаться. Некоторым удается освоиться за месяцы, а кто-то может затянуть это на годы.
Очень рад, что статья вам понравилась. Спасибо за обратную связь :).
Спасибо за интересную обратную связь.
Касательно типизации: если бы вы чуть внимательнее прочитали, я использую формулировку: "ЭТО ЛИШЬ НЕСКОЛЬКО ТИПОВ". Существует множество других подходов и методов. Я думаю, вы понимаете, что все зависит от конкретного проекта, и не везде всё применимо. Спасибо за уточнение про Docker, думаю, его тоже действительно стоило включить в статью, но он не является панацеей. Robot Framework, старый инструмент, но многие современные потребности и задачи он покрывает, у него есть свои плюсы и минусы, как и у всех.
Никто не будет спорить с тем, что Agile — это методология разработки программного обеспечения. Просто если мы смотрим на вопрос с функциональной точки зрения, например, для менеджера Agile будет методологией управления проектом, для тестировщика — в том числе методологией тестирования (ведь именно этим он и занимается), для аналитика и разраба - другое, но все вместе они работают по Agile. Гайд написан именно для тестировщика, поэтому использована такая терминология. Возможно, кому-то это будет проще для понимания.
Касательно того, что на реальном проекте не будет легко и ответственности для тестировщика. В большинстве случаев, скорее да. Будет сложно и многое непонятно. Но давайте не будем столь узки в своем видении. Для кого-то будет легко, а кто-то еще и оптимизирует что-то с ходу и внесет изменения. Мы же с вами не можем знать и тыкать пальцем в небо, говоря за всех, у кого какие проекты. Все зависит от конкретной ситуации.
За качество продукта отвечают действительно все, и то, что все виноваты, это и так понятно. Но на этапе обучения мне кажется важным донести до тестировщика его вклад в проект, что от него многое зависит, что сподвигнет его на дальнейшее развитие! Это важно для ребят, которые только вливаются. Когда баг в проде, я не имею в виду, что нужно агриться на тестировщика. Есть кейсы, которые тестировщик не может проверить, и для этого, в том числе, пишутся юнит-тесты. Нужно обсуждать все это в команде и пытаться понять, почему это произошло, и как этого не повторить. Но иногда это зависит от уровня скилла тестировщика. Главное не уходить в крайности с такой позицией, что все виноваты. "А я то что, все виноваты" особенно для начинающих тестировщиков это может быть краеугольным камнем для успешности проекта, а у меня гайд именно для ребят которые только хотят влиться в эту профессию или хотят побольше узнать о ней.
Спасибо! Обязательно продолжайте поиск работы и совмещайте его с обучением. Уверен, у вас все получится:)!
Спасибо за интересную обратную связь. Понятие абстрактности действительно может испугать.
Спасибо за обратную связь! Рад, что вам понравилась статья.
Тоже наслышан не с лучшей стороны про Нетологию, что, якобы, они затягивают лекции и льют много воды. Жаль, что с ними у вас так вышло.
Кроме JMeter, есть еще Gatling, Locust и облачные платформы Loader.io, Flood.io, BlazeMeter. Но на практике сталкиваюсь, в основном, с использованием JMeter для серверной части, Selenium для браузеров и JMH для Java.
Согласен. Ручная проверка по сценариям - это тоже вид тестирования, но в текущих реалиях рынок джунов просто переполнен, и оплата не столь высокая, если вы хотите только этим заниматься. Зачастую хорошим стартапам, проектам сейчас нужно, чтобы тестировщик играл проактивную роль в построении процесса, поскольку они сами развиваются, и скорее на работу возьмут того, кто сможет не только бегать по сценариям, но и помочь скилами и навыками на любых уровнях. Тогда они охотнее уже будут вкладываться в тебя и твое обучение, видя в тебе перспективу. Ведь все компании смотрят в будущее. Отсюда вопрос: если ты тоже хочешь развиваться, то что еще умеешь, в какую сторону смотришь и какие навыки есть?
А если компания имеет устоявшиеся процессы, веб, то она тем более уже покрывает большую часть автотестами. Поэтому, да, жизнь джунов не так легка, как её разукрашивает менеджмент. Есть очень большая конкуренция. Поэтому считаю правильнее сразу говорить о том, что работа тестировщика может быть разной и более сложной, и оплата будет соответствовать вашим навыкам.
Спасибо за интересный отзыв. Безусловно, вы правы. Для джунов не всегда необходимо знание кода (просто хотя бы примерное понимание) и автоматизация. Всё зависит от проекта. Однако, я попытался включить в гайд идею того, какой путь можно пройти и на что обратить внимание, чтобы прогрессировать дальше и становиться, например, мидлами.
Думаю, людям, не разбирающимся в тестировании, могло бы быть интересно увидеть общую картину и какие могут быть пути развития и прогресса, например, в автоматизацию.
Приветствую. Картинки действительно генерировались с помощью Midjourney для атмосферности, а все описание и структура из собственного опыта и практики работы. Хорошего вам дня :)