Когда кликать QA

Моя статья "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-ГОСТ, командный состав не важен, отзывы потребителей выходят на уровень юридических претензий)
*-* обязательная выделенная команда тестирования и контроля качества, совмещающая техподдержку, но отдельная от группы аналитиков и тех.консультантов.

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

Аналитики для тестировщиков

Список прямых ссылок и лично моё мнение о каждом докладе на конференции Analyst Days 10, проходившей 24-25 мая 2019 года в Санкт-Петербурге.
Зачем такой список? Мне лично не удобно долго смотреть доклады с сайта конференций или по плей-листу youtube. Поскольку мне часто хочется поделиться своими новыми знаниями, то потенциальным читателям облегчаю задачу поиска и запуска конкретного контента. А также мой список всегда имеет аннотации для конкретизации тематики.
Да, программа конфы красиво сгруппирована и есть инфа, по которой можно определить рекламные или заказные доклады, но для меня становятся лишними клики для открытия страницы с подробным контекстом каждого доклада. Составив себе список только из наименований докладов без имён компаний и рассказчиков моё внимание фокусируется лишь на смысле излагаемого материала. А плей-лист портала видеозаписей маловат при скроллинге, его нельзя отсортировать под себя и нет отметок об уже просмотренном. Некоторые откроешь, но для полного просмотра откладываешь, поэтому смена цвета линка в этом случае не помогает. Вот если бы указывался процент моего просмотра, то такой индикатор был бы более полезен.
Раньше площадкой для хранения видео был портал vimeo, но и его проигрыватель сильно перекрывался огромной плашкой куков.
К организаторам конфы, а точнее к тех.группе записи, сложились предложения:
* либо вообще не включать в запись блок вопросы-ответы, либо вопросы записывать в такой же микрофон, как и у докладчика. Потому что ответ без вопроса звучит глупо, непонятно, лишне и тому подобное;
* видео с докладчиком выводить в экран меньшего размера для улучшения восприятия. Нерационально использовать половину экрана на пустоту за телом докладчика, а слайды уменьшать до их нечитабельности;
* мастер-классы и доклады с досками, заполняемыми в режиме реального времени, сопроводить дополнительной видеокамерой, направленной на сам флипчарт для увеличения всем;
* звук из мастер-классов записывать через микрофоны, распараллеленные с ведущим.
Да, понимаю боль организатора - билеты на конференцию плохо покупают, а бесплатная публикация записей не несёт дохода. Но если записи станут удовлетворять вышеописанному, а также будут иметь лёгкую аннотацию от присутствовавших (=реклама из первых рук), то за просмотры можно будет брать ощутимую плату. 20-ю конференцию тестировщиков пытались продавать, но если бы вместо одного и того же ролика каждую запись предварял отзыв от побывавших (аннотация и отзыв бесплатно, а полная запись за плату), то организаторы собрали бы хороший куш.
Слабая наполненность залов и заверения (Никита Макаров про тестирование и конференции  с "01:05:52 - Про гайзенбаг" и далее) организаторов параллельной конференции Heisenbug  навело на мысль, что Analyst Days и SQA Days стоит объединить в одну, но расширить третьим течением - привлечь программистов, разработчиков, архитекторов. Тогда три потока (аналитик, программист и тестировщик) пересекутся в зоне BarCamp, их работодатель сэкономит на билетах, а конференция поднимется в статусе за счёт глобальности.

Мой список сгруппирован по приоритету для тестировщика (по-жизни я из числа критиков и оценщиков качества), но не отсортирован по порядку важности (мой просмотр получился в такой очереди, обусловленной наименованием каждого доклада).


