В нашем блоге, равно как и внутри компании, большую часть времени мы обсуждаем одну тему: тестирование и его организацию. Мы часто пишем, как применять те или иные подходы к анализу качества продукта, много времени уделяем автоматизации тестов, постоянно следим за различными конференциями — в общем, все время пытаемся понять, как улучшить нашу работу и принести больше пользы конечным пользователям. Нам интересно писать про эти задачи, а статистика посещений материалов показывает, что и читать их тоже бывает полезно.
Исходная ситуация: крупный клиент со сложным ПО, тестированием которого занимается команда в 20+ специалистов. Клиент хочет, чтобы каждый месяц мы отчитывались о состоянии его продукта и проделанной нами работе. В общем, стандартная для рынка ситуация. Но в какой-то момент заказчик решил изменить формат отчетности. Вместо одного свободного, нас попросили разбить его на сложные категории, позволяющие сразу восьми разным департаментам понять, какая работа, важная именно для них, была проделана за отчетный период. В итоге мы имеем не один отчет, а сразу восемь, на подготовку которых уходит от 25 до 40 часов. Так стандартная для рынка ситуация превратилась в ночной кошмар.
Наше решение: вспомнить, что автоматизировать можно не только тест-кейсы, но и бизнес-процессы. В июле отчет, на который обычно уходило несколько дней и, примерно, 100 кружек кофе для разъяренных менеджеров и тестировщиков, мы подготовили за 10 минут. И решили, что впредь на всех крупных проектах бизнес-процесс «клиент — тестирование — отчетность» должен быть автоматизирован. Хотите узнать, какой эффект оказывает отказ от бесконечных таблиц, справок, сводных табелей на процесс тестирования и отношения с клиентами? Тогда следуйте за нами. Но начнем мы с короткого рассказа-утопии…
То, как видит организацию тестирования менеджер-идеалист
Организация тестирования продукта, которым ежемесячно пользуются тысячи, а иногда и сотни тысяч клиентов — задача мечты для любого амбициозного менеджера по тестированию. На встречах с заказчиком идеи так и сыпятся из тебя, мысленно ты уже выстраиваешь стратегию работы с сервисом. Все муторные и скрытые от глаз конечного пользователя операции мы автоматизируем. Подберем классного специалиста по интерфейсу и юзабилити, способного повысить лояльность клиентов к бренду. Подключим с десяток сильных инженеров по ручному тестированию, до этого работавших на проектах схожей тематики. Они быстро погрузятся в новый продукт и помогут нам решить болезненные, но неизбежные для старта проблемы в духе «У нас вообще ничего не работает так, как надо — помогите!»
В процессе, порой многочасового, словесного пинг-понга ты видишь, как глаза технического директора начинают гореть, он включается в диалог и предлагает обсудить варианты решения тех или иных архитектурных проблем сервиса. Менеджер по продукту уже уверен, что еще один мощный рывок — и клиенты будут абсолютно удовлетворены сервисом, созданию и выводу на рынок которого он посвятил последних несколько месяцев, а то и лет. И когда феи-крестные уже запели свои торжественные гимны, в воздухе повисает неловкий вопрос…
То, как выглядит организация тестирования на самом деле
А как же все эти планы и активности мы трансформируем в понятные, наглядные, а главное — прослеживаемые отчеты? Что технический директор покажет генеральному директору компании или руководителю подразделения в конце отчетного месяца, когда придет время платить за услуги стороннего заказчика? В этот момент тебе надо придумать, как превратить построенные воздушные замки в четко измеряемые и понятные документы.
Как утверждает наш аккаунт-менеджер Олег Грабко, в целом, в создании отчетности нет никаких проблем. Он руководит тестированием на больших коммерческих и государственных проектах, поэтому привык к никогда не заканчивающейся работе с разношерстными данными: «Таблицы-таблицы-таблицы. Где бы я ни работал, с каким бы заказчиком ни разговаривал, мы все время обсуждаем данные, уходящие в бесконечность Excel-ких документов».
Проблема первая: каждый отчет — это чье-то время,
а значит — деньги
«С одной стороны, я могу понять заказчика, желающего платить только за время, потраченное на тестирование, — говорит Олег. — С другой стороны, я не знаю ни одного заказчика, который при этом отказался бы от подробных отчетов о проделанной нами работе». В итоге начинается торг, какой объем времени заказчик готов заложить на подготовку ежемесячной отчетности, а какой переложить на плечи подрядчика.
Эта игра в кошки-мышки вот уже годами продолжается на всех крупных проектах. За это время появились десятки платных систем, предлагающих автоматизировать какой-то кусок отчетности: потраченное сотрудниками время, динамику заведения новых баг-репортов и закрытия исправленных ошибок. Казалось бы: используй их, и все будут счастливы. Но «решения из коробки» почти всегда требуют серьезных ручных доработок, чтобы заказчик в конце месяца получил именно тот отчет, который ждет.
«Когда совершенно неожиданно на подготовку одного отчета для крупного клиента стало уходить не 5-7, а до 40 часов чистого времени, мы поняли, что пора что-то менять, — говорит Олег. — После одного такого «эффективного» месяца мы больше не могли смотреть, как в пустоту бумажной волокиты проваливаются часы и часы, которые мы могли бы потратить на тестирование».
Итог: вместо 40 часов — 10 минут на формирование отчета и 30 минут на его проверку. Мы сэкономили и деньги заказчика, и деньги компании.
Проблема вторая: каждый отчет — это чьи-то нервы
Когда на протяжении многих лет работаешь с людьми, а уж тем более руководишь ими, волей-неволей начинаешь интересоваться психологией. И не популярными теориями, описанными в тонких книжках с кричащими названиями «Заставь их подчиниться твоей воле за неделю», а глубокому анализу ключевого, базового вопроса нашей цивилизации: «Что делает человека счастливым, и как не убить работой это счастье?» Если почитать исследования, посвященные теории переключения между разными задачами и влиянию этого переключения на эмоциональный фон человека, то становится понятно, почему большинство тестировщиков ненавидят отчеты.
Проблема простая и неплохо изученная еще в 20-х годах прошлого века: каждое «переключение» имеет свою цену. И чем реже эти переключения происходят, тем большую цену придется за них заплатить. Не пробегайте эту мысль глазами, остановитесь и просто подумайте: а как бы вы относились к работе, если бы раз в месяц вам предлагали, к примеру, вырыть траншею. То есть 21 рабочий день вы тестируете интересный продукт, проходите курсы, чтобы повысить квалификацию, посещаете занятия по английскому языку, а затем, на 22 день, вам дают таблицу и просят отметить в ней все, чем вы занимались.
Окей, вы перенесли время из системы автоматического учета, перенесли задачи, сформировали отчет — не сходится. Тут что-то выпало, там что-то осталось за бортом, а еще менеджер, висящий над душой с бесконечным «Когда ждать? Когда ждать? Когда ждать?». А теперь представьте мир, где на все это вы тратите минуту-другую в конце рабочего дня, а затем система сама формирует все нужные заказчику документы. И теперь это не фантазия, а наш подход к работе.
Итог: инженеры по тестированию наконец-таки выдохнули и больше не воспринимают конец рабочего месяца как день пыток и решения задач, не свойственных ни их темпераменту, ни их интересам. Заказчик же получает большую лояльность людей, задействованных на проекте. Они больше не воспринимают его как «того самого, кто вот это вот мне все устроил».
Проблема третья: каждый отчет — это чья-то ошибка
«Наверное, об этом смешнее всего говорить, — смеется Олег. — Но тестировщики до дрожи боятся пропустить критичные баги, поэтому могут буквально зависнуть на каком-нибудь отчете». И если инженеры могут с этим как-то смириться (коллеги, спокойнее, я сказал «могут», а не «должны»), то менеджеры — нет. Любая ошибка в строгом по форме отчете — это риск потерять клиента, поэтому всю документацию приходится проверять по нескольку раз.
А если ошибка все-таки произошла, и мы не можем быстро ее устранить? Тогда приходится перепроверять каждый пункт, каждую ячейку — и так до финального свистка.
Итог: заказчик получает выверенный отчет, менеджеры и бухгалтеры на его стороне могут быть уверены, что мы предоставили им точные данные.
Как мы это сделали?
В конце этого материала хотим коротко рассказать, как же мы в итоге решили эту проблему. Всех карт раскрывать не станем, но покажем наш стэк.
Интерпретатор — Python 3.5.2
Из стандартных библиотек:
- datetime — работа с датой и временем;
- re — работа с регулярными выражениями;
- json — работа с форматом JSON;
- sys — управление интерпретатором Python;
- calendar — работа с календарем;
- logging — логирование.
Из сторонних библиотек:
- requests[2.19.1] — работа с REST запросами;
- openpyxl[2.5.3] — работа с файлами Excel.
Дополнительно:
- Операционная система — Linux Mint 18.3 Sylvia/
- IDE — pycharm-community-2018.1.4
- Git-сервер — gitlab.com
Мы готовы дать несколько советов, с чего стоит начать автоматизацию бизнес-процессов:
1. Выделите все сущности вашей отчетности. Измерить и посчитать можно все. Автоматизировать подсчет под конкретный проект — тоже. Важно: если на этом этапе вы пропустите что-то, что якобы занимает «немного времени», то это уже не имеет никакого отношения к автоматизации. Это значит, что вы построили неправильную архитектуру, которая не просто не ускорит вашу работу, но может внести в нее ненужный хаос.
2. Думайте о бизнесе, а не о коде. Если у вас небольшой проект на 2-3 человека, то старые добрые таблицы — ваш лучший вариант. Не нужно автоматизировать то, что не принесет вам конкретных, хорошо просчитанных результатов. Сэкономленные 2 часа никогда «не отобьют» труд команды по автоматизации.
3. Не предлагайте решение. Вообще. Никогда. Формулируйте условия, опишите текущее положение дел — и отпустите ваших автоматизаторов на волю. Если вы не ошиблись в людях, отобранных в команду, они вас точно удивят нестандартными решениями.
4. Код не должен быть одноразовым. Выстраивайте архитектуру, а не пишите скрипты. Скрипты устаревают, становятся неактуальными, а хорошо выстроенная система — нет. Ее всегда можно развивать эволюционно.
На сегодня — все!
До встречи в блоге «Лаборатории качества».
