Исходно чек-лист записала как напоминание, в том числе и себе. Потому что к задачам приходится возвращаться, в том числе людям, которые их НЕ проверяли. Например, во время регрессии надо хотя бы базово проверить функционал.
И вот ты открываешь задачу, листаешь до последнего комментария посмотреть, какая документация, что как работает, а там… Пусто. Или скромное «Все проверено, все ок». А документация где? Я же не в теме задачи, я хочу прочитать побольше!
Или если заказчик пишет, что у него что-то не работает, а ты хочешь проверить, покрыта ли ситуация автотестами. Идешь в задачу, а там нет ссылки на автотесты. Их вообще не писали? Или просто ссылку не дали? Приходится выяснять…
Так и появился чек-лист закрытия задачи:
- Проверить задачу (здравствуй, кэп). Используйте готовые чек-листы для типовых задач + избегайте типовых ошибок в автотестах.
- Написать по ней документацию (min — пользовательскую, max — пользовательскую и «для коллег»).
- В JIRA оставить комментарий «проверил на сборке core ***, customer ***, посмотрел то, то и то, дока вот она».
- Приложить к задаче тестовые данные, если что-то проверялось вручную.
Он вроде как «про нас», но на самом деле универсальный. Ну разве что в вашей компании тестировщик не пишет документацию, тогда второй пункт меняем на «проверить, что вся нужная документация написана или актуализирована».
Разберем каждый пункт отдельно.
Документация
Если документации никакой по задаче нет (неважно, баг это или improvement), она переоткрывается.
Если документация есть, но в JIRA нет на нее ссылки в последнем комментарии — задача переоткрывается. (суровые времена, суровые меры)
Минимально надо написать / исправить пользовательские требования.
Если же были изменения в конфигах проекта, надо проверить, что есть техническая документация по такому изменению. Если ее нет, пишем.
Если добавлялась задачи миграции — сразу написать общую инструкцию по обновлению релиза.
Комментарий
Если придется возвращаться к задаче позднее, иногда бывает полезно узнать, на какой версии тестировал тестировщик и что он проверял (вкратце).
Записываем версии из mercurial, даем ссылку на документацию и краткое описание: Проверил вручную через интерфейс / SOAP / буфер.
Тестовые данные
Если задача проверялась вручную, обязательно прикладываем к ней тестовые данные (если они не весят 3Тб)
Да, эти данные можно получить из общего хранилища, но там они могут быть уже изменены или даже удалены. (У нас есть общее хранилище тестовых данных, но все файлики хранятся на диске. В системе контроля версий пробовали, не понравилось, туда вообще никто не коммитит, а на диск хоть как-то складывают)
Иногда кажется, что это все фигня, одного контрагента создали или выборки по view собрали.
Но если через полгода у Заказчика всплывет проблема и будут подниматься старые задачи для воспроизведения, эти файлики очень помогут, проверено и не раз. А вот актуальные данные из хранилища уже устареют.
Помните — взять готовый sql-запрос и проверить по базе займет 1 минуту. А снова сидеть и составлять этот запрос — это может и час занять, если не больше. Экономьте свое время!
Поэтому:
- Создали БД из dbStart — аттачим dbStart (экселька, в которой сохранен срез базы для тестирования).
- Загружали тестовые данные из хранилища — аттачим загруженный файл.
- Загружали их откуда-то еще — добавляем в хранилище и аттачим к задаче.
См также:
Как в Maven быстро создать БД по шаблону? — о том, как мы делаем dbStart для тестирования.
Коммент с тестами, докой и данными должен быть заключительным. А не так, что «я написал такие-то тесты, нашел такие-то проблемы» и потом переписка с разработчиком на 20 комментов, а твой «заключительный» затерялся где-то в середине. Если затерялся — продублируй (старый можно удалить).
Примеры
Когда мы набрали новых тестировщиков, этой статьи стало мало. Потому что задачи джуниоров я переоткрывала и рассказывала, как надо исправить завершающий комментарий, чтобы он был понятным. А они, в свою очередь, просили примеры «как правильно».
Так в статье появился еще один блок — «Примеры». Тут важно дать ссылки на реальные задачи в рабочей jira + какие-то доп статьи в конфлюенсе. Примеры должны быть разные: как на огромные комментарии, когда по задаче написано 200 автотестов, так и на небольшие задачи, с которыми ребята будут сталкиваться каждый день.
Я ссылки давать не буду, но смысл, надеюсь, понятен. Выглядит раздел примерно так:
Примеры больших задач, где много доки и тестов:
- TEST-679 — Доработки JMS
- TEST-760 — Обратный поток в разные JMS-источники
Примеры небольших задач: TEST-816 — расширили модель согласий.
При тестировании «добавить функционал в Демо» обращайте особое внимание на рефакторинг — выносите документацию к core, тесты все в Демо, а остальное через инклюд итд. Пример: TEST-4519 — Добавить кросс-сверку ФЛ-ИП в Демо.
Примеры полезных комментов «как я это тестил», к которым возвращаешься повторно (их лучше в HOWTO выносить, но и в задаче надо оставить): TEST-812 — Сделать перестроение индекса неблокируемым (куда ставить бряку*, чтобы проверить)
* Бряка: Breakpoint (жаргонное) — точка остановки кода. Это когда вы запускаете исходный код в режиме отладки, такие точки помогают отследить параметры, локализовать ошибку.
P.S. — другие статьи по тестированию см в моем блоге
Комментарии (30)
dimkrayan
28.08.2019 10:44имхо, все это сильно излишне.
Хочешь посмотреть, были ли написаны тесты — найди в гите коммит с номером задачи и посмотри.
Документация — аналогично, в коде.
Там же можно посмотреть историю, что стало с этим кодом потом.
А дублировать документацию — это надо следить за ее актуальностью. Следовательно — иметь хороший инструмент для этого. И таски, имхо, нужным функционалом не обладают.
Molechka Автор
28.08.2019 14:24В смысле «дублировать документацию»? Документация пишется не в джире, а в вики. В джире дается на нее ссылка.
А вот по поводу «сиди, копайся во вкладке коммитов и сам ищи» — это как раз неуважение к чужому времени. Тебе лень написать закрывающий коммент, а другие должны искать, тратить на это время. Нет, если у вас на работе всем в кайф тратить время впустую — кто ж против. У нас даже те, кто сначала отмахивается «да посмотри в коммитах» раз сам с таким столкнется, два, и тоже скажет «Ага, с комментарием то удобнее и быстрее»dimkrayan
28.08.2019 15:04если честно, очень давно не видел актуальной вики.
А документация может писаться в коде, например — javadoc.
По поводу копаться-искать — тесты лежат в строго определенном месте. Давайте предположим, что программер не старался специально всех запутать.Molechka Автор
28.08.2019 15:12Это статья для тестировщика, который закрывает задачу, проверив, что:
а) все работает
б) документация написана
в) автотесты тоже есть и написаны
От «программера» требуется другое — написать, что потестить, если затронуты разные участки кода. Мб подсказать, как можно проверить специфическое место.
javadoc заказчику тоже отдавать? У нас заказной продукт и есть внутренняя документация «для своих» и внешняя для заказчиков. И всю стараемся поддерживать в актуальном состоянии. Да, разумеется, документация устаревает, ну так она и в вики, и в коде устареет. Увидел старье? Поправь, на худой конец поставь задачу на улучшение.
Ну и плюс генерация из кода, но в красивом виде )
dimkrayan
28.08.2019 15:22>javadoc заказчику тоже отдавать?
оно автоматически из него генерится. Но речь идет, конечно же, о конкретном уровне документации. Какую кнопочку нажимать, тут не напишешь.
>Это статья для тестировщика
Из статьи это не очевидно.
>Увидел старье? Поправь, на худой конец поставь задачу на улучшение.
В коде я вижу и код и документацию к нему одновременно. Следовательно, с многократно большей вероятностью поправлю, чем вики. А документацией «для своих» в 99% случаев являются названия классов, методов и переменных.Molechka Автор
28.08.2019 15:40> Из статьи это не очевидно.
По хабам разве что. Хотя в разных компаниях этим разные люди занимаются. Где-то разработчики сами задачи закрывают, где-то только аналитики доку правят. У всех свои процессы, но при закрытии задачи этот чек-лист никому не повредит, если не лень будет сделать.
> А документацией «для своих» в 99% случаев являются названия классов, методов и переменных.
Ну, у нас не так)dimkrayan
28.08.2019 15:46Повредит. Как минимум, займет время.
Принесет ли соразмерную пользу? Вот это ведь и обсуждаем. Мне пока-что это кажется односторонним пожеланием. «Чтобы другие сделали так, как удобно мне». А для тех, кто это должен делать, я это вижу лишь очередной «бюрократией», которую все так не любят.Sanchek
28.08.2019 17:54Завтра ваш коллега заболеет/уйдет в декрет/выйграет в лоттерею и уйдет из компании со словами: «Все, я богат. Пока, неудачники, я вас всегда ненавидел!».
Вам отдадут на доработку его недокументированный код. Что вам останется делать в такой ситуации? Переписывать с нуля?Molechka Автор
28.08.2019 17:57Бюрократия — это когда надо 100500 всего сделать, причем никому не нужного. Обязательно документацию «по феншую» написать и прочее. Никто не предлагает заниматься бюрократией. Если ты ЧТО-ТО сделал, дай ссылку в закрывающем комментарии.
Афигеть просто сколько времени займет дать ссылку на страничку, которая у тебя перед глазами (ты же ее редактировал только что). Никак не сопоставимо с ручным поиском этой страницы человека, не знакомого с задачей, да :)
Если же в компании не принято писать документацию, автотесты… Ну да, ссылку будет некуда давать, увы и ах. У нас принято
UnclShura
28.08.2019 18:01Ну останетесь вы с неполной, устаревшей и неструктурированой документацией и что? Так лучше?
И еще: даже самая подробная, хорошо структурированая докуметация бесполезна если о ее существовании не знаешь. Это камень в вики (Confluence в частности), которая фактически write-only.Molechka Автор
28.08.2019 20:38Если вы вообще не пишите документацию на проекте ибо «фи фи фи вики, только код, только хардкор» — да, ссылку давать некуда.
Если автотесты тоже нигде не описываются, потому что они написаны на простом и понятном коде и все их сразу понимают, даже джуны (ню-ню, но допустим) — да, тогда вам не на что давать ссылки.
И все равно остается закрывающий коммент «что вообще проверялось». Чтобы впоследствии человек мог прочитать его и либо воспроизвести тесты, либо проверить, проводилось ли тестирование именно его случая
dimkrayan
28.08.2019 18:02ни разу при вхождении в проект не рассчитывал на документацию. Тем более в вики. Код — сам по себе документация. И надо его писать так, чтобы он легко читался. Описано, например, в «чистый код».
Molechka Автор
28.08.2019 20:39Надо, кто ж спорит. Но в чистоту кода верится еще меньше, чем в чистоту документации
UnclShura
28.08.2019 17:57Вот это, кстати, правильный подход. Надо тебе доку потому, что без нее сложно и путаешься — напиши. Автотесты (юнит тесты) тебе помогают? Пиши.
Заставлять кого-то другого делать «как правильно» — неправильно.
Вики тут хороший пример. Мы ведем вики (не системно), но она всегда устаревшая. Но когда приходит кто-то с вопросом и тебе влом отвечать на одно и то-же десятый раз — вот тогда вики обновляется и отдается. А самим нам она не нужна вообще-то. Делать что-то, что не помогает в работе смысла нет даже если оно «правильно» и «все знают что...».
shockable
30.08.2019 06:39Необычайно удивительно узнать, что такая проблема существовала в 2013 году и тем более осталась актуальной в 2019. Чем, собственно говоря, занимается отдел контроля процессов? По какому процессу в целом осуществляется разработка?
Molechka Автор
30.08.2019 11:171. Я написала «статья актуальна», а статья про чек-лист, а не про проблему. Чек-лист остался актуальным, только примеры для новичков дописали. А что в нем должно было устареть? Документацию перестали писать? Нет. Автотесты перестали писать? Тоже нет.
2. Отдел контроля процессов? Как я счастлива, что живу не в столь бюрократическом мире)) Это мне про статью то говорят что «бюрократия жеж, целых 2 минуты тратить ссылки вставлять, о кошмар!!!», а тут целый отдел, который рассказывает тебе, как строить процессы в твоем отделе))
3. Как влияет процесс разработки на закрывающий комментарий тестировщика? Он что при ватерфолл, что при аджайл, что при золотой середине актуален. ЕСЛИ человек хочет, чтобы любой коллега мог открыть задачу и сразу понять, что было по ней сделано. Если не хочет, то чек-лист неактуален
rboots
Почему на КПВ менеджер представлен человеком, а программист — белкой?
tvr
Ну тут ещё вопрос кем лучше быть — антропоморфной говорящей белкой с носом или человеком без оного.
Кстати, интересно, как Зелёный пис смотрит на эксплуатацию этих милых, явно разумных, созданий?
Leadmonkey
Это не программист, это тестировщик.
Molechka Автор
Да, это диалог двух тестировщиков. Белка — неразумный тестировщик (новичок), Катька — более опытный товарищ
hudson
А мне тоже показалось, что это программист и тестировщик
Molechka Автор
Требовать с разработчика документацию и «что ты проверял» — хех, мечты мечты ))
raptors
А кто тогда переоткрывает задачу, если там нет ссылки на документацию?
Это же как раз тестировщик задачу и закрывал.
Molechka Автор
Я переоткрывала, я была оплотом бюрократии, когда все дружно на ретро решили, что этот чек-лист разумен. (я — тестировщик)
raptors
Спрошу по-другому. Зачем вы как тестировщик закрывали задачу, если там не было ссылки на документацию?
Molechka Автор
Что вы понимаете под «вы»? Вы — это лично я? Или «вы» — это все наши тестировщики? Я не закрывала задачи без ссылок на документацию, только если забыв ее вложить. Или если я думала, что документация тут не нужна. Иногда это было правильно, а иногда нет, просто я про какую-то документацию не подумала / забыла о ней
raptors
Вы — это лично вы. Почему вам приходится переоткрывать задачу, которую вы же и закрывали? Или вы как санитар ходите по чужим задачам и переоткрываете?) Всё равно вопрос тогда, почему другой тестировщик закрыл задачу, когда есть правило не закрывать таски без ссылки на доку? Видимо, кто-то счёл, что документация там не нужна.
Molechka Автор
Да, я как санитар ходила по чужим задачам и переоткрывала. Причины других разные — подумал, что документация не нужна. Доку написал, ссылку не дал. Забыл, что нужно пополнить доку «вот тут». Дока нужна, но не было времени ее сделать…
Написать чек-лист ? все сразу начали работать по нему. «Да, да, это очень хороший чек-лист и мы будем по нему работать, обязательно… Когда-нибудь потом»