полезное:
Байки из Банка. Как нам помогли пользовательские истории - о влиянии метода на весь процесс разработки
Единый язык проекта - два документа, которые должны быть изначально, словарь терминов (продуктовый, внутрикомандный) и диаграмма сущностей продукта
Погружение в новую предметную область, чек-лист аналитика - универсальный список дел для любой должности (аналитик, программист, тестировщик) + пункт о % выполненности + причины задержки
«Пиши-упрощай»: как сделать требования легкими для восприятия? - в помощь issue review
Трассировка: лучшие практики - реальные советы-напоминалки к шагам issue review
4 правила археолога: как «раскопать» систему - легаси, зачем первейший документ - структура проги, визуализация кода = карта (плохо слышно)
Фасилитация рабочих встреч: творчески и результативно - не подготовленное совещание не обеспечивает комфортного обсуждения (неожиданное прерывание текущей работы, недостаточность информации о материале дискуссии)
Все лгут. Живите с этим - техники практической психологии применимы тестировщиком на стадии планирования
Сценарии неэффективного использования ресурсов аналитика - что на кого спихнуть и когда
Игра в разработку. Опыт оценки профессиональных качеств аналитика - аттестация для доверия, статуса, планирования (не используемых в CSS), можно подменить покер-разработкой
Роль бизнес аналитика в решении нестандартных задач на сложных проектах - алгоритм решения проблем
Система мониторинга: продвинутый набор технических метрик или панорама успеха? - приятно слушать понятную речь о собственно изобретённом методе сбора и обработки информации
Самопредставление - мастеркласс от актёра в год театра для работников с первоочередной надобностью - общение и написание текстов (правильных, интересных, читабельных = по законам драмматургии)
Антикризисный аналитик: как подхватить проект и не надорваться - не так весело, как у Дорофеева про прокрастинацию, но также полезно и разложено по полочкам
Как мы оцениваем и развиваем больше сотни аналитиков - больше о том, как выбрать область развития в конкретной компании, есть подсказки надобности по ролям
Ценность ясности цели - про типы оппонентов и как их раскручивать
Кто и как на самом деле пользуется системой: от догадок к цифрам - как собрать и применять стат.данные о пользователях web-приложения
UX дашборда мечты. Как превратить хаотичные данные в один красивый динамичный экран - о правилах построения отчётов для верхнего звена
Учимся играть в бизнес-анализ - коротко о необходимости игры, но забыта обучающая роль
Учимся играть в бизнес-анализ (мастер-класс) - визуализация с подробными пояснениями, обучение от хорошо подготовленной лекторши; более пол-записи - самостоятельная работа в группах - не попал звук в ролик = бесполезный просмотр записи
Тактические приемы при работе с субподрядчиками - об одном успехе одной команды (что помогло, без перечисления помех)
Проверка гипотез требований к функциям и UX/UI с помощью Customer Journey Map. Рабочий кейс - альтернатива сочетанию методик демка+ретро
Свой DSL на проекте: когда и как - шаги по созданию своего и под себя не фреймворка, а намного глубже - целого языка, который ускорил написание кода и выявление багов (на уровне аналитика и кода)
Чек-лист для описания требований к интеграции - в помощь при тест-дизайне интеграции
TM Forum API: что, зачем и почему - телеменеджмент правила про стандарты
Ограниченность как источник вдохновения. Проектирование систем на базе идей инклюзивного дизайна - составление данных для тестов доступности
Дневник аналитика или как не стоит писать на gherkin - забавно о соблюдении правил
Заповедная зона – где продукт живет в мире с госзаказом - эмоционально о подводных камнях приоритетности качества в том числе
Работа аналитика в медицинской компании - тестировщику, идущему в мед.сферу, есть из чего дизайнить тесты


