Не ройте колодцы в тестировании

Любой человек должен уметь менять пеленки, 
планировать вторжения, резать свиней, 

конструировать здания, управлять кораблями, писать сонеты, 

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

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

сотрудничать, действовать самостоятельно, решать уравнения, 

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

Специализация — удел насекомых.

Роберт Хайнлайн 
Достаточно времени для любви

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

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

Поэтому сегодня поговорим о "колодцах", ситуациях, в которых, специально или бессознательно, команды тестирования, работающие вместе, разводят по разные стороны. И - почему это плохо.

Считайте данную заметку, своего рода антисилосным (silos = колодец) манифестом в тестировании. Только без лозунгов и транспарантов.

Откуда приходят колодцы в тестирование?

There are no best practices. 

By this I mean there is no practice that is better than all other possible practices, 

regardless of the context.  In other words, no matter what the practice and how valuable

 it may be in one context, I can destroy it by altering things about the situation

 surrounding the practice.
James Bach, Creator of Rapid Software Testing

http://www.satisfice.com/blog/archives/27

There are not such things as best practices in product development. 

There are only practices that are adequate within certain context. 

Craig Larman

Large-scale Scrum. More with less

Идея стара как мир. Человек обученный делать одно и то же действие, имеющий описание, как это делать и - нормативы (в нашем современном мире используется слово KPI), делает это более эффективно (и дешево, может быть), чем если бы совмещал копание, например, с разметкой - что копать.

Такой подход пытаются применить и в тестировани, но проблема в том, что земля которую "копают" тестировщики - меняется со временем. 

Как понимать эту метафору?

То как мы понимаем систему, в которой работаем, влияет на то, как мы работаем. Поэтому предлагаю вспомнить фреймворк Кеневин: https://www.unusual-concepts.ru/blog/2012/12/cynefin

Тем, кто не знаком - предлагаю прочитать. 

Если прочитали и пытаетесь осознать, что для нас это значит - мы (разработчики софта) находимся в левом верхнем углу картинки, т.е. находимся в запутанной системе. И в наших запутанных системах - нет лучших практик.

Это означает то, что если вы выделили в определенный момент человека на формирование понятного тест пака и это вам помогло, то делать этот паттерн обязательным и постоянно иметь в штате выделенную роль тест аналитика/тест дизайнера - ошибка.

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

Меняется все: ситуация на рынке, люди в команде, загрузка каждой роли, и формирование "негибкости" в виде "бест-практик" - выделенных отделов - приводит к потере эффективности  уже всей команды.

В наших запутанных системах нет лучших практик, но могут быть адекватные практики в контексте.

Нам же важно как эффективно работает вся команда? Как быстро поставляется продукт на рынок - разве нет?

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

Разделение труда, локальные оптимизации и системное мышление

Если предоставить систему самой себе, то ее компоненты начнут обосабливаться 

и станут независимыми центрами прибыли,что уничтожит систему...

Секрет -  в кооперации между компонентами в целях организации.

У. Эдвард Деминг

Culture eats strategy for breakfast.
Peter Druker

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

У каждого отдела появится формальное разделение труда, формальные служебные обязанности, и, как следствие, - свой формальный план работ, за который ему платят. Чем больше передаточных звеньев-отделов вы создадите, тем больше отдельных планов работ у вас появится. 

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

Как следствие - требуется 100% утилизация сотрудников в этих группах людей - они должны работать настолько эффективно и продуктивно, насколько это нужно этой отдельной выделенной команде, поскольку у каждой команды свои KPI. В подразделениях пытаются оптимизировать свою работу - сделаться локально производительными - производить каждый момент времени максимальное количество работы.

И тут выявляется главная проблема нашего времени - мы редко пытаемся в таким небольших группах оптимизировать систему. Мы оптимизируем себя - как можно быстрее писать тесты, как можно быстрее прогонять регрессию, как можно максимально быстро найти баги (чтобы вернуть вот-это-вот-все разработчикам). 

