Продолжение первой части

Давайте начнём с того, кто такой QA? Не функция, хотя и она, а как инженер.

Хороший QA, сейчас забываем про ИИ-истерию, должен активно участвовать в разработке, выступать тем самым quality gate, формировать ещё до этапа разработки позитивные и, самое главное, НЕГАТИВНЫЕ сценарии (тоже BDD как раз об этом), уточнять видение продукта, постановку, формировать документацию в виде тестов и т.д..

Но большинство QA-инженеров, с которыми мне довелось работать, исповедуют другую философию: вы дайте нам готовый продукт, готовые доки и сценарии, а уж потом мы как выпрыгнем, как выскочим…

Протестировать изолировано модуль с интеграциями? Напишите нам стабы, дайте инструменты. Самостоятельно сходить в кролик или редис? Не-не-не, мы такого не умеем, максимум curl дёрнем руками. И я тут без иронии. Лично делал воркшопы для команд QA.

Замокать сервис? Postman-ом? А как это? Не, давайте готовое решение. Централизованно мокать? А чем? А какие продукты есть? А может быть вы нам стаб напишете?

И я даже не особо сгущаю краски. Думаете, просто так появилась та самая сессия по ИИ с Mockoon?

В холдинге знают, что я буквально молю: дайте мне QA, который на этапе препланинга/3 amigo будет не кивать головой, а говорить: аналитика фигня, дорабатывайте.

Но нет. Все кивают, всем всё понятно, а потом опаньки: а как этот модуль работает, а как его тестировать, а расскажите мне…

Ну честно, приходится устраивать сессии и говорить: видите, в доке написано, что параметр должен называться: some_thing согласно постановке? А вам пришёл something. Это баг, нарушающий постановку, и тут нужно не бежать к разработчику и спрашивать как вам жить, а формировать тикет с багом. Там уж пусть разработка с аналитиком решают, это баг или фича. И либо доуточняют постановку, либо исправляют написанное.

Написать тесты в параллель с разработкой? Ой, у нас ручки... Нам бы дождаться(песенка выше)

И ты такой: ну твою же ж... И давай воркшопить... Потому что в прод надо, фиксить надо, T2M растёт...

Так что бизнесу нужно QA. Но качественное. То самое, из книжек.

Но сейчас, если ты начинаешь нормально работать с ИИ(да даже без ИИ) на уровне аналитики, значительное число сценариев уже закрывается ДО. Нужно просто грамотную постановку сделать. «Подрючить» аналитику. Банальное: зафиксировать DoR/DoD. Что туда входит в обязаловку.

И потом сценарии появляются «сами». Их нужно автоматизировать только.

Сюрприз – это ИИ сделать легко. Так как ей как раз эти сценарии и acceptance criteria самое оно.

А если мы уходим в SDD, то тут вообще кисло, так как ИИ буквально сам уже пишет не только unit-тесты. И разработчику проще всего на этом этапе сформировать то самое тестирование. Отдельным набором скиллов, повесив на отдельную модель/агента. И реализовав и тестирование отдельного модуля(оно само получается) и e2e... а если у тебя спеки и тесты к ним уже собраны в должном виде...

В общем, пока лично я пытаюсь подружить QA с ИИ-инструментами, но перспективы видятся грустные. И не потому что QA не нужно, нет. А потому что они одни из наиболее легко заменяемых элементов процесса. С разрабами-джунами та же фигня, с аналитиками тоже проблемы. Но мне видится, что они более устойчивы.

Посмотрим, что будет на дистанции, куда кривая судьбы ИИ выведет. Но сейчас бы я осторожно относился к идее "вкатить в ИТ" через QA.

И если есть такая мысль, то рекомендовал бы стратегию построить от противного: прошерстить тот же НН и посмотреть профессии/направления, где:

1. Самый высокий спрос (больше всего вакансий) 2. С упором по вакансиям на джунов, ведь ИИ «вырезает», в первую очередь, именно их. Нет джуниорских вакансий — нет входа, каким бы вкусным ни был рынок. 3. Самые высокие ЗП и на стартовых позициях и на топовых. Вы же не хотите всю жизнь с условными 100к крутиться? ИТ-шечка же ж...

И на пересечении искать перспективное направление. Плюс то, которое будет нравиться именно вам – на дистанции выигрывает то, чем готовы заниматься без пинка. Вариантов, в действительности, много.

QA, а у вас как? Кто пересобрал себя под эпоху ИИ-агентов?

https://t.me/chiefofcomm