Home

Автор: Илья Комендантов

Оригинальная публикация

Когда встречаю объявления типа: "В связи с расширением штата сотрудников, требуется..", "Молодая развивающаяся компания ищет.. " и подобные им, сразу представляю, как маленькое село вырастает в пгт, оно, в свою очередь, в город, а тот – в мегаполис.

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

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

Такое себе – нагрузочное тестирование. Может стоит для анализа проблем фирмы нанимать перформанс инженеров? Почему бы и нет.. Интересно, были прецеденты?

Психологи говорят, что многие проблемы человека уходят корнями в его детство, этот же допущение верно и по отношению к организациям:

Детство. Много воды утекло с тех пор, как руководство осознало необходимость проверки продукта до его продажи и постановило – создать отдел тестирования. Сначала наняли аж двух тестировщиков, а когда всплыло, что продукт не такой совершенный (как уверяли программисты) ещё к ним тим-лидера (ТЛ) и гастрабайтера, пусть тоже будет. ТЛ распределил области ответственности между тестировщиками и понеслась, каждый пишет себе план и выполняет определённый объём работ, рапортует менеджеру, тот – дальше. Все при деле.

Взрослые годы. Сейчас отдел тестирования разросся (занялись аутсорсингом тестирования), давно подняли баг-трекер, набрали ещё людей (общей суммой около ста!), сформировали команды, даже попытались автоматизировать часть продуктов (правда путного получилось мало, ну и ладно). Да только так и работают по-старинке: у каждого инженера своя область ответственности, работы много, и основное время съедает выполнение тестов.

Стоп! Вы заметили проблемы, которые тянутся из "детства"?

• Где взять столько спецов?
  У каждого своя область (допустим их пять) ответственности, а продукт один. Следовательно, чтобы его качественно оттестировать, надо пять спецов. Чем круче спец, тем лучше результат. Промежуточное решение, принятое во многих фирмах – на критичные область бросать совсем мега-пацанов, а на остальные области, людей попроще.
• Хорошие спецы хотят хороших денег.
  Совсем обнаглели, не может же большая фирма сотням сотрудников, платить такие же зарплаты, какие предлагают мелкие стартапы, чтобы сразу купить себе мега-пацанов!
• Нерешённая вторая проблема порождает текучку.
  С одной стороны не можем себе позволить платить запредельные суммы, с другой стороны тяжело отпускать мега-спецов, что ставит проект под угрозу. Пока найдёшь или обучишь нового, пока он втянется в процесс, а работу надо делать ещё вчера. Остаётся что? Обещать, обещать светлое будущее.
• Эффективность сотрудников.
  Если одному сотруднику платят в два раза больше чем другому, то это ещё не означает, что он работает лучше или делает больше работы.
• Во многих случаях знания о продукте тяжело просто взять и передать новому человеку, оно "уплывает" вместе с покинувшим проект сотрудником.
  Написание очень подробных тест-кейсов может решить проблему, но их создание требует много времени, которое лучше потратить на тестирование (самому себе писать подробные тесты нет смысла, обычно пишут тезисные подсказки, что не забыть проверить).
• Постоянное переключение между задачами:
  Написание тест-плана, тест-кейсов, подготовка тестового окружения, непосредственное тестирование – не позволяет создать серьёзных наработок, в какой-то одной из этих областей.
• Всё это вместе взятое снижает общее качество оказанных услуг.

Модель работы тестировщика, пришедшую из "детства" фирмы, назовём "вертикальной моделью" и она порождает проблемы при увеличении штата сотрудников (список проблем см. выше, можете расширить и углубить). Схематично можно представить так:

Естественно, в каждой фирме свои особенности, что-то из "серой" области переходит в "зелёную", не суть.

Как сделать рефакторинг, чтобы пускай не полностью, но хотя бы частично решить проблемы, описанные выше?

Давайте рассмотрим несколько "постулатов":

• "Дорогой" сотрудник должен делать "дорогую" работу. Как только это правило нарушается – фирма теряет деньги. Если "дешёвый" сотрудник делает "дорогую" работу – фирма теряет в качестве.
• Разделение труда является причиной повышения общей производительности труда организованной группы специалистов (синергетический эффект) за счет:
  a. Выработки навыков и автоматизма совершения простых повторяющихся операций
  b. Сокращения времени, затрачиваемого на переход между различными операциями
• 20% людей делают 80% работы - принцип Парето.

Основываясь на всех этих постулатах, создадим модель распределения труда тестировщиков, которую так и назовём "горизонтальная модель":