Мало кто задумывается, но тест кейсы ради тест кейсов клиенту не нужны. И тестирование - клиенту не нужно. Даже код клиенту не нужен. Что нужно клиенту, так это  работающее решение, удовлетворяющее его нужды, и быстрая поставка этого решения, и быстрая реакция на проблемы клиента с нашим гм... - решением.  Но мы продолжаем локальную оптимизацию в отдельно взятой роли - тестировании. 

Разные роли имеют разную загрузку по каждой отдельной таске. Если говорить про тестирование, то ручное тестирование может занимать 1 день, автоматизация - 5 часов, а регрессия ручная (например не все автоматизировано) всего билда - неделя. 

Для выпуска одной этой задачи у одной группы людей может быть столько работы, что попа дымится, а другие ждут, пока работа придет к ним и они начнут дымиться сами. Появляется перепроизводство - пока "те другие" работают, нам же нужно подготовить или сделать "побольше" любой другой работы, потому что у нас KPI и нам нужно оправдать свое существование. Нас же не поймут, если мы будем просто сидеть и ждать?

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

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

А еще - появляется должность по синхронизации работ. Например появляется Тест Менеджер, у которого есть люди по синхронизации работ ролей: тест лид автоматизации, тест лид регрессии.

Мы не забыли, что все еще говорим о тестировании? О том, что те, кто вообще иметь должен глубокую экспертизу в этой области, делит себя на под-области и   тратит время на то, чтобы синхронизировать себя?

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

Чем бОльший отдельный отдел вы создадите, чем бОльше вообще отделов вы создадите  - чем бОльшее разделение вы внесете между людьми, тем менее эффективнее  вы будете работать как система. 

Напомню - вне системы вы не нужны. Клиенту нужно решение, а не автоматизированные тесты. 

Плохие, очень плохие и ужасные примеры колодцев в тестировании

"Опять эти тестировщики поют себе гимны… Дворник — это больше, чем дворник… Сантехник — это больше, чем сантехник… Пылесос — это больше, чем пылесос. Да так вообще про всё сказать можно ) aax"  

Комментарий man4j к статье  Тестировщик - больше, чем профессия 

https://habrahabr.ru/post/221447/ 

На самом деле тестировщики не уникальны в своих ошибках - они копируют ошибки систем в которой живут.  Они продолжают делится на группы, вместо объединения в единую команду. Они отгораживаются "своей работой" чтобы удовлетворять KPI. Но есть уникальность в том, на какие группы разделяются тестировщики. 

Далее -  примеры из жизни, когда тестировщики строят колодцы внутри себя. Примеры из личного опыта - поэтому допускаю, что перечислил не все, но самое памятное. Свои раны. "Пепел Клааса стучит в моем сердце...". 

Функциональные и регрессионные 

Классический колодец в тестировании - выделение команды регрессии. И такая команда делает регресс, только регресс, всегда регресс, и - ничего кроме регресса. 

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

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

Дополнительной проблемой наличия отдельной команды регресса будет то, что в головах появится обязательно - разделение работы на большие куски. Сначала проверим новый функционал (кусок побольше), а затем проведем два цикла регрессионного тестирования (два потому что обязательно найдем ошибки). В нашем мире высоких быстрых (быстро-меняющихся) технологий еще находятся люди, не понимающие, если вы начинаете искать проблемы позже - вы их найдете позже. И стоить вам это будет дороже. Создается Waterfall не только в процессе разработки, а еще и в процессе самого процесса тестирования - waterfall в квадрате. 

Если у нас есть две команды - функционального и регрессионного тестирования, то как мы передаем тесты? На моей памяти, это делалось всегда руками команды регрессионного тестирования, потому что "Вам все тест планы дали, если будут вопросы - спросите". После любой проблемы: "Вы не разобрались? А что же вы не спросили?!"  Для меня всегда странно, что люди передающие знания вешают ответственность за получение знаний на учеников и только на учеников. "Я все рассказал, они - не спросили". Перекладывание ответственности - оно появляется всегда, когда у вас есть разделение ответственности.  Если группа людей отвечает за полный цикл тестирования - фраз "мы передали, они не взяли" не должно быть.

