Многомерный issue-трекер

Это задачи для системы управления тестированием. Jira X-Ray, например.

я мимо проходил и засосоало,

Получи ISTQB Foundation сертификат чтоль, а то от таких доморощенных тестеров больше проблем чем пользы.

testlink.org ещё слыхал я. А на практике нужно понимание покрытия и здоровья релиза, и волевое решение релизить или нет(в котором не только QA принимает участие, но и жадный бизнес как минимум). А для багфикса старых версий нужны ветки поддержки (если нужны конечно). Т.е. не может быть багфикса 17.0, может быть только багфикс 17.0.1 или 17.1.0.

Jira X-Ray, например.

Вся Jira идет мимо, потому что будет переводить всех пользователей к себе в облако. А вот это как раз не приемлемо.

https://redmine.org/

Бывает

какие варианты в принципе уже рассматривали?

bugzilla

Там есть milestone. Просто привязываешь issues к milestone – например, v1.0.0-rc-0. И к нему набор issues. Сбоку фильтром выбираешь и всё. Это у github, gitlab и gitea есть из коробки.

Но это больше для разрабов. У манагеров свои приколюхи. Jira, там. Redmine.

В этом треде удивительно то, что целых два раза уже redmine советовали. Им до сих пор кто-то пользуется! Чатик старпёров.

А можно подробнее? Я как-то упустил эту новость

Неплохо так твой работодатель хочет сэкономить от 200к в мксяц на девопсе.

А можно подробнее? Я как-то упустил эту новость

https://www.atlassian.com/migration/journey-to-cloud

Я у себя на работе пяток дэшбордов забраковал за маломерность и в итоге написал свой, превозмогая боль. У наших результатов примерно 3 измерения выведено табличками и потом еще 3 бонусные оси «авторасследований» скрывается за каждой ячейкой с фэйлом («а если тест прошлой версии взять? а если код прошлой версии взять?…»). Почему никто не сделал такой радости готовой — ума не приложу.

Это задачи для системы управления тестированием. Jira X-Ray, например.

я мимо проходил и засосоало,

Получи ISTQB Foundation сертификат чтоль, а то от таких доморощенных тестеров больше проблем чем пользы

Да, теоретически Jira X-Ray сделано для этого. Но проблема в том, что практически Jira — кривое неудобное говнище, которое сделано менеджерами для менеджеров, и вообще вся эффективность ее стоит под вопросом по сравнению с минимальными наколенными решениями.

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

Особенно я хочу зацепить статистику прохождения тестов из X-Ray, как и статистику активных/отработанных задач в трекере, которые не значат почти ничего для непрограммиста, то есть, для какого-нибудь менеджера. Например, непрохождение старым кодом теста по свежему сценарию (но штатному, соответствующему ТЗ) значит намного больше, чем успешное исполнение десяти старых тестов, которые были тщательно подперты костылями недобросовестным сотрудником для успешного прохождения теста. Я недавно столкнулся с такой ситуацией, что коллега-новичок высрал кусок дерьма, однако, этот кусок дерьма работал в строго определенных условиях и сценариях. Чуть тронул его — всё развалилось. По тикетам и тестам у него всё красиво, но как опытный программист я понимаю, что этот код нельзя пускать в прод. И как я должен этот факт оформить в насмерть бюрократизированной Жире? Jira дает менеджеру ложную иллюзию понимания ситуации, которой он на самом деле не понимает, но достаточно скоро поймет, когда подойдет срок релиза, а проект будет неработоспособен.

Много фич, много формализации засунули в Жиру, но реальный процесс разработки нечеткий, а потому гибкий. Чем меньше ограничений инструмент накладывает на пользователя, тем лучше. Потому что в итоге всё будет зависеть от того, как грамотно программисты с тестировщиками напишут и выполнят тесты, насколько тесты будут воспроизводимы и отражать конечный сценарий применения. А с юзабилити у энтерпрайза почему-то хронический швах, потому что грамотных экспертов по UI/UX там почти нет, а основную массу решений принимают маркетологи и менеджеры с таргет группами.

