Миф о документации, продолжение
И самое интересное - стоит сказать про "документацию" правду, которую в глубине души и так все знают, - и это обычно провоцирует бурление говн, и поток самых невероятных высказываний.
Давайте посмотрим, почему же люди пишут документы тогда, когда они их действительно пишут, а не рассуждают о том, как бы хорошо было, если бы они были, и как плохо, ( Read more... )
Давайте посмотрим, почему же люди пишут документы тогда, когда они их действительно пишут, а не рассуждают о том, как бы хорошо было, если бы они были, и как плохо, ( Read more... )
Reply
Reply
Reply
Reply
нужно понимать, что сколько бы у вас не было тестировщиков, они не правят баги, не оптимизируют процесс, не принимают решение о выпуске. Задача тестирования - предоставить информацию о том, насколько все плохо. Задача команды - сделать, чтобы было хорошо. Задача QA - сделать, чтобы в следующий раз было лучше.
Reply
И если человек не склонен относить Software Development Process целиком к QA, как например - я, то это, поверьте, ровным счетом ничего не значит. :) QA, тестирование - это не более чем названия. Научить их употреблять можно даже осла, понимание процесса разработки ПО у него от этого не появится.
Reply
если коротко, QA - обеспечение качества, предотвращение дефектов. чаще всего в форме построения и совершенствования процессов. QA не тестируют. Теоретически, построив хороший процесс, можно вообще обойтись без тестирования как выделенной активности.
Тестирование - это QC (контроль качества) плюс разведка (оценка качества). Тестировщики не управляют процессом, и напрямую не влияют на качество. У вас может быть отличная команда тестеров, и 100500 обнаруженных, но неисправленных багов.
Reply
"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 разработка подобных средств никак не относится, по крайней мере, в терминологии, принятой в нашей индустрии и в микроэлектронике.
Во всех остальных случаях можно только стараться находить ошибки пораньше, "предотвратить" их появление невозможно.
Reply
QA, QC и Testing - совершенно разные активности.
Смотрите. Я могу находить дефекты определенного класса в коде, который написал кодер Вася. И он их будет исправлять, и вносить новые. Это тестирование. Но как тестировщик (или "QA Lead"), я не могу отправить Васю на курсы по Java, после которых он перестанет дефекты такого класса вносить. В первом случае я качество контролирую, во втором - обеспечиваю.
Набор defect prevention техник достаточно большой, для какой-то команды это может быть просто "начать использовать VCS", для какой-то - обучение, например. Скажем, у нас в команде нет людей с опытом разработки высоконагруженных многопоточных приложений, и замена языка никак не спасет продукт от соответствующих проблем.
Что касается программистов, то, как мне кажется, *инженер* очень сильно отличается от *кодера* - другой опыт, отношение к работе и область ответственности.
Reply
Да, существуют отдельные области, где инженеры придумывают алгоритмы на бумажке, по 10 раз все просчитывают, перепроверяют, доказывают корректность, а потом дают бумажку кодеру, чья единственная ответственность -- не наляпать там ошибок при переводе с одного языка на другой.
На практике, кодер -- это жуткое расточительство. Человек должен понимать, что он и для кого делает. Он должен понимать предметную область до определенной степени, он часто должен уметь задать правильные вопросы по требованиям, которые он берет для разработки. Это обходится гораздо дешевле и дает возможность разрабатывать софт и внедрять его, а не просто лабать код.
Reply
Reply
Нет, это невозможно. По крайней мере никому в этом мире ещё не удавалось.
>Тестировщики не управляют процессом, и напрямую не влияют на качество. У вас может быть отличная команда тестеров, и 100500 обнаруженных, но неисправленных багов.
Ну исправление багов -- это конечно задача разработчиков.
Но с практической точки зрения нельзя взять только людей, которые узко специализируются только на тестировании, но не взять QA в вашем определении.
Также бессмысленно наличие только людей которые не тестируют, но точат процесс тестирования.
В этой связи нужны и те и те. Что опять-таки приводит к практическому смешению обязанностей. В этом случае более жизнеспособна форма, когда есть QA Lead, который с одной стороны может и процесс подогнуть и посмотреть как люди тестируют и им в чем-то помочь. С другой стороны есть просто QA, на которых лежит рутина по тестированию и его автоматизации.
Reply
Теоретически, это (в некоторой степени) возможно, в случае, если код целиком генерируется из формальной спецификации, непротиворечивость и полнота которой доказывается.
Скажем, в университете нам преподавали Btoolkit. http://en.wikipedia.org/wiki/B-Method
Стоит отдельно отметить, что никто в здравом уме не будет считать разработку и применение таких методов как B-Method заслугой и результатом QA. :) У меня лично как-то язык не поворачивается. :)
Однако, даже в этом случае не исключено расхождение между спецификацией, и реальной ситуацией - тем, что на самом деле требуется. Так что не худо бы все-таки испытать софтину, разработанную с применением B-method-а. А вот разработотка "программы и методики испытаний" к ней - это уже задача QA. Как и сама проверка.
Reply
Я надеюсь непротиворечивость и полнота тоже совершенно автоматически и точно устанавливается за разумное время :) А то можно ведь ошибиться при доказательстве (такое вот часто бывало при доказательстве теоремы Ферма. Считается, например, что сам Ферма провел какое-то рассуждение, которые он посчитал очевидным, но при этом оно было не вполне корректно)
Но даже в этом случае, как справедливо замечено, возможны ошибки на уровне как изначальных предпосылок и так и требований к результату, которые формально будут соблюдены, но хэппе никто все равно не станет.
На практике же я не могу представить себе полного разделения между тем, кто придумывает как вести тестирование и тем, кто тестирует. Это сродни архитектору, который "архитектурит", а вот работу делают все остальные, при этом на код архитектор не смотрит.
Reply
Доказательство там полностью автоматическое, в результате успешного доказательства генерируется программа. Как-то так.
Этот курс был у моих друзей с другого потока. Им надо было написать квиксорт. Постоянно рассказывали об ощущениях, и матерились страшенно. :)
> На практике же я не могу представить себе полного разделения между тем, кто придумывает как вести тестирование и тем, кто тестирует. Это сродни архитектору, который "архитектурит", а вот работу делают все остальные, при этом на код архитектор не смотрит.
Ага. И сродни главбуху, который разрабатывает план счетов с типовыми проводками для операций, минимизируя налоги, но при этом не отвечает за бухучет.
Reply
Как описать с использованием далеко не самого мощного выразительного средства концепцию, что были какие-то элементы, а потом их перенумеровали, но при этом не появилось ни новых элементов, ни старых не исчезло и при этом они стали упорядочены -- это сложно. Очень сложно для такой простой задачи.
Reply
Leave a comment