Во многом, для того чтобы работать с системой, о которой я рассказал в первых двух частях, достаточно возможностей самой Jira. Чтобы отслеживать текущее состояние по проектам, вполне подходит совмещение фильтров (по проекту и статусу Open) и дашбордов.  Но на мой взгляд это не слишком интересно отслеживать работу конкретно по тест кейсам. Интереснее оперативно получать информацию о тех кейсах, которые показали ошибки (Resolution: Failed). Для того, чтобы работа была приятнее, нужно настроить какие поля будут отображаться для этого фильтра. Делается это прямо из навигатора по задачам, пункт справа вверху Set Column Order for filter.

Я использую следующие поля: Priority,Key, Summary, Status, Assignee, Fix Version,Links, Created, Updated. А когда смотрю на табличку анализирую записи вот так. Смотрю, есть ли внешние ссылки (Links). Если есть, то просматриваю сначала описание тест кейса для теста (там так же могут быть внешние ссылки) и после смотрю внешние ссылки для этого теста. Если ссылок нет и  приоритет выше, чем Major смотрю дату создания и последнего обновления и комментарии по тест кейсу и тесту. Если ничего нет запрашиваю объяснения у человека, который выполнил тестирование (Assignee) и его лида (тут уже достаточно памяти). Такой подход не позволяет решить проблему обмена информацией и своевременной актуализации тест кейсов. Например существовавшая функциональность сильно изменилась в новой версии, но информация об этом будет в несена  в тест кейсы только после того, как изменения будут проанализированы тестерами. К этому времени тест кейсы могут быть уже пройдены. Вместе с тем это достаточно надежный способ для того, чтобы поддерживать актуальную информацию о регрессионных проблемах при тестировании.

Итак, что легко можно автоматизировать при работе с TCMS средствами Jira, например:

• Получение актуального статуса по объему оставшейся и выполненной работы (фильтр, либо отчет. Project Pivot Report, например);
• Получение статуса по загрузке участников группы в тестирование по тест кейсам (фильтр + портлет Pie Chart);
• Составление календаря с указанием предполагаемых сроков завершения тестирования по каждому тесту [правда, обычно по всем разом] (фильтр + портлет Issue Calendar);
• Получение актуального статуса по упавшим тестам (фильтр);
• Получение отчётов по проделанной работе  (отчеты по проекту);
• Получение списка изменений в тест кейсах (фильтр по Update After/Before);
• Получение списка автоматических тестов (фильтр);
• Получение отчета по загрузке работой по людям и по версиям (снова отчеты по проекту);

В общем то, всё что касается отчётов и вытягивания информации по задачам можно сделать стандартными средствами. Но вот управлять задачами на тестирование уже так легко не получится. Стандартными средствами нельзя создать множество подзадач или задач и поставить правильные линки. Даже через массовые операции (Bulk Operations) этого сделать нельзя.  Я когда, при проектировании столкнулся с этой проблемой сильно задумался. Три дня, пока создавал сабтаски руками, думал о том, что вся предыдущая работа вот-вот пойдёт насмарку, потому что работа с системой требовала неадекватного количества операций, длительных по времени, что делало систему нерабочей в тех объемах в которых хотелось. А хотелось не только управлять тест кейсами, но контролировать тестирование по ним.

Решений, в итоге, было несколько (в порядке появления):

1. Забыть про создание отдельных задач (тестов) к тест кейсам и обойтись одной общей (Test by Test Cases, а в описании давать список ссылок). Проблему этот подход не решал.

2. Доработать Jira, чтобы можно было создавать сабтаски массово. После реализации оказалось, что это не эффективно и отнимало слишком много ресурсов на серверной стороне.

3. Разработать плагин для Jira. Идея сразу умерла, уже не помню почему.