Вот мегакруто было бы сделать так, чтобы можно было найти статистику тестов по конкретным строчкам кода или комитам. Или, наоборот, найти чьи правки завалили кучу тестов. Чтобы работал комп, а не менеджер с тестером сидел и целыми днями тыкал в выпадающие списки Jira вместо пасьянса и вконтактика. И чтобы в итоге получался работающий софт, а не красивые графики.

В этом треде удивительно то, что целых два раза уже redmine советовали. Им до сих пор кто-то пользуется! Чатик старпёров.

Штука действительно старпёрская. Я просто не знаю ничего другого.

В этом треде удивительно то, что целых два раза уже redmine советовали. Им до сих пор кто-то пользуется! Чатик старпёров

А есть что-то лучше Redmine с Luxury Buttons?

У наших результатов примерно 3 измерения выведено табличками и потом еще 3 бонусные оси «авторасследований» скрывается за каждой ячейкой с фэйлом

Какие оси используете? Как я понимаю, это версия софтины, тест, версия теста. Дальше в каждой ячейке уже не столько аналитические данные, сколько активное взаимодействие с системой для проведения уточняющего тестирования.

, а то от таких доморощенных тестеров больше проблем чем пользы

Ну да, если багу найдёт какое-то быдло без сертификата, то её не пофиксишь - известное дело!

Как я понимаю, это версия софтины, тест, версия теста.

Нет. Версия теста это тоже уточняющее тестирование, давать expected результат должна только последняя, остальные нужны лишь для детективной работы.

Я тоже сначала выбирал не те наружние оси. Оказалось, что все, что интересно для обзора test health и должно поддерживаться всегда рабочим — наружние, а все, что можно варьировать автоматически для расследований — внутри, и они непересекаются.

Наружние: несколько test plans в основном по одному на component, их за оси не считаем. Внутри каждого 1) test, 2) OS (product) version, 3) OS (product) configuration (специфика команды). На пересечении этих трех есть интересная величина: результат теста со всем новым (на самом деле нет*). Внутри него, помимо, собственно, логов последних N запусков, обретаются, в случае unexpected value: 4) версия среза OS (platform) 5) версия компонента 6) версия теста.

Еще мне надо было не спутать OS version с версией среза OS. Первое — отдельный продукт, со своими разнящимися требованиями и т.п., второе — его срез во времени. OS version в нашем случае это не запуск одного и того же на разных платформах, это почти что SuT version, потому что тестируем и продаем мы OS целиком. Типа, если тебе не повезет тестировыть софтину мажорной версии A build B на ОС X.Y build Z, то A, B, X.Y и Z — очень разные оси. A и X.Y снаружи (поддерживаешь ты их все), B и Z внутри (внутри A и X.Y нефиг на старье сидеть).

(*) даже ничего не варьируя, можно и нужно запускать одно и то же еще и еще раз. тогда результат может быть не один для нестабильного теста, тогда в клеточке много цветов, а у нас много вопросов.

Держи еще в нагрузку одну странную UX мудрость. Идеальный интерфейс запуска тестов один и может быть только один: все тесты выполняются абсолютно всегда и непрерывно, а оператор делает для этого ровно ничего. Только всегда имеет под рукой готовые максимально свежие результаты. + результаты варьирования всего, что можно с diff’ом в один клик. После этого любой интерфейс test scheduling’а с ненулевыми усилиями закономерно воспринимается бесконечно сложным в использовании.

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

и в итоге написал свой, превозмогая боль.

Почему никто не сделал такой радости готовой — ума не приложу.

Ну и где этот ваш, доведенный до состояния «готовый к использованию» и выложенный под открытой лицензией? ;-)

Я как-то openproject и dolibar пытался щупать, выглядят приятно (по крайней мере приятнее redmine и НАМНОГО приятнее джиры и всех продуктов atlassian вместе взятых)

Ну и где этот ваш, доведенный до состояния «готовый к использованию» и выложенный под открытой лицензией?

Давай на миллисекунду допустим, что у меня он есть. Зачем мне выкладывать его под открытой лицензией? Между прочим, я знаю про еще как минимум один проект наколенной организации-автоматизации тестирования. Потому что люди реально страдают, а Jira писана полными кретинами, которые не имеют ни малейшего понятия про организацию разработки, что доказывает тот факт, что они даже свою систему с технической стороны не способны грамотно реализовать. И при этом она не является опенсорсом, и при этом ее лочат на сервера Atlassian. Мне остается лишь тщетно пытаться догадываться, какими мотивами руководствуются люди, которые Jira покупают.

