Как стать автором
Обновить

Комментарии 30

Почему на КПВ менеджер представлен человеком, а программист — белкой?
НЛО прилетело и опубликовало эту надпись здесь
Это не программист, это тестировщик.
Да, это диалог двух тестировщиков. Белка — неразумный тестировщик (новичок), Катька — более опытный товарищ
А мне тоже показалось, что это программист и тестировщик
Требовать с разработчика документацию и «что ты проверял» — хех, мечты мечты ))
Если документация есть, но в JIRA нет на нее ссылки в последнем комментарии — задача переоткрывается. (суровые времена, суровые меры)

А кто тогда переоткрывает задачу, если там нет ссылки на документацию?
Это же как раз тестировщик задачу и закрывал.
Я переоткрывала, я была оплотом бюрократии, когда все дружно на ретро решили, что этот чек-лист разумен. (я — тестировщик)

Спрошу по-другому. Зачем вы как тестировщик закрывали задачу, если там не было ссылки на документацию?

Что вы понимаете под «вы»? Вы — это лично я? Или «вы» — это все наши тестировщики? Я не закрывала задачи без ссылок на документацию, только если забыв ее вложить. Или если я думала, что документация тут не нужна. Иногда это было правильно, а иногда нет, просто я про какую-то документацию не подумала / забыла о ней

Вы — это лично вы. Почему вам приходится переоткрывать задачу, которую вы же и закрывали? Или вы как санитар ходите по чужим задачам и переоткрываете?) Всё равно вопрос тогда, почему другой тестировщик закрыл задачу, когда есть правило не закрывать таски без ссылки на доку? Видимо, кто-то счёл, что документация там не нужна.

Да, я как санитар ходила по чужим задачам и переоткрывала. Причины других разные — подумал, что документация не нужна. Доку написал, ссылку не дал. Забыл, что нужно пополнить доку «вот тут». Дока нужна, но не было времени ее сделать…

Написать чек-лист ≠ все сразу начали работать по нему. «Да, да, это очень хороший чек-лист и мы будем по нему работать, обязательно… Когда-нибудь потом»
имхо, все это сильно излишне.
Хочешь посмотреть, были ли написаны тесты — найди в гите коммит с номером задачи и посмотри.
Документация — аналогично, в коде.
Там же можно посмотреть историю, что стало с этим кодом потом.
А дублировать документацию — это надо следить за ее актуальностью. Следовательно — иметь хороший инструмент для этого. И таски, имхо, нужным функционалом не обладают.
В смысле «дублировать документацию»? Документация пишется не в джире, а в вики. В джире дается на нее ссылка.

А вот по поводу «сиди, копайся во вкладке коммитов и сам ищи» — это как раз неуважение к чужому времени. Тебе лень написать закрывающий коммент, а другие должны искать, тратить на это время. Нет, если у вас на работе всем в кайф тратить время впустую — кто ж против. У нас даже те, кто сначала отмахивается «да посмотри в коммитах» раз сам с таким столкнется, два, и тоже скажет «Ага, с комментарием то удобнее и быстрее»
если честно, очень давно не видел актуальной вики.

А документация может писаться в коде, например — javadoc.

По поводу копаться-искать — тесты лежат в строго определенном месте. Давайте предположим, что программер не старался специально всех запутать.
Это статья для тестировщика, который закрывает задачу, проверив, что:
а) все работает
б) документация написана
в) автотесты тоже есть и написаны

От «программера» требуется другое — написать, что потестить, если затронуты разные участки кода. Мб подсказать, как можно проверить специфическое место.

javadoc заказчику тоже отдавать? У нас заказной продукт и есть внутренняя документация «для своих» и внешняя для заказчиков. И всю стараемся поддерживать в актуальном состоянии. Да, разумеется, документация устаревает, ну так она и в вики, и в коде устареет. Увидел старье? Поправь, на худой конец поставь задачу на улучшение.

Ну и плюс генерация из кода, но в красивом виде )

>javadoc заказчику тоже отдавать?
оно автоматически из него генерится. Но речь идет, конечно же, о конкретном уровне документации. Какую кнопочку нажимать, тут не напишешь.
>Это статья для тестировщика
Из статьи это не очевидно.
>Увидел старье? Поправь, на худой конец поставь задачу на улучшение.
В коде я вижу и код и документацию к нему одновременно. Следовательно, с многократно большей вероятностью поправлю, чем вики. А документацией «для своих» в 99% случаев являются названия классов, методов и переменных.
> Из статьи это не очевидно.
По хабам разве что. Хотя в разных компаниях этим разные люди занимаются. Где-то разработчики сами задачи закрывают, где-то только аналитики доку правят. У всех свои процессы, но при закрытии задачи этот чек-лист никому не повредит, если не лень будет сделать.

