Comments on: Test & Test Case Management in Jira [условности] http://blog.alsedi.com/test-test-case-management-in-jira-part-0/ О QA, Shareware и ИТ Wed, 05 Oct 2011 06:52:02 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Ekaterina http://blog.alsedi.com/test-test-case-management-in-jira-part-0/#comment-97 Ekaterina Thu, 11 Nov 2010 06:10:12 +0000 http://alsedi.com/blog/?p=611#comment-97 Алексей, добрый день. У вас в журнале часть картинок не показывается, а очень интересно посмотреть :) Алексей, добрый день.
У вас в журнале часть картинок не показывается, а очень интересно посмотреть :)

]]> By: Test & Test Case Management in Jira [инструменты] | Alex Sergeev @ ALSEDI http://blog.alsedi.com/test-test-case-management-in-jira-part-0/#comment-28 Test & Test Case Management in Jira [инструменты] | Alex Sergeev @ ALSEDI Tue, 22 Dec 2009 22:40:26 +0000 http://alsedi.com/blog/?p=611#comment-28 [...] 1. Условности 2. Реализация 3. Автоматизации работы – вы тут 4. [...] [...] 1. Условности 2. Реализация 3. Автоматизации работы – вы тут 4. [...]

]]> By: Test & Test Case Management in Jira [реализация] | Alex Sergeev @ ALSEDI http://blog.alsedi.com/test-test-case-management-in-jira-part-0/#comment-27 Test & Test Case Management in Jira [реализация] | Alex Sergeev @ ALSEDI Mon, 14 Dec 2009 16:22:31 +0000 http://alsedi.com/blog/?p=611#comment-27 [...] 1. Условности 2. Реализация – вы тут 3. Автоматизации работы – [...] [...] 1. Условности 2. Реализация – вы тут 3. Автоматизации работы – [...]

]]> By: Alex http://blog.alsedi.com/test-test-case-management-in-jira-part-0/#comment-26 Alex Fri, 27 Nov 2009 13:19:34 +0000 http://alsedi.com/blog/?p=611#comment-26 С вашим процессом разобрался, вполне нормальный вариант. Различий много, фактически это другой подход к организации тестирования. У нас есть несколько принципиальных расхождений. Первое в сопоставлении тестов и тест кейсов. У меня «тест» — это действие по одному тест кейсу. Сделано это для того, чтобы было легче отслеживать «жизнь» найденной ошибки в процессе разработки: - Упавший тест порождает задачу в багтрекинговом проекте; - Баг в трекинговой системе порождает задачу в девелопменте; В перспективе на основе этих связей можно <strong>отслеживать</strong> наиболее <strong>рискованные участки</strong> кода и бизнес функций и просчитывать риски еще до релиза. Но использовать связь один к одному или один ко многим зависит только от того процесса, который нужно получить. Мне требовалось четкое соответствие тесткейсов, тестов, ошибок и задач в девелопменте. Если этого не требуется, то соотношение количества тест кейсов и тестов к ним значение имеет только в плане удобства. Второе расхождение в организации тестирования по тест кейсам и организации коллекцией тест кейсов (в вашей терминологии — тест пакетов). Помимо функциональных тестов в TCMS хранятся сценарии для стресс тестирования и инсталляционного тестирования, так же ведутся тест кейсы для автоматизации (ничем особым не отличаются, кроме специфичного описания). Разделение тест кейсов на пакеты, повторю то, что написано выше, сделано на основе мета данных и приоритетов и компонент (для идентификации конечного продукта). Причем первичным признаком для выбора при тестировании является приоритет. Метки разделяют тест кейсы на коллекции по функциональности (как у вас), но могут включать в себя сценарии любого приоритета. В рутинной работе используется только разделение по приоритету, метки чаще используются для удобства тестера, проводящего тестирования. Но по задумке комбинацией значений этих трёх полей позволяет просто и гибко составлять тест планы по нужным признакам, оценить время на тестирование и какие команды будут вовлечены в тестирование. Тут, как я понимаю уже глобальное отличие процессов — у вас отдел тестирования не выделен. Третье отличие в жизненном цикле тест кейса. Насколько я понял из описания, вы после тестировании закрываете тест кейсы. У меня пока тест кейс остаётся актуальным — он открыт. Закрытие тест кейса означает, что его использовать больше нельзя. Но это по большому счёту ерунда, просто разный принцип и небольшие преимущества при поиске. Вот в общем то и всё по отличиям, надеюсь это поможет. Теперь я так же могу ответить про вопрос про увязывание статусов. Я его не понял сначала. У меня нет такой проблемы со статусами, потому что используется несколько проектов – для ведения тест кейсов, для ведения ошибок, для ведения разработки. <strong>Во всех проектах</strong>, упрощая, <strong>свои статусы</strong>. Связи между проектами сделаны через ссылки (Link), они же позволяют оценивать статус задачи. Для расширенного видения есть отчеты <strong>Link Hierarchy Report For Versions</strong> и <strong>Link Hierarchy Report For Issues</strong>. По поводу того, как избежать неправильного использования элементов тестирования в Jira, если я правильно понял про артефакты тестов. У меня как раз перенос в отдельный проект и помог предотвратить не правильное использование специальных фишек для тестирования в разработке. Более того у меня для тест кейсов несколько проектов. Впрочем разработчики люди адекватные и если начинались какие-либо косяки, то личной беседой и объяснениями всё улаживалось. Поскольку модель не противоречила и не усложняла процесс для разработчика, то все охотно шли на встречу. С технической точки зрения, разграничения внутри одного проекта можно сделать несколькими способами: - изменением Workflow и настройкой шагов таким образом, чтобы у разработчика не было возможности в ручную управлять настройками, относящимися к тестам. Сложный, но самый надежный вариант, который при правильной реализации, к тому же, упростит работу с Jira для всех (делается через настройку Workflow Actions, Screens, Conditions и Validators в настройках шагов) - настройкой в проекте ролей (Project Roles + Permission Scheme) и Security Schemes (но я бы предпочел их не касаться даже трёх метровой палкой). С вашим процессом разобрался, вполне нормальный вариант. Различий много, фактически это другой подход к организации тестирования.

