Ну смотрите, по факту ваша команда разработки становиться зависима от тесировщиков, становится заложниками человеческого фактора и команда разработки в уже не могут работать без тестировщиков.

Или же вообще удалить

Реального опыта с совсем убрать ручное тестирование я не встречал :)

Ручное тестирование - увы )

Стас, не согласен. Ручных тестировщиков надо переучивать. Автоматизаторы, по сути, это уже разработчики :)

Чем компенсировали отсутствие ручного тестирования?

Не-не-не. Когда есть ручные тестировщики и стадия(!) тестирования, она развращает разработку - и ребята пусть и неосознанно стараются довести задачу до "отправлено в тестирование", а не до сделано. Да и когда находится ошибка в проде - стандартная проблема "не досмотрело тестирование, или поселило баг разработка". Вообще, я про вредность отдельной стадии тестирования и тестировщиков всех видов могу долго говорить ;)

Другой вопрос, что именно пришлось компенсировать и каков был путь до приемлемого результата

Стадии делать не надо, надо делать процесс. И лучше, чтобы работы в рамках этого процесса были выполнены не самим разработчиком. А еще лучше, чтобы они были автоматизированы.

но вот выделение разработчика, который будет в первую очередь отвечать за acceptance test automation, например - очень ок.

Ручные тестировщики могут писать кейсы не скриптами, а языком.

Не-не-не. Когда есть ручные тестировщики и стадия(!) тестирования, она развращает разработку - и ребята пусть и неосознанно стараются довести задачу до "отправлено в тестирование", а не до сделано. Да и когда находится ошибка в проде - стандартная проблема "не досмотрело тестирование, или поселило баг разработка". Вообще, я про вредность отдельной стадии тестирования и тестировщиков всех видов могу долго говорить ;)

но вот выделение разработчика, который будет в первую очередь отвечать за acceptance test automation, например - очень ок.

Я когда-то по поводу тестирования писал: 1) Мне кажется, что единственный устойчивый вариант с автоматизацией тестирования - это когда автоматизацией тестирования занимается разработка. Т.е. 100% разработки пишет автотесты (интеграционные, функциональные). Если этим занимается отдельный отдел автоматизации тестирования или выделенный какой-то человек, то получается плохо, эти тесты живут отдельно от разработки, новые фичи покрываются тестами только спустя какое-то время и написаны тесты плохо. Потому что хороший автотестировщик - это крайне редкий зверь. 2) Мне кажется, что не все можно покрыть автотестами, поэтому ручное "тестирование" все-равно должно быть. Существует много вещей, которые покрыть автотестами невозможно или тяжело - всякие нефункциональные требования - налазит кнопочка на другую или нет, правильно ли отрисовываются стили, удобно будет новой фичей пользоваться или нет, вписывается ли новая кнопка в общий дизайн и в гайдлайн, а вообще эта фича решает задачу бизнеса? Но все эти вещи может проверить ПО, который заказывал фичу, точнее ДОЛЖЕН вручную проверить, что будет уходить в продакшн. 3) Мне кажется, что ручное тестирование в идеале должно быть бизнес-тестированием, а не проверкой, есть ли 500ки, открывается ли вообще страничка и т.д. В ручное бизнес-тестирование фича должна приходить в рабочем состоянии. Если сервис пятисотит, странички не открываются из-за багов в js-коде и т.д., то разработчик официально объявляется мудаком, получает минуса в карму и с ним лично проводится разъяснительная работа о том, как так получилось, что он собственный код ни разу не запустил и считает ли он это нормальным. 4) Мне кажется, ручное тестирование должно тестировать фичи, а не релизы. Автотесты, которые пишет разработчик сильно уменьшают возвраты с тестирования + если регресс у нас покрыт автотестами, то ручное тестирование фичи, которое на самом деле должно быть "бизнес-тестированием" занимает в среднем порядка 10% от времени разработки этой фичи. Кроме того, фича - то что можно спрограммировать, проверить и выложить - должна быть маленькая. Если фичи - большие, то вероятность там найти ошибки - большая, количество возвратов сильно больше, лишнего тестирования той же самой функциональности тоже сильно больше. 5) Мне кажется, что ручное тестирование имеет смысл для сложной интеграции и легаси Например, тестирование интеграции в телефонии.