4. Использовать XML-RPC. Вот это уже прижилось, хотя всё-равно потребовались небольшие доработки в Jira. Оказалось, что в RPC так же нет возможности создавать подзадачи, хотя просто задачи создавать можно. А в Jira отличие задачи от подзадачи только в её типе (Issue Types) и том, что у подзадачи ссылка на родительскую задачу не пустое значение. Не смотря на просьбы участников, эта возможность еще не добавлена в официальный плагин XML-RPC. Большой привет Atlassian. Но никто не мешает внести изменения самостоятельно. К сожалению плагин, который опубликован в таске JRA-6896 не работает с версиями старше 3.10, придётся править исходники, которые поставляются вместе с используемой версией Jira (не самая сложная работа).

В результате я написал несколько простых программ, которые позволили сделать рутинную работу намного проще и быстрее.

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

Она позволяет залогинится, получить список фильтров, получить список задач по выбранному фильтру и создать подзадачи. При создании подзадача формируется из данных тест кейса и данных логина в Jira.

В итоге подзадача состоит из:

- Summary -  Тема (Summary) тест кейса с префиксом Test ( например, TEST – Check login form)

- Reporter – имя залогинившегося пользователя

- Assignee – Никого (Unassigned).

- Fix For, Affected Version, Component, Original Estimate, тип теста (автоматический/ручной) и Labels. Копируются из тест кейса.

Такой набор данных позволяет четко идентифицировать ответственных людей, область воздействия теста и затраты по времени не заглядывая в тест кейс.

Ответственный (Assignee) за тестирование проставляется позже через Bulk Operations, либо точечно.

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

Тут уже использовалось соединение через XML-RPC с Confluence и с Jira. Вообще, я только когда разобрался в этих возможностях понял, что оба продукта разрабатывают разные группы, со своим взглядом (и похоже они иногда вынашивают планы взаимного тотального уничтожения).

В плагине для Confluence не пришлось что-либо менять. Эта программа вытаскивает версии из нескольких проектов в Jira, подставляет нужные темплейты (с тест планом, тест кейсами, найденными багами)  и каким то волшебным способом создаёт страницу в Confluence.

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

На нём используется всего три портлета:

• Time Sheet Summary на одну неделю. Позволяет оперативно видеть какими задачами и сколько времени (через Worklog) занимался сотрудник;
• Issue Calender с опцией показа крайнего срока (Due date). Позволяет определить сколько задач в ближайшее время должны быть завершены;
• Show Saved Filter With Columns с фильтром по открытым задачам на человека, показывает сколько всего задач, с каким сроком и приоритетом висят на сотруднике.

Остальные дашборды можно посмотреть тут и тут.

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

В статье много картинок и имеет смысл её сначала прочесть целиком (а так же предыдущую часть, про условности), а потом повторить шаг за шагом.

Создание проекта

Проект добавляется через Administration > Projects > Add Project

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

Схема ниже показывает что и в какой последовательности будет изменено в настройках проекта, её полезно держать перед глазами.

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

Во время написания статьи я использовал тот же принцип, только добавил название группы проектов перед его именем, получилось TC Demo.

Новые типы задач

Новые типы задач можно добавить через Administration > Issue Settings (слева колонка) > Issue Types > Add New Issue Type (в Jira 3 – внизу страницы). Нужно добавить два новых типа:

1. TestCase, как Standard Issue Type, для хранения сценариев и прочих атрибутов тест кейса.
2. Test, как Sub-Task Issue Type, для управления тестированием по тест кейсам.

Ради развлечения стоит поменять иконки (например взять из блока Адама Гушера, там обалденные жучки).

По умолчанию созданные типы задач сразу попадают в основную схему (Default Issue Type Scheme). Оттуда их можно убрать, но это не обязательно.

Там же, но на вкладке Issue Types Scheme нужно создать новую схему и ассоциировать с ней созданные типы задач. Не помешает так же задать TestCase как основной тип задач для этой схемы. Просто для экономии времени при заполнении в будущем.

После создания схема не будет привязана ни к одному из проектов. Установить эту схему для проекта можно прямо со страницы со списком схем, нажав Associate (если надо сразу несколько проектов добавить — самое то), либо через страницу администрирования проекта.

Дополнительные поля для тест кейсов