У нас есть несколько принципиальных расхождений. Первое в сопоставлении тестов и тест кейсов. У меня «тест» — это действие по одному тест кейсу. Сделано это для того, чтобы было легче отслеживать «жизнь» найденной ошибки в процессе разработки:
- Упавший тест порождает задачу в багтрекинговом проекте;
- Баг в трекинговой системе порождает задачу в девелопменте;
В перспективе на основе этих связей можно отслеживать наиболее рискованные участки кода и бизнес функций и просчитывать риски еще до релиза.

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

Второе расхождение в организации тестирования по тест кейсам и организации коллекцией тест кейсов (в вашей терминологии — тест пакетов). Помимо функциональных тестов в TCMS хранятся сценарии для стресс тестирования и инсталляционного тестирования, так же ведутся тест кейсы для автоматизации (ничем особым не отличаются, кроме специфичного описания). Разделение тест кейсов на пакеты, повторю то, что написано выше, сделано на основе мета данных и приоритетов и компонент (для идентификации конечного продукта). Причем первичным признаком для выбора при тестировании является приоритет. Метки разделяют тест кейсы на коллекции по функциональности (как у вас), но могут включать в себя сценарии любого приоритета. В рутинной работе используется только разделение по приоритету, метки чаще используются для удобства тестера, проводящего тестирования. Но по задумке комбинацией значений этих трёх полей позволяет просто и гибко составлять тест планы по нужным признакам, оценить время на тестирование и какие команды будут вовлечены в тестирование. Тут, как я понимаю уже глобальное отличие процессов — у вас отдел тестирования не выделен.

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

Вот в общем то и всё по отличиям, надеюсь это поможет.

Теперь я так же могу ответить про вопрос про увязывание статусов. Я его не понял сначала. У меня нет такой проблемы со статусами, потому что используется несколько проектов – для ведения тест кейсов, для ведения ошибок, для ведения разработки. Во всех проектах, упрощая, свои статусы. Связи между проектами сделаны через ссылки (Link), они же позволяют оценивать статус задачи. Для расширенного видения есть отчеты Link Hierarchy Report For Versions и Link Hierarchy Report For Issues.

По поводу того, как избежать неправильного использования элементов тестирования в Jira, если я правильно понял про артефакты тестов. У меня как раз перенос в отдельный проект и помог предотвратить не правильное использование специальных фишек для тестирования в разработке. Более того у меня для тест кейсов несколько проектов.

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