Коллеги, где будет чат, если телеграмм закроют? Или все через впн/прокси продолжат?

Тоже по большей части согласен, единственно очень поменял взгляд на тестировщиков и их ценность после прочтения книги Гибкое тестирование

я убирал совсем ручное тестирование - именно ручных тестировщиков. Сама проверка работоспособности сервиса никуда не исчезала, конечно же. Регресс - автоматом, бизнес тестирование - ПО, за качество отвечает команда инженеров (разработчиков), среди которых никаких QA не было (и на самом деле не надо).

Что такое ПО в данном случае ? Кто тестирует интеграцию ? Кто создаёт нетривиальные кейсы, которые нельзя автоматизировать ?

Я когда-то по поводу тестирования писал: 1) Мне кажется, что единственный устойчивый вариант с автоматизацией тестирования - это когда автоматизацией тестирования занимается разработка. Т.е. 100% разработки пишет автотесты (интеграционные, функциональные). Если этим занимается отдельный отдел автоматизации тестирования или выделенный какой-то человек, то получается плохо, эти тесты живут отдельно от разработки, новые фичи покрываются тестами только спустя какое-то время и написаны тесты плохо. Потому что хороший автотестировщик - это крайне редкий зверь. 2) Мне кажется, что не все можно покрыть автотестами, поэтому ручное "тестирование" все-равно должно быть. Существует много вещей, которые покрыть автотестами невозможно или тяжело - всякие нефункциональные требования - налазит кнопочка на другую или нет, правильно ли отрисовываются стили, удобно будет новой фичей пользоваться или нет, вписывается ли новая кнопка в общий дизайн и в гайдлайн, а вообще эта фича решает задачу бизнеса? Но все эти вещи может проверить ПО, который заказывал фичу, точнее ДОЛЖЕН вручную проверить, что будет уходить в продакшн. 3) Мне кажется, что ручное тестирование в идеале должно быть бизнес-тестированием, а не проверкой, есть ли 500ки, открывается ли вообще страничка и т.д. В ручное бизнес-тестирование фича должна приходить в рабочем состоянии. Если сервис пятисотит, странички не открываются из-за багов в js-коде и т.д., то разработчик официально объявляется мудаком, получает минуса в карму и с ним лично проводится разъяснительная работа о том, как так получилось, что он собственный код ни разу не запустил и считает ли он это нормальным. 4) Мне кажется, ручное тестирование должно тестировать фичи, а не релизы. Автотесты, которые пишет разработчик сильно уменьшают возвраты с тестирования + если регресс у нас покрыт автотестами, то ручное тестирование фичи, которое на самом деле должно быть "бизнес-тестированием" занимает в среднем порядка 10% от времени разработки этой фичи. Кроме того, фича - то что можно спрограммировать, проверить и выложить - должна быть маленькая. Если фичи - большие, то вероятность там найти ошибки - большая, количество возвратов сильно больше, лишнего тестирования той же самой функциональности тоже сильно больше. 5) Мне кажется, что ручное тестирование имеет смысл для сложной интеграции и легаси Например, тестирование интеграции в телефонии.

А если они это качество не обеспечивают ?

растить команду, чтобы она обеспечивала качество, которое надо.

Сложно) для многих нанять тестировщика проще будет думаю))

так тестировщики никак не решают проблему качества, они просто не позволяют плохому продукту вылиться в прод, а процент брака остается такой же. за счет тестирования снижается количество багов на проде, но увеличивается time to market сильно.

