Comments 26
>Стать QA инженером в 2024 году и начать зарабатывать первые деньги
...легко, для начала надо перестать читать статьи со сгенерированными текстом и картинками
В целом статья неплохая, но есть недочёты с моей т.з.:
1)Мне кажется, для новичка нагрузочное тестирование уже излишне. Обычно новички начинают с функционаьного. тестирования
2) автоматизация под вопросом (если речь не идёт о человеке, который сразу хочет в чистую автоматизацию). Обычно начинают всё-таки с ручного ибо без навыков тест-дизайна ни одна автоматизация не спасёт
3) Язык программирования хороший навык, но далеко не везде будет нужен глубинный анализ кода. Чаще речь идёт о черно-сером ящике.
Несомненно, требования к новичкам сейчас растут, но я бы посоветовала в первую очередь налегать на те области, в которые собираешься пойти.
Спасибо за интересный отзыв. Безусловно, вы правы. Для джунов не всегда необходимо знание кода (просто хотя бы примерное понимание) и автоматизация. Всё зависит от проекта. Однако, я попытался включить в гайд идею того, какой путь можно пройти и на что обратить внимание, чтобы прогрессировать дальше и становиться, например, мидлами.
Думаю, людям, не разбирающимся в тестировании, могло бы быть интересно увидеть общую картину и какие могут быть пути развития и прогресса, например, в автоматизацию.
Могу сказать как человек, который прошел курс, где все это было (Привет, Нетология!) и могу сказать, что от изучения того, чем явно не собираешься заниматься в ближайшее время больше вреда чем пользы. Например, я совсем не помню как проводится нагрузочное тестирование, которому был посвящен целый модуль. Я помню основные принципы, немного знаю JMeter, но более глубокими познаниями не владею. Но время я на этот модуль потратила довольно много и, честно, уже 100 раз пожалела, что взяла именно большой курс.
Конечно, по верхам можно познакомиться с основными принципами, чтобы понимать куда хочется расти, но время, однозначно, стоит в первую очередь уделять приоритетному направлению, а остальным уже по остаточному принципу (для общего развития).
Тоже наслышан не с лучшей стороны про Нетологию, что, якобы, они затягивают лекции и льют много воды. Жаль, что с ними у вас так вышло.
Кроме JMeter, есть еще Gatling, Locust и облачные платформы Loader.io, Flood.io, BlazeMeter. Но на практике сталкиваюсь, в основном, с использованием JMeter для серверной части, Selenium для браузеров и JMH для Java.
Сами лекции в большинстве своем неплохие, но т.к. я не разбираюсь в этом решила взять побольше курс. Сейчас понимаю, что вторая часть курса мне особо не нужна была - лучше бы короткий курс взяла. В длинном единственная ценная для меня часть - лекции по мобильному тестированию, особенно то, что касалось ручного. Ту же безопасность тоже читали неплохо, но маловато как по мне для полноценного обучения.
Сколько времени понадобится, если качественно выполнить все пункты статьи?
Про то, что тестирование не проще программирования вы описали неплохо. С другой стороны, в ИТ рвутся через тестирование т.к. возникает ощущение, а при правильном менеджменте оно так и будет, что начать будет проще. Условная ручная проверка по сценариям, написанным кем-то, тоже тестирование. Другое дело - это не совсем про работу тестировщика в широком его понимании. Что думаете об этом?
Согласен. Ручная проверка по сценариям - это тоже вид тестирования, но в текущих реалиях рынок джунов просто переполнен, и оплата не столь высокая, если вы хотите только этим заниматься. Зачастую хорошим стартапам, проектам сейчас нужно, чтобы тестировщик играл проактивную роль в построении процесса, поскольку они сами развиваются, и скорее на работу возьмут того, кто сможет не только бегать по сценариям, но и помочь скилами и навыками на любых уровнях. Тогда они охотнее уже будут вкладываться в тебя и твое обучение, видя в тебе перспективу. Ведь все компании смотрят в будущее. Отсюда вопрос: если ты тоже хочешь развиваться, то что еще умеешь, в какую сторону смотришь и какие навыки есть?
А если компания имеет устоявшиеся процессы, веб, то она тем более уже покрывает большую часть автотестами. Поэтому, да, жизнь джунов не так легка, как её разукрашивает менеджмент. Есть очень большая конкуренция. Поэтому считаю правильнее сразу говорить о том, что работа тестировщика может быть разной и более сложной, и оплата будет соответствовать вашим навыкам.
Тестировщики, которые только идут по написанным сценариям вряд ли найдут работу. Даже от стажера ожидают, что он в состоянии хотя бы написать простенький сценарий.
Мне очень понравилась ваша статья. Обязательно ее порекомендую для прочтения коллегам и своим менти.
+1 карма!
Хорошая статья, быть может поможет какому-нибудь молодому qa понимать, что "да что это ваше qa, кнопочки тыкать" от самодовольного прогера, сильно много смысла не имеет
Абстрактность тестирования: в отличие от программирования, где существуют конкретные задачи и цели, тестирование зачастую требует абстрактного мышления. Необходимо создавать тестовые случаи, которые покрывают различные аспекты функциональности программы, а также предвидеть возможные ошибки, которые могут возникнуть.
Но чучуть перемешалось. Абстрактное мышление все таки умение переносить реальные ситуации в абстрактные понятия, и работать с их свойствами, чтобы потом повлиять обратно на реальность. А умение QA выдумать необычный случай, который ещё и разрабы не предусмотрели, идёт скорее от насмотренности (вспомнить что условный Вася постоянно оставляет микронеточности с дизайном, знать что в условном Андроиде надо пробовать экран переворачивать, и смотреть, остался ли он в старом состоянии), и креативности, чтобы какой-то хитрый кейс выдумать.
Само понятие абстрактное мышление просто чуть людей пугает, особенно после школьной математики, знания в которой часто люди связывают с абстрактным мышлением, и которая много у кого вызывала сложности
Очень ободряющий пост, спасибо)
Сам окончил курсы и в поисках работы уже достаточно продолжительное время, после стандартных отказов на хх, уже руки опускаются.
Тем временем читаю посты, смотрю тестеров в ютую, читаю книги, что бы на этом тернистом пути поиска работы(стажировки), знания не улетучились. Только благодаря постам с хабр, руки не опускаю)
Спасибо за статью, я всегда люблю, когда рассказывают про тестирование и про то, что сама позиция гораздо сложнее, чем кажется на первый взгляд. Но тем не менее хочется обратить внимание на несколько пунктов, чтобы не сбивать лишний раз людей.
Ответственность за качество: тестировщики несут ответственность за обнаружение всех возможных ошибок в программном обеспечении, что требует высокой степени внимательности и детализации.
Вот тут я вас поправлю.
Во-первых, тестировщики не несут ответственность за обнаружение всех возможных ошибок. Цель тестирования - не искать ошибки, цель - обеспечивать высокий уровень качества продукта согласно определенным критериям. Искать баги - один из способов достижения этой цели.
Во-вторых. Есть такой хороший вопрос на собеседовании, который мне задавали не раз. Он звучит так: "Кто отвечает за качество продукта?" Правильный ответ: "Все". Все, включая программистов, должны отвечать за качество продукта. Я тут тоже не буду расписывать долго, но плохи те процессы, если программист просто резолвит задачу без своих проверок. А еще программисты пишут юнит тесты.
Технологии и методы тестирования постоянно развиваются
Могу я попросить вас привести пример, как за последние пару лет развились технологии и методы тестирования? Я бы просто не отделял тестирование от общих тенденций, которые касаются всего IT. Технологии и методы программирования так же развиваются и похлеще тестирования.
Ведь, как говорится, страшно или тяжело - в обучении, а на реальной работе, в бою будет легко
Нет, не будет. Учить проще. Проблема в том, что люди начитаются теории, а потом не могут адаптироваться к процессам на работе и их увольняют. На реальной работе, особенно в первые месяцы онбординга намного сложнее.
Знание методологий тестирования: Понимание основных методологий тестирования, таких как Waterfall, Agile, Scrum, и их применение в работе.
Это не методологии тестирования, это методологии всей разработки продукта.
В остальном, я бы оставил в статье поменьше теории, она уже есть и на хабре и много где, да и структурирована более правильней, в особенности вон пункты про типы тестирования, у них к слову есть определенная правильная типизация, не надо их все мешать в одну кучу. Про инструменты еще. Тут в целом надо добавить не обязательно изучать все, надо читать только о том, что может пригодится для конкретной позиции и конкретного проекта. А еще у вас в современных инструментах тестирования Robot Framework, которому 16 лет уже) И я не уверен, что кто-то вообще использует половину из написанного в современных инструментах. А еще есть Android Studio, но нет XCode. И где Docker?) Ладно, тут можно много еще полезного придумать.
Спасибо за интересную обратную связь.
Касательно типизации: если бы вы чуть внимательнее прочитали, я использую формулировку: "ЭТО ЛИШЬ НЕСКОЛЬКО ТИПОВ". Существует множество других подходов и методов. Я думаю, вы понимаете, что все зависит от конкретного проекта, и не везде всё применимо. Спасибо за уточнение про Docker, думаю, его тоже действительно стоило включить в статью, но он не является панацеей. Robot Framework, старый инструмент, но многие современные потребности и задачи он покрывает, у него есть свои плюсы и минусы, как и у всех.
Никто не будет спорить с тем, что Agile — это методология разработки программного обеспечения. Просто если мы смотрим на вопрос с функциональной точки зрения, например, для менеджера Agile будет методологией управления проектом, для тестировщика — в том числе методологией тестирования (ведь именно этим он и занимается), для аналитика и разраба - другое, но все вместе они работают по Agile. Гайд написан именно для тестировщика, поэтому использована такая терминология. Возможно, кому-то это будет проще для понимания.
Касательно того, что на реальном проекте не будет легко и ответственности для тестировщика. В большинстве случаев, скорее да. Будет сложно и многое непонятно. Но давайте не будем столь узки в своем видении. Для кого-то будет легко, а кто-то еще и оптимизирует что-то с ходу и внесет изменения. Мы же с вами не можем знать и тыкать пальцем в небо, говоря за всех, у кого какие проекты. Все зависит от конкретной ситуации.
За качество продукта отвечают действительно все, и то, что все виноваты, это и так понятно. Но на этапе обучения мне кажется важным донести до тестировщика его вклад в проект, что от него многое зависит, что сподвигнет его на дальнейшее развитие! Это важно для ребят, которые только вливаются. Когда баг в проде, я не имею в виду, что нужно агриться на тестировщика. Есть кейсы, которые тестировщик не может проверить, и для этого, в том числе, пишутся юнит-тесты. Нужно обсуждать все это в команде и пытаться понять, почему это произошло, и как этого не повторить. Но иногда это зависит от уровня скилла тестировщика. Главное не уходить в крайности с такой позицией, что все виноваты. "А я то что, все виноваты" особенно для начинающих тестировщиков это может быть краеугольным камнем для успешности проекта, а у меня гайд именно для ребят которые только хотят влиться в эту профессию или хотят побольше узнать о ней.
Касательно типизации: если бы вы чуть внимательнее прочитали, я использую формулировку: "ЭТО ЛИШЬ НЕСКОЛЬКО ТИПОВ".
Я очень не хотел писать подробнее, потому что я очень не люблю углубляться в теорию, но видимо придется, чтобы люди не путались. Потому что этот вопрос задают на собеседовании и на нем же его заваливают. Основные типы тестирования можно классифицировать по различным критериям, в зависимости от цели тестирования, объекта тестирования, стадии разработки и так далее.
Например, по методу проверки его разделяют на функциональное и нефункциональное тестирование. В нефункциональное входят нагрузочное тестирование, тестирование производительности, совместимости, безопасности, надежности и т.д.
По уровню абстракции оно уже распределяется на модульное тестирование, интеграционное тестирование, системное тестирование и приемочное тестирование.
По цели тестирования: позитивное тестирование, негативное тестирование, регрессионное тестирование, автоматизированное тестирование и ручное тестирование.
Есть еще классификации. И да, это очень важно, нельзя просто взять и начать рассказывать все типы тестирования, что вы знаете в любом порядке. Важно понимать эти классификации и распределение. Вы же просто указали часть типов тестирования в список без распределения по классификации (я выделил ваши пункты болдом). Так делать нельзя, это может еще больше запутать людей.
Никто не будет спорить с тем, что Agile — это методология разработки программного обеспечения. Просто если мы смотрим на вопрос с функциональной точки зрения, например, для менеджера Agile будет методологией управления проектом, для тестировщика — в том числе методологией тестирования (ведь именно этим он и занимается), для аналитика и разраба - другое, но все вместе они работают по Agile.
Нет, снова запутаете начинающих тестировщиков. У Agile есть вполне очевидный жизненный цикл: Plan -> Design -> Develop -> Test -> Deploy -> Review -> Launch. Это цикл разработки программного обеспечения. Тестирование - только часть этого процесса. Да, я не сбуду спорить, что тестировщик начинает свою работу гораздо раньше, еще на этапе построения дизайна (это тоже спрашивают на собеседовании), для понимания основных требований, это уже другой вопрос. Но это методология разработки, не надо называть её методологией тестирования. Начинающий тестировщик должен понимать общий процесс разработки и свою роль в нем.
и то, что все виноваты, это и так понятно.
Я такого не говорил) Я рассказал, что все отвечают на проекте за качество продукта, вы же делаете свои выводы) Я же говорил, что каждый в своей мере отвечает за свой компонент и за свою область и так же контролирует его качество.
"А я то что, все виноваты" особенно для начинающих тестировщиков это может быть краеугольным камнем для успешности проекта
Это опять же неправильный вывод) Не выдумывайте)
Спасибо вам, очень вдохновляющая и поддерживающая статья, на начальном этапе это необходимо. Отдельный интерес вызывает читать баталии автора и комментаторов))). Думаю, как обычно, истина где-то посередине.
Стать QA инженером в 2024 году и начать зарабатывать первые деньги?