Если вы прошли через весь проект и составили тесты, у вас появляется самое важное, что есть в исследованиях - знания почему это так, а не иначе. У вас появляется опыт. У вас формируются эвристики (еще одна полезная ссылка) . У вас появляются ответы на вопросы типа  "почему все вот это вот так работает" и - ответы на вопросы "кому могло понадобится именно это"? Если вы получили список тестов - вы этих знаний не имеете. Худшие тестировшики, которых я когда либо видел - пришли из "только-регрессии". У этих людей я замечал профессионально выжженное желание исследовать продукт.  Без понимания продукта, гонять регрессию - бессмысленно. Вы делаете механическую пустую работу.

Отдельная регрессионная команда это искусственное разделение команды на хороших и плохих специалистов, это создание waterfall проблем внутри тестирования, это поздние баги и тормоз в производительности команды, это дополнительные ресурсы на синхронизацию знаний между командами функционального и регрессионного тестирования.

Это неправильно и это должно прекратиться. 

Ручное и автоматизированное

И если у вас нет таких проблем - нет команд регрессионного тестирования, то за углом вас могут поджидать выделенные команды автоматизации.

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

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

Время от времени мне приходится собеседовать - искать людей себе и другим командам. И среди всей массы кандидатов ярко выделяются автоматизаторы. Люди действительно разбираются, как строить фреймворки, используют различные языки программирования, знают паттерны проектирования, но обладают проблемами другого сорта.

99,99% прошедших через меня людей уже забыли как делать тест дизайн, но еще не научились хорошо программировать. Люди забыли кто такой  Lee Copeland, но уже во всю везде применяют singleton паттерны. К сожалению многие из этих коллег не видят в этом проблемы. Вместо того, чтобы стать профессиональными тестировщиками, люди хотят стать профессиональными создателями новых фреймворков. И разделение, специализация здесь усиливает пропасть между "нами - профессионалами" и теми - другими, которые "должны".

На конференции Гайзенбаг 2017 в Москве я стоя на стенде общался с большим количеством коллег. Запомнилась девочка, которая на вопрос - не хочет ли она присоединится к нашей компании, ответила, что ее все устраивает. Что ее устраивает? То что она единственный автоматизатор в команде. Есть еще 5 ручников, но она единственная и неповторимая. Передавать знания? Это долго и не все готовы прикоснутся к этому таинству. Из простого перебора известных команд-keywords в Idea или Eclips cделали таинство...

Каста автоматизаторов должна быть свергнута и тестировщики должны объединиться. 

Тест менеджеры вне команд

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

Разговор не задался с самого начала.

Меня спросили что такое QA и я ответил, как считаю правильным - что в некоторых организациях существуют отдельно назначенные люди, смотрящие за процессом и "отвечающие за качество", хотя сами они ничего не производят и повлиять на качество (своими руками) - не могут. Часто еще вешают такую обязанность на тестировщиков - что тоже неправильно. Люди делающие работу - должны отвечать за качество своей работы сами. И если есть отдельные люди вне выполнения работы, но названные смотрящими за качеством - от них нужно избавляться, либо заставлять работать. Когда я посмотрел на Главу, я увидел застывший немой крик в его глазах.

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

Что выяснилось еще. Глава управлял тест менеджерами, которые не нанимали людей в тестировании и не увольняли - это делали сами "аджайл команды" компании. Также - они не имели возможности повышать людей или изменять процесс ("аджайл" команды как ни как). Что эти менеджеры делали? Им позволялось советовать. Их советам команды могли не следовать. И я бы понял если бы речь шла о скрам мастерах, но речь шла о тест менеджерах, которые были сфокусированы на "обеспечении качества".

Вишенкой про собеседование - главе было интересно только, насколько я знаю теорию. Мои рассказы о практических реализациях его не интересовали, он переводил беседу обратно - "а как говорит теория?".

Тестирование само по себе - техническая область, и наличие человека не вовлеченного в процесс и опирающегося на вторичные сведения (мнение подчиненных или мнение команды) свидетельствует о недальновидности. Именно поэтому скрам мастера - фасилитируют/помогают принимать решение, а не решают за команду - что делать. Именно поэтому тест менеджеры, не участвующие в  самом процессе разработки - не эффективны. Да, такие люди могут обладать хорошими навыками внедрения и улучшения процессов, найма сотрудников, но оторванные от процесса - они могут выполнять только вторичную роль. Команды - первичны.