> А документацией «для своих» в 99% случаев являются названия классов, методов и переменных.
Ну, у нас не так)
Повредит. Как минимум, займет время.
Принесет ли соразмерную пользу? Вот это ведь и обсуждаем. Мне пока-что это кажется односторонним пожеланием. «Чтобы другие сделали так, как удобно мне». А для тех, кто это должен делать, я это вижу лишь очередной «бюрократией», которую все так не любят.
Завтра ваш коллега заболеет/уйдет в декрет/выйграет в лоттерею и уйдет из компании со словами: «Все, я богат. Пока, неудачники, я вас всегда ненавидел!».
Вам отдадут на доработку его недокументированный код. Что вам останется делать в такой ситуации? Переписывать с нуля?
Бюрократия — это когда надо 100500 всего сделать, причем никому не нужного. Обязательно документацию «по феншую» написать и прочее. Никто не предлагает заниматься бюрократией. Если ты ЧТО-ТО сделал, дай ссылку в закрывающем комментарии.

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

Если же в компании не принято писать документацию, автотесты… Ну да, ссылку будет некуда давать, увы и ах. У нас принято
Ну останетесь вы с неполной, устаревшей и неструктурированой документацией и что? Так лучше?

И еще: даже самая подробная, хорошо структурированая докуметация бесполезна если о ее существовании не знаешь. Это камень в вики (Confluence в частности), которая фактически write-only.
Если вы вообще не пишите документацию на проекте ибо «фи фи фи вики, только код, только хардкор» — да, ссылку давать некуда.

Если автотесты тоже нигде не описываются, потому что они написаны на простом и понятном коде и все их сразу понимают, даже джуны (ню-ню, но допустим) — да, тогда вам не на что давать ссылки.

И все равно остается закрывающий коммент «что вообще проверялось». Чтобы впоследствии человек мог прочитать его и либо воспроизвести тесты, либо проверить, проводилось ли тестирование именно его случая
ни разу при вхождении в проект не рассчитывал на документацию. Тем более в вики. Код — сам по себе документация. И надо его писать так, чтобы он легко читался. Описано, например, в «чистый код».
Надо, кто ж спорит. Но в чистоту кода верится еще меньше, чем в чистоту документации
хз, на всех проектах, где я работал, за чистотой кода следили. Даже периодически приводили в порядок старый код.
Вот прям везде хороший код, но при этом ноль документации, потому что она вся в коде, даже тесты?
Вот это, кстати, правильный подход. Надо тебе доку потому, что без нее сложно и путаешься — напиши. Автотесты (юнит тесты) тебе помогают? Пиши.

Заставлять кого-то другого делать «как правильно» — неправильно.

Вики тут хороший пример. Мы ведем вики (не системно), но она всегда устаревшая. Но когда приходит кто-то с вопросом и тебе влом отвечать на одно и то-же десятый раз — вот тогда вики обновляется и отдается. А самим нам она не нужна вообще-то. Делать что-то, что не помогает в работе смысла нет даже если оно «правильно» и «все знают что...».
Необычайно удивительно узнать, что такая проблема существовала в 2013 году и тем более осталась актуальной в 2019. Чем, собственно говоря, занимается отдел контроля процессов? По какому процессу в целом осуществляется разработка?
1. Я написала «статья актуальна», а статья про чек-лист, а не про проблему. Чек-лист остался актуальным, только примеры для новичков дописали. А что в нем должно было устареть? Документацию перестали писать? Нет. Автотесты перестали писать? Тоже нет.

2. Отдел контроля процессов? Как я счастлива, что живу не в столь бюрократическом мире)) Это мне про статью то говорят что «бюрократия жеж, целых 2 минуты тратить ссылки вставлять, о кошмар!!!», а тут целый отдел, который рассказывает тебе, как строить процессы в твоем отделе))

3. Как влияет процесс разработки на закрывающий комментарий тестировщика? Он что при ватерфолл, что при аджайл, что при золотой середине актуален. ЕСЛИ человек хочет, чтобы любой коллега мог открыть задачу и сразу понять, что было по ней сделано. Если не хочет, то чек-лист неактуален
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории