От Павел Войлов (Т-28А)
К writer123
Дата 01.02.2012 19:07:56
Рубрики Современность; Космос;

Делать надо все хорошо, плохо оно и само получится (с)

Приветствую,

>Совместное самотестирование провести кто запрещает?
>Даже если вы это отдадите тестировщикам, то на выходе у вас будет всё равно описание типа "такие-то мои действия привели к ошибке, которая выражается в ... и ..., вот такой был вывод, вот такое состояние" ну и т.п.
>Что дальше? Дальше придётся взять те же две группы, посадить их вместе, запустить им всё это, повторить ошибку самостоятельно и совместно искать её до опупения.

Это плохой вариант, на который ориентироваться нельзя. В нормальной команде QA Engineer иногда знает код даже лучше разработчиков, способен его исследовать и в багрепорте указать путь (или пути) его исправления с кодом/псевдокодом. И должен быть готов самостоятельно эту ошибку исправлять. Фактически же суть ошибки и ответственного (этого тестера или другого, разработчика этого или другого) за ее исправление назначают на Defect Triage совместно руководитель разработчиков и руководитель тестеров.

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

В багрепорте должен приводиться полный путь воспроизведения и/или воспроизводящий код/бинарь. После назначения ответственного за исправление воспроизвести это будет его прямой обязанностью.

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

Почему не зная? Тестировщик вообще-то даже более широкий кругозор может иметь чем девелопер, потому что при реализации разнообразных AE, поз/нег сценариев и ручных харнессов вполне может работать с несколькими модулями или системой в целом - в отличие от разработчика, который погружен на 1-2 текущие задачи.
Ну если конечно девочек задешево в QA набирать, то тогда да.

С уважением, Павел
От writer123
К Павел Войлов (Т-28А) (01.02.2012 19:07:56)
Дата 01.02.2012 19:48:40

Re: Делать надо...

>Это плохой вариант, на который ориентироваться нельзя.
Это самый реальный вариант. Тот, который вы описываете - очень дорогой и сложный.

>В нормальной команде QA Engineer иногда знает код даже лучше разработчиков, способен его исследовать и в багрепорте указать путь (или пути) его исправления с кодом/псевдокодом.
Каков будет КПД его работы по исследованию и отладке чужого кода?
Программистам всё равно придётся проверять то что он там нашёл и наисправлял и согласовывать представления тестировщика о том как работает проект с тем, как он реально работает.

>И должен быть готов самостоятельно эту ошибку исправлять.
Это плохо кончится.

>Фактически же суть ошибки и ответственного (этого тестера или другого, разработчика этого или другого) за ее исправление назначают на Defect Triage совместно руководитель разработчиков и руководитель тестеров.
Угу, и в итоге ответственными и исправляющими становится программисты, что я и описал ранее. Только с целой процедурой по маканию их в собственные косяки.

>В багрепорте должен приводиться полный путь воспроизведения и/или воспроизводящий код/бинарь.
Должен, поскольку без него толку с такого тестирования вообще негусто. Однако же далеко не всегда этот путь будет и будет корректен.

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

>Почему не зная?
Потому что если он тестирует зная - то это либо путь вникуда (он знает, как всё должно работать и ровно так же, как и сами программисты тщательно убеждается в том, что оно работает так, как задумано - неработа его не интересует), либо штучный человек особого склада ума.

>Тестировщик вообще-то даже более широкий кругозор может иметь чем девелопер, потому что при реализации разнообразных AE, поз/нег сценариев и ручных харнессов вполне может работать с несколькими модулями или системой в целом - в отличие от разработчика, который погружен на 1-2 текущие задачи.
Может, но тогда см. выше.

>Ну если конечно девочек задешево в QA набирать, то тогда да.
Дык а в реальности задёшево и набирают.

На самом деле все эти вещи имеют право на жизнь, но не являются чудесным решением всех проблем, которым их сейчас принято представлять. И создают ряд новых самодостаточных проблем. Разумный подход нужен. А когда он есть - это уже частности.
От Павел Войлов (Т-28А)
К writer123 (01.02.2012 19:48:40)
Дата 01.02.2012 20:25:38