Возвращаясь к главе тест менеджеров. Мы заканчивали общаться и уже я стал задавать вопросы:

Я: А как вы отслеживаете качество работы?
Глава: Мы собираем метрики
Я: И что вы потом с ними делаете?
Глава: Мы их анализируем
Я: И что вы обнаружили?
Глава: Пока рано делать выводы.
Я: А вы их показывали, эти метрики команде?
Глава: Пока нет.

Мы собираем метрики, но не показываем их команде... Это можно перевести как: "Мы оторваны от реальности".

Замечено, что большую роль в разделении групп людей вкладывает ЭГО людей. Люди любят статус, и любят быть руководителем: лидом, менеджером, старшим хотя бы над одним человеком. Люди желают продвигаться дальше в менеджерской части - и разделение на группы это их способ двигаться. К сожалению этим они не двигают команды к клиентам.

Если есть отдельные люди вне выполнения работы, но названные смотрящими за качеством - от них нужно избавляться, либо заставлять работать. 

Тест дизайнеры/аналитики  и исполнители/экзекьютеры

Самое странное разбиение, когда одни планируют или пишут тесты, а другие - тесты выполняют.

Я допускаю такое разделение как временный результат работы команды, и временное разграничение. Но иметь человека только пишущего тесты и отдельно человека только их прогоняющих - сложно уложить в голове, но есть и такое разделение. Более того есть целая "ода" такой касте: http://quality-lab.ru/test-analysts-who-is-this/

Не понимая изменений в продукте, полагаться на "идеального" знающего и вычленять эту экспертизу  - опасно.

Знаете какой самый верный способ проверять составленные тесты? Выполнять тесты и получать реакцию системы - изучать систему. Но что мы имеем?

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

Один человек изучает требования и передает ее тест дизайнеру. Он выполнил свою работу. Он молодец.

Второй человек пишет тест кейсы и передает их тем, кто их должен выполнять. Он тоже молодец.

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

А если найдется проблема, эта группа людей начинает работать обратно? Экзекьютор в тест дизайнера, и тест дизайнер в аналитика?  Это же "их работа" - правда же? И поэтому к пуговицам претензий нет.

Можно аргументировать - "но есть же люди, которые знают лучше". Мой вопрос - остальных вы так и хотите считать все время - "худшими"?  Люди становятся теми, кем их считают.

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

"Подводя итоги, можно сказать, что тест-аналитик – это своеобразное связующее звено между заказчиком и остальной командой тестирования."

Это не связующее звено - это опасное прокси, из-за которого команды пытаются жить отдельно от клиентов, теряют знания о продукте, и  - от этого надо избавляться.

Уход от ответственности

- Не мы такие - жизнь такая 

Кинофильм "Бумер"

— Не смотрите так — дело не во мне. 
Нас, молодых, так учили, понимаете? 
Нас… так учили… 
Нас с детства так учили 

Кинофильм "Убить дракона"

Оправдания.

Снятие ответственности.

Собственная беспомощность - как стратегия выживания.

 "Мы работаем так, потому что так у нас работает" 

"У нас так принято" +  еще сто и одна причина не брать на себя ответственность за то, где ты находишься. 

И люди гробят себя и свою профессию. И профессионально выжигают внутри себя профессионала.

Мы умеем оправдывать свои поступки. Правдиво. Честно. Веря самим себе.

Пора с этим заканчивать.

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

Для систем жизненно важен принцип уменьшения задержки реакции на изменения.  Поэтому если вы вводите еще одно передаточное звено, или вообще еще одно специализированное звено - ваша система становится сложнее.  Узкие специалисты - не оптимизированная система.  

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

Тестирование отдельно - всегда зло.

Разделение тестировщиков на под-тестировщиков - зло в квадрате.

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

Специализация - удел насекомых.

Удачного воссоединения комрады.

И с наступившим вас Новым Годом!