ну, послушайте...:
Зачем вам ПО. Драма в трех частях - нет 3 частей, нет драмы, но множество пунктов для общения с заказчиком
10 советов по организации удалённой работы аналитика - не затронуты технические и экономические стороны
Управление временем для аналитика - балабол
Управление требованиями в работе с удаленной командой - не столько специфичность управления требованиями, сколько общие подсказки по удалённой работе в области инструментов
Выбираем качество требований - забыто время доставки, как часть качества
IT Дирижер - слишком заумно и книжно
Единым махом семерых побивахом! или почему нельзя создать единственный понятный документ для всех - не 7, а только 3 типа доков; коучер, а голос дрожит как у дебютантки; чит-лист параметров для ума писателя доки
Эволюция процесса разработки продукта: роль аналитика - от аналитика к владельцу продукта
Путь из Бизнес-заказчиков во Владельцы продукта - как нашли или переименовали "козлов отпущения"
Визуализация данных - просто и наглядно - мисс-очевидность про место uml в техзадании
Нестандартный подход к разработке через тестирование. Практический кейс - реклама своего продукта, написанного для внутренних нужд
Как управлять аналитиками? - сплошная теория от любительницы поболтать бессвязно
Аналитическая орда. Как захватить "Козельск" стейкхолдера без потерь! - о необходимости распределить роли, планировании и строгом соблюдении правил в резко выросшей команде для идеального agile
Передача знаний: быстро, весело, полезно - на примере эстафеты, при смене сотрудника, структуризация подготовки и самого трансфера по законам педагогики
Аналитик 2.0. Как информация, которой владеет аналитик, влияет на мотивацию в команде - куда бежать, когда уже и так всё хорошо
УПРАВЛЕНИЕ. ЛИДЕРСТВО. ПАРТНЕРСТВО - о результатах опроса
Оценка соответствия модели основных бизнес-процессов стратегии компании - теория экономики стартапа
Влияние аналитиков на развитие компании - аналитики отвоевали своё место
Нерешенные вопросы в бизнес-анализе - нудный искатель серебряной пули
Сторителлинг в бизнес коммуникациях (командостроение, продвижение, переговоры, продажи). Сторибанки - неподготовленный лектор постоянно мычит и скачет с темы на тему, попытки отвечать на неслышимые вопросы
Сторителлинг (мастер-класс) - разговоры участников еле-слышны, поэтому сложно уловить смысл и важные моменты мастер-класса, сплошные недомолвки
Use Case VS User Story. Выбираем подход к специфицированию требований - скучно, нудный "учитель"
Мы строили, строили и наконец построили или краткая история эволюции интеграционного сервиса - весьма специфичен для аналитиков
Декомпозиция системы или "ну пусть это будет подсистема интеграции..." - весьма специфичен для аналитиков, теоритезировано
Практика архитектурного проектирования ИТ решений - яркий пример спешившего на конфу "учителя" - избыточность инфы на слайдах, опечатки, нудность голоса
Интеграция и пустота. Заглядываем внутрь моков - более для тестировщиков, но сказка не к месту
Опыт управления изменениями с помощью формирования концепции - специфичная хеппи-стори отдела аналитиков
Особенности сбора требований в Data Science-проектах - теоритезировано сугубо для аналитиков
Роль аналитика в Data Governance - специфично для сообществ аналитиков
Общебанковский модельный репозиторий - прикручивание графического приложения к нуждам архитектора
Автоматизация бизнес-процессов в строительстве - реклама собственного продукта
Archimate — швейцарский нож аналитика - об инструменте для рисования диаграмм


Не подумайте, что доклады из папки "ну, послушайте..." попали на моё плохое настроение. Нет, в первоначальном списке они перемежались с полезными. Просто на фоне хороших презентаций, вкупе с накопленными знаниями и специализацией для аналитиков вторая половина для QA - не вариант. Факт того, что ни один доклад не попал в разряд ненужных, говорит о том, что подобная конференция и её информационно-познавательная роль не менее важна в жизни тестировщика. 

Тет-а-тет

