Автоматизация управления тестированием с помощью Google Docs.

[maxapryg]

   Поскольку внутреннюю конференцию пока откладывают, а выступление уже готово, решила выложить его сюда. Этот пост о моем опыте автоматизации управления тестированием с помощью такого тривиального и простого инструмента как Google Docs (да, я руководитель отдела тестирвоания ПО, внезапно). Поехали.

• Менеджер постоянно спрашивает про статус тестирования?
• Достали нудные одинаковые отчеты с кучей данных?
• Надоело пялиться в Jira?
• Мечтаешь не следить за тестерами, а гладить котиков?

Ну а если серьезно, то вот несколько признаков того, что этот пост может быть вам интересен или полезен:

• Задачи распределяются вручную
• Нет возможности получить полную картину тестирования одним кликом
• Приходится делать много повторяющихся действий
• Jira и ее workflow далеки от совершенства

Да, я буду рассказывать на примере Jira, но на самом деле на ее месте естественно может быть любая баг-трекинговая система, отдающая json. Итак, несколько основных принципов, от которых я отталкивалась (они же хитрые планы):

Хитрый план №1. Делать как можно меньше.
Нет серьезно. В мире куча интересного, а у руководителя, помимо рутинных задач, куча работы, значит максимум рутины надо автоматизировать. Сначала выявляем рутину, то есть действия, которые отнимают много времени/сил/кликов/нервов, но не заставляют думать. В моем случае это распределение задач и написание отчетов.

Для того, чтобы понять, почему именно эти два пункта, придется, немного узнать о том, как у нас построен процесс тестирования. Если не вдаваться в подробности, то тестируем мы три раза:

1. Когда задача переходит из разработки в тестирование. То есть в общем песочнице, в которую попадают все комиты и которую мы называем trunk. Тут в принципе ничего сложного, чтобы понять, кто что тестирует, надо просто посмотреть на поле Assignee.
2. В сборке очередного пачта.  Тут уже сложнее: собраный патч выкладывается на отдельный сервер и начинается тестирование всех задач, входящих в него. Да, задачи тоже можно распределить по полю Assignee, но тогда может получиться так, что у одного тестера 10 задач, у другого 2, а у того, кто на больничном еще 15. Кроме того, большинство задач добавляются в патч закрытыми, и по Jira никак не понять, что задача протестирована в патче (можно конечно добавить отдельный статус, но это тоже не очень удобно).
3. После выхода патча на бой, все задачи в нем тестируются еще раз. Проблемы те же, что и во втором пункте.

Понятно, что нужна какая-то отдельная среда, в которой статус тестирования патча был бы виден, так сказать, онлайн. Я выбрала Google Docs (ну да, слабость у меня к табличному представлению данных, ничего не могу с собой поделать). Естественно, переносить данные из Jira руками мне было лень, поэтому пришлось научиться писать небольшие скрипты для своих документов. Итак, план:

Вытаскиваем данные из Jira в GD. Переходим в Инструменты -> Редактор скриптов, создаем новый скрипт для подключения к Jira.

function jiraConnect() {
var fetchArgs = {
admin:"admin",
contentType: "application/json",
headers: {"Authorization":"Basic xxxxxxxxxxxxxxxxxxxxxxx"},
muteHttpExceptions : true
};
return fetchArgs; }
Понятно, что xxxxxxxxxxxxxxxxxxxxxxx - это логин/пароль в base64. Да, не кидайте в меня тапками, знаете способ лучше - буду благодарна за информацию. Далее получаем нужный json  с помощью урла и парсим его. Выглядит это примерно так:

var fetchArgs = jiraConnect();
var httpResponse = UrlFetchApp.fetch(releaseUrl, fetchArgs);
var release = JSON.parse(httpResponse);

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

Распределяем задачи. Тут немного интереснее: придется подумать, по каким параметрам обычно распределяются задачи и какие могут быть исключения из общих правил. В итоге получится некий набор правил распределения, на каждое из которых нужно будет написать скрипт.
   Простой пример: отдел из двух человек, Маша и Даша, каждая при закрытие задачи ставит в поле Assigne свое имя. При этом Маша еще занимается аналитической работой. Тогда два правила: сначала распределяем задачи по полю Assinge, а потом, отдаем Даше машины задачи, пока у Маши останется не более N% задач в патче.
   На этом этапе конечно лучше учесть максимальное количество возможных кейсов, но у меня все равно периодически возникает необходимость что-то поменять в плане распределения, поэтому я ввела еще дополнительные элементы управления на экстренный случай (кнопки и выпадающие меню).