Дополнительные поля добавляются через Administration > Issue Fields (колонка слева) > Custom Fields > Add Custom Field

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

По умолчанию значение всех полей такое (это разметка wiki):

|| Step || Action || Expected Result ||
| | | |

А отображаться будет вот так:

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

Этот параметр может иметь сразу несколько значений. В сам список достаточно добавить Manual (выбрано по умолчанию) и Automated. В моём случае их комбинация позволяет определить состояние автоматизации тест кейса.

В зависимости от условий эти поля можно привязать либо к определённому типу задач, либо к проекту, либо к тому и другому — для порядка.

Создание конфигурации полей

Хозяйке на заметку: В Jira, кроме стандартных полей, можно создать собственные поля самого разного типа от простых текстовых до календаря. Для каждого своего поля можно специально указать контекст использования – в каких проектах или задачах это поле может быть использовано. Чем проще эти настройки, тем лучше и тем меньше недоумения возникает, когда при клонировании проекта оказывается, что части полей нет, хотя настройки схем абсолютно одинаковые.

Если поле не предназначено для повсеместного использования, то лучше всего его привязать к типу задач, для которых оно предназначено. Задаётся привязка там же, где создаются дополнительные поля (Custom Fields). Выглядеть это будет так:

Правила отображения и обязательности полей

Эти правила задаются через Administration > Issue Fields (колонка слева) > Field Configuration. В действительности очень полезная вещь, которая позволяет избежать бардака. Там же задаётся видимость некоторых полей. Полезность этой настройки становится явной только когда срочно нужно отключить доступ к полю сразу во многих проектах, с одной схемой полей. В общем то больше административная вещь и её лучше не трогать при настройке проекта, если вы не уверены нужно ли это.

Так же, тут настраивается и отображение текстовых полей. Их можно показывать как обычный текст (Default Text Renderer), а можно как текст с wiki разметкой (Wiki Style Renderer). Wiki Style Renderer потребуется как раз для полей Pre & Post – conditions и Steps. Переключается режим отображения через ссылку “Renderers” для каждого поля.

Напрямую эти правила не используются, а включаются в состав схем полей (Field Configuration Scheme). Сразу при создании они не ассоциируются ни с одной схемой, ассоциации выставляются уже в схеме в которую включена конфиграция. Настроить схему можно через Administration > Issue Fields (колонка слева) > Field Configuration Scheme.

Field Configuration Scheme

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

Все типы задач в проекте не связанные явно с конфигурациями полей в схеме, подключенной к проекту, будут ассоциированы со схемой по умолчанию (Default Field Configuration). Это важно помнить, потому что, ошибки с отображением полей в этой части особенно трудно найти потом.

Создание разных видов отображения полей

Screen

Определяет какие поля, в какой последовательности и на какой вкладке (Tab) будут показаны на экране, при вызове этого отображения. Изменения подхватываются на лету. У меня сделано четыре разных представления, по два на каждый тип задачи, для изменения и просмотра записей.
Создание новой задачи типа TestCase разбито на два экрана (Tab), на первом основная информация по самой задаче, а на втором только то, что имеет отношение к тест кейсу.

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

Отображение полей при просмотре тест кейса и теста схожи:

TestCase (Demo TestCase Screen):

Test (sub-task, Demo Test Screen):

Screen Scheme

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

При создании схемы в качество основного отображения лучше выбрать то, которое отвечает за создание задачи и после отдельно указать отображение для просмотра. Для тест кейса (Demo TC Screen Scheme, для теста Demo T Screen Scheme точно так же объедияет отображение для теста – Demo Test Screen [create/edit] и Demo Test Screen [view]) эта связка будет выглядеть так:

Теперь эти схемы нужно связать с типами задач. Делается это с помощью Issue Type Screen Scheme. (Administration > Issue Fields (колонка слева) > Issue Type Screen Schemes).

И тут при создании новой схемы в качестве отображения по умолчанию выбрать просто Default Screen Scheme. Это обеспечит спокойное добавление новых типов задач и возможность быстро заметить направильные связи по схемам для них.