У специалиста по качеству со временем вырабатывается профессиональная черта правды. Если QA на каком-то этапе умолчит или недоговорит о возможных провальных последствиях, то руководству позже придётся весьма немало раскошелиться, чтобы "замять" проблему или исправить. Ещё несколько лет назад Максим Дорофеев обмолвился в одном из своих докладов, что предпочитает избегать полёты на определённой марке самолётов, потому что когда-то сам тестировал ПО для небесных машин. А недавно его опасения аукнулись отказом аэропортов от лайнеров мирового гиганта. Получается, что тестировщик своевременно не настоял на исправлении багов, а жизни рядовых пассажиров уже не вернуть, компания терпит огромные убытки и теряет доверие. Или же QA занизили уровень ответственности на этапе проектирования, то есть капельку, но обманули вышестоящие инстанции, чтобы общая оценка KPI соответствовала ожидаемой.
Как тестировщику сработаться с программистами и начальниками, если каждый из них с детства привык к маминой лести (читай "лжи"), нетерпим к правде и критике. Agile манифест предпочитает "быстрое" общение и пренебрегает бюрократией. Хотя именно в документировании, без общения с глазу на глаз, тестировщик полноценно может реализовать своё предназначение - детально и вовремя обратить всеобщее внимание на проблему без вуалирований. На днях мне рассказали случай о начальнице- мазохистке и подчинённом, которого она надеялась уличить в некомпетентности. Начальница получила по электронной почте документ, обнаружила неточность в данных. Как вы думаете, что она предприняла, чтобы опечатка была исправлена? Вернула электронное письмо с припиской о причине доработки? Нет! В век перехода на электронный бизнес начальница распечатала весь документ и на одном из листов обвела маркером место помарки. Потом не поленилась и пришла в кабинет с другими подчинёнными, на глазах у которых ткнула пальцем в опечатку под носом у виновного. Чего она этим хотела добиться? Увидеть униженного и насладиться властью? Возможно. Но получилось обратное, в очередной раз подчеркнула собственную отсталость в освоении современных технологий, потому что у мелкого сотрудника и без того было достаточно срочной и более важной работы, нежели вставлять одну единственную запятую. А ведь если бы об этой опечатке было сообщено через электронный документооборот, то не только у всего коллектива осталось бы рабочее настроение на остаток дня, но и репутация обоих осталась бы безупречной, да и расход канцелярии уменьшился. И это не единичный случай в службе ей подобных.
Примерно в такое же положение члены команды разработки ставят друг друга, когда тестировщик выявляет баг. Если QA - новичок, то его желание побежать к программисту и ткнуть того носом в код можно оправдать только желанием выбиться в "знайки". Но когда сам программист заявляется к тестировщику с претензией на перевод бага в фичу, он должен быть готов к тому, что будет посрамлён своей ограниченной осведомлённостью в предметной области. Тестировщик чаще всего знает о продукте намного больше и шире, чем кодер. И пользователю первой очереди буквально ничего не стоит доказать свою правоту. Разработчик может обидеться на честность специалиста по качеству, но обман будет стоить очень дорого всей команде. Поэтому отстаиваю приоритет ошибок, даже если приходится преувеличивать последствия, но чаще достаточно перечислить лишь самые страшные. А программисту, нанимающемуся в команду с давно работающими в ней тестировщиками, необходимо быть готовым к постоянной оценке его дел. Иначе, зачем же группе разработки нужны QA.
Что же такое "гибкость" для тестировщика? Макаревич пел: "Не стоит прогибаться под изменчивый мир, пусть лучше он прогнётся под нас." Не подменяют ли руководители проектов понятия "рабство", "безукоснительное подчинение" столь модным словом agile? Руководитель ConquestSS ежедневную смену продуктов и направлений тестирования, без возможности долгосрочного планирования хотя бы на один спринт называл "стилем agile". Ему очень хотелось, чтобы досконально подкованный тестировщик глаза в глаза высказывал провалы проектирования недоучке-программисту, вместо письменных долговечных комментариев к задаче. А ведь то, что единожды сказано одному, не доступно остальным. Значит каждому последующему проггеру пришлось бы выслушивать очередное унизительное нравоучение. После нескольких таких разбирательств ратую за обсуждение задач сразу в разделе комментариев Jira вместо созвонов по Skype (команда на 90% распределённая и все совещания проходят через звонки). Тем самым "убиваю двух зайцев": информация подробностей сразу доступна всем заинтересованным лицам, внутрикомандные отношения не портятся из-за чьей-то некомпетентности в предметной области.
Письменная речь имеет много преимуществ:
- перед отправкой можно перечитать и исправить опечатки, нелогичность мыслей, официальный документ исключает использование обидных эпитетов, которые могут проскочить в живом диалоге;
- напечатанный (на листе, в электронном виде) или рукописный текст сам по себе уже является документом, который легко и просто переиспользовать, прикрепить к тех.заданию или представить в виде доказательства при поиске причины проблемы;
- грамотность укрепляется и развивается за счёт письма;
- мелкая моторика развивает нервные окончания, ответственные за мыслительный процесс.
При устном разговоре "слово - не воробей, вылетит - не поймаешь". Поэтому если не хотите быть униженным, то просите давать оценку вашей деятельности письменно. Критик или тестировщик сто раз подумает и подберёт точные слова, которые и мысль обозначат конкретно, и ваше достоинство не унизят случайной фразой.
Но когда QA даёт отчёт по продукту, то большинство проблем приходится обобщать. При этом может утеряться важность и критичность. Если же ваш тест-менеджер умеет рассчитывать KPI найденных задач с полным учётом Severity и Priority, то его отчёт можно считать почти правдивым. Никакая статистика не сможет вместить объём того, что ещё не обнаружено. Коэффициент гибкости тестировщика напрямую зависит от критериев качественности продукта по мнению его владельцев. В этом плане специалисты по качеству аналогичны артистам, которые говорят словами автора пьесы, недоговаривая мысль, чтобы придать многозначность творению, Арлекины лгут зрителю, чтобы оправдать ожидания.
Имеет ли право тестировщик на обман или недосказанность? Как быть нам с постулатами профессии: строго соблюдать инструкции при позитивном тесте, сравнивать результат программистского труда с нормативами, объективно давать отчёт о состоянии продукта. Где ж тут место гибкости? Или agile и специалист по качеству не совместимы? Выбирать вам самим - полная и чистая правда с последующим спокойным сном и совестью, либо красивые и ожидаемые отчёты с последующим нервным расстройством от обилия молитв "лишь бы не попался шаловливый юзер".