>Это плохой вариант, на который ориентироваться нельзя.
Это самый реальный вариант. Тот, который вы описываете - очень дорогой и сложный.
>В нормальной команде QA Engineer иногда знает код даже лучше разработчиков, способен его исследовать и в багрепорте указать путь (или пути) его исправления с кодом/псевдокодом.
Каков будет КПД его работы по исследованию и отладке чужого кода?
Программистам всё равно придётся проверять то что он там нашёл и наисправлял и согласовывать представления тестировщика о том как работает проект с тем, как он реально работает.
>И должен быть готов самостоятельно эту ошибку исправлять.
Это плохо кончится.
>Фактически же суть ошибки и ответственного (этого тестера или другого, разработчика этого или другого) за ее исправление назначают на Defect Triage совместно руководитель разработчиков и руководитель тестеров.
Угу, и в итоге ответственными и исправляющими становится программисты, что я и описал ранее. Только с целой процедурой по маканию их в собственные косяки.
>В багрепорте должен приводиться полный путь воспроизведения и/или воспроизводящий код/бинарь.
Должен, поскольку без него толку с такого тестирования вообще негусто. Однако же далеко не всегда этот путь будет и будет корректен.
>После назначения ответственного за исправление воспроизвести это будет его прямой обязанностью.
Вы написали своими словами то что описал и я. Всё равно в конечном итоге эти две группы сядут, будут воспроизводить, искать и придумывать, как исправить.
>Почему не зная?
Потому что если он тестирует зная - то это либо путь вникуда (он знает, как всё должно работать и ровно так же, как и сами программисты тщательно убеждается в том, что оно работает так, как задумано - неработа его не интересует), либо штучный человек особого склада ума.
>Тестировщик вообще-то даже более широкий кругозор может иметь чем девелопер, потому что при реализации разнообразных AE, поз/нег сценариев и ручных харнессов вполне может работать с несколькими модулями или системой в целом - в отличие от разработчика, который погружен на 1-2 текущие задачи.
Может, но тогда см. выше.
>Ну если конечно девочек задешево в QA набирать, то тогда да.
Дык а в реальности задёшево и набирают.
На самом деле все эти вещи имеют право на жизнь, но не являются чудесным решением всех проблем, которым их сейчас принято представлять. И создают ряд новых самодостаточных проблем. Разумный подход нужен. А когда он есть - это уже частности.
>Это самый реальный вариант. Тот, который вы описываете - очень дорогой и сложный.
Мы Фобос-Грунт за N миллиардов(онов) запускаем или курсовые по программированию на заказ делаем? Тот вариант, который я описываю, реально работает в весьма средненьких компаниях, правда, профессионально занимающихся разработкой софта, а не высоколобой наукой. Ну так может быть надо было профессионалам отдать разработку ПО?
>Каков будет КПД его работы по исследованию и отладке чужого кода?
КПД его работы завист от его профессионального уровня и опыта, а также в немалой степени от профессионального уровня и опыта автора кода. Если оба уровня заметно выше пещерного, серьезных проблем не возникает. При регулярно возникающих проблемах один из участников процесса переводится на другую должность, другую задачу или увольняется.
>Программистам всё равно придётся проверять то что он там нашёл и наисправлял и согласовывать представления тестировщика о том как работает проект с тем, как он реально работает.
Во-первых, если Вы считаете, что "наисправленное" самим программистом не требует верификации, то Вы ошибаетесь. Каждый исправленный дефект проходит код-ревю и/или верификацию, вне зависимости от того, кто его исправлял.
Во-вторых, представления тестировщика не нуждаются в согласовании при наличии проектной документации и руководителя разработчиков - который собственно и определяет как и что должно исправляться - на основе мнений тестера, разработчика и своего - после чего и приступают собственно к исправлению.
>Это плохо кончится.
Ваше мнение не потверждается опытом, по крайней мере моим. Кончается обычно очередным релизом и повторением цикла до следующего релиза, если он имеет место.
>Угу, и в итоге ответственными и исправляющими становится программисты, что я и описал ранее. Только с целой процедурой по маканию их в собственные косяки.
Ничего подобного. Ответственнными и исправляющими становятся те, кто в данной ситуации справится лучше - исходя из загруженности, сложности ошибки, подготовки тестера и т.п.
А в косяки макать необходимо. Для того, чтобы в следующий раз этот человек работал внимательнее, или для замены этого человека по совокупности/грубости косяков.
>Должен, поскольку без него толку с такого тестирования вообще негусто. Однако же далеко не всегда этот путь будет и будет корректен.
Эти тривиальные вещи как-то опровергают то, о чем я говорю?
>Вы написали своими словами то что описал и я. Всё равно в конечном итоге эти две группы сядут, будут воспроизводить, искать и придумывать, как исправить.
Там, где процесс разработки хаотический и не руководимый - так и будет. А в отлаженном цикле разработки сидеть в каждый момент времени будет тот, кто "поймал игрушку" (по аналогии с детской игрой), т.е. единственная активная роль в данный момент - девелопер для оценки багрепорта, или резолвер, или код-ревьювер, или верификатор. Подчеркну - не должность и не позиция, а роль. Содержание (конкретного человека) на каждую из которых определяет руководитель(ли) лично или коллегиально.
>Потому что если он тестирует зная - то это либо путь вникуда (он знает, как всё должно работать и ровно так же, как и сами программисты тщательно убеждается в том, что оно работает так, как задумано - неработа его не интересует), либо штучный человек особого склада ума.
Это какие-то абстрактные рассуждения, какое отношение они имеют к решению поставленной задачи? Нет ресурсов или не умеем - не беремся.
>Может, но тогда см. выше.
Что именно выше? Девочек не нанимать? В некоторых проектах нужны как раз девочки - по соотношению цена/качество - но не в Фобос-Грунте.
>Дык а в реальности задёшево и набирают.
Ну, мышам можно порекомендовать не кушать кактус. Лишать их этого священного права или вырывать его у них из глотки никто и не собирается.
>На самом деле все эти вещи имеют право на жизнь, но не являются чудесным решением всех проблем, которым их сейчас принято представлять. И создают ряд новых самодостаточных проблем. Разумный подход нужен. А когда он есть - это уже частности.
Это не чудесное решение, это то, как делают в компаниях-разработчиках софта, которые не первый десяток лет на рынке. Но, конечно, в каждой конторе могут придумать свой самобытный и "не имеющий аналогов в мире" Путь, это их право.