Я как-то openproject и dolibar пытался щупать, выглядят приятно (по крайней мере приятнее redmine и НАМНОГО приятнее джиры и всех продуктов atlassian вместе взятых)

Для чего использовалось? Для организации тестирования? Потому что забивать болт молотком удобнее, чем закручивать гвоздь отверткой. В данном случае я имею в виду сравнение openproject vs dolibar vs redmine, про Jira говорить нечего, даже текстовой файл на сетевом диске удобней чем Jira.

Ни для чего серьёзного, просто ставил на посмотреть возможности

У Dolibarr есть online demo

Зачем мне выкладывать его под открытой лицензией?

Ну тогда и не жужжите что кто-то другой так не сделал, раз такого не делаете сами.. ;-)

А посоветуй чего молодежного, чтобы не так стыдно было за седые мудя.

В том-то и дело, что «быдло без сертификата» кучу багов пропустит т.к. не знает основные принципы тестирования продукта. Это тебе не разработка, в тестировании важно следование процессу. А сертификат покажет, что человек как минимум про эти процессы слышал.

не знает основные принципы тестирования продукта

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

коллега-новичок высрал кусок дерьма, как этот факт оформить в насмерть бюрократизированной Жире?

Да блокер открой и всё. Коммит ревёртишь, новичку люлей. В след раз пусть фичу отключаемой делает.

активное развитие фич

Ну тут уж надо смириться, что оно все нестабильно. Ты по-любому не сможешь ничего хорошо протестировать, если даже требования меняются по сто раз на дню. Делай частые релизы, непрерывную интеграцию, feature toggles и т.п.

Много фич, много формализации засунули в Жиру,

Без формализации иногда не обойтись. Попробуй, вон, выпустить продукт для медиков, на который нужно получить добро от FDA и EMA. Без кучи бюрократии тут не обойтись и вот эти системы вроде иксрея в этом не слабо помогают.

Потому что в итоге всё будет зависеть от того, как грамотно программисты с тестировщиками напишут и выполнят тесты, насколько тесты будут воспроизводимы и отражать конечный сценарий применения.

Вот поэтому тесты и должны проводить сертифицированные специалисты, а не макаки-ручники, плящущие под дудку менеджера.

основной принцип покрытия кода тестами != основные принципы тестирования продукта.

Покрытие ради покрытия тебе ничего не даст.

Погуглил и ничего не нашёл, как я понимаю.

Гдавный вопрос, на который отвечают принципы тестирования - покрытие кода. Очевидно, с нулевым покрытием всё прочее не имеет смысла. Но тут вдруг сертифицированный нонэйм сообщает про !=. Это сильно.

Гдавный вопрос, на который отвечают принципы тестирования - покрытие кода.

Да ты змею от члена не можешь отличить, похоже.

Redmine?

Гдавный вопрос, на который отвечают принципы тестирования - покрытие кода

нед, не гдавный.

У Dolibarr есть online demo

Есть, но мне тяжело оценить его, не попользовавшись хотя бы недельку. Это с каким-нибудь SAP прям с первого заходя ясно, что это кромешный ад и пользоваться этим невозможно — и то, может быть я что-то упустил и на самом деле все-таки можно пользоваться.

Пока что поверхностно я вижу слишком много фич с непонятным смыслом. Например, повестка дня, где записан какой-то

Type	Phone call
Start date	03/11/2021 05:26 PM
End date	03/11/2021 05:37 PM

Мне вот интересно, кто-то в самом деле так делает? Я захожу в тикеты, а там:

Public Tracking ID	ygozv7i6k6epe15q
Subject	  test
Creation date	03/19/2021 01:02 PM - Time elapsed since: 10:22
Read on	
Closing date	03/19/2021 06:13 PM
Assigned to     David Doe
Progression	100%
Initial Message	test.test de algo XD

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

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

Ну тогда и не жужжите что кто-то другой так не сделал, раз такого не делаете сами

