Я случайно познакомился с системным администратором, и, по его словам, ребятам-тестировщикам не дают предпочтений в организации по сравнению с разработчиками. Без сомнения, выпуски программного обеспечения невозможны без тестеров, но я никогда не брал свои руки на тестирование, так что не слишком осведомлен об этом. Без обид.
Ответы:
По моему опыту, к сожалению, к ним часто относятся как к сотрудникам второго сорта, и, что еще хуже, это легкомысленная привилегия для программистов.
Это связано с рядом вещей:
Когда тестировщики делают свою работу правильно, всем легко, но программисты забывают, что они вообще существуют. Подобно сетевому администратору, вы замечаете их только тогда, когда они не выполняют свою работу или выполняют их плохо. Таким образом, с точки зрения остальной части организации, они помнят только за свои ошибки.
Это ошибочно считается работой начального уровня для людей, которые стремятся быть программистами, но еще не имеют квалификации для этих работ. Фактически, в одной компании, в которой я работал, им дали должности младшего программиста, несмотря на их просьбы получить должность Q & A. Даже того факта, что они работали в отделе контроля качества, было недостаточно, чтобы заставить HR уйти в отставку.
Из-за # 2 предполагается, что все тестировщики - люди начального уровня, и им следует платить соответственно.
Никто не любит, когда его критикуют, а защитники-программисты слишком часто не любят тестеров, потому что их работа требует, чтобы они целый день указывали на ошибки программиста. Как менеджер, я постоянно был на миссии по связям с общественностью, чтобы напомнить программистам, что команда QA была там, чтобы заставить их хорошо выглядеть, а не рассказывать.
Как правило, это работа, на которую люди попадают случайно, а не по выбору, по крайней мере на начальном этапе. Я не помню ни одного учебного плана в школах, где я учился, чтобы подготовить людей к вопросам и ответам на программы. Они существуют, но, как правило, в начальных профессиональных школах, что только способствует предположению, что они являются менее квалифицированными специалистами.
Задания на тестирование гораздо чаще, чем задания на программирование, отправляются за границу. По крайней мере, программисты могут утверждать, что более эффективно сообщать о потребностях проектирования локально и что важно знать, как работает ведущее приложение компании внутри компании. Тем не менее, тестирование намного проще для модульности и, следовательно, проще для аутсорсинга.
По всем вышеперечисленным причинам тестировщики, как правило, видят надписи на стене и переходят к другим работам (например, программированию), особенно к действительно хорошим. Это означает, что большинство тестовых заданий, как правило, укомплектовано большим количеством людей начального уровня, которые еще не сгорели на нем или занялись другими делами, что, к сожалению, подкрепляет некоторые из вышеперечисленных идей.
Это зависит от компании, но обычно. Их часто рассматривают как граждан второго сорта, а во многих компаниях тестирование рассматривается как позиция начального уровня, с которой вы бы затем стали настоящим разработчиком.
Это, конечно, дерьмо. Поработав с некоторыми хорошими тестерами, я могу сказать, что они и ценны, и их трудно найти. Кто-то с умом, который достаточно креативен, чтобы находить неочевидные ошибки, и достаточно методичен, чтобы выполнять основательную работу.
Однако есть одно исключение: я знал нескольких тестировщиков Microsoft и слышал, что там есть первоклассные граждане.
Я работал функциональным тестером в течение года над довольно крупным проектом. В каждой команде из 10 человек было по 2-3 человека. Надо сказать, что к нам относились так же важно, как к разработчикам.
Поиск ошибок не легок. Во-первых, тестеры должны понимать, что должен делать код. Это означает чтение и понимание требований. Ключевым моментом здесь является понимание требований - если тестировщики не могут понять требования достаточно хорошо, чтобы знать, как писать положительные тестовые примеры, вы должны быть обеспокоены. Это означает, что разработчики написали некоторый код, который делает то, что они предполагали. Это предположение правильно? Вы не знаете, пока не разобрались с требованиями, и можете поблагодарить своих тестировщиков за обнаружение этого недостатка.
Во-вторых, тестеры должны писать ложные тестовые случаи, которые гарантируют, что код не выполняет то, что он не должен делать. Разумное правило заключается в том, что вы пишете 5-10 ложных тестовых случаев для каждого положительного теста. Это означает понимание требований еще дальше, и часто этоинформация является или была, по крайней мере, в нашем проекте, запутанной и неоднозначной. (И это было не из-за низких усилий по сбору требований - в нашей команде было около 13 000 человек). Опять же, разработчики будут писать свой код, используя свои предположения, или, что еще хуже, даже не рассматривая это вообще. Так что же делает код в этих условиях, которые не являются нормальными? Вы не знаете, пока не проверили это. Может быть, программа не отвечает; может быть, он просто падает; возможно это уничтожает данные; возможно, это позволяет пользователю запускать команды от имени пользователя root. Что бы это ни делало, ты хочешь знать. В противном случае вы можете однажды прочесть следующий заголовок в газете - БАГ В ПРОГРАММЕ ФЛАГМЕННОГО ХАРАКТЕРА [ИМЯ КОМПАНИИ] УТВЕРЖДАЕТ НОМЕРА КРЕДИТНЫХ КАРТ КЛИЕНТОВ.
Так что относитесь к своим тестерам хорошо. Относись к ним хорошо. В конце концов, именно они устраняют ошибки в вашем программном обеспечении и облегчают вашу и нашу жизнь.
Хорошие тестировщики, которые могут эффективно анализировать проблемы и выполнять приличную автоматизацию тестирования, стоят на вес золота, так как есть очень много ковбойских тестеров (когда они берут интервью у одного «тестера», однажды он действительно рассмеялся, осознав, что мы знали, что он делает на месте, пока его проверяют в его резюме).
В моей команде тестер рассматривается как равный, что включает в себя ответственность и зарплату. Если вам нужен тестер, который нажимает на следующий день в течение всего дня - перенесите его в другое место где-нибудь дешево (мы тоже так делаем)
Обновление после прочтения других ответов: Есть много специалистов по обеспечению качества, которые любят работу, которую они делают. Просто чтобы дать другую перспективу, если вы не сталкивались с какими-либо уважаемыми позициями QA, вот один пример: тестирование встроенных приложений / мобильных приложений для ведущих автопроизводителей. Они гарантируют, что бизнес-требования полностью удовлетворены до того, как автомобиль будет выпущен на рынок, и ни один пользователь не увидит медленную или не реагирующую приборную панель автомобиля. Они тесно сотрудничают с менеджерами и руководителями более высокого уровня, а также с разработчиками, начиная с планирования процесса обеспечения качества и заканчивая практическим тестированием на симуляторах на объекте проектирования. Я не могу думать о них как о низком профиле, они несут огромные обязанности и собственность, и они являются одними из лучших инженеров.
Теперь мой предыдущий ответ, оборотная сторона:
Я заметил, что выпускники инженерных специальностей ненавидят выделяться для тестирующих подразделений (контекст: Индия, крупные фирмы, занимающиеся разработкой программного обеспечения, где все обусловлено «требованиями бизнеса»), поскольку они считают это нетехнической рабочей средой. Им дают листы Excel с инструкциями, такими как «нажмите на все ссылки на веб-странице и проверьте», они вынуждены работать с выпускниками нетехнических потоков (наука, искусство), которые они считают унижением, и чувствуют, что их технические навыки не используется. Эти ассигнования основаны исключительно на требованиях организации, и более свежая, в большинстве случаев, не имеет возможности договориться о своей карьере. Поэтому, если вы ищите работу, стремясь к такой крупной ИТ-компании, вас предупредили. Вы практически ничего не можете сделать, кроме как выйти из компании в нужное время.
Если нет возможности освоить автоматизированное тестирование, нагрузочное тестирование и тестирование производительности и т. Д., Карьера в некоторой степени остается на прежнем уровне. Лично я знаю, что возможности для локальных заданий (= куча денег с точки зрения оффшорного программиста) больше подходят для тестирования юнитов в моя организация, чем любая другая единица. Они работают со всеми отраслевыми вертикалями в качестве наполнителя или клея, поскольку тестирование неизбежно в проектах во всех областях.
Если вы уверены, что сможете вести свою карьеру так, как вам хочется, тестирование не является чем-то скромным. Имея 4-5 лет опыта и небольшую удачу, вы можете получить очень хорошее представление, иногда взаимодействуя с бизнес-пользователями высшего уровня. Вы также можете хорошо понять отрасль / домен, в котором вы работаете (по сравнению с разработчиком, который в основном сосредоточился бы на каком-то фрагменте системы). В этот момент можно также перейти на роль бизнес-аналитика.
Я знаю компании, где команда QA отвечает за релизы. Это означает, что они могут блокировать выпуск из-за нехватки качества. Если о проблеме сообщают в области, они являются первыми в линии огня (хорошо сразу после полевого инженера).
Как правило, они имеют более высокую область знаний. Они, как правило, лучше знают общую функциональность продукта, в то время как разработчики концентрируются на своих модулях / функциях.
Также я знаю организации QA, где им приходится писать свои собственные инструменты тестирования. Не говоря уже об автоматизации всего этого. Я разработчик и всегда ценил тех, кто проверяет мои возможности.
По крайней мере, в моей организации QA одинаково относятся к разработчикам. Я думаю, что это из-за области (телекоммуникации), где знания протокола и сетевой архитектуры одинаково ценятся с навыками программирования.
Да. Нравится вам это или нет, они одинаково важны, но всегда менее предпочтительны. Может быть потому, что их легко заменить.