Потому что учиться нужно всегда. Работа в командах не панацея. Буквально на последнем проекте. Писали полную дичь, на вопрос почему так? Ответ всегда один - не знаю, я в компании 20 лет, и на всех проектах так делали. Т.е. люди даже не удосужившись почитать рекомендации от создателей фреймворка, а просто использовали подходы 20 летней давности, потому что они как-то работали. Неудобно, сложно, невозможно читать и поддерживать. Но все остальное считалось неправильным, просто потому что было им не знакомо.
Я бы поправил название. Оно слишком громкое. А по факту, применимо исключительно к тестированию веб-приложений. Даже для desktop и mobile не очень подходит. Не говоря уже про более специфичные кейсы вроде embedded, medical, automotive, aircraft, etc. Ещё бы неплохо больше ссылок на источники информации. Например, пирамида тестирования - взята из ISTQB Basic. Если заглянуть в syllabus advanced level. То там уже все ближе к реальности. Пирамида всегда строиться от архитектуры конкретного приложения. Колличество, слоёв между unit и system как раз от архитектуры зависит. У меня бывали проекты когда unit оборачивались в module, module оборачивались в component, component оборачивались в subsystem, а уже subsystem собирались в system. И везде свои протоколы коммуникаций. Также, интересно посмотреть источник по sanity vs regression. У меня отложилось в памяти, что основная разница - это регрессия покрывает старый функционал, не тронутый последней итерацией. Т.е. тесты на писанные ранее. А вот sanity - это как раз тестирование последнего инкремента, а не просто абстрактного функционала. Именно того функционала, что был внесён/изменён в последнем спринте или более долгой итерации.
Крутая подборка фич. У меня только вопрос - есть ли какой-то вменяемый способ дебажить пайплайн в принципе. Ну и особенно со всеми вложениями вроде variables/include/etc? Или я правильно понял, что ничего особенно хорошего для этой проблемы нет?
Что-то вы совсем плохого мнения про этот мир. Ножницы для левшей - сущесвуют, погуглите. Даже продаются в канцеляриях. У меня жена и дочка в семье левши, сломали статистику. Зато удобно было дочку кормить, она себе левой рукой ест на коленях а я правой. Ну и с жена за столом всегда садиться слева, чтобы удобней было.
Играл я в такую экономику. А потом понял, что жизнь имела тебя ввиду со всеми твоими расчетами. Жил я себе, заработал на автомобиль в кредит. Выплатил за год. Женился, появился ребенок. А потом жена заболела через год. И тут тебе приходят и говорят, что чтобы жена имела шанс выжить нужно делать операцию в другой стране, потому что в твоей - не умеют. Нужно на этот шанс 120 тысяч долларов, не считая проживания и лечения до момента операции, так как нужно ещё донора подобрать. Насобирал с помощью родственников, а потом узнал что слава Богу у страны есть программы помощи таким пациентам и да нам повезло, эти деньги клинике перевело государство. Так что свои расходы составили всего тысяч 30. На лечение билеты и другие расходы до операции. Потом купил дом за городом, потому что жене обычной простудой болеть смертельно опасно, а тут привет COVID от которого и спортсмены загибаются. Но тут здравствуйте, сосед решил, что тебя сильно ущемляют и решил освободить. Пришлось бросить дом и валить, пока от тебя и твоей семьи не освободили эту планету. Я сразу знал, что а Европе жизнь ITшника не такая уж и клёвая. Но тут пришлось прочувствовать полностью. Стоимость аренды совсем не та, расходы тоже, а вот net зарплата оказывается поменьше будет. Да и у компании с заказами на фоне войны было все не супер гладко. Пришлось меня уволить. Хорошо, тут повезло, пока меня увольняли нашел другую контору. И ещё слава Европе тут тебя увольняют с нормальными выплатами где-то за полгода зарплаты. Ну вот уволили, но вышел на новую работу через неделю и купил второй автомобиль. Потому что для этой работы нужно было ездит в офис, а ребенка из школы забирать самому не всегда получиться. Работа позже заканчивается. Поработал в новой компании, но у них тоже не все так гладко. Уволили через полтора года, получил ещё раз выплаты. Так что, что я могу сказать. Планы - это все хорошо и весело и строить из нужно. Только вот без плана Б, это все не стоит ничего. Как и недвижимость, которую купил, а теперь пользоваться толком не можешь. Надёжней вкладывать в себя. А то рынок он такой, сегодня IT в топе, а завтра тебя заменили на ИИ.
Из всего перечисленного, одна хорошая новость, менеджеры наконец-то должны обладать техническим бэкграундом, а не просто рассказывать про единорогов. Но по личному опыту пока такого не наблюдаю. Может мне так повезло просто. Ну а вообще хотелось бы на собеседованиях более приближенных к реалиям вопросов. Только пару раз попадались такие в израильских компаниях. То алгоритмы хотят от тестировщика, а потом оказывается что ты их будешь использовать - никогда. Да и вообще, автоматизацией заниматься некогда, потому что мы планировать не умеем и не хотим. То напиши пару фреймворков с нуля, за пару дней под наш стек. Ну да их же по-любому, каждую неделю переписываешь. Да и вообще на поверку в компании уже давно написаны фреймворки и никто тебе их улучшать не даст хоть им уже и 10 лет. Твоё дело заниматься поддержкой.
Хорошая статья. Особенно отлично описаны mock, stub, fake. Сколько видел сломанных копий на эту тему. Для определения require и assert есть установившаяся в тестировании терминология: soft assert - проверяет результат и разрешает продолжение теста, hard assert проверяет результат и останавливает тест в случае фейла.
Да должен. Он не должен это уметь делать. Но знать разницу между двумя словами и разницу в стоимости и применимости для его проекта знать обязан. Контейнеризация дешевле в использовании, как по эксплуатации, так и банально по стоимости у облаков. Но, не все проекты можно делать на ней.
А вот это вообще root cause 90% провалом на проектах. Когда хотят "скраежопить", абсолютно не понимая чем это обернется. Не хотим держать свои сервера, CapEx - зло, переходим на облака, мы любим OpEx. И по налогам приятнее и денег сразу столько не нужно. А потом прибегает менеджер. Ой, что-то там такой счёт выставили из облаков. А давайте не будем сервера держать по выходным. Но отчёты по тестам в понедельник я хочу. А сервера по выходным не включайте. Это вместо того, чтобы настроить нормально автостарт и автостоп для окружений. Но менеджер же не хочет знать. Это же для него технические детали, хотя тут речь про деньги. А так да, мир такой - все что просто, стоит дополнительных расходов. Хочешь сэкономить - придётся освоить довольно сложные схемы и автоматизацию. Если и дорого и слишком сложно, то зачем вообще начинать проект? Можно же совсем ничего не делать.
Вы же сами написали, что DevOps - выделенная команда, а не проектная. У них таких проектов как ваш может быть довольно много. Т.е. они не могут работать в линейной иерархии, как обычный проект. Там просто нет выхода как работать по матрице. А в случае матричной структуры, без тикетов - никак. Вот есть у них, например, 50 проектов. И возможно ваш - далеко не самый приоритетный. Если дать возможность влиять напрямую, то вы его "пропихнете". Именно поэтому, вводится изоляция команды DevOps и тикеты. Только с помощью тикетов и их приоритезации, можно не поехать кукухой в этом хаосе. И да, вам неприятно, ваши личные метрики идут на дно. Но для компании в целом, возможно, это было меньшим злом и выгоднее, возможно были 5 других более важных и денежных проектов, которые взлетели за ваш счёт. Это всё конечно теория и домыслы как должно быть. Конкретный кейс может быть вовсе не таким счастливым.
Позволю себе немножко не согласиться. Поток сознания от PM - это повод найти нормального PM, который общается не потоком сознания, а чем-то более вразумительный и приближенным к делам, компании, продукту и процессу. Поток сознания может выливать только заказчик, который платит деньги. И только это может оправдывать такое поведение. Все остальные в рамках компании - это сотрудники осваивающие деньги клиентов и в идеале приносящие этим самым клиентам пользу. Но вот когда менеджер начинает вести себя как клиент, получая такую же зарплату и не оплачивая труд других из своего кармана. То это просто воровство ресурсов компании временем других сотрудников, которые не обязаны разбирать такие потоки. Для этого и есть менеджер, а если он не может то бизнес-аналитик. Который переводит с потоков на понятный технический язык. Технари должны получить задачу и выполнить ее, а не переводить поток сознания во что-то человеко-разборчивое. Это весьма непростое и стоящее многих нервов занятие.
Я вот работаю с помощью AI и хочу сказать, что год назад он давал более толковые и полезные советы.
Все очень сильно зависит от стека и насколько оно есть в свободном доступе на GitHub. Например, Java Spring или Selenium - без проблем. API все мейнстримные - тоже. Пробовал Robot Franework, всё намного хуже. Какой-нибудь Grafana K6 на JS - вообще прям печаль. А полезешь в эмбедед, так вообще засада полная, он про даташиты и прочие доки на чипы вообще почти ничего не знает. Если только чип старый и полно примеров кода, может что-то вытянуть.
Я вот работал на медицинском проекте. Там внезапно, перед тем как написать хоть строчку кода, нужно пройти пачку тренингов и подписаться, что ты их прошел. Иначе весь проект в топку и "Миша, давай по-новой." Как быть? ИИ подпишется? Ну и это для всего safety critical и military. Разработчик - это не просто кнопки давить, но ещё и "козёл отпущения", в случае чего.
А тут кажется, что у вас с архитектурой беда или с политиками чистого кода. Как девочка залила данные в таблицу, которую нужно было удалить? Что эта таблица вообще делала в мастере? У меня на всех проектах за такое по рукам били, если неиспользуемый код оставался, это просто ревью не могло пройти.
Люто-бешено плюсую. Дошли до стадии. Мне проще самому баги фиксить и комитить, чем девелоперам объяснять и писать трёх страничное описание с картинками, схемами и диаграммами, которые сами девелоперы не осилили.
Я как-то раз решил FreeBSD 9, если не ошибаюсь установить на Pentium MMX 166 MHz. Просто лежал без дела на балконе. Неделю ядро пересобиралось. Но потом зашевелилось даже.
Прекрасная статья, спасибо за неё. Есть рецепт решения ещё одной проблемы? Как поменять команду/компанию, когда она не хочет меняться? У меня сейчас полный день сурка, потому что всем нужно объяснять буквально как дышать. Документацию писать не хотят, потому что - "это невозможно". Правильно выставлять статусы тикетов - "нет, не хочу". Пользоваться версиями - "нет, мне сложно". Любые попытки, сделать что-то правильно, разбиваются о - мне лень это делать, если хочешь можешь сделать это сам за меня. А я буду делать только то что мне интересно.
Я не понимаю, почему в каждой компании хотят переопределить роли. Есть же ISTQB. Который, как минимум описывает роли Tester, Automated Tester, Test Manager. Писать тест план и стратегию - это задача никак не рядового тестировщика. Там слишком много завязок на менеджмент, разработчиков и расписание проекта. Знать которые, вообще не компетенция рядового тестировщика. А когда на проекте тестировщик в единственном экземпляре, я ещё ни разу не видел даже вменяемых требований. А без требований вся тест стратегия и план не имеют смысла. Потому что только отталкиваясь от требований, можно сделать осознанный выбор стека инструментов, языков программирования видов и типов тестирования, тестового окружения и фикстур. Ну и построить traceability matrix. Что до SDET, то SDET как правило не занимается тестами в отличие от Automated Test Engineer. SDET занимается реализацией задач от Test Architect. Прописыванием тест фреймворка его архитектурой, разбивкой на модули, включение зависимостей. Зачастую это выливается в дополнительный уровень абстракции под конкретный продукт. Поверх базовых RestAssured/Selenium/Requests/Appium/RobotFramework etc. Реализацией моков/стабов/симуляторов. DevOps команда прикручивает пайплайны к этому всему, а автоматизаторы прописывают уже сами тест-кейсы со сценариями с или без BDD/DDT. Тогда автоматизаторы просто получают API с CRUD операциями вся логика тестов прописывается на данном уровне абстракции. А там уже легко подменяя более низкоуровневую абстракцию. Одни и те же сценарии можно использовать например как для API тестирования, так и для UI. Это если как оно работает в идеале. Ну а если, где-то начинается экономия, то соответственно пойдут и компромиссы и кому-то придется совмещать роли. Ну и времени и сил прописывать дополнительные слои абстракции - не будет.
Тестировщик - это не совсем часть разработки. Это этап между разработкой и приемной, чтобы сэкономить нервы бизнесу принимающему результат. Если заказчику, внутреннему или внешнему, показать результат первого билда напрямую от разработчиков. То скорее всего у него будет нервный тик и лёгкая паника. А вот если показать 3, 5, 10 после тестировщиков. То шансы на продление контракта и новые заказы вырастут по параболе. А вот QA - это совсем не про разработку. QA ликвидирует баги не только кучей разных методов и методик тестирования. Но он просто уничтожает их пока они даже случились. Благодаря внедрению правильных процессов, улучшению коммуникации, документации, прототипирования ну и CI/CD. До сих пор существуют компании, которые вместо использования Figma, пытаются договориться о дизайне в Excel и на пальцах. Что только делает shift left огромного количества проблем и багов. Которые легко можно было бы обсудить и отстрелить просто сделав адекватные против за пару недель.
Потому что учиться нужно всегда. Работа в командах не панацея. Буквально на последнем проекте. Писали полную дичь, на вопрос почему так? Ответ всегда один - не знаю, я в компании 20 лет, и на всех проектах так делали. Т.е. люди даже не удосужившись почитать рекомендации от создателей фреймворка, а просто использовали подходы 20 летней давности, потому что они как-то работали. Неудобно, сложно, невозможно читать и поддерживать. Но все остальное считалось неправильным, просто потому что было им не знакомо.
Я бы поправил название. Оно слишком громкое. А по факту, применимо исключительно к тестированию веб-приложений. Даже для desktop и mobile не очень подходит. Не говоря уже про более специфичные кейсы вроде embedded, medical, automotive, aircraft, etc.
Ещё бы неплохо больше ссылок на источники информации. Например, пирамида тестирования - взята из ISTQB Basic. Если заглянуть в syllabus advanced level. То там уже все ближе к реальности. Пирамида всегда строиться от архитектуры конкретного приложения. Колличество, слоёв между unit и system как раз от архитектуры зависит. У меня бывали проекты когда unit оборачивались в module, module оборачивались в component, component оборачивались в subsystem, а уже subsystem собирались в system. И везде свои протоколы коммуникаций.
Также, интересно посмотреть источник по sanity vs regression. У меня отложилось в памяти, что основная разница - это регрессия покрывает старый функционал, не тронутый последней итерацией. Т.е. тесты на писанные ранее. А вот sanity - это как раз тестирование последнего инкремента, а не просто абстрактного функционала. Именно того функционала, что был внесён/изменён в последнем спринте или более долгой итерации.
Крутая подборка фич.
У меня только вопрос - есть ли какой-то вменяемый способ дебажить пайплайн в принципе. Ну и особенно со всеми вложениями вроде variables/include/etc? Или я правильно понял, что ничего особенно хорошего для этой проблемы нет?
Что-то вы совсем плохого мнения про этот мир. Ножницы для левшей - сущесвуют, погуглите. Даже продаются в канцеляриях. У меня жена и дочка в семье левши, сломали статистику. Зато удобно было дочку кормить, она себе левой рукой ест на коленях а я правой. Ну и с жена за столом всегда садиться слева, чтобы удобней было.
Играл я в такую экономику. А потом понял, что жизнь имела тебя ввиду со всеми твоими расчетами.
Жил я себе, заработал на автомобиль в кредит. Выплатил за год.
Женился, появился ребенок. А потом жена заболела через год. И тут тебе приходят и говорят, что чтобы жена имела шанс выжить нужно делать операцию в другой стране, потому что в твоей - не умеют. Нужно на этот шанс 120 тысяч долларов, не считая проживания и лечения до момента операции, так как нужно ещё донора подобрать. Насобирал с помощью родственников, а потом узнал что слава Богу у страны есть программы помощи таким пациентам и да нам повезло, эти деньги клинике перевело государство. Так что свои расходы составили всего тысяч 30. На лечение билеты и другие расходы до операции.
Потом купил дом за городом, потому что жене обычной простудой болеть смертельно опасно, а тут привет COVID от которого и спортсмены загибаются.
Но тут здравствуйте, сосед решил, что тебя сильно ущемляют и решил освободить. Пришлось бросить дом и валить, пока от тебя и твоей семьи не освободили эту планету.
Я сразу знал, что а Европе жизнь ITшника не такая уж и клёвая. Но тут пришлось прочувствовать полностью. Стоимость аренды совсем не та, расходы тоже, а вот net зарплата оказывается поменьше будет.
Да и у компании с заказами на фоне войны было все не супер гладко. Пришлось меня уволить. Хорошо, тут повезло, пока меня увольняли нашел другую контору. И ещё слава Европе тут тебя увольняют с нормальными выплатами где-то за полгода зарплаты. Ну вот уволили, но вышел на новую работу через неделю и купил второй автомобиль. Потому что для этой работы нужно было ездит в офис, а ребенка из школы забирать самому не всегда получиться. Работа позже заканчивается. Поработал в новой компании, но у них тоже не все так гладко. Уволили через полтора года, получил ещё раз выплаты.
Так что, что я могу сказать. Планы - это все хорошо и весело и строить из нужно. Только вот без плана Б, это все не стоит ничего. Как и недвижимость, которую купил, а теперь пользоваться толком не можешь.
Надёжней вкладывать в себя. А то рынок он такой, сегодня IT в топе, а завтра тебя заменили на ИИ.
Из всего перечисленного, одна хорошая новость, менеджеры наконец-то должны обладать техническим бэкграундом, а не просто рассказывать про единорогов. Но по личному опыту пока такого не наблюдаю. Может мне так повезло просто.
Ну а вообще хотелось бы на собеседованиях более приближенных к реалиям вопросов. Только пару раз попадались такие в израильских компаниях.
То алгоритмы хотят от тестировщика, а потом оказывается что ты их будешь использовать - никогда. Да и вообще, автоматизацией заниматься некогда, потому что мы планировать не умеем и не хотим. То напиши пару фреймворков с нуля, за пару дней под наш стек. Ну да их же по-любому, каждую неделю переписываешь. Да и вообще на поверку в компании уже давно написаны фреймворки и никто тебе их улучшать не даст хоть им уже и 10 лет. Твоё дело заниматься поддержкой.
Хорошая статья. Особенно отлично описаны mock, stub, fake. Сколько видел сломанных копий на эту тему.
Для определения require и assert есть установившаяся в тестировании терминология: soft assert - проверяет результат и разрешает продолжение теста, hard assert проверяет результат и останавливает тест в случае фейла.
Да должен. Он не должен это уметь делать. Но знать разницу между двумя словами и разницу в стоимости и применимости для его проекта знать обязан. Контейнеризация дешевле в использовании, как по эксплуатации, так и банально по стоимости у облаков. Но, не все проекты можно делать на ней.
А вот это вообще root cause 90% провалом на проектах. Когда хотят "скраежопить", абсолютно не понимая чем это обернется.
Не хотим держать свои сервера, CapEx - зло, переходим на облака, мы любим OpEx. И по налогам приятнее и денег сразу столько не нужно. А потом прибегает менеджер. Ой, что-то там такой счёт выставили из облаков. А давайте не будем сервера держать по выходным. Но отчёты по тестам в понедельник я хочу. А сервера по выходным не включайте. Это вместо того, чтобы настроить нормально автостарт и автостоп для окружений. Но менеджер же не хочет знать. Это же для него технические детали, хотя тут речь про деньги.
А так да, мир такой - все что просто, стоит дополнительных расходов. Хочешь сэкономить - придётся освоить довольно сложные схемы и автоматизацию.
Если и дорого и слишком сложно, то зачем вообще начинать проект? Можно же совсем ничего не делать.
Вы же сами написали, что DevOps - выделенная команда, а не проектная. У них таких проектов как ваш может быть довольно много. Т.е. они не могут работать в линейной иерархии, как обычный проект. Там просто нет выхода как работать по матрице. А в случае матричной структуры, без тикетов - никак.
Вот есть у них, например, 50 проектов. И возможно ваш - далеко не самый приоритетный. Если дать возможность влиять напрямую, то вы его "пропихнете". Именно поэтому, вводится изоляция команды DevOps и тикеты. Только с помощью тикетов и их приоритезации, можно не поехать кукухой в этом хаосе. И да, вам неприятно, ваши личные метрики идут на дно. Но для компании в целом, возможно, это было меньшим злом и выгоднее, возможно были 5 других более важных и денежных проектов, которые взлетели за ваш счёт.
Это всё конечно теория и домыслы как должно быть. Конкретный кейс может быть вовсе не таким счастливым.
Позволю себе немножко не согласиться. Поток сознания от PM - это повод найти нормального PM, который общается не потоком сознания, а чем-то более вразумительный и приближенным к делам, компании, продукту и процессу.
Поток сознания может выливать только заказчик, который платит деньги. И только это может оправдывать такое поведение. Все остальные в рамках компании - это сотрудники осваивающие деньги клиентов и в идеале приносящие этим самым клиентам пользу. Но вот когда менеджер начинает вести себя как клиент, получая такую же зарплату и не оплачивая труд других из своего кармана. То это просто воровство ресурсов компании временем других сотрудников, которые не обязаны разбирать такие потоки. Для этого и есть менеджер, а если он не может то бизнес-аналитик. Который переводит с потоков на понятный технический язык. Технари должны получить задачу и выполнить ее, а не переводить поток сознания во что-то человеко-разборчивое. Это весьма непростое и стоящее многих нервов занятие.
Учить AI - это конечно полезно. Но:
Галлюцинации, никто не отменял.
Я вот работаю с помощью AI и хочу сказать, что год назад он давал более толковые и полезные советы.
Все очень сильно зависит от стека и насколько оно есть в свободном доступе на GitHub. Например, Java Spring или Selenium - без проблем. API все мейнстримные - тоже. Пробовал Robot Franework, всё намного хуже. Какой-нибудь Grafana K6 на JS - вообще прям печаль. А полезешь в эмбедед, так вообще засада полная, он про даташиты и прочие доки на чипы вообще почти ничего не знает. Если только чип старый и полно примеров кода, может что-то вытянуть.
Я вот работал на медицинском проекте. Там внезапно, перед тем как написать хоть строчку кода, нужно пройти пачку тренингов и подписаться, что ты их прошел. Иначе весь проект в топку и "Миша, давай по-новой." Как быть? ИИ подпишется? Ну и это для всего safety critical и military. Разработчик - это не просто кнопки давить, но ещё и "козёл отпущения", в случае чего.
А тут кажется, что у вас с архитектурой беда или с политиками чистого кода. Как девочка залила данные в таблицу, которую нужно было удалить? Что эта таблица вообще делала в мастере? У меня на всех проектах за такое по рукам били, если неиспользуемый код оставался, это просто ревью не могло пройти.
За день сделаешь?
Сделаю.
А за 2?
Можно и за 2.
А за неделю?
Нет, за неделю не могу. Тут помощник нужен. (с)
Люто-бешено плюсую.
Дошли до стадии. Мне проще самому баги фиксить и комитить, чем девелоперам объяснять и писать трёх страничное описание с картинками, схемами и диаграммами, которые сами девелоперы не осилили.
А как же Gattling?
Я как-то раз решил FreeBSD 9, если не ошибаюсь установить на Pentium MMX 166 MHz. Просто лежал без дела на балконе. Неделю ядро пересобиралось. Но потом зашевелилось даже.
Прекрасная статья, спасибо за неё.
Есть рецепт решения ещё одной проблемы?
Как поменять команду/компанию, когда она не хочет меняться?
У меня сейчас полный день сурка, потому что всем нужно объяснять буквально как дышать.
Документацию писать не хотят, потому что - "это невозможно".
Правильно выставлять статусы тикетов - "нет, не хочу".
Пользоваться версиями - "нет, мне сложно".
Любые попытки, сделать что-то правильно, разбиваются о - мне лень это делать, если хочешь можешь сделать это сам за меня. А я буду делать только то что мне интересно.
Я не понимаю, почему в каждой компании хотят переопределить роли. Есть же ISTQB. Который, как минимум описывает роли Tester, Automated Tester, Test Manager.
Писать тест план и стратегию - это задача никак не рядового тестировщика. Там слишком много завязок на менеджмент, разработчиков и расписание проекта. Знать которые, вообще не компетенция рядового тестировщика. А когда на проекте тестировщик в единственном экземпляре, я ещё ни разу не видел даже вменяемых требований. А без требований вся тест стратегия и план не имеют смысла. Потому что только отталкиваясь от требований, можно сделать осознанный выбор стека инструментов, языков программирования видов и типов тестирования, тестового окружения и фикстур. Ну и построить traceability matrix.
Что до SDET, то SDET как правило не занимается тестами в отличие от Automated Test Engineer. SDET занимается реализацией задач от Test Architect. Прописыванием тест фреймворка его архитектурой, разбивкой на модули, включение зависимостей. Зачастую это выливается в дополнительный уровень абстракции под конкретный продукт. Поверх базовых RestAssured/Selenium/Requests/Appium/RobotFramework etc. Реализацией моков/стабов/симуляторов. DevOps команда прикручивает пайплайны к этому всему, а автоматизаторы прописывают уже сами тест-кейсы со сценариями с или без BDD/DDT.
Тогда автоматизаторы просто получают API с CRUD операциями вся логика тестов прописывается на данном уровне абстракции. А там уже легко подменяя более низкоуровневую абстракцию. Одни и те же сценарии можно использовать например как для API тестирования, так и для UI.
Это если как оно работает в идеале. Ну а если, где-то начинается экономия, то соответственно пойдут и компромиссы и кому-то придется совмещать роли. Ну и времени и сил прописывать дополнительные слои абстракции - не будет.
Тестировщик - это не совсем часть разработки. Это этап между разработкой и приемной, чтобы сэкономить нервы бизнесу принимающему результат. Если заказчику, внутреннему или внешнему, показать результат первого билда напрямую от разработчиков. То скорее всего у него будет нервный тик и лёгкая паника. А вот если показать 3, 5, 10 после тестировщиков. То шансы на продление контракта и новые заказы вырастут по параболе.
А вот QA - это совсем не про разработку. QA ликвидирует баги не только кучей разных методов и методик тестирования. Но он просто уничтожает их пока они даже случились. Благодаря внедрению правильных процессов, улучшению коммуникации, документации, прототипирования ну и CI/CD.
До сих пор существуют компании, которые вместо использования Figma, пытаются договориться о дизайне в Excel и на пальцах.
Что только делает shift left огромного количества проблем и багов. Которые легко можно было бы обсудить и отстрелить просто сделав адекватные против за пару недель.