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

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

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

Улучшение тестирование планируется по трём направлениям — процессы, методики и инструментарий. Изменение процессов сложное, только если действовать революционными изменениями, если умерить пыл и проводить изменения плавно получается просто и намного тише. Инструментарий в плане внедрения намного сложнее, особенно для обеспечения процессов. Любая формализация ведения задач и отчетности вызывает скрытое сопротивление, преодолеть его хоть и не сложно, но требует времени и много внимания.

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

Общее планирование развития разумно начать с формализации и унификации существующих процессов: что тестеры делают до, во время и после релиза; как нужно вести заметки по работе; и так далее. У меня это вылилось вот в такие пункты документа по улучшениям:

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

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

В последующих планах в основном придется оперировать только этими тремя сущностями – процессы, методики и инструменты. Насколько насыщенными будут дальнейшие планы, напрямую зависит от уровня продумывания и исполнения двух первых этапов.

MindMap Ежедневных митингов (кликабельно)

]]> http://blog.alsedi.com/mindmap-dlya-ezhednevnyx-mitingov/feed/ 0 http://blog.alsedi.com/departament-qa-otslezhivanie-zadach-kak-chast-informacionnoj-sistemy-chast-2/ http://blog.alsedi.com/departament-qa-otslezhivanie-zadach-kak-chast-informacionnoj-sistemy-chast-2/#comments Tue, 14 Oct 2008 16:57:09 +0000 Alex http://alsedi.com/blog/?p=113 Continue reading →]]> В первой части я кратко упомянул о том, как может выглядеть процесс выпуска релиза в небольшой компании. В больших фирмах существует намного больше людей, которые заинтересованы в конечном продукте. Некоторые мнения приходится учитывать не только в процессе выпуска программного продукта, но и при создании информационной системы о процессе разработки и тестирования.
Ниже показаны основные группы людей, которым может потребоваться информация о том, что происходит с продуктом и что в нём будет еще до момента финального релиза.

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

Список вопросов неполный, но 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 для позднего исправления. Процесс запускается по новой… в идеале.

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