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

[gaperton]

И самое интересное - стоит сказать про "документацию" правду, которую в глубине души и так все знают, - и это обычно провоцирует бурление говн, и поток самых невероятных высказываний.

Давайте посмотрим, почему же люди пишут документы тогда, когда они их действительно пишут, а не рассуждают о том, как бы хорошо было, если бы они были, и как плохо,

Comments

[rlabs]

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

[malica_dee]

А еще можно ввести дресс-код и штрафы за опоздания.

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

Про документацию

[pingback_bot]

User localstorm referenced to your post from Про документацию saying: [...] Часть 2 [...]

[localstorm]

Привет, как обычно насладился зарядом здравого смысла.. :)

Есть вопрос, на который бы я хотел узнать твой взгляд, gaperton. Вопрос такой. Какие последствия это влечет для активности, называемой QA

[gaperton]

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

1) QA проверяет конкретное изменение, плюс к этому, конечно, нужен регрессионный тест ("все остальное не изменилось"). Регрессионный тест может быть автоматизирован.
2) В случае, если регрессионный тест проводится вручную QA, им нужен тест-план, по которому они должны идти. Тест план в этом случае обновляется силами QA. Это достаточно дорогой подход к тестированию - но он практически возможен.
3) "...и проанализировать влияние изменения на систему в целом..." - это в общем случае могут только программисты сделать.

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

[localstorm]

Кстати, вот ещё интересный вопрос. Да, все изложенное о документации соответствует действительности. Вот что тогда интересно

[rlabs]

сработает, если а) это будут достаточно опытные тестировщики, а не QA, и б) качество релизов будут поднимать разработчики.

[localstorm]

Объясните как вы понимаете разницу между QA и тестировщиками в таком случае.

[gaperton]

Одно по английски, другое - по русски :).

[sim0nsays]

Очень разумно и здорово, спасибо.
Так на практике всегда у меня и бывало, но структуризация и аргументация хорошая. В JavaDoc впрочем все равно не верю.

Эх, было бы на английском - всем на работе бы давал читать.