LINUX.ORG.RU

История изменений

Исправление byko3y, (текущая версия) :

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

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

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

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

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

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

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

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

Исходная версия byko3y, :

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

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

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

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

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

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

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

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