Я когда-то по поводу тестирования писал: 1) Мне кажется, что единственный устойчивый вариант с автоматизацией тестирования - это когда автоматизацией тестирования занимается разработка. Т.е. 100% разработки пишет автотесты (интеграционные, функциональные). Если этим занимается отдельный отдел автоматизации тестирования или выделенный какой-то человек, то получается плохо, эти тесты живут отдельно от разработки, новые фичи покрываются тестами только спустя какое-то время и написаны тесты плохо. Потому что хороший автотестировщик - это крайне редкий зверь. 2) Мне кажется, что не все можно покрыть автотестами, поэтому ручное "тестирование" все-равно должно быть. Существует много вещей, которые покрыть автотестами невозможно или тяжело - всякие нефункциональные требования - налазит кнопочка на другую или нет, правильно ли отрисовываются стили, удобно будет новой фичей пользоваться или нет, вписывается ли новая кнопка в общий дизайн и в гайдлайн, а вообще эта фича решает задачу бизнеса? Но все эти вещи может проверить ПО, который заказывал фичу, точнее ДОЛЖЕН вручную проверить, что будет уходить в продакшн. 3) Мне кажется, что ручное тестирование в идеале должно быть бизнес-тестированием, а не проверкой, есть ли 500ки, открывается ли вообще страничка и т.д. В ручное бизнес-тестирование фича должна приходить в рабочем состоянии. Если сервис пятисотит, странички не открываются из-за багов в js-коде и т.д., то разработчик официально объявляется мудаком, получает минуса в карму и с ним лично проводится разъяснительная работа о том, как так получилось, что он собственный код ни разу не запустил и считает ли он это нормальным. 4) Мне кажется, ручное тестирование должно тестировать фичи, а не релизы. Автотесты, которые пишет разработчик сильно уменьшают возвраты с тестирования + если регресс у нас покрыт автотестами, то ручное тестирование фичи, которое на самом деле должно быть "бизнес-тестированием" занимает в среднем порядка 10% от времени разработки этой фичи. Кроме того, фича - то что можно спрограммировать, проверить и выложить - должна быть маленькая. Если фичи - большие, то вероятность там найти ошибки - большая, количество возвратов сильно больше, лишнего тестирования той же самой функциональности тоже сильно больше. 5) Мне кажется, что ручное тестирование имеет смысл для сложной интеграции и легаси Например, тестирование интеграции в телефонии.

А если разработчик напишет код, затем сам протестирует, это будет много быстрее, чем за него протестирует тестировщик ?

А ещё: друзья, есть здесь гуру конфлюенс? Кто может поделиться бест практиками ее ведения, как с джирой линковал, структуру делал? Буду очень благодарна за лайфхаки и время❤️ Я на очень примитивном уровне с ней работала, даже стыдно..

А если разработчик напишет код, затем сам протестирует, это будет много быстрее, чем за него протестирует тестировщик ?

А многим ли вообще охота тестировать ? Мне кажется, что разработчикам интересно кодить, а не тестировать. Ну а насчёт продакта - бизнес есть бизнес. Подавляющее большинство вообще вникать не хочет в тестирование. Они выполняют банальные проверки и все. Чтобы выполнить качественное тестирование, это же нужно быть аналитиком отчасти.

разработчик, который не разбирается в продукте (не «отчасти аналитик»), крайне редко бывает хорошим разработчиком.

Наверное, зависит от организации работы в компании и загрузки разработчиков.

нет, не зависит. В 99% нынешней разработки, нет.

Как-то категорично звучит. Основная цель тестирования - достижение приемлимого качества продукта. Критерии качества определяется командой и рынком. Юнит тесты - девеллперы, Функциональное, Интеграция, нагрузочное, производительность и регрешн - автоматизация, и кстати далеко не всегда. Бывают случаи, когда быстрее/дешевле вручную протестировать что-то, чем дописать и исправить много зависимого кода. не важно кто занимается автоматизацией тестов, главное - качество продукта. Юзабилити, ui и прочее - только мануальное тестирование, если ПО имеет достаточно времени - ок, только я очень сомневаюсь в качестве проведенного тестирования. Профессиональный тестировщик не тот, кто принимает решение о допуске релиза в продакшн, а тот кто способен оценить качество продукта и поддерживать его. Это делается с помощью определенных метрик, которые используют qa. Ответственность за качество лежит на всей команде разработки, включая qa и dev. Чтобы у девов создавалась ценность качества продукта, лучше проводить ретро, чем удалять из команды квалифицированных qa или заставлять писать девов автотесты. Я бы не обесценивала чужой труд.

Смотря что вы имеете ввиду под качеством продукта. Если не помогает достигать, то как минимум влияет на качество, не оттестированная версия может сильно повлиять на продукт.