Re: Делать надо...

Приветствую,

>Это самый реальный вариант. Тот, который вы описываете - очень дорогой и сложный.

Мы Фобос-Грунт за N миллиардов(онов) запускаем или курсовые по программированию на заказ делаем? Тот вариант, который я описываю, реально работает в весьма средненьких компаниях, правда, профессионально занимающихся разработкой софта, а не высоколобой наукой. Ну так может быть надо было профессионалам отдать разработку ПО?

>Каков будет КПД его работы по исследованию и отладке чужого кода?

КПД его работы завист от его профессионального уровня и опыта, а также в немалой степени от профессионального уровня и опыта автора кода. Если оба уровня заметно выше пещерного, серьезных проблем не возникает. При регулярно возникающих проблемах один из участников процесса переводится на другую должность, другую задачу или увольняется.

>Программистам всё равно придётся проверять то что он там нашёл и наисправлял и согласовывать представления тестировщика о том как работает проект с тем, как он реально работает.

Во-первых, если Вы считаете, что "наисправленное" самим программистом не требует верификации, то Вы ошибаетесь. Каждый исправленный дефект проходит код-ревю и/или верификацию, вне зависимости от того, кто его исправлял.
Во-вторых, представления тестировщика не нуждаются в согласовании при наличии проектной документации и руководителя разработчиков - который собственно и определяет как и что должно исправляться - на основе мнений тестера, разработчика и своего - после чего и приступают собственно к исправлению.

>Это плохо кончится.

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

>Угу, и в итоге ответственными и исправляющими становится программисты, что я и описал ранее. Только с целой процедурой по маканию их в собственные косяки.

Ничего подобного. Ответственнными и исправляющими становятся те, кто в данной ситуации справится лучше - исходя из загруженности, сложности ошибки, подготовки тестера и т.п.
А в косяки макать необходимо. Для того, чтобы в следующий раз этот человек работал внимательнее, или для замены этого человека по совокупности/грубости косяков.

>Должен, поскольку без него толку с такого тестирования вообще негусто. Однако же далеко не всегда этот путь будет и будет корректен.

Эти тривиальные вещи как-то опровергают то, о чем я говорю?

>Вы написали своими словами то что описал и я. Всё равно в конечном итоге эти две группы сядут, будут воспроизводить, искать и придумывать, как исправить.

Там, где процесс разработки хаотический и не руководимый - так и будет. А в отлаженном цикле разработки сидеть в каждый момент времени будет тот, кто "поймал игрушку" (по аналогии с детской игрой), т.е. единственная активная роль в данный момент - девелопер для оценки багрепорта, или резолвер, или код-ревьювер, или верификатор. Подчеркну - не должность и не позиция, а роль. Содержание (конкретного человека) на каждую из которых определяет руководитель(ли) лично или коллегиально.

>Потому что если он тестирует зная - то это либо путь вникуда (он знает, как всё должно работать и ровно так же, как и сами программисты тщательно убеждается в том, что оно работает так, как задумано - неработа его не интересует), либо штучный человек особого склада ума.

Это какие-то абстрактные рассуждения, какое отношение они имеют к решению поставленной задачи? Нет ресурсов или не умеем - не беремся.

>Может, но тогда см. выше.

Что именно выше? Девочек не нанимать? В некоторых проектах нужны как раз девочки - по соотношению цена/качество - но не в Фобос-Грунте.

>Дык а в реальности задёшево и набирают.

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

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

Это не чудесное решение, это то, как делают в компаниях-разработчиках софта, которые не первый десяток лет на рынке. Но, конечно, в каждой конторе могут придумать свой самобытный и "не имеющий аналогов в мире" Путь, это их право.

С уважением, Павел
От doctor64
К Павел Войлов (Т-28А) (01.02.2012 19:07:56)
Дата 01.02.2012 19:36:58

Подписываюсь под каждым словом.

Дополню, что в моей мелкой конторе, делающей чипы для связи, тест девелоперы зарабатывают побольше многих фирмварщиков.