Подключаем все схемы в проект

На странице администрирования проекта через ссылки Select можно выбирать нужные схемы, получится примерно так:

Проверяем в работе

Если всё правильно то:

• При создании или редактировании задачи (Create New Issue, Edit Issue):
  • при выборе проекта (Project) с тест кейсами в списке «Issue Type» будет только «TestCase».
    
  • форма с полями задачи содержит две вкладки — Base Information и Test Case. На вкладке Test Case видны четыре поля — Pre & Post Conditions, Steps, Test Case State. Для полей Pre & Post Conditions, Steps включён режим Wiki markup
    
• При просмотре wiki разметка правильно отрабаытвается и видны все поля тест кейса, примерно так:
  

В качестве заключения

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

Собираясь продолжить рассказ, начатый больше года назад, о тех проблемах, c которыми я столкнулся во время руководства QA отделом, долго не мог решить о чем рассказать дальше. Выбор был между идеями по организации работы QA и описанием технического обеспечения. Оказалось, что тяжело рассказывать об идеях, не рассказав подробнее об инструментах.

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

Условий минимум, всё строится на жизненном цикле тест кейса в системе и связи его с тестами и автоматизацией.

Жизненный цикл

Он такой

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

Готовый тест кейс сперва уходит на ревью и после того, как он будет вылизан, то отправляется либо на автоматизацию, либо в план ручного тестирования (для представления планов используются фильтры в Jira). В какой именно план попадёт тест кейс зависит от значения статуса (Status). Будет ли тест кейс автоматизирован или нет решается на этапе его описания, соответственно и содержание будет разным.

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

Проводить ревью всех тест кейсов не имеет смысла чаще чем раз на крупный релиз, и часто достаточно проверить актуальность только тех тест кейсов, которые не были пройдены ни для одной версии в релизе (чтобы не было путаницы в терминах, у нас релиз включает в себя множество версий, в общем как аналог Release Line). У меня ненужные больше тест кейсы не удаляют, а только закрывают (Close) и забывают, никаких особых причин для этого нет, просто так принято.

Связь с Jira

Тест кейсы и тесты по ним в Jira представлены в виде задачи TestCase и под-задачи Test. В TestCase находится всё описание, включая начальные (Pre) и конечные (Post) условия, там же выставляется приоритет и статус, которые отражают текущее положение тест кейса в жизненном цикле:

«Живой» тест кейс (Status – Open):
Assignee = Reporter – тест кейс на стадии разработки и еще не готов для использования
Assignee = лидер группы (или другой человек отвечающий за ревью) — тест кейс проверяется
Assignee = Unassigned – тест кейс проверен и может быть использован для тестирования.
Assignee = разработчик – тест кейс отправлен на автоматизацию
Assignee = Unassigned, Test Сase State = Automated – тест кейс отправлен на автоматизацию

Устаревший тест кейс:
Status = Closed, Assignee = Unassigned или человек, которые закрыл тест кейс (но это не важно, всё есть в истории изменений).

Для разбиения тест кейсов на группы используются совместно метки (Labels) и приоритет (Priority).

В приоритете используется только три уровня — Critical, Major, Normal, которые определяют частоту использования тест кейса — для каждой версии (билда), для каждого значимого изменения (например — связанных компонент) и если есть время, соответственно. Метки используются для группировки по любому интересующему признаку — бизнес значимость, функциональность, прощупываемая с разных сторон. Причем такие группы кросс-компонентные (компонент может означать – целый проект, часть бизнес логики, группу проектов, что угодно, лишь бы было полезно в работе).

Комбинацией фильтров и плагинов (для Jira или Confluence) набор задач приводится в приемлемый вид и может быть выведен на персональных дашбордах или на общих страницах в Confluence (например через плагин jiraissues).

