Вы написали про автотесты/самотестирование, ориентируясь на книги, где процессы выстроены идеально. За почти 4 года работы я был только в одной команде, где можно было назвать "нормальным" организацию процессов и даже в ней тестировщики забирали всю работу тестирования на себя, т.к. они банально быстрее с этим справятся и разработчик намного шустрее исправит весь скоп, который ему пришлет тестер, чем будет сидеть и проверять каждую мелочь(и все равно потом будет править баги, но будет их максимум процентов на 20 меньше, чем без его проверки). В 90-95% команд разраб бегает то к дизам, то к менеджерам, то к аналитикам, потому что всегда есть условности, которые стоит обговорить и решить(банально кривое ТЗ, косяки дизов, требования от бизнеса по ходу разработки). Вы же предлагаете еще и нагрузить их тестированием. (Кстати, как у вас там с постановкой задач и организацией макетов, если вы так искренне удивляетесь словам своего разработчика?) 1. Подскажите, сколько времени есть у ваших разрабов для написания автотестов и даете ли вы им закладывать часы на тестирование своих задач? Потому что во многих компаниях это даже не учитывается и разрабам предъявляют, если задача делается долго 2. Есть ли понимание, что среднее время выполнения задачи на этапе разработки увеличится на 20-30%? При этом остальные задачи будут стоять на месте, зато тестировщики чуть меньше будут работать. 3. Вы пробовали сравнивать именно в своей команде, быстрее ли пойдет процесс, если разраб будет делать еще и работу тестировщика? Потому что при тестировании в других командах либо выигрыш был на 1-5%(из личного опыта), при этом у разрабов выгорание прилетало через 3-4 месяца, либо наоборот еще хуже становилось и возвращались обратно к стандартному процессу
Ваши идеи хороши в теории, к этому действительно стоит стремиться, но, к сожалению, мы упираемся в реалии
Вы написали про автотесты/самотестирование, ориентируясь на книги, где процессы выстроены идеально. За почти 4 года работы я был только в одной команде, где можно было назвать "нормальным" организацию процессов и даже в ней тестировщики забирали всю работу тестирования на себя, т.к. они банально быстрее с этим справятся и разработчик намного шустрее исправит весь скоп, который ему пришлет тестер, чем будет сидеть и проверять каждую мелочь(и все равно потом будет править баги, но будет их максимум процентов на 20 меньше, чем без его проверки).
В 90-95% команд разраб бегает то к дизам, то к менеджерам, то к аналитикам, потому что всегда есть условности, которые стоит обговорить и решить(банально кривое ТЗ, косяки дизов, требования от бизнеса по ходу разработки). Вы же предлагаете еще и нагрузить их тестированием. (Кстати, как у вас там с постановкой задач и организацией макетов, если вы так искренне удивляетесь словам своего разработчика?)
1. Подскажите, сколько времени есть у ваших разрабов для написания автотестов и даете ли вы им закладывать часы на тестирование своих задач? Потому что во многих компаниях это даже не учитывается и разрабам предъявляют, если задача делается долго
2. Есть ли понимание, что среднее время выполнения задачи на этапе разработки увеличится на 20-30%? При этом остальные задачи будут стоять на месте, зато тестировщики чуть меньше будут работать.
3. Вы пробовали сравнивать именно в своей команде, быстрее ли пойдет процесс, если разраб будет делать еще и работу тестировщика? Потому что при тестировании в других командах либо выигрыш был на 1-5%(из личного опыта), при этом у разрабов выгорание прилетало через 3-4 месяца, либо наоборот еще хуже становилось и возвращались обратно к стандартному процессу
Ваши идеи хороши в теории, к этому действительно стоит стремиться, но, к сожалению, мы упираемся в реалии