Pull to refresh

Comments 12

UFO just landed and posted this here
Поднабраться опыта, развить менеджмент и тест-дизайн и вот у тебя уже сопоставимая с гипотетическим джуном зп.
Тестировщику не нужно учить алгоритмы, кучу фреймворков языка, много SQL, паттерны — джуну нужно.
UFO just landed and posted this here
Проблема может быть не только и не столько в коде. Тестировщик может быть хорошим, и может указать место в коде, где проблема. Может писать автотесты, писать инструменты для тестов, хэлперы, разворачиватели баз всякие. И при этом не знать тех вещей, которые обязан знать даже джун. Рано или поздно, если такой тестер развивается — он становится разработчиком в тестировании (STED), про отличия деятельности такого человека от разработчика хорошо написано в статье habr.com/ru/post/414563
Основное мое предположение в том что отличие высококвалифицированного QA (с программированием, преферансом и аналитикой) и высококвалифицированного разработчика именно в работе мозга. И полагаю платят вторым больше еще и потому что изначальная цель — создать продукт, который можно продать. И его влияние на результат определяется явно. А влияние тестировщика на результат определяется неявно, поэтому больше вопросов типа «за что платить человеку, который ничего не создает». Конечно за десятилетия разработки компании уже перешли от всяких waterfall к agile и scrum и QA стали задействовать на гораздо более ранних стадиях и более вовлеченно в проекции на весь цикл работы продукта. Но инерция изначального восприятия профессии и мысли типа «любой может стать тестером, легкий путь вайти в IT» все еще делают свое дело.
по факту, хороший тестировщик сможет указать конкретное место в коде, где проблема.

Чувак, который может спокойно указать конкретное проблемное место в коде — это не просто хороший тестировщик, это судя по всему человек, который имеет представление о том, как работает «черный ящик», который он тестирует. Причем знает настолько подробно, что сходу определяет проблемное место.
Вопрос к знатокам: почему он до сих пор в должности тестеровщика, а не разработчика?
Впору вводить термин для описания дискриминации по роли (тестирование vs разработка), какой-нибудь ролизм. Классика жанра, «раз такой умный, почему в тестировании сидишь?» или все вот эти ребята, приходящие на собесы в джуны-тестеров с целью «войти в айти и переметнуться в разрабы». Понятно от куда ноги растут, тестирование как деятельность сильно дискредитирована джуно-обезъянским подходом «йа тыкаю кпопки по кейсам». А еще нормальные ребята редко могут хорошо изъясняться (см. Michael Bolton и все что касается проблемы донесения testing stories).

Отвечая собственно на вопрос, лично для меня роль тестировщика видится более разнообразной. Например, тот же код писать никто не запрещает (а бывает даже через чур поощряют, пытаясь свалить все автотесты на тестеров), возможность псевдо-менеджерской деятельности, наставничества, мозголомания в тест-анализе, ну и можно развиваться в ширь и/или специализироваться (например, глубокоуважаемые пенстестеры).
Ruby on Rails не язык программирования, а фреймворк. Вообще как-то все свелось к рекламе…
Как тестировщик, не понимаю смысла этой статьи :)
Что-то в духе: «Чтобы найти работу, нужно что-то знать и иметь какой-то опыт, но вообще не обязательно»
Да, каждый раз открываешь такие статьи с интересом, может чего нового. Ан нет, постоянные эти:
— «нужно быть любознательным и с фантазией» — а разработчику, аналитикам и вообще всем неконвеейрным работникам это не нужно?
— «поучитесь на курсах» — если бы эта статья не была написана организатором курсом, то тут бы был раздел про «почитайте Савина и еще 1-2 книжки на выбор»
— «получите бумажку-сертификат» — хоть бы кто упомянул, что этот самый сертификат вообще-то вещь адски холиварная в современных тестировщиских кругах
Можете, пожалуйста, чуть подробнее о холиварах насчёт ISTQB для новичка?
Как вы подметили, холиварность именно в ценности для новичка. Если постараться подытожить, то можно выделить:
(+) Проще пройти первоначальный тупой фильтр HR по ключевым словам (тут Болтон предлагает хитрость: вставить фразу «У меня нет ISTQB сертификации и я с удовольствием объясню почему.»)
(+) В некоторых регионах действительно сложно найти самую первую работу не имея этих 5 букв в резюме.
(+) Прочитать сопутствующие материалы и книги будет полезным, хотя бы лишь для того чтобы уменьшить «степень неведения» (order of ignorance).

(-) Сертификация не учит и не показывает наличие у человека практических и реальных навыков. Достаточно проштудировать базу вопросов и зазубрить определения, сдать, да спокойно забыть на следующий день. Для меня это основная причина отказа от этого сертификата, т.к. я начала готовиться и поняла что это абсолютно тоже самое что ЕНТ, по которому у меня таким бредовым макаром вышла пятерка по казахскому.
(-) Силлабус и глоссарий, которые предлагается зазубрить, подаются как «стандарт тестирования» и «лучшие практики», что на деле вызывает вопросы. Например, context-driven подход утверждает, что ценность каждой практики сильно зависит от контекста применения, а следовательно, не может существовать самой-самой лучшей практики и единого стандарта тестирования. Это можно проследить на простейшей проблеме терминологий: можно сколько угодно зубрить термины и определения из глоссария, но когда приходишь на реальный проект, где уже есть тестирование, термины могут разительно отличаться. Это не значит, что их совсем не надо знать, но нужно относиться к ним скептически.
(-) Конкретно эта сертификация продвигается не самыми чистыми методами и во многом цель скорее в выкачивании денег, чем продвижении качественного тестирования. Если выкладывать деньги из собственного кармана, то думаю лучше книжки купить или BBST/RST пройти.

Неплохая ветка, где мусолят эту тему.
Sign up to leave a comment.