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

В данной статье я буду говорить о создании отдела тестирования в зрелой компании со своими бизнес-процессами, но в которой нет отдела тестирования и его надо сформировать и регламентировать его работу.

Я не буду детально описывать во всех подробностях, что надо делать вроде этого: «взять ручку в правую руку, листок бумаги в левую, написать на листке…» Во-первых, вам это не поможет, так как в каждой компании надо действовать по ситуации и такие детали будут излишни, во-вторых это излишне для руководителя, имеющего уже определённый опыт, в-третьих это поможет только новичкам, но новичок без опыта на руководящей должности в отделе тестирования не должен заниматься формированием отделов. Но здесь есть одна оговорка, если новичок пробивной малый, который уверен в своих силах и постоянно обучается, совершенствуется и работает не покладая рук, то в этом случае он может выступать в роли руководителя вновь формируемого отдела, но ему лучше начать формировать отдел в стартапе. При этом у новичка должен быть практический опыт работы в сфере тестирования и желательно на высоком уровне, так как в стартапе он будет сначала единственным работником отдела, со временем постепенно расширяя штат сотрудников. Я именно так и начинал.

Хоть мелких подробностей и не будет в статье, но общий порядок действий будет мной озвучен, иначе зачем тогда вообще создавать статью!? Я постараюсь изложить в статье максимум данных. Также в статье будут ссылки на отдельно созданные мной статьи, в которых будут прилагаться шаблоны основных документов, которые нужны в отделе тестирования, с поясняющими данными. Начнём.

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

Труднее всего IT-директору найти руководителя отдела тестирования из-за того, что многие кандидаты начитались литературы и «красиво поют» на собеседовании, а когда дело доходит до практики, то тут и проявляется вся неграмотность руководителя. К сожалению, таких очень много.

Бесплатный совет IT-директору: ищите руководителя практика в области тестирования или того, кто имеет в прошлом большой практический опыт тестирования. Как он руководит коллективом вам остаётся только определить на собеседовании. Но не рекомендую брать на роль руководителя отдела тестирования менеджера, поверхностно знающего о тестировании, даже если это разработчик любого уровня. Встречал такие случаи – там всё грустно. Если сами вы не можете определить уровень технических знаний новичка, то подключите знакомых, у которых есть руководитель отдела тестирования, и который может провести техническую часть собеседования вашего нового руководителя отдела тестирования.

Вас нашли, и вы наконец-то стали руководителем нового отдела тестирования, где нет пока сотрудников. Тут начинается самое интересное, так как вы не обычный работник и вам никто не будет говорить, что вам делать. Для вас будет только одна вводная «сформировать отдел тестирования и наладить работу» при этом подразумевается, что вы знаете как это делать. Но руководить готовым отделом и формировать отдел с нуля это две разные вещи. До управления вы дойдёте только если успешно сформируете отдел. Поэтому вам надо самим чётко определить вектор своего движения и начать двигаться, иначе вы окажетесь на улице после испытательного срока или раньше. Что же делать дальше? Об этом мы сейчас и поговорим. Сразу скажу, что описанный мною порядок возможно не единственно возможный.

Первое что вам необходимо сделать – составить план работы на ближайшее время, который включает в себя следующее:

1. Изучение взаимодействия отделов управления IT:
— Какие отделы включает в себя управление IT;
— Какие функциональные обязанности отделов управления IT;
— Принципы и правила процессов взаимодействия отделов управления IT.
2. Изучение принципов процесса разработки и внедрения в эксплуатацию ПО в текущей компании:
— Процесс разработки ПО;
— Процесс приёмки ПО;
— Процесс ввода ПО в эксплуатацию;
— Эксплуатация ПО.
3. Изучение бизнес-процессов компании и схемы взаимодействия подразделений компании:
— Какие подразделения существуют в компании;
— Какие функциональные обязанности подразделений и список решаемых ими задач;
— С какими смежными подразделениями взаимодействуют существующие подразделения;
— Какие используются для решения задач инструменты, регламенты и схемы взаимодействия.
4. Изучение продуктов компании:
— Какое ПО разрабатывается и требует тестирования (составляем схемы связей, структуры и т.д.);
— Изучение технико-эксплуатационных характеристик;
— Изучение задач в баг-трекере (знать проблемы ПО и текущее состояние дел).
5. Составление документов отдела:
— Должностная инструкция тестировщика;
— Регламент отдела тестирования;
— План тестирования каждого продукта;
— Отчёт для руководства (еженедельный либо ежемесячный);
— Вопросы и задачи для приёма новых сотрудников;
— Тестовая документация: отчёты о тестировании, тест-кейсы, чек-листы и т.д. (это шаблоны, на основании которых будут создаваться промышленные документы).
6. Анализ и выбор инструментов:
— Система хранения и выполнения тест-кейсов;
— Инструменты для автоматизированного и нагрузочного тестирования;
— Наладка и настройка тестовых сред (с привлечением разработчиков, системных администраторов, DevOps-инженеров).

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

Можно и без плана «ринуться в бой», но вы постоянно будете себе хаотично придумывать некую деятельность, чтобы не бездействовать и, как итог, вы попадёте в хаос метаясь как молекула от одного к другому и ничего конкретного не делая, для постепенного и стабильного развития отдела. Да и работа без плана странное занятие. К примеру, я в своей деятельности создаю планы на каждую неделю. Это не обязательно документы на десятки страниц – это может быть одностраничный план с несколькими крупными задачами, разбитыми на мелкие подзадачи и не всегда эти задачи я делаю лично, ведь план должен включать работу всего отдела.

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

