?

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:


Unshaven and Drunk
rlabs at 2011-06-19 09:21 (UTC) (Link)
сработает, если а) это будут достаточно опытные тестировщики, а не QA, и б) качество релизов будут поднимать разработчики.
Lost In Paradox
localstorm at 2011-06-19 10:01 (UTC) (Link)
Объясните как вы понимаете разницу между QA и тестировщиками в таком случае.
Gaperton
gaperton at 2011-06-19 10:39 (UTC) (Link)
Одно по английски, другое - по русски :).
Unshaven and Drunk
rlabs at 2011-06-19 10:53 (UTC) (Link)
привычка путать QA и тестирование приводит к неоправданным ожиданиям, вроде того, что "у нас низкое качество - давайте наймем больше тестеров" или к перевешиванию ответственности за качество на тестировщиков.

нужно понимать, что сколько бы у вас не было тестировщиков, они не правят баги, не оптимизируют процесс, не принимают решение о выпуске. Задача тестирования - предоставить информацию о том, насколько все плохо. Задача команды - сделать, чтобы было хорошо. Задача QA - сделать, чтобы в следующий раз было лучше.
Gaperton
gaperton at 2011-06-19 11:12 (UTC) (Link)
Здесь речь идет о тестерах и QA Engineer-ах, а не о тестировании и понятии Quality Assurance.

И если человек не склонен относить Software Development Process целиком к QA, как например - я, то это, поверьте, ровным счетом ничего не значит. :) QA, тестирование - это не более чем названия. Научить их употреблять можно даже осла, понимание процесса разработки ПО у него от этого не появится.
Unshaven and Drunk
rlabs at 2011-06-19 10:44 (UTC) (Link)
прозвучит банально, но http://www.google.com/search?q=qa+vs+testing

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

Тестирование - это QC (контроль качества) плюс разведка (оценка качества). Тестировщики не управляют процессом, и напрямую не влияют на качество. У вас может быть отличная команда тестеров, и 100500 обнаруженных, но неисправленных багов.
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-а. С этими проблемами руководитель команды разбирается, ему за это деньги платят.
Lost In Paradox
localstorm at 2011-06-19 11:14 (UTC) (Link)
>Теоретически, построив хороший процесс, можно вообще обойтись без тестирования как выделенной активности.

Нет, это невозможно. По крайней мере никому в этом мире ещё не удавалось.

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

Ну исправление багов -- это конечно задача разработчиков.

Но с практической точки зрения нельзя взять только людей, которые узко специализируются только на тестировании, но не взять QA в вашем определении.

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

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

Теоретически, это (в некоторой степени) возможно, в случае, если код целиком генерируется из формальной спецификации, непротиворечивость и полнота которой доказывается.

Скажем, в университете нам преподавали Btoolkit. http://en.wikipedia.org/wiki/B-Method

Стоит отдельно отметить, что никто в здравом уме не будет считать разработку и применение таких методов как B-Method заслугой и результатом QA. :) У меня лично как-то язык не поворачивается. :)

Однако, даже в этом случае не исключено расхождение между спецификацией, и реальной ситуацией - тем, что на самом деле требуется. Так что не худо бы все-таки испытать софтину, разработанную с применением B-method-а. А вот разработотка "программы и методики испытаний" к ней - это уже задача QA. Как и сама проверка.
Lost In Paradox
localstorm at 2011-06-19 11:35 (UTC) (Link)
>код целиком генерируется из формальной спецификации, непротиворечивость и полнота которой доказывается

Я надеюсь непротиворечивость и полнота тоже совершенно автоматически и точно устанавливается за разумное время :) А то можно ведь ошибиться при доказательстве (такое вот часто бывало при доказательстве теоремы Ферма. Считается, например, что сам Ферма провел какое-то рассуждение, которые он посчитал очевидным, но при этом оно было не вполне корректно)

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

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

Доказательство там полностью автоматическое, в результате успешного доказательства генерируется программа. Как-то так.

Этот курс был у моих друзей с другого потока. Им надо было написать квиксорт. Постоянно рассказывали об ощущениях, и матерились страшенно. :)

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

Ага. И сродни главбуху, который разрабатывает план счетов с типовыми проводками для операций, минимизируя налоги, но при этом не отвечает за бухучет.
Lost In Paradox
localstorm at 2011-06-19 11:47 (UTC) (Link)
Да было у меня что-то похожее. Самое сложное, при кажущейся очевидности, это описать требования. Пусть даже не квиксорт, а просто какой-нибудь сорт.

Как описать с использованием далеко не самого мощного выразительного средства концепцию, что были какие-то элементы, а потом их перенумеровали, но при этом не появилось ни новых элементов, ни старых не исчезло и при этом они стали упорядочены -- это сложно. Очень сложно для такой простой задачи.
Lost In Paradox
localstorm at 2011-06-19 11:57 (UTC) (Link)

Ради смеха

Я понимаю, что все понимают, что все это слишком далеко от практики, но тем не менее. Эта мысль мне показалась забавной.

Мне вот интересно, как тюнить первоманс в приложениях, созданных с применением B-Method? Это ж надо нехилое воображение иметь, чтобы написать такую формально корректную спеку, и чтобы код сгенерировался оптимальный. Это, наверное, только изобретателю этого кодогенератора по зубам...
hedgeov
hedgeov at 2011-06-19 17:52 (UTC) (Link)
Касательно формальной спецификации: был у меня практический опыт работы с кодом, генерированным из UML, непротиворечивого и полного. В общем там было всё ооооочень плохо :) Практическая рекомендация опытных коллег была такая: эта хрень точно и без ошибок умеет вот эту функцию выполнять, проверяли. Если тебе надо еще и вот это вот использовать -- напиши своё, то что есть ну очень кривое и не чинится за разумное время.
Previous Entry  Next Entry