С технической точки зрения, разграничения внутри одного проекта можно сделать несколькими способами:
- изменением Workflow и настройкой шагов таким образом, чтобы у разработчика не было возможности в ручную управлять настройками, относящимися к тестам. Сложный, но самый надежный вариант, который при правильной реализации, к тому же, упростит работу с Jira для всех (делается через настройку Workflow Actions, Screens, Conditions и Validators в настройках шагов)
- настройкой в проекте ролей (Project Roles + Permission Scheme) и Security Schemes (но я бы предпочел их не касаться даже трёх метровой палкой).

]]> By: Roman http://blog.alsedi.com/test-test-case-management-in-jira-part-0/#comment-25 Roman Fri, 27 Nov 2009 07:49:31 +0000 http://alsedi.com/blog/?p=611#comment-25 Конечно же, вполне возможна нестыковка в определениях. Кроме того, я никогда не исключаю большей компетенции собеседника :). Тест-кейс для меня (собственно как и у вас) является как раз набором 6-10 отдельных вполне конкретных шагов для проверки ожидаемого результата. Тест-кейсы являются основой построения сценария, т.е. теста. Как видите, получается, что несколько тесткейсов и составляют тест. Используемый мной принцип таков. Применительно к функциональному тестированию, поведение системы можно представить как некое дерево, ствол которого является основной, правильной ветвью и как правило выражается первичным требованием. тест-кейс как правило проверяет одну ветвь поведения. Несколько тесткейсов, покрывающих наиболее важные и наиболее вероятные ветви, объединяются в тестпакеты, выполнение которых по определенному сценарию, описанному в тесте и предполагает проверку функциональности. Функциональность как правило выражается задачей с подзадачами. В среднем получается 1-2 тестпакета на одну функциональность. Отдельно выделяются тестпакеты для системного тестирования. Собственно, это уже получаются тесткейсы по проверке ожидаемых результатов в ходе использования всей системы, этакого полного цикла поведения. Зачастую некоторые функциональные тесткейсы почти в их изначальном виде попадают в системные тестпакеты. Системные тестпакеты выделяются также как таковые и их ненамного больше чем для одной функциональности. Регрессионные тесты мною выделяются практически исключительно на функциональном уровне по принципу: тесткейсы, задействующие многие функциональности + "стволовые" тесткейсы + часто и/или критично заваливающиеся. На уровне методов и процедур отдельных модулей системы я формирую некие автоматизированные acceptance пакеты, которые прогоняются после сборок. Собственно, мне надо реализовать управление функциональными и системными тестами, которые пока исключительно ручные. Касаемо проекта. Скажу сразу, проект, в котором потребовалось такое управление, является длительным и направлен на развитие основной платформы, на основе которой выполняются некие короткие заказные проектные разработки. Время указывается только для тесткейса и для меня является опытным значением. Т.е. я по собственному опыту проставляю в тесткейсе при его создании время выполнения. Программист-архитектор проводит ревью (в идеале конечно) и вперед. Далее время изменяется в соответствии с потраченным, а отклонение учитывается в последующем. Выполненный тест закрывается. При необходимости проведения тестов снова тесткейсы открываются, назначаются ответственные, корректируется время. При необходимости учета статистики, особенно по версиям, используется история тесткейса. Вот собственно, вкратце и все. Мне очень даже нравится ваш способ реализации тестменеджмента в жире (позвольте мне ее так называть), но несколько неудобно в один проект выделять тестирование, т.к. нет отдельной группы тестирования, а количество проектов, ведущихся одновременно около 3-5. На каждом проекте свой человек выполняющий роль тестера и как правило являющийся аналитиком (минус маленькой компании). Ясно сразу, что получится путаница или даже анархия. В целом я регламентировал процесс тестирования для рамочного проекта, но документирование и управление тестами стало краеугольным камнем. Сначала в проектах функциональное тетстирование велось в рамках задач как подзадачи. Но практически сразу стало ясно, что это до добра не доведет. Пока что я ввел на каждом проекте отдельные компоненты "Тестирование" и "увел" все тесты в них. А для ссылки на задачи и баги использую "связи". Но и это мне не представляется панацеей. Люди, работая в проекте, видят артефакты тестов и соблазняются на их использование. Также происходит и с их атрибутами (статусы и резолюции). Впрочем понятно, что надо пожестче регламентировать работу в жире, но в то же время хочется не упустить скрытые возможности системы. Использование резолюций для нас сейчас представляется наиболее приемлемым. Но может вы что посоветуете? Конечно же, вполне возможна нестыковка в определениях. Кроме того, я никогда не исключаю большей компетенции собеседника :). Тест-кейс для меня (собственно как и у вас) является как раз набором 6-10 отдельных вполне конкретных шагов для проверки ожидаемого результата. Тест-кейсы являются основой построения сценария, т.е. теста. Как видите, получается, что несколько тесткейсов и составляют тест. Используемый мной принцип таков. Применительно к функциональному тестированию, поведение системы можно представить как некое дерево, ствол которого является основной, правильной ветвью и как правило выражается первичным требованием. тест-кейс как правило проверяет одну ветвь поведения. Несколько тесткейсов, покрывающих наиболее важные и наиболее вероятные ветви, объединяются в тестпакеты, выполнение которых по определенному сценарию, описанному в тесте и предполагает проверку функциональности. Функциональность как правило выражается задачей с подзадачами.
В среднем получается 1-2 тестпакета на одну функциональность. Отдельно выделяются тестпакеты для системного тестирования. Собственно, это уже получаются тесткейсы по проверке ожидаемых результатов в ходе использования всей системы, этакого полного цикла поведения. Зачастую некоторые функциональные тесткейсы почти в их изначальном виде попадают в системные тестпакеты. Системные тестпакеты выделяются также как таковые и их ненамного больше чем для одной функциональности. Регрессионные тесты мною выделяются практически исключительно на функциональном уровне по принципу: тесткейсы, задействующие многие функциональности + “стволовые” тесткейсы + часто и/или критично заваливающиеся. На уровне методов и процедур отдельных модулей системы я формирую некие автоматизированные acceptance пакеты, которые прогоняются после сборок. Собственно, мне надо реализовать управление функциональными и системными тестами, которые пока исключительно ручные.
Касаемо проекта. Скажу сразу, проект, в котором потребовалось такое управление, является длительным и направлен на развитие основной платформы, на основе которой выполняются некие короткие заказные проектные разработки. Время указывается только для тесткейса и для меня является опытным значением. Т.е. я по собственному опыту проставляю в тесткейсе при его создании время выполнения. Программист-архитектор проводит ревью (в идеале конечно) и вперед. Далее время изменяется в соответствии с потраченным, а отклонение учитывается в последующем. Выполненный тест закрывается. При необходимости проведения тестов снова тесткейсы открываются, назначаются ответственные, корректируется время. При необходимости учета статистики, особенно по версиям, используется история тесткейса. Вот собственно, вкратце и все.
Мне очень даже нравится ваш способ реализации тестменеджмента в жире (позвольте мне ее так называть), но несколько неудобно в один проект выделять тестирование, т.к. нет отдельной группы тестирования, а количество проектов, ведущихся одновременно около 3-5. На каждом проекте свой человек выполняющий роль тестера и как правило являющийся аналитиком (минус маленькой компании). Ясно сразу, что получится путаница или даже анархия. В целом я регламентировал процесс тестирования для рамочного проекта, но документирование и управление тестами стало краеугольным камнем.
Сначала в проектах функциональное тетстирование велось в рамках задач как подзадачи. Но практически сразу стало ясно, что это до добра не доведет. Пока что я ввел на каждом проекте отдельные компоненты “Тестирование” и “увел” все тесты в них. А для ссылки на задачи и баги использую “связи”. Но и это мне не представляется панацеей. Люди, работая в проекте, видят артефакты тестов и соблазняются на их использование. Также происходит и с их атрибутами (статусы и резолюции). Впрочем понятно, что надо пожестче регламентировать работу в жире, но в то же время хочется не упустить скрытые возможности системы. Использование резолюций для нас сейчас представляется наиболее приемлемым. Но может вы что посоветуете?

]]> By: Alex http://blog.alsedi.com/test-test-case-management-in-jira-part-0/#comment-24 Alex Thu, 26 Nov 2009 11:14:07 +0000 http://alsedi.com/blog/?p=611#comment-24 Мне кажется вы не совсем поняли то, о чем я написал, плюс у нас не состыковка в определениях. Тест кейс для меня, вкратце, — это набор шагов с ожидаемым результатом. Тест — это ряд действий, совершаемых по сценарию. Поэтому тест в моём варианте является дочерним к тест кейсу. Статусы в Jira контекстно зависимые и их можно настроить только для определённых проектов. Впрочем, для обозначение упавших тестов я использую поле Resolution, которое действительно видно во всех проектах. Хотя это не стало камнем преткновения для кого-либо. По поводу вашего варианта хочется понять точнее, каким образом происходит работа. После этого можно будет продолжить обсуждение. Сейчас есть большой риск из-за различий в понятиях окончательно друг друга не понять. Так же могло ввести заблуждение отрывочный характер записей, я их сегодня подправлю. По тому что вы написали я понял лишь поверхностно как у вас всё устроено. Не понятно как много задач создаётся, что включает в себя то, что вы называете тест-кейсом. Каким образом проводится регрессионное тестирование? Как обеспечивается управление тестовыми сценариями по времени. Как тестовые сценарии передаются на автоматизацию? Как по одному и тому же сценарию получить отчёт о его поведении по нескольким версиям? Как заранее, определить сколько времени потребуется на тестирование? Мне кажется вы не совсем поняли то, о чем я написал, плюс у нас не состыковка в определениях. Тест кейс для меня, вкратце, — это набор шагов с ожидаемым результатом. Тест — это ряд действий, совершаемых по сценарию. Поэтому тест в моём варианте является дочерним к тест кейсу.