Это был не совсем риторический вопрос. Это скорее было обсуждение модели разработки. Я давно работаю над системами документооборота, CRM, которые иногда также используются в роли трекера, и у меня есть планы по поводу того, чтобы перекатиться в эту сферу, учитывая некоторое кол-во опыта, который у меня накопился. Правда, совсем не ясно в каком формате комерциализованности это вообще будет. А нынешний рынок в сфере систем управления разработкой довольно прост: closed source overengineered говно, либо open source «сделай сам».

коллега-новичок высрал кусок дерьма, как этот факт оформить в насмерть бюрократизированной Жире?

Да блокер открой и всё. Коммит ревёртишь, новичку люлей. В след раз пусть фичу отключаемой делает

Ну фича не прямо-таки роняет всю систему, а просто отвратительно работает. Разговор был скорее про систему тестирования качества — так-то написать я могу что угодно под каким угодно соусом. Но, например, как дальше проследить, что новичок не сделает очередной костыль? Это снова ручная работа будет же ж — зачем мне Jira вообще? Это вообще основной вопрос к ней — почему Jira лучше кучки текстовых файлов?

Ну тут уж надо смириться, что оно все нестабильно. Ты по-любому не сможешь ничего хорошо протестировать, если даже требования меняются по сто раз на дню. Делай частые релизы, непрерывную интеграцию, feature toggles и т.п

Это я скорее о том, что способы формализации в Jira не помогают при такой разработке. Пока что из всего, что я пробовал, лучшим вариантом при активной разработке было вести здоровый текстовой файл с описанием фич и статусом их разработки, который по мере релизов перечитывается и обновляется с ног до головы. Причем, делать это удобнее и проще именно в текстовом файле, где сразу всё видно, и можно копипастить в конце-концов, а не двигать/пересоздавать/разбивать/связывать задачки, которые в итоге через неделю нужно будет все равно перетряхивать с ног до головы. В итоге конкретно в Jira это скатывается в три крайности:

 — висящие тухлые задачи, похожие на треды из Talks, где примерно ко второй странице обсуждение уже не относится к исходному сообщению. То есть, задача вроде и не сделана, и не отменена, и фича в процессе разработки, но уже совсем другая, или их даже несколько, или они объединены во что-то новое, а задача осталось. Маркетологи Atlassian говорят нам «оформляйте это инструментами Jira, связывайте с другими задачами, оформляйте подзадачи». По факту, если так реально делать, то очень быстро в структуре задач черт ногу сломит, а манагеры целыми днями будут только сортировать задачки;
 — много-много-много мелких задач, которые быстро выполняются или отменяются, которые в самом сложном случае имеют простые связи с другими задачками. Проблема заключается в том, что в таком сценарии для одного разработчика при интенсивной разработке совершенно нормально иметь несколько сотен задачек, поверхностное чтение которых не дает представления о состоянии разработки для отдаленного от разработки этой фичи человека;  — одна мегазадача-мусорник, которая тянется два года с начала разработки. Попытки пересоздавать мегазадачу после каждого релиза со связью на старую упрощают чтение, но не решают проблему под корень.

Короче говоря, это всё симптомы неправильной формы для фактических процессов, то есть, натягивание совы на глобус.

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

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

Прибит гвоздем к проблемной области так плотно, что не оторвать.

Движок для выполнения тестов у него под капотом более универсален и выложен: https://github.com/t184256/fingertip

Редмайн и багзилу как очевидные

как очевидные что?

Это тебе не разработка, в тестировании важно следование процессу. А сертификат покажет, что человек как минимум про эти процессы слышал.

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

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

Или я неправ?

На собеседовнии спроси умеет ли вим закрывать

killall vim.

Есть сломавшиеся, которые требуют внимательного изучения, есть успешно прошедшие, которые требуют сохранения отчета об успехе… Вот как-бы все это учитывать…

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

Меня такое спрашивали, на экране был вим, сказали закрыть, я взял тетрадочку и закрыл эркан с вимом. Поднимаю голову и смотрю на чувака… через секунд 15 тишины он как заржёт

killall vim

Так он и кильнулся, ага. Только если контрольный - 9 в голову

Редмайн и багзилу как очевидные

как очевидные что?

Как очевидные цели для изучения, и как подозреваемые на то что не очень подходят…