- PVSM.RU - https://www.pvsm.ru -

Я Software Engineer in Test (SET). Многие не совсем понимают, что это значит. Разработчики часто называют меня «тестировщиком» или «QA», а бывший директор однажды подумал, что я занимаюсь DevOps. Хотя моя работа и охватывает данные области, они не являются моим основным направлением занятости. Давайте я постараюсь прояснить, что значит быть SET.
Software Engineer in Test (ака Software Development Engineer in Test, SDET) — это разработчик, который занимается разработкой софта для тестирования: инструменты, фреймворки, автоматизированные тесты [1]. SET-ы главным образом фокусируются на автоматизации, чтобы запускать тесты быстро и с возможностью повторов. Автоматизированные тесты [2] это тоже программный продукт: точно так же, как фронтенд-разработчики программируют веб-страницы, а бэкенд-разработчики пишут код для микросервисов, SET-ы пишут автоматизированные тесты, для чего применяются те же практики и навыки написания кода. Я часто говорю, что у Software Engineer in Test сердце разработчика.
Нет. Никогда не говорите подобного SET. Автоматизация тестирования включает гораздо больше, чем просто «написание скриптов для тестирования». Серьезные решения касательно тестирования требуют серьезной разработки и усилий. Высокоуровневая автоматизация тест-кейсов это обычно только небольшая часть всего. SET-ы ответственны за:
Взаимодействие с разработчиками и владельцами продукта:
— участие в планировании и реализации
— ревью продуктового кода
— формулировка тестовых сценариев.
Разработка фреймворков автоматизации тестирования.
Автоматизация тестовых сценариев [3] с использованием фреймворков.
Использование шаблонов проектирования, где это возможно.
Настройка инфраструктуры для запуска тестов:
— Запуск тестов на CI/CD [4].
— Запуск параллельных [5] тестов.
— Запуск тестов с подходящими тестовыми данными [6].
Настройка дашбордов для предоставления отчетности по результатам тестов в режиме реального времени.
Обучение других лучшим практикам тестирования и обеспечения качества.
Разработка вспомогательных инструментов для ручного и исследовательского тестирования.
Говоря о том, что тестирование это «всего лишь написание скриптов», мы умаляем роль SET и недооцениваем объем работ.
Роли «тестировщик» и QA существовали десятилетиями, но роль SET впервые была обозначена в 2000-х, когда стала необходимой и возможной крупномасштабная автоматизация тестирования. Как указано в Википедии, название роли “Software Developer Engineer in Test” (SDET) ввел Microsoft в 2005, и другие IT-компании, например Amazon and Apple быстро подхватили этот термин. Google же использовал для этой же роли термин Software Engineer in Test. Лично я предпочитаю говорить SET просто потому, что оно более лаконичное.
По моему мнению, роль SET заметно отличается от традиционной роли QA или тестировщика. Тестировщики исторически фокусируются на ручном тестировании и поэтому им не требуются сильные навыки программирования. Их сильными сторонами всегда были знание предметной области, интуиция, нестандартное , навыки планирования тестирования и настройки системы тестирования. И это все безусловно важные, незаменимые навыки. В это время SET-ы живут одновременно в мире как тестирования, так и разработки. Они используют навыки разработчика, чтобы поставить программные решения для проблем тестирования. Для роли SET гораздо более важна автоматизация. В наши дни большинство вакансий, связанных с тестированием, предполагают роль SET; ручные тестовые роли в значительной степени устарели. Тем не менее, потребность в ручном тестировании будет всегда, потому что есть такие проблемы, которые самому человеку обнаружить гораздо легче, чем с помощью скрипта (или интеллектуального агента).
Лично я избегаю использования названий QA и «тестировщик» в отношении себя, поскольку они не в полной мере описывают всё то, чем я занимаюсь. Я также избегаю названия «инженер по автоматизации», поскольку, опять же, оно не включает в себя все задачи, с которыми я имею дело. Я занимаюсь тестированием программного обеспечения как разработчик и поставляю решения для автоматизации с нуля. Я горжусь тем, что являюсь разработчиком, специализирующимся на тестировании.
Всех желающих приглашаем на открытое занятие «Теория тестирования. Виды тестирования». На этом уроке мы поговорим о различных видах тестирования. Научимся отличать черные коробки от белых, регрессионное тестирование от дымового. Регистрация здесь. [8]
Автор:
rikki_tikki
Источник [9]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/qa/372704
Ссылки в тексте:
[1] автоматизированные тесты: https://testproject.io/
[2] Автоматизированные тесты: https://blog.testproject.io/2018/09/18/your-test-automation-framework-needs-testing-too/
[3] Автоматизация тестовых сценариев: https://blog.testproject.io/2018/10/30/dont-be-scared-use-a-sandbox-to-help-jump-start-your-automation-skills/
[4] CI/CD: https://blog.testproject.io/2017/05/11/jenkins-ci/
[5] параллельных: https://automationpanda.com/2018/01/21/to-infinity-and-beyond-a-guide-to-parallel-testing/
[6] тестовыми данными: https://automationpanda.com/2017/08/05/handling-test-data-in-bdd/
[7] мышление: http://www.braintools.ru
[8] здесь.: https://otus.pw/XmT9/
[9] Источник: https://habr.com/ru/post/654507/?utm_source=habrahabr&utm_medium=rss&utm_campaign=654507
Нажмите здесь для печати.