Не ройте колодцы в тестировании
(Из ленты Качество Вызывает Уважение)
планировать вторжения, резать свиней,
программировать компьютеры, вкусно готовить,
хорошо сражаться, достойно умирать.
Достаточно времени для любви
Идея заметки появилась что называется «по накоплению» — из-за прочтения некоторого количества статей, подслушанных разговоров и общения с коллегами. В этих статьях и беседах оправдывалось разделение труда в тестировании — как механизма повышения эффективности труда. Люди действительно считали, что узко-специализируя людей — можно добиться большего.
Поэтому сегодня поговорим о «колодцах», ситуациях, в которых, специально или бессознательно, команды тестирования, работающие вместе, разводят по разные стороны. И — почему это плохо.
Считайте данную заметку, своего рода антисилосным (silos = колодец) манифестом в тестировании. Только без лозунгов и транспарантов.
Откуда приходят колодцы в тестирование?
James Bach, Creator of Rapid Software Testing
Идея стара как мир. Человек обученный делать одно и то же действие, имеющий описание, как это делать и — нормативы (в нашем современном мире используется слово KPI), делает это более эффективно (и дешево, может быть), чем если бы совмещал копание, например, с разметкой — что копать.
Такой подход пытаются применить и в тестировани, но проблема в том, что земля которую «копают» тестировщики — меняется со временем.
Если прочитали и пытаетесь осознать, что для нас это значит — мы (разработчики софта) находимся в левом верхнем углу картинки, т.е. находимся в запутанной системе. И в наших запутанных системах — нет лучших практик.
Меняется все: ситуация на рынке, люди в команде, загрузка каждой роли, и формирование «негибкости» в виде «бест-практик» — выделенных отделов — приводит к потере эффективности уже всей команды.
В наших запутанных системах нет лучших практик, но могут быть адекватные практики в контексте.
Нам же важно как эффективно работает вся команда? Как быстро поставляется продукт на рынок — разве нет?
Если нет, то мы продолжаем копать землю совковыми вилами. Но там где был чернозем, уже плещется болотце.
Разделение труда, локальные оптимизации и системное мышление
Culture eats strategy for breakfast.
Peter Druker
Если создать несколько разных отделов (под отделом я здесь имею ввиду отдельную группу людей объединенных по ролевому признаку — например только регрессионное тестирование или только автоматизированное тестирование), поставить там разных начальников, то у вас появится несколько знаковых вещей.
У каждого отдела появится формальное разделение труда, формальные служебные обязанности, и, как следствие, — свой формальный план работ, за который ему платят. Чем больше передаточных звеньев-отделов вы создадите, тем больше отдельных планов работ у вас появится.
Мало кто задумывается, но тест кейсы ради тест кейсов клиенту не нужны. И тестирование — клиенту не нужно. Даже код клиенту не нужен. Что нужно клиенту, так это работающее решение, удовлетворяющее его нужды, и быстрая поставка этого решения, и быстрая реакция на проблемы клиента с нашим гм… — решением. Но мы продолжаем локальную оптимизацию в отдельно взятой роли — тестировании.
Разные роли имеют разную загрузку по каждой отдельной таске. Если говорить про тестирование, то ручное тестирование может занимать 1 день, автоматизация — 5 часов, а регрессия ручная (например не все автоматизировано) всего билда — неделя.
Для выпуска одной этой задачи у одной группы людей может быть столько работы, что попа дымится, а другие ждут, пока работа придет к ним и они начнут дымиться сами. Появляется перепроизводство — пока «те другие» работают, нам же нужно подготовить или сделать «побольше» любой другой работы, потому что у нас KPI и нам нужно оправдать свое существование. Нас же не поймут, если мы будем просто сидеть и ждать?
Это вызывает шок, но чтобы система работала эффективно, некоторые элементы системы должны работать недостаточно эффективно. И чтобы быстро выполнить работу, которая важна для клиента, мы должны… бинго — не создавать переполненные очереди для себя — для отделов. Отделы совершают один из самых страшный грехов — перепроизводство.
А еще у каждого отдела появится разделение на «мы» и «они». Мы — команда, они — те кто нам мешают делать нашу локально-эффективную командную работу. Это не обязательный образ мышления всегда и везде, но это закреплено формально. Несомненно тут и появляются утверждения «мы свою работу сделали», и тут же появляются вопросы — «кто виноват и что делать».
А еще — появляется должность по синхронизации работ. Например появляется Тест Менеджер, у которого есть люди по синхронизации работ ролей: тест лид автоматизации, тест лид регрессии.
Мы не забыли, что все еще говорим о тестировании? О том, что те, кто вообще иметь должен глубокую экспертизу в этой области, делит себя на под-области и тратит время на то, чтобы синхронизировать себя?
В то время, когда ученные бьются над единой теорией поля, тестировщики создают подсистемы внутри себя и тратят ресурсы на синхронизацию.
Чем бОльший отдельный отдел вы создадите, чем бОльше вообще отделов вы создадите — чем бОльшее разделение вы внесете между людьми, тем менее эффективнее вы будете работать как система.
Напомню — вне системы вы не нужны. Клиенту нужно решение, а не автоматизированные тесты.
Плохие, очень плохие и ужасные примеры колодцев в тестировании
Плохие, очень плохие и ужасные примеры колодцев в тестировании
На самом деле тестировщики не уникальны в своих ошибках — они копируют ошибки систем в которой живут. Они продолжают делится на группы, вместо объединения в единую команду. Они отгораживаются «своей работой» чтобы удовлетворять KPI. Но есть уникальность в том, на какие группы разделяются тестировщики.
Далее — примеры из жизни, когда тестировщики строят колодцы внутри себя. Примеры из личного опыта — поэтому допускаю, что перечислил не все, но самое памятное. Свои раны. «Пепел Клааса стучит в моем сердце…».
Функциональные и регрессионные
Классический колодец в тестировании — выделение команды регрессии. И такая команда делает регресс, только регресс, всегда регресс, и — ничего кроме регресса.
Регрессия на моей памяти «хорошей» никогда не считалась. «Сослать в регрессию»- становится наказанием. Сама работа становится — клеймом: «Он ничего не умеет — только гонять регрессию». Однажды я слышал от умнейшего тест менеджера фразу «Они еще не заслужили тестировать новую функциональность. Пусть сначала научатся гонять регрессию». В головах у у профессионалов засела мысль, что люди должны заслужить не быть тестировщиками регресии.
Если вы прошли через весь проект и составили тесты, у вас появляется самое важное, что есть в исследованиях — знания почему это так, а не иначе. У вас появляется опыт. У вас формируются эвристики (еще одна полезная ссылка) . У вас появляются ответы на вопросы типа «почему все вот это вот так работает» и — ответы на вопросы «кому могло понадобится именно это»? Если вы получили список тестов — вы этих знаний не имеете. Худшие тестировшики, которых я когда либо видел — пришли из «только-регрессии». У этих людей я замечал профессионально выжженное желание исследовать продукт. Без понимания продукта, гонять регрессию — бессмысленно. Вы делаете механическую пустую работу.
Это неправильно и это должно прекратиться.
Ручное и автоматизированное
И если у вас нет таких проблем — нет команд регрессионного тестирования, то за углом вас могут поджидать выделенные команды автоматизации.
Попасть в автоматизацию сейчас считается чуть ли не вершиной карьеры тестировщика, наравне с карьерой тест-менеджера. «Я хочу двигаться дальше в сторону автоматизации» — часто, что слышишь на собеседовании. И мне есть сказать несколько слов по поводу узко-специализированных специалистов в автоматизации.
Если регрессия — это ссылка, то автоматизация — это высшая каста с именем «вы-должны-писать-тесты-чтобы-сразу-можно-было-автоматизировать». Люди считают себя выше ручных тестировщиков, что в итоге приводит к деградации.
Время от времени мне приходится собеседовать — искать людей себе и другим командам. И среди всей массы кандидатов ярко выделяются автоматизаторы. Люди действительно разбираются, как строить фреймворки, используют различные языки программирования, знают паттерны проектирования, но обладают проблемами другого сорта.
99,99% прошедших через меня людей уже забыли как делать тест дизайн, но еще не научились хорошо программировать. Люди забыли кто такой Lee Copeland, но уже во всю везде применяют singleton паттерны. К сожалению многие из этих коллег не видят в этом проблемы. Вместо того, чтобы стать профессиональными тестировщиками, люди хотят стать профессиональными создателями новых фреймворков. И разделение, специализация здесь усиливает пропасть между «нами — профессионалами» и теми — другими, которые «должны».
На конференции Гайзенбаг 2017 в Москве я стоя на стенде общался с большим количеством коллег. Запомнилась девочка, которая на вопрос — не хочет ли она присоединится к нашей компании, ответила, что ее все устраивает. Что ее устраивает? То что она единственный автоматизатор в команде. Есть еще 5 ручников, но она единственная и неповторимая. Передавать знания? Это долго и не все готовы прикоснутся к этому таинству. Из простого перебора известных команд-keywords в Idea или Eclips cделали таинство…
Тест менеджеры вне команд
Разговор не задался с самого начала.
Меня спросили что такое QA и я ответил, как считаю правильным — что в некоторых организациях существуют отдельно назначенные люди, смотрящие за процессом и «отвечающие за качество», хотя сами они ничего не производят и повлиять на качество (своими руками) — не могут. Часто еще вешают такую обязанность на тестировщиков — что тоже неправильно. Люди делающие работу — должны отвечать за качество своей работы сами. И если есть отдельные люди вне выполнения работы, но названные смотрящими за качеством — от них нужно избавляться, либо заставлять работать. Когда я посмотрел на Главу, я увидел застывший немой крик в его глазах.
Позже я понял, почему Глава так изумился. Мой монолог его должность — упразднил, а самого его — уволил. Но это было в конце.
Что выяснилось еще. Глава управлял тест менеджерами, которые не нанимали людей в тестировании и не увольняли — это делали сами «аджайл команды» компании. Также — они не имели возможности повышать людей или изменять процесс («аджайл» команды как ни как). Что эти менеджеры делали? Им позволялось советовать. Их советам команды могли не следовать. И я бы понял если бы речь шла о скрам мастерах, но речь шла о тест менеджерах, которые были сфокусированы на «обеспечении качества».
Вишенкой про собеседование — главе было интересно только, насколько я знаю теорию. Мои рассказы о практических реализациях его не интересовали, он переводил беседу обратно — «а как говорит теория?».
Тестирование само по себе — техническая область, и наличие человека не вовлеченного в процесс и опирающегося на вторичные сведения (мнение подчиненных или мнение команды) свидетельствует о недальновидности. Именно поэтому скрам мастера — фасилитируют/помогают принимать решение, а не решают за команду — что делать. Именно поэтому тест менеджеры, не участвующие в самом процессе разработки — не эффективны. Да, такие люди могут обладать хорошими навыками внедрения и улучшения процессов, найма сотрудников, но оторванные от процесса — они могут выполнять только вторичную роль. Команды — первичны.
Возвращаясь к главе тест менеджеров. Мы заканчивали общаться и уже я стал задавать вопросы:
Я: А как вы отслеживаете качество работы?
Глава: Мы собираем метрики
Я: И что вы потом с ними делаете?
Глава: Мы их анализируем
Я: И что вы обнаружили?
Глава: Пока рано делать выводы.
Я: А вы их показывали, эти метрики команде?
Глава: Пока нет.
Мы собираем метрики, но не показываем их команде… Это можно перевести как: «Мы оторваны от реальности».
Замечено, что большую роль в разделении групп людей вкладывает ЭГО людей. Люди любят статус, и любят быть руководителем: лидом, менеджером, старшим хотя бы над одним человеком. Люди желают продвигаться дальше в менеджерской части — и разделение на группы это их способ двигаться. К сожалению этим они не двигают команды к клиентам.
Если есть отдельные люди вне выполнения работы, но названные смотрящими за качеством — от них нужно избавляться, либо заставлять работать.
Тест дизайнеры/аналитики и исполнители/экзекьютеры
Я допускаю такое разделение как временный результат работы команды, и временное разграничение. Но иметь человека только пишущего тесты и отдельно человека только их прогоняющих — сложно уложить в голове, но есть и такое разделение. Более того есть целая «ода» такой касте: http://quality-lab.ru/test-analysts-who-is-this/
Не понимая изменений в продукте, полагаться на «идеального» знающего и вычленять эту экспертизу — опасно.
Знаете какой самый верный способ проверять составленные тесты? Выполнять тесты и получать реакцию системы — изучать систему. Но что мы имеем?
«Итак, мой рабочий день практически закончен. Осталось всю полученную и обработанную информацию передать тест-дизайнеру для разработки стратегии и написания тестов»
Один человек изучает требования и передает ее тест дизайнеру. Он выполнил свою работу. Он молодец.
Второй человек пишет тест кейсы и передает их тем, кто их должен выполнять. Он тоже молодец.
Человек, который получает тесты и должен их выполнять (не понимая почему все вот так вот написано) должен тоже стать молодцом и прогнать эти тесты все без остатка.
А если найдется проблема, эта группа людей начинает работать обратно? Экзекьютор в тест дизайнера, и тест дизайнер в аналитика? Это же «их работа» — правда же? И поэтому к пуговицам претензий нет.
Можно аргументировать — «но есть же люди, которые знают лучше». Мой вопрос — остальных вы так и хотите считать все время — «худшими»? Люди становятся теми, кем их считают.
Это не связующее звено — это опасное прокси, из-за которого команды пытаются жить отдельно от клиентов, теряют знания о продукте, и — от этого надо избавляться.
Уход от ответственности
Нас, молодых, так учили, понимаете?
Нас… так учили…
Нас с детства так учили
Снятие ответственности.
Собственная беспомощность — как стратегия выживания.
«Мы работаем так, потому что так у нас работает»
«У нас так принято» + еще сто и одна причина не брать на себя ответственность за то, где ты находишься.
И люди гробят себя и свою профессию. И профессионально выжигают внутри себя профессионала.
Мы умеем оправдывать свои поступки. Правдиво. Честно. Веря самим себе.
Пора с этим заканчивать.
Тестировщики никакие не уникальные существа — они часть команды по разработке и поставке, и, даже, — сопровождению решений.
Для систем жизненно важен принцип уменьшения задержки реакции на изменения. Поэтому если вы вводите еще одно передаточное звено, или вообще еще одно специализированное звено — ваша система становится сложнее. Узкие специалисты — не оптимизированная система.
Меня можно упрекнуть, что пора бы и вообще не считать отдельно тестирование от разработки, и текст длинный — а нужно одним предложением — аджайл всем. Но я отвечу тем, что написал в начале В наших запутанных системах нет лучших практик, но могут быть адекватные практики в контексте. Внезапный аджайл может убить и продукт и организацию — нужна последовательная трансформация. Если в команде тестирования все плохо — нужно начать трансфорировать хотя бы там.
Разделение тестировщиков на под-тестировщиков — зло в квадрате.
И с наступившим вас Новым Годом!
