Что такое разработчик в тесте? [закрыто]

Недавно я разговаривал с рекрутером, который хочет пригласить меня в компанию на должность разработчика в тесте. По сути, он заставил это звучать как положение, когда вы начинаете играть с новыми методами программирования, тестировать ошибки и усовершенствования программного обеспечения, но вам не нужно беспокоиться о стандартных сроках. Вы можете быть очень творческими в своей работе.

Но это описание было все еще немного неопределенным для меня. Я работаю веб-разработчиком уже несколько лет, в основном работаю на PHP. Поэтому я хотел знать, знают ли другие члены сообщества о том, что обычно подразумевают эти должности.

Я знаю, что это не может быть темой, подходящей для этого форума, но это была лучшая подгонка, которую я мог найти среди Stack Exchange, и я был бы очень признателен, если бы этот вопрос не был закрыт, поскольку здесь действительно нет места, где можно спросить об этом. ,

Я пытался найти его в Google, но там не так много информации. Так что же такое разработчик в тесте?

Я являюсь инженером по разработке программного обеспечения в тестировании и работаю в двух разных компаниях. В настоящее время я работаю в Microsoft.

Вообще говоря, Брайан Оукли прав: вы пишете программное обеспечение, которое тестирует программное обеспечение.

Кроме того, это зависит от вашего уровня опыта, объема ваших обязанностей и типа программного обеспечения, которое будет производить работодатель. Позиция SDET может включать в себя написание чего угодно - от основ проверочных тестов на уровне возможностей до написания и поддержки тестовой инфраструктуры для выполнения этих тестов. Также нередко бывает, что SDETS специализируются на целенаправленном тестировании для определенных типов требований (тестирование безопасности, производительности / масштаба, удобства использования и т. Д. - примеры, которые сразу приходят на ум).

Описание, которое вы получили от рекрутера, звучит как техника плохой продажи.

• Вы не возитесь; у вас есть n дней, чтобы получить автоматическое тестовое покрытие по x функциям, развернутым в y различных поддерживаемых средах на z языках.
• О, кстати: эти тесты должны выполняться достаточно быстро, чтобы разработчики имели быстрый цикл разработки / тестирования, потому что ...
• Нет стандартных сроков? Вы отвечаете за качество продукта, а дата выпуска была назначена маркетингом 6 месяцев назад. Команда разработчиков опоздала на 6 недель, выполнив стабильную сборку для вашей команды тестирования, и компания не собирается сдвигать эту дату выпуска (снова). Является ли продукт или услуга достаточно стабильной, чтобы выпустить пару миллионов (миллиардов?) Человек в один и тот же день?
• ... и если ( когда ) клиенты звонят с проблемами ... "Почему (черт возьми) ты не поймал это первым?"

Я надеюсь, что это даст вам пример того, что такое SDET.

«Разработчик в тесте» обычно означает, что вы работаете в отделе контроля качества или выполняете роль QA, но основное внимание уделяется написанию автоматических тестов, а не созданию и запуску тестовых случаев вручную. Дело в том, что написание программного обеспечения для тестирования программного обеспечения. Это может быть особенно сложный выбор профессии, поскольку он требует как навыков программирования, так и хорошего понимания тестирования программного обеспечения.

Однако разные названия означают разные вещи для разных компаний, поэтому окончательный ответ должен исходить от рекрутера.

Роль SDET - это почти то, что вы делаете, о чем свидетельствуют все ее разные названия: QA / Developer, QA Engineer, Automation Developer. Моя нынешняя должность на самом деле - «Инженер-тестировщик», которую я никогда не слышал, чтобы она называлась до начала этой работы. Независимо от конкретного названия, это новая позиция в большинстве компаний, поэтому ожидания могут быть бесполезными. «Помогите нам автоматизировать наше тестирование и прочее ...». Это могут быть инструменты CI, тестирование API, облачные сервисы, интеграция с внутренними системами и т. Д.

Другим аспектом работы, которого я не вижу в этой теме, является улучшение процесса. SDET обычно проводят QA некоторое время, и опять же, как правило, они более технические, чем остальная команда QA, включая их менеджера. Они много знают о тестируемой системе, т. Е. «Где похоронены тела». По этим причинам руководство SDET, как правило, слушает SDET и может оказать большое влияние на процесс - не только на процесс тестирования, но и на способ создания продукта. Что может быть круто, если вы в это.