Статусы в Jira контекстно зависимые и их можно настроить только для определённых проектов. Впрочем, для обозначение упавших тестов я использую поле Resolution, которое действительно видно во всех проектах. Хотя это не стало камнем преткновения для кого-либо.

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

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

]]> By: Roman http://blog.alsedi.com/test-test-case-management-in-jira-part-0/#comment-23 Roman Thu, 26 Nov 2009 08:46:49 +0000 http://alsedi.com/blog/?p=611#comment-23 Странно, что у вас тест-кейсы включают в себя тесты. Вообще налицо как раз обратная иерархия. Ну да ладно. Вопрос, как быть со статусами тестов, когда они заваливаются. Необходим статус failed или что-то типа того. Тогда этот статус не будет увязываться с задачами, требованиями, фичами и др. Как быть в таком случае? Сам по себе тест менеджмент - это не обратная сторона багтрекинга, и даже не аналогия управления требованиями, а как раз участок того самого проблемного места, из-за которого многие системы управления проектами и страдают. Этакий "любовный треугольник" - требование - тест - баг. Так вот я пока лишь путем ошибок, проб и опыта смог достичь оптимального применения жиры через выделение отдельного компонента "Тестирование". В нем создаю отдельные задачи (тесты или тестпланы - называйте как хотите) и подзадачи (тест-кейсы). Специально даже пришлось создать новые виды issue. Тесты я связываю с требованиями и/или задачами и при заваливании теста создаю баги в рамках того требования которое тестировалось. НО!!! Не получилось пока ни свести, ни разграничить статусы тестов и задач. Странно, что у вас тест-кейсы включают в себя тесты. Вообще налицо как раз обратная иерархия. Ну да ладно. Вопрос, как быть со статусами тестов, когда они заваливаются. Необходим статус failed или что-то типа того. Тогда этот статус не будет увязываться с задачами, требованиями, фичами и др. Как быть в таком случае? Сам по себе тест менеджмент – это не обратная сторона багтрекинга, и даже не аналогия управления требованиями, а как раз участок того самого проблемного места, из-за которого многие системы управления проектами и страдают. Этакий “любовный треугольник” – требование – тест – баг. Так вот я пока лишь путем ошибок, проб и опыта смог достичь оптимального применения жиры через выделение отдельного компонента “Тестирование”. В нем создаю отдельные задачи (тесты или тестпланы – называйте как хотите) и подзадачи (тест-кейсы). Специально даже пришлось создать новые виды issue. Тесты я связываю с требованиями и/или задачами и при заваливании теста создаю баги в рамках того требования которое тестировалось. НО!!! Не получилось пока ни свести, ни разграничить статусы тестов и задач.

]]>