Изучение бизнес-процессов и работы подразделений компании

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

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

Изучение ПО компании

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

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

Составляем документы отдела тестирования

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

Регламент отдела. Некоторые создают регламент ради того, чтобы он был. Регламент ради регламента, зачем? Если регламент неработающий, то он бесполезен. Некоторые создают регламент думая, что он нужен для ограничения действий сотрудников и для их жёсткого контроля. Это чушь!

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

Если вы думаете, что, придя в компанию, можно в первую неделю создать рабочий регламент отдела, то вы глубоко ошибаетесь, так как ваш регламент будет ничего не значащей и не работающей профанацией, для «галочки» перед руководством. Поэтому сначала изучите процессы компании, а потом начните писать регламент, и вы увидите, что у вас рождается рабочий инструмент в рамках компании. Если руководству нужен регламент в первые же дни, то объясните им почему это путь в никуда.

План тестирования. В среде тестировщиков о составе плана тестирования есть огромное количество заблуждений. Планом тестирования называют наборы тест-кейсов и прочие ничего общего не имеющие с планом тестирования документы. О структуре плана тестирования будет мной рассказано в отдельной статье. Ссылка на план тестирования и на прочие документы будет в конце данной статьи. Для многих план тестирования бесполезен, для некоторых он нужен, чтобы отчитаться перед руководством. В чём же польза плана тестирования?

Из многого что написано в плане есть информация о видах тестирования проводимых при тестировании определённого ПО, а также технические характеристики и структура тестовых сред. Первое будет полезно новым тестировщикам, которые придя к вам на новое место работы смогут изучить план и понять какие виды тестирования и для чего требуется проводить при проверке тестируемого ПО. Характеристики важны будут системным администраторам, разработчикам, тестировщикам и т.д. при разворачивании тестовых сред. Если план тестирования создаётся не для отчёта, то ещё много полезной информации найдут в нём сотрудники компании.

Отчёт отдела для руководства. В некоторых организациях руководство не требует отчёты о проделанной работе от руководителей отделов, а в некоторых они обязательны. Мы с вами будем рассматривать второй тип организаций. При подготовке шаблона отчёта создаём в нём разделы:
— Работы, выполняемые на прошлой неделе;
— План работ на текущую неделю;
— Проблемы, которые мешают в работе и пути их решения;
— Предложения по улучшению процессов вашего подразделения и подразделений компании.

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

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

Тестовая документация. Чтобы отдел работал эффективно вам необходимо регламентировать и стандартизировать работу. Это не значит изучить промышленные стандарты и внедрить их все. Это значит ввести собственные стандарты составления документации и ведения процессов. Это упростит вам работу. Процессы описаны у вас в регламенте и в регламентах других отделов, теперь подготовьте шаблоны документов, на основании которых ваши сотрудники будут создавать рабочие документы:
— отчёт о тестировании ПО;
— тест-кейсы;
— чек-листы и т.д.

Сотрудникам останется только взять готовый шаблон и на сновании его подготовить рабочий документ.

Анализ и выбор инструментов

В процессе работы будут создаваться тест-кейсы и вам конечно же надо будет определиться где они будут храниться: таблицы Excel на общем ресурсе или локально; специализированные инструменты для написания, хранения тест-кейсов и выполнения тестов. Рекомендую выбирать специализированные инструменты, так как в них можно после выполнения тестов строить различные отчёты для себя и руководства, а также они намного удобнее табличек, которые заполняются вручную.

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

Тестовые среды. Чтобы что-то тестировать вам придётся развернуть тестовые среды самостоятельно или с привлечением разработчиков, системных администраторов или DevOps-инженеров. В своей практике я стараюсь использовать две тестовые среды на одно тестируемое решение.

Как создать отдел тестирования программного обеспечения

«Рабочая среда» = «Рабочие сервера».
Правка ошибок и публикация исправлений производится разработчиками на «Тестовая среда 1».
На «Тестовая среда 1» публикуются отдельные реализованные задачи и исправления и тестируются тестировщиками.
На «Тестовая среда 2» публикуются полные релизы со всеми исправлениями перед выходом продукта на «Рабочая среда» и проводится полное комплексное тестирование ПО.
На «Тестовая среда 2» не производится правка ошибок и внесение каких-либо отдельных изменений вне процесса подготовки продуктов к размещению на «Рабочая среда».
На «Рабочая среда» публикуются продукты с «Тестовая среда 2» и только после полного комплексного тестирования продуктов на «Тестовая среда 2».
На «Рабочая среда» не производится правка ошибок вне процесса тестирования, допускаются размещение исправлений на критические ошибки и данные исправления также размещаются на «Тестовая среда 1».
На каждом этапе рабочая группа решает пойдёт ПО на следующий стенд и в рабочую среду. Если ПО устанавливается на тестовый сервер, то в рабочую группу входят тестировщики и разработчики, если ПО готовится к размещению на рабочий сервер, то в рабочую группу дополнительно входят менеджеры проектов и прочие руководители с решающим правом голоса.

Тестовая среда подразумевает под собой весь комплекс ПО. К примеру, если компания разрабатывает SaaS сервис, имеющий front-end и back-end, базы, балансировщики и т.д., то тестовая среда должна содержать всё это в себе, чтобы весь этот «зверинец» можно было протестировать в любой момент, не затрагивая рабочие сервера.

Заключение

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

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

Документация

Ссылки на озвученные в статье документы:

Регламент работы отдела тестирования

План тестирования программного обеспечения

Обновлено 18.01.2021:

Должностные инструкции отдела тестирования