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

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

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

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

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

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

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

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

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