Что получилось в итоге:

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

Хитрый план №2. Не делать дважды то, что можно сделать один раз.
В работе обязательно есть такие действия, которые каждый раз приходится делать "как в первый раз". Обычно это что-то трудоемкое, требующее определенных навыков, ума или внимания, но при этом не на столько частое, чтобы можно было сделать все на автомате. У меня это например разбор состава сборки, когда нужно по каким-то не совсем и не всегда очевидным признакам понять, что нужно отвязать, привязать, переложить, а на что обязательно стоит обратить внимание. Принцип ничем особо не отличается от предыдущих пунктов: выделяем правила и пишем под них скрипты. Но на большом объеме данных становятся заметны некоторые подводные камни:

• Не всегда по «голой» жире можно понять, что происходит
• Работа скриптов прерывается из-за слишком долгого выполнения
• Нельзя выполнять несколько скриптов параллельно
• Человеческий фактор (данные в Jira не идеальны)

Со вторым пунктом все просто: пишем отдельные скрипты на каждую задачу (не говнокодим, если по-простому), тогда времени выполнения вполне хватает. С третьим пунктом я решила просто смириться. А вот первый и последний сильно затрудняют алгоритмизацию процесса автоматизации. В итоге я пошла методом от-противного, то есть, не выделяла правила, по которым нужно работать, а выделила правила, которыми точно можно отсечь часть данных. В итоге все однозначное за меня распределяют скрипты, а вот неоднозначное приходится разбирать руками, но понятно, что объем данных при этом значительно уменьшается.

Хитрый план №3. Следить и властвовать. А вот это уже шутка) Но и в ней есть доля правды: процесс тестирования надо мониторить. А значит, данные результаты каждого этапа тестирования должны легко фиксироваться, а среда мониторинга должна быть достаточно гибкой.
   Сначала я максимально облегчила работу тестировщиков с моим файлом: разделила данные на отдельные списки для каждого человека и ввела выпадающие поля для заполнения результатов. Все красиво оформила и добавила инструкции для самых "маленьких и тупых". Вообще визуальная составляющая очень важна, и если выделить критичную задачу красным, то вряд ли на нее не обратят внимания. Но это лирика.
   В итоге я сделала меню и кнопки управления для каждого конкретного логически завершенного действия и добавила немного диалоговых окон. Хочу рассказать об этом чуть подробнее. И на кнопку, и на пункт меню можно назначить любой скрипт, который запускается из редактора скриптов.
   С кнопкой все совсем просто: нажимаем Вставка->Рисунок, рисуем кнопку и размещаем ее на нужной странице документа. Потом жмем на нее правой клавишей мыши и прописываем скрипт, который будет запускаться каждый раз при нажатии на эти кнопку. Готово.
   С меню чуть сложнее: его надо приписать отдельным скриптом, в котором создать функцию onOpen, которая будет срабатывать каждый раз при открытии документа.

function onOpen() {
var doc = SpreadsheetApp.getActiveSpreadsheet();
doc.addMenu("Управление", [{name: "Задать патч", functionName: "setRelease"},
             {name: "Обновить данные по задачам", functionName: "updateLinkData"}]);
doc.addMenu("Для тестирования", [{name: "Распределить задачи", functionName: "testing"},
                   {name: "Расширить список задач", functionName: "addTestingTask"},
                   {name: "Сформировать sign-off", functionName: "signOff"},
                   {name: "Сформировать verification report", functionName: "verificationReport"}]); }

С диалоговыми окнами тоже все просто:
Browser.inputBox("Номер  патча"); - вызовет окно с соответствующим текстовым сообщением, в котором будет один input.
Browser.msgBox("Задачи разобраны") - вызовет окно с соответствующим текстовым сообщением;

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

• Хорошее настроение, ведь нуднятины и скуки в работе убавится
• Время на что-то реально полезное и интересное
• Полную картину мира тестирования, да и проекта в целом
• АБСОЛЮТНУЮ ВЛАСТЬ!!!