Судя по всему - хорошо что не взяли) ну его, связываться...

Такая ситуация возникает ежедневно! Вы ответе (ему) Вы описали проблемы и высказали одно предложение, если я правильно прочитала, по автоматизации, которое решает вопрос только в среднесрочной перспективе. Все остальные аспекты - мотивация, потеря людей, затраты, все верно, только это не решает сиюминутную проблему. Поэтому я вынуждена согласиться с фидбэком, использовать имеющиеся ресурсы, если возможно. Могу я поинтересоваться, каким на Ваш взгляд должно быть решение здесь и сейчас, если отсутствует FTE?

Программисты не умеют свой код тестировать )))

Я не из ИТ, но зачиталась)) и вопрос и ответы, интересно. Отчасти это касается моей профессии... (если что, я со всеми высказываниями согласна, у всех разный подход, и конечно плохо нагружать людей доп работой). Но, посчитаем в часах. Если 40 рабочих часов разделить на 5 разрабов, то получится по 8 часов на чела в неделю. Это значит каждый должен будет потратить примерно по ~1,5 часа в день сверхурочно на тест. А сверхурочные часы у нас по ТК оплачиваются как минимум 1,5 размере. Отсюда, можно предположить, что работодателю это будет дороже чем нанять всё же нового QA. Или, в порядке бреда, можно предложить 2ум разрабам устроиться на 0,5 ставки тестером (так говорят вообще?), возможно они захотят доп денег заработать например. Но вариант размазать часы на всех равномерно мне видится более реалистичным. Вопрос ещё, принято ли в ит компаниях оплачивать сверхурочнве часы? Ну и ждать когда найдут нового QA)))

Зависит от продукта и ситуации. Пожалуй с чем я не согласен, так это то, что время QA стоит дешевле. Зарплаты QA, если не рассматривать чисто ручных тестировщиков, не уступают зарплатам разработчиков. К тому же, вряд ли все пять разработчиков в команде уровня старший и выше. Так что чьё время дороже - еще вопрос.

Если говорить о руководстве, оставив в стороне причины по которым убрали QA. Задача руководителя по возможности выстроить оптимальный процесс теми ресурсами, что доступны, если больше ресурсов получить не удается. Такие ситуации как раз и раскрывают руководителя.

А привлечь разработчиков к тестированию в ситуации отсутствия или недостатка QA - не плохой вариант.

Разработчики могут писать функциональные тесты через АПИ сервиса, QA валидирует, что эти тесты достаточны и тратит свое время на какие-то отдельные краевые случаи, тем самым не проверяя то, что уже проверяется тестами.

QA выбирает фреймворк для сложных интеграционных сценариев. Разработчики подключаются к написанию сценариев.

Если продукт можно тестировать только в ручную - выделение компонент, которые можно покрыть автоматическими тестами. Улучшение покрытия юнит/компонентными тестами. После добавления функционала разработчик запускает продукт, проводит тестирование и прикрепляет отчет что он протестировал. QA проверяет отчет и может выборочно что-то перепроверить. Так же QA отвечает за ведение тестовых сценариев.

QA привлекается на этап постановки задачи, чтобы он мог сформулировать тестовые сценарии, которые надо будет проверить/реализовать разработчику, если используются автотесты.

У этого есть свои плюсы. Во-первых нахождение ошибки смещается ближе к разработке. Соответсвенно исправить ошибку становится дешевле. Разработчики лучше понимают продукт, исключается ситуация, что разработчик внес изменение, но как проверить их не знает.

Фактически QA становится экспертом в плане подходов тестирования. Проверяет, что существующие сценарии являются достаточными. При этом большая часть проверок ложится на разработчиков.

Перед руководством придется защищать, что автоматизация, если её не было, потребует времени. В любом случае разработчикам придется потратить время, чтобы изучить фреймворки для тестирования, синхронизироваться с QA как писать тесты.

Так же, тут возникает проблема «бас фактора». В случае ухода QA экспертиза теряется. Поэтому в такой ситуации, надо вырабатывать единообразные подходы в процессах тестирования во всей компании. Фактически, аналогично тому, как сейчас в компаниях есть девопс инженеры - они предоставляют инструментарий, фреймворк, которым уже пользуются все разработчики. Если появляется новый сервис, то за добавление его в деплой отвечает команда разработки, девопс привлекается в случае проблем или не типовых случаев.

Но в целом да, ботлнек есть, но так и вопрос собственно был, что можно с этим сделать. Ситуация может быть и другая - QA ушел на длительный больничный - несколько месяцев, полгода. Что делать. Тут, конечно, можно не перестраивать процессы, но можно и перестроить.

Я был в ситуации нехватки QA и да, это требует больших усилий от разработчика и не все разработчики согласны с таким подходом, есть те, кто считает, что его работа заканчивается после успешного билда, а дальше работа QA.

Хорошо когда всех ресурсов хватает, но так не всегда бывает. :)

Хорошее решение, мне кажется, начать с увольнения того, кто ставит проект под удар. Ну а дальше пересчитать ресурсы и либо убрать разработчиков, либо добавить QA. ps. Сейчас тенденция такая, что время QA стоит столько же, сколько время разработчика.

Вы хотя бы хороший технический спец (если верно понял) - опыт, харды. Уж кто кто, а менеджмент явно должен прислушиваться. Каждый раз когда я так открываю глаза своему руководству вижу еще больше непонимания. Разок даже «попросили», когда случилось «я же говорил» и обвинили меня разумеется, а не себя, не услышавшего предупреждения🤣

Ну слушайте, тут очевидно человек не грамотный и без опыта работы с командами разработки. Я бы ответил ровно также, как и вы.

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