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

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

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

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

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

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

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

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

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

Выбор своего направления большинство начинает с мечтаний о своём успехе. Некоторые начинают копаться в выбранной теме и в результате либо разочаровываются, либо добиваются успеха. Но большая часть продолжает жить в своих грёзах. Обычно это проявляется в завышенной оценке своих знаний. Бурное развитие ИТ и появлении ярлыков на некоторых направлениях привело к появлению множества “специалистов” с романтическим представлением о своих способностях и знаниях.

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

Проверяется вопросами:

- Как вы развиваетесь? Обычно говорят читаю книги или блоги или сайты

- Что вы читали последнее время?

Если на втором вопросе происходит затык (не пауза на вспоминание названий, а именно неуверенность), но ответ “я читал книжку Х” всё-таки следует, можно поговорить о том, что в ней узнал человек. После собеседования, если книга неизвестная попробовать найти её и оценить самому. Это как безопасный секс, только с мозгами.

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

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