Систему трекинга ошибок я реализовывал на основе Jira (в силу разных обстоятельств, впрочем я в этом не одинок). Все изменения, которые потребовалось сделать не потребовали никаких доработак кода Jira (то есть при апгрейде не возникает проблем). Система не изолированная и во многом рассчитана на то, что ей будут пользоваться менеджеры и лиды команд. Естественно копаться никто долго не хочет и главный вопрос – что у нас с релизом [в плане ошибок]. Для того, чтобы сделать на основе Jira понятную структуру, которая позволила бы наглядно ответить на этот вопрос понадобилось изменить воркфлоу для проекта, хранящего ошибки. К существующим, стандартным, было добавлено несколько новых статусов:

• Открыт (Переоткрыт)
• В разработке
• Требуется дополнительная информация
• В тестировании
• Работа закончена
• Не баг
• Проверен и закрыт

Далее с помощью портлетов Show Saved Filters (можно использовать Show Saved Filters with Columns) , фильтров с учётом статуса и Pie Chart был сделан дашборд, который показывал сколько задач на каком этапе находятся. Чарт добавлен только ради большей наглядности.

(Картинка не увеличивается, и дана только чтобы показать расположение элементов)

Далее этот дашборд и фильтры (что важно) через Share делаются доступными для всех заинтересованных лиц. Удобвство такого хода в том, что в любой момент изменим этот дашборд у себя можно изменить его у всех остальных.

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

На этом дашборде всего четыре портлета:

• Pie Chart по фильтру, который охватывает все незакрытые таски по всем моим ребятам.
• Statistics. Общая статистика по:
  • по статусам открытых задач в проектах QA;
  • по проектам,в которых открыты задачи на команду тестировщиков;
  • по открытым задачам по людям в проектах QA.

В дополнение к ежедневным митингам, позволяет контролировать загрузку каждого человека по Jira и соотносить задачи в трекинге с реальностью.

Тоже самое, по смыслу, время от времени говорил мне мой руководитель. Он не мог понять чем конкретно занимается мой депортамент, в какой последовательности и для чего. Оспаривать то, что работы делается много он не мог, но при этом и имел полное право не понимать, что же всё-таки делается.
На картинке выше четыре стиля отчета, использовавшиеся в разные промежутки времени (с 2006 года по начало 2009). Красная черта – это отметка страницы А4.

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

Название проекта

Что было сделано и какие проблемы встретились. Обычным человеческим языком.

Имена участников

Он не давал связи с реальными задачами в трекинговой системе и было не понятно, что делал каждый конкретный участник. Пораскинув мозгами и переборов лень подчиненных получилось сделать второй отчет на основе записей в Jira. Отчет содержал название задачи и ссылку на трекинг.

Имя

Задача 1 (под назавание ссылка)

Задача 2 (ссылка)

Он получился длиннее первого в несколько раз и хотя теперь можно было получить представление о том, что делал человек, понять, что происходит на проекте было сложнее, по самому отчету, нужно было идти в Jira и делать выборку. Так же он дополнялся страницами в Wiki (Confluence) по каждому проекту. Такие страницы описывали, как раз что происходит с проектом и конкретное участие сотрудников. Но на них надо было заходить специально. Лень руководства победила формат отчета, за год так и не получилось приучить сначала смотреть к Confluence, а потом спрашивать.

Путь от такого отчета к автоматической сборке занял больше года и все недовольства удавалось отбивать предложением указать формат отчета четко. Удачное решение пришло в голову после обнаружений RPC сервиса в трекинговой системе. За несколько дней была написана программа и придумана реструктуризация, которая позволила бы генерировать любые отчеты по существующим данным. В Jira было задействовано всё от компонент, до кастомных полей. Третий отчет был огромен. На картинке лишь пятая часть. Он вытаскивал из задачи название, описание и worklog, складывал всё вместе и сортировал по людям. Страницы в Confluence по прежнему были, но теперь состояние проектов и информацию о работе людей можно было получить прямо из отчета. Да и моё участие в написании отчета сократилось до финального ревью и выкидывания лишниго. И того, за место 2 часов отчет готовился за 10 – 15 минут.

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

На первый лист идёт информация по проектам, дальше по людям.