Senior QA (SQA) – это "мостик" между командой тестировщиков и практически всеми участниками процесса разработки, он не выполняет тесты, всё его время направленно на подготовку непосредственно процесса тестирования. Он тесно общается с ответственным за создание требований к продукту, а когда они созданы (FA) и проверены (им же), внесены возможные коррективы, он переключается на структуру и дизайн будущего приложения. Общается с ответственными за это дело архитекторами и дизайнерами, пишет тест-план. После того, как разработчики приступили к кодированию, SQA занимается написанием тест-кейсов для всех фич продукта. Долгими вечерами общается с девелоперами (пивко?) для получения целостной картины работы приложения и написания подробных тест-кейсов. Знание различных методик тестирования позволяет оптимизировать набор тест-кейсов, а "подсмотренный" у программистов код – не пропустить ничего действительно важного. Такой подход к работе позволяет SQA целиком сосредоточиться на написании тест-кейсов, создания разнообразных шаблонов, как тест-планов, так и шаблонов тестирования стандартных диалоговых окон и др. Подобными шаблонами можно делиться с SQA других команд, а также черпать идеи из чужих шаблонов.

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

Middle QA (MQA) – этот человек уже своеобразный "мостик" между SQA и JQA. Он подготавливает возможности для выполнения тест-кейсов. Настраивает тестовое окружение: конфигурирует сервера, пишет необходимые AUTs (Applications Under Test), устанавливает ОС. Занимается автоматизацией (если решено какую-то часть продукта автоматизировать), изучает дополнительные программы (Selenium, QTP, AutoIt, BOM check, InputDirector и др.). После приобретения опыта в такого рода "тестировании", MQA уже накопил достаточное количество образов (ghost, acronis..) как ОС так и серверов. Он занимается оптимизацией использования машин и ресурсов. Подключается к выполнению тест-кейсов в случае необходимости.

Junior QA (JQA) – по сути, именно этих людей называют тестировщиками. Их основная обязанность – выполнение тест-кейсов, описание багов, создание отчётов, проверка починенных дефектов. Для большей эффективности работы, они мониторят список всех дефектов (если над продуктом работает ещё команды, например, из других стран). И если кто-то думает, что SQA выполнит свои тесты лучше чем JQA, то это совсем не обязательно так.

Принцип "Матрёшки": Человек приходит в тестирование без опыта. Знакомится с жизненным циклом дефектов, выполняет тест-кейсы (прошу заметить, очень грамотные тест-кейсы), тем самым обучаясь. Если может – дополняет их. Получает опыт. Из JQA переходит в MQA. Подготавливая тестовое окружение, он уже может учесть все нюансы, с которыми сталкивался в процессе тестирования. Получает новый опыт в программировании либо использовании программ автоматизации (если таковая присутствует на проекте), глубокие знания в конфигурировании серверов и операционных систем. Переходит на позицию SQA – тут так вообще не паханное поле для развития, но так как он был и JQA и MQA, при написании тест-кейсов он учитывает не только теорию, но и весь свой предыдущий опыт.

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

Теперь разберём, как решаются, описанные выше проблемы "вертикальной модели":

1. Где взять столько спецов?
   Действительно спецом должен быть только SQA, фирме на помощь приходит принцип "Матрёшки", а также "просеивание" кадров, что позволяет легче найти такого сотрудника. Он – лицо команды (человек-команда). То есть, если в продукте пять областей ответственности, для качественного тестирования нам надо не пять мега-пацанов, а одного.
2. Хорошие спецы хотят хороших денег.
   SQA – должен получать много. Фирма может себе это позволить, всё-таки он один, а не их пять на проект. Ни стартап ни большая фирма с "вертикальной моделью" организации не сможет "перекупить" нашего парня!
3. Текучка.
   a. Текучка SQA – крайне нежелательна, поэтому з/п у него серьёзная, конкурентная. Все усилия HR направлены в основном на них: Командировки на конференции, тренинги, бонусы, личные пожелания.
   b. Текучка MQA – неприятна, но не смертельна. HR сюда тоже заглядывают – бонусы, тренинги и др.
   c. Текучка JQA – вполне себе приемлемое положение, возможно даже первоначальный найм на контракт, скажем год, как себя покажет, так и примем решение, что делать с ним дальше (Если работа человеку понравится, он докажет, что годен быть MQA).
4. Эффективность сотрудников.
   a. Каждый концентрируется только на своей области, что позволяет создавать оптимизирующие наработки (шаблоны, вспомогательные программы и др.).
   b. Перебрасывание серьёзного спеца на работу с начальными этапами разработки (например, тестирование требований), позволяет "предупредить" многие баги и тем самым сэкономить время и деньги фирмы.
   c. SQA не тестирует, то есть "дорогой" сотрудник не делает "дешёвую" работу.
5. Потеря знаний о продукте, вместе с уходом людей.
   a. Во-первых, теперь люди представляющие "полную картину" продукта, редко уходят в другое место.
   b. Во-вторых, все знания запечатлены в подробных тест-кейсах, в которых учтены и особенности продукта, особенности кода (или просто внутренней структуры приложения), методы оптимизации (например, pairwise). Так что, если вдруг фирма потеряет главного бойца последней линии обороны, как минимум будут проведены качественные регрессионные тесты. Некоторые продукты разрабатываются десятками лет и имеют уже 11-ю версию :)
6. Постоянное переключение между задачами.
   a. Каждый сотрудник работает в своей области.
   b. SQA переключается, но не туда-сюда по нескольку раз в неделю, а последовательно, от тестирования требований, к дизайну и разработки, потом на написание тест-кейсов, это нормально.
7. Качество тестирования.
   Качество тестирования повышается за счёт пунктов 3-6.

Теперь преимущества, которые появляются как следствие перехода на другую модель работы:

1. На более качественные услуги фирма тратит меньше средств.
2. Самый дорогой сотрудник работает вне зависимости от задержек билдов или каких-либо холдеров, так как не занимается непосредственным тестированием (MQA частично тоже). В случае задержек или проблем с билдом "простаивают" только "дешёвые" сотрудники.
3. HR концентрируют усилия только на SQA и частично на MQA, что важно при большом количестве сотрудников, ибо никогда нельзя угодить большинству. В "горизонтальной модели" этого и не требуется.
4. Упрощённый рекрутинг. Если написаны подробнейшие тест-кейсы (MQA помогает расписывать их, добавляет названия машин, ОС и серверов с логинами и паролями), машины с нужными ОС и серверами настроены, часть работы автоматизирована, то прогонять оставшиеся тест-кейсы может любой человек с улицы, продвинутый пользователь ПК. А там уже курируем их, наблюдаем, делаем выводы.
5. Фирма не вкладывается в JQA и тем самым не "связывается" с сотрудником, и тем самым не теряет лишние деньги. JQA выполняют определённую работу, могут свободно изучать все процессы в фирме, присматриваться к работе более старших (по званию) коллег и решить, нравится – не нравится. Они выполняют грамотные тест-кейсы, тем самым уже самообучаясь. Имеют доступ к любым внутренним тренингам (проводимые MQA и SQA для каких-то своих нужд). Изучают баг-трекер, жизненный цикл дефектов, то есть основы, понравилось – пошёл дальше, здесь уже фирма их "подхватывает" и начинает активно помогать в дальнейшем развитии. По себе могу сказать, что первый год в новой сфере приносит столько нового, что никаких тренингов и не нужно, если работа нравится – прёт и само по себе. Человеку свойственно развиваться и обучаться.
6. По з/п я склоняюсь к соотношению JQA/MQA/SQA : 1 / 2-2.5 / 4-6.
7. Есть ещё такая идея – создать "буфер" исполнителей, например, цикл регрессии вообще не требует участия SQA, в основном это запуск автоматических скриптов (если такие имеются на проекте) и ими занимается MQA и ручной прогон набора тест-кейсов, для него можно подключить JQA из "буфера" на определённое время. Чем-то напоминает аутсорсинг :+) . Хотя вполне можно справляться и своими силами. Зависит от проекта.

Недостатки:

Долго думал над недостатками, но те, что смог придумать, решаются довольно быстро и просто. Кто, что придумает, сообщайте, будем дописывать ;).

ВЫВОДЫ:

Отделение мух от котлет Разделение труда позволяет сосредоточить серьёзных специалистов на работе, требующей знаний, опыта, английского языка (для общения) и много ещё чего, то есть на "дорогой" работе, на подготовке тест-плана и создании тест-кейсов, их приоритезации и оптимизации. Выполнение же самих тестов забирает много времени, но и может быть выполнено человеком (или несколькими) с достаточно "посредственными" знаниями и без опыта работы. То есть позволяет подключать людей с улицы, практически в любой фазе проекта.

UPDATE:
Как стало понятно из коментов в блоге, мой стиль изложения окончательно запутал думающие умы. Сравнение для большей наглядности, SQA - не является бюрократом, который сидит и следит как вся команда пашет.. :)))
SQA фактически "рисует машину на бумаге" он её создаёт, а остальные только занимаются тем, что делают заготовки из железа, пластика (MQA) и собирают всё это вместе по шаблону (JQA). Когда прикручивается новая фича, SQA дорисовывает её, используя всякую там оптимизацию и приоритезацию, чтобы всем остальным было проще ;-) Вот функциональный архитектор у программистов, отдалённо напоминает SQA в отделе тестирования, можно и его обозвать бюрократом и наехать, мол ничего не делаешь хад!

Обсудить в форуме