?

Log in

November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

Миф о документации, продолжение

Posted on 2011.06.18 at 23:06

Comments:


Gaperton
gaperton at 2011-06-19 10:58 (UTC) (Link)
Разумеется они тестируют. :)
"The QA engineer is a test engineer, but he/she does more than just testing. The good QA engineer understands the entire software development process... blah-blah-blah...".

С тем же успехом можно дать поиск по "software engineering vs coding". Software Engineer не перестанет после этого быть программистом, а программист не станет кодером, который тока код пишет, и ничего вокруг не знает и не понимает.

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

Во всех остальных случаях можно только стараться находить ошибки пораньше, "предотвратить" их появление невозможно.
Unshaven and Drunk
rlabs at 2011-06-19 11:57 (UTC) (Link)
то, что тестировщика привыкли называть QA, не делает его QA.
QA, QC и Testing - совершенно разные активности.

Смотрите. Я могу находить дефекты определенного класса в коде, который написал кодер Вася. И он их будет исправлять, и вносить новые. Это тестирование. Но как тестировщик (или "QA Lead"), я не могу отправить Васю на курсы по Java, после которых он перестанет дефекты такого класса вносить. В первом случае я качество контролирую, во втором - обеспечиваю.

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

Что касается программистов, то, как мне кажется, *инженер* очень сильно отличается от *кодера* - другой опыт, отношение к работе и область ответственности.
Lost In Paradox
localstorm at 2011-06-19 12:10 (UTC) (Link)

Dirty Little Secret

Открою, казалось бы, очевидную истину. Кодер -- это почти миф.

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

На практике, кодер -- это жуткое расточительство. Человек должен понимать, что он и для кого делает. Он должен понимать предметную область до определенной степени, он часто должен уметь задать правильные вопросы по требованиям, которые он берет для разработки. Это обходится гораздо дешевле и дает возможность разрабатывать софт и внедрять его, а не просто лабать код.
Gaperton
gaperton at 2011-06-19 12:15 (UTC) (Link)
> то, что тестировщика привыкли называть QA, не делает его QA.

Именно что делает.

> Но как тестировщик (или "QA Lead"), я не могу отправить Васю на курсы по Java, после которых он перестанет дефекты такого класса вносить. В первом случае я качество контролирую, во втором - обеспечиваю.

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

> Набор defect prevention техник достаточно большой, для какой-то команды это может быть просто "начать использовать VCS"

Аналогично. Решение о применении VCS относится к общей технологической политики компании, что есть ответственность топ-менеджмента, и относится к SCM, а не QA.

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

А это вообще не ваше дело как QA Engineer-а. С этими проблемами руководитель команды разбирается, ему за это деньги платят.
Previous Entry  Next Entry