Заинтересованные в релизе группы людей

Список вопросов неполный, но QA должны знать ответы хотя бы на них. Для этого, в первую очередь, потребуется отслеживать выполнение задач по разработке и тестированию. Существование трекера первый шаг к построению нормальной информационной системы.
Подойдет любая система трекинга, в которой можно реализовать такую структуру (я предпочитаю Atlassian Jira, для небольших проектов Eventum):

• Backlog – группа проектов в которой по версиям и продуктам разбиваются пожелания и требования бизнес стороны. Это не только спецификации (ТЗ), но и простые заметки, пришедшие от бизнес стороны в стиле «нужно сделать это, примерно вот так функционирует и выглядит». На основе таких «business story» можно построить спецификацию и согласовать с бизнесом.
• Development Project – Группа проектов по разработке конкретных продуктов. Основная часть задач появляется с привязкой к Backlog проекту. Это позволяет отслеживать соответствие требованиям бизнеса и начать работу QA еще до завершения разработки (что-то вроде Test Driving Development, но мягче).
• Feedback – Группа проектов для получения отзывов от клиентов и бизнес стороны по работе текущей версии и проблемам с ними связанным (но не для трекинга багов по разрабатываемой версии).
• QA – Группа проектов, привязанных к таким же проектам в Development Project. В них будет вестись трекинг задач, связанных с тестированием версии или общей работы, но не багов!
• Bugs – Группа проектов, привязанных к проектам в QA и Development Project. Здесь тестировщики создают все таски связанные с найденными ошибками и предлагают улучшения проектов.

Зачем нужно три проекта для QA? Для того, чтобы не создавать мусорной кучи. Feedback доступен не только тестировщикам (которые, по идее, знают о разрабатываемых продуктах больше остальных), но и бизнес стороне. Люди со стороны бизнеса имеют полное право не знать о том, что существует множество версий и множество компонент внутри продуктов, но должны иметь возможность сообщить о проблеме при работе. Для этого им нужно знать только что они делали и версию продукта, с которым они работали (а не всю систему), когда появилась проблема.

Причем, не важен тип решения (а пользователь может и не знать что там еще стоит за окном в которое он смотрит), разрабатываемого компанией:

• самостоятельное приложение;
• серверное приложение с доступом из стороннего (Web сервис, XML/HMTL сервер);
• клиентское приложение с доступом к стороннему (Debuggers, разнообразные сетевые клиенты);
• клиент-серверное приложение, с собственным сервером и клиентом (платформы с удаленным доступом);

Разобраться где конкретно ошибка и ошибка ли дело QA и разработчиков. Часто разработчики могут сделать это быстрее.

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

Группа проектов QA позволяет отделить работу по тестированию от результатов. Для каждого релиза создается свой набор обязательных задач для проверки. В зависимости от проекта и версии список может меняться, адаптируясь под условия. Вместе с рутинными задачами в эти проекты могут быть добавлены задачи относящиеся к процессу тестирования. Например, автоматизация тестов, исследования программ и методик для тестирования.

Принципиальная схема процесса при такой структуре проектов выглядит так:

Потоки информации между проектами

При использовании этой схемы Backlog объединяет в себе первичные требования бизнеса, общее обсуждение технической реализации или ТЗ (в зависимости от возможностей), проблемы из Feedback и Bugs, которые требуют много времени на исправление или переработки бизнес логики. Основные задачи в Backlog описывают большие куски работы, разбиение которых делается через сабтаски. Далее эта информация клонируется (или разбивается на части и клонируется) в проекты по разработке и добавляется в задачи по подготовки к тестированию в QA проектах (написание тесткейсов, переработка существующих тестов, автоматизация и так далее). После релиза в соответствующем проекте QA создаётся общая задача на тестирование, а конкретная работа выделяется в сабтаски. При нахождении ошибок при тестировании они описываются в соответствующем проекте Bugs и либо клонируются в Development Project, либо заносятся в Backlog для позднего исправления. Процесс запускается по новой… в идеале.

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