Моя статья "Tester's KPI" и участившиеся билды продуктов компании ConquestSS без тестирования сподвигли меня объединить данные обоих исследований и попытаться найти лучшую пропорцию количества тестировщиков и курируемых продуктов в команде разработки. Видеоролик "Нужен ли тестировщик на проекте?" от ПОИНТ-курсов утверждает, что наилучшее сочетание - это 1 тестировщик на 3 программиста, и в данных для моих графиков оно почти соблюдено.
Давайте оценим соотношения по фактическим цифрам.
Компания ConquestSS за 37 месяцев разработки одного продукта опубликовала 33 билда, за 8 месяцев параллельной разработки двух продуктов опубликовала 12 билдов, за 76 месяцев параллельной разработки трёх продуктов опубликовала 51 билд, за 37 месяцев параллельной разработки 4 продуктов опубликовала 59 билдов, за 12 месяцев разработки двух продуктов опубликовала 26 билдов. Примерная пропорция 1месяц/1продукт сбилась в правой части графика из-за отсутствия тестировщиков. Это хорошо заметно по следующему графику.
На всём протяжении выбранного периода, за который у меня накопились данные из публичных источников, пропорция 1тестировщик/3программиста сохранялась до последней части, когда команда ConquestSS совсем исключила тестировщиков-профессионалов (осталась лишь тех.писательница, слегка обучившаяся тестированию) и штат программистов сократился в 4 раза. В первом периоде один тестировщик параллельно обслуживал 3 продукта и за 107 месяцев было опубликовано 82 билда, два тестировщика на 3 продукта и 6 программистов помогли выпустить 12 билдов за 11 месяцев, 3 тестировщика на 9 программистов выпустили 17 билдов за 18 месяцев, 4 тестировщика на 10 программистов за 3 месяца выложили 5 билдов, 3 тестировщика (без ведущего специалиста) на 11 программистов за 13 месяцев выпустили 22 билда, а оставщиеся два с полтиной программиста за 17 месяцев выложили 42 билда. Эти цифры убеждают меня в моём мнении, что пропорция продуктов и тестировщиков более эффективна при соотношении 1/1. В предпоследнем периоде количество билдов в месяц возросло, поскольку все три тестировщика остались из числа юниоров, а шестой период при полном отсутствии тестировщиков подтверждает моё мнение, что программисты с лёгкостю пропускают в прод критичные баги, из-за которых приходится срочно выкладывать фикс-билды.
Графики показывают интенсивность билдов по точкам. Если точки расположены на одной прямой, значит номер версии не увеличивался и билд собирался для исправления какого-то важного бага юзера. По вертикали - номера версий продуктов, по горизонтали - даты выпуска, четыре цвета точек (синий, рыжий, зелёный, голубой) соответствуют четырём основным (без WEB сайта и портала) продуктам (SQLDetective, ClearSQL, ClearDB, docuVIEWER). У группы разработки ConquestSS существует правило: если от пользователя приходит критичный баг, то фикс-билд выкладывается всем в течение одной-двух недель. Но если баг важный для юзера, но готовится к выпуску следующая версия продукта, то юзеру даётся индивидуальный билд, а фикс официально публикуется в новой версии. По прижатости точек на графике вы можете заметить, как росло и падало качество продуктов со временем "взросления" одного тестировщика (первый период), приходом и уходом мидлов (второй и третий периоды), при полностью обновлённой группе тестирования (четвёртый период - один синьор и три юниора, пятый период - три юниора) и при полном отсутствии профессиональных тестировщиков (последний период).
Прежде чем приглашать в команду тестировщика, хорошенько подумайте, а нужен ли вообще кто-то ещё вашей команде. Например, фин.директор и маркетолог ConquestSS, избавляясь от ведущего QA инженера или справляясь о житье-бытие, оговариваются по Фрейду, заявляя, что своих багоделов всегда достаточно, чтобы развалить компанию. Судя по вышеизложенным цифрам, группа разработки может работать стабильно, если раз в месяц концентрируется над одним продуктом. Вполне оправдан спринт в месяц для десктопного продукта, но слегка назойлив для юзера. Но если учесть, что компания ConquestSS поддерживает 3-4 продукта, то стабильные публикации билдов одного продукта раз в квартал смогли бы успокоить клиентов в плане надёжности поставщика, а группа разработки не распылялась бы на все продукты ежедневно. А там, глядишь и с глобалами бы проблема отпала, поскольку на ежемесячных планёрках такие задачи не смогли бы забыться.
Для себя, нас - тестировщиков, делю на четыре группы:
- инженер QA (quality assurance) постоянно задаёт неудобные вопросы, ведущие к развитию продукта и команды, лезет во все дела, имеет право голоса и влияния. Преподаватели из "Стратоплан" зовут таких бунтарями (смотрите доклады М. Завилейского "Три составляющие" и Олега М. Вайнбера "Зачем мы приходим в организацию и почему она нанимает именно нас");
- инженер QC (quality checker) - констататор фактов без собственного мнения, покладистый и безмолвный;
- инженер BA/BI (business analyst, business intelligence) - идейный лоббист юзерского и своего мнения;
- тестировщик на техподдержке - сборщик фактов и переводчик между пользователем и кодировщиком без права собственного мнения.
Не смотря на давнишнее рождение компании ConquestSS (с 2005 года) группа разработки придерживается позиции стартапа, поэтому так легко пренебрегает качеством продуктов. Хорошо бы на эти графики наложить суммы продаж, но у меня нет такой информации, которая бы доказала РМ-у необходимость профессионального тестирования. Программист никогда не проверит свой код так, как этим продуктом пользовался бы конечный юзер.
После просмотра доклада "Как QA инженеры могут повлиять на качество продукта? Или не могут?" Николая Алименкова на QA Fest 2016 у меня сформировалось мнение, что бизнесу разного уровня нужен определённый специалист:
* начальная стадия бизнеса (стартап, 1..5 разработчиков, нет или мало отзывов юзеров)
*-* роли тестировщика, аналитика, внедренца, техподдержки выполняют сами разработчики и владелец продукта, бизнес-аналитик выполняет роль технического консультанта
* средняя стадия бизнеса (продукту несколько лет на рынке, 5-20 разработчиков и аналитиков, отзывы регулярные)
*-* достаточно тестировщика на техподдержке и толкового аналитика-внедренца с функцией тех-консультанта
* стабильный бизнес (продукт сертифицируется по ТУ-ISO-ГОСТ, командный состав не важен, отзывы потребителей выходят на уровень юридических претензий)
*-* обязательная выделенная команда тестирования и контроля качества, совмещающая техподдержку, но отдельная от группы аналитиков и тех.консультантов.
А как в вашей команде соотносятся количества тестировщиков с программистами, продуктами и регулярностью выпусков?
Давайте оценим соотношения по фактическим цифрам.
 |
| Соотношение билдов в месяц и продуктов |
 |
| Соотношение тестировщиков и выпускаемых билдов |
Графики показывают интенсивность билдов по точкам. Если точки расположены на одной прямой, значит номер версии не увеличивался и билд собирался для исправления какого-то важного бага юзера. По вертикали - номера версий продуктов, по горизонтали - даты выпуска, четыре цвета точек (синий, рыжий, зелёный, голубой) соответствуют четырём основным (без WEB сайта и портала) продуктам (SQLDetective, ClearSQL, ClearDB, docuVIEWER). У группы разработки ConquestSS существует правило: если от пользователя приходит критичный баг, то фикс-билд выкладывается всем в течение одной-двух недель. Но если баг важный для юзера, но готовится к выпуску следующая версия продукта, то юзеру даётся индивидуальный билд, а фикс официально публикуется в новой версии. По прижатости точек на графике вы можете заметить, как росло и падало качество продуктов со временем "взросления" одного тестировщика (первый период), приходом и уходом мидлов (второй и третий периоды), при полностью обновлённой группе тестирования (четвёртый период - один синьор и три юниора, пятый период - три юниора) и при полном отсутствии профессиональных тестировщиков (последний период).
Прежде чем приглашать в команду тестировщика, хорошенько подумайте, а нужен ли вообще кто-то ещё вашей команде. Например, фин.директор и маркетолог ConquestSS, избавляясь от ведущего QA инженера или справляясь о житье-бытие, оговариваются по Фрейду, заявляя, что своих багоделов всегда достаточно, чтобы развалить компанию. Судя по вышеизложенным цифрам, группа разработки может работать стабильно, если раз в месяц концентрируется над одним продуктом. Вполне оправдан спринт в месяц для десктопного продукта, но слегка назойлив для юзера. Но если учесть, что компания ConquestSS поддерживает 3-4 продукта, то стабильные публикации билдов одного продукта раз в квартал смогли бы успокоить клиентов в плане надёжности поставщика, а группа разработки не распылялась бы на все продукты ежедневно. А там, глядишь и с глобалами бы проблема отпала, поскольку на ежемесячных планёрках такие задачи не смогли бы забыться.
Для себя, нас - тестировщиков, делю на четыре группы:
- инженер QA (quality assurance) постоянно задаёт неудобные вопросы, ведущие к развитию продукта и команды, лезет во все дела, имеет право голоса и влияния. Преподаватели из "Стратоплан" зовут таких бунтарями (смотрите доклады М. Завилейского "Три составляющие" и Олега М. Вайнбера "Зачем мы приходим в организацию и почему она нанимает именно нас");
- инженер QC (quality checker) - констататор фактов без собственного мнения, покладистый и безмолвный;
- инженер BA/BI (business analyst, business intelligence) - идейный лоббист юзерского и своего мнения;
- тестировщик на техподдержке - сборщик фактов и переводчик между пользователем и кодировщиком без права собственного мнения.
Не смотря на давнишнее рождение компании ConquestSS (с 2005 года) группа разработки придерживается позиции стартапа, поэтому так легко пренебрегает качеством продуктов. Хорошо бы на эти графики наложить суммы продаж, но у меня нет такой информации, которая бы доказала РМ-у необходимость профессионального тестирования. Программист никогда не проверит свой код так, как этим продуктом пользовался бы конечный юзер.
После просмотра доклада "Как QA инженеры могут повлиять на качество продукта? Или не могут?" Николая Алименкова на QA Fest 2016 у меня сформировалось мнение, что бизнесу разного уровня нужен определённый специалист:
* начальная стадия бизнеса (стартап, 1..5 разработчиков, нет или мало отзывов юзеров)
*-* роли тестировщика, аналитика, внедренца, техподдержки выполняют сами разработчики и владелец продукта, бизнес-аналитик выполняет роль технического консультанта
* средняя стадия бизнеса (продукту несколько лет на рынке, 5-20 разработчиков и аналитиков, отзывы регулярные)
*-* достаточно тестировщика на техподдержке и толкового аналитика-внедренца с функцией тех-консультанта
* стабильный бизнес (продукт сертифицируется по ТУ-ISO-ГОСТ, командный состав не важен, отзывы потребителей выходят на уровень юридических претензий)
*-* обязательная выделенная команда тестирования и контроля качества, совмещающая техподдержку, но отдельная от группы аналитиков и тех.консультантов.
А как в вашей команде соотносятся количества тестировщиков с программистами, продуктами и регулярностью выпусков?
"Кто ты, QA-инженер или тестировщик?" (https://habr.com/ru/company/dodopizzadev/blog/497014/) - статья о разнице между QA и QC с ссылками на общепринятые определения.
ОтветитьУдалить