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

Критика зачастую говорит больше о проблемах критикующего, 

чем о проблемах того, на кого она направлена. 

Андрей Парабеллум. Бизнес и ЖЖизнь

Первопричиной и основной темой для данной заметки послужил известный опрос про "нехватки" и "проблемы" тестировщиков: http://www.it4business.ru/edu/2598 . Началом заметки - обед с коллегой по цеху Максом Корнеевым. 

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

"По делу, но ничего нового"

"Самое сложное - договориться"

Моя первая реакция на опрос была недолгая задумчивость и проставление +1 всем строкам со словами "И это бывало".

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


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

Я испытываю изжогу сомнение что:

А) Опрос верно составлен (использовались заблуждения и отрыв от реальности)

Б) Следовательно его неправильно поняли (каждый в меру своих заблуждений и отрывов)

В) Следовательно неверно ответили 

В) Что хоть кто-то сделает "работу над ошибками"

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

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

А посему постараюсь убрать свои проблемы, думать объективно, не тыкать пальцами и не критиковать... Ну или чуть чуть критиковать.

КРИЗИС ЖАНРА

ОТДЕЛЬНО ВЗЯТЫЙ ЧЕЛОВЕК

В опросе перемешаны как профессиональные, так и личные качества. Но

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

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

Опрос был весьма и весьма мал, чтобы построить полный профиль идеального тестировщика в сферической команде, а посему пункты похожие на 

Умения доводить дело до конца (19%, 96 голосов)

Умения коммуницировать и договариваться (40%, 205 голосов)   


Квалификации и опыта в основных вопросах тестирования (33%, 166 голосов)

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

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

Я - русский, и я - не алкоголик - надеюсь вы поняли о чем я.

А ТЫ КТО ТАКОЙ?

Мы ничего не знаем про тех - кто отвечал на опрос....

Ну ладно, вы лично знаете 5-ых - тех кто был в подкастах, меня и себя (я еще - Макса).

Но кто остальные?

И это не только вопрос - кто он по профессии?

И это даже не только - сколько лет он в профессии?

И даже не то - сколько лет и в какой профессии он вообще проработал?

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

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

Здравые статьи по составлению опросов из первой страницы гугла:
http://www.createsurvey.ru/papers/ru-howto-make-a-good-survey.htm
Посмотреть, почитать хорошие примеры.


http://www.marketing-ua.com/articles.php?articleId=629
Здравые емкие мысли про паспортички и детекторы

Личное мнение - оно такое личное. Должна быть возможность классифицировать респондентов. По проектам, размеру команды, зрелости процессов в проекте  и даже - зрелости самого респондента. Иначе результаты ничего не значат.

РОЛИ

Тестировщики спрашивают: Кто такие тестировщики? 
Не тестировщики отвечают: Те кто гоняет тесты и находит баги. 

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

Глядя на вопросы и заплюсованные ответы, чувствуется, что опрос крутиться вокруг этого заблуждения, иначе как объяснить тот факт, что все забыли

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

Если совсем совсем крупно, то давайте вспомним о

Тест дизайнерах
Тех кто пишет тестовые сценарии

Ручных исполнителях тестов 
Те кто находится на передовой, гоняет тесты и находит баги.

Технических тест лидах и менеджерах
Тех, кто планирует работу команды, репортит

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

Процесс менеджерах
Специалисты, которые пытаются каждый раз окинуть ясным взором долгий путь от постановки требований и до релиза и назначить очередной Lesson Learned/Post Mortem/Proces review собрание и поднять вопросы:
- что мы можем улучшить и как,
- что мы можем выкинуть и как.

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

Не хватает - Умения составлять удобные и простые тестовые сценарии

Не хватает - Понимание целей и задач процесса тестирования

Не хватает - Умения программировать

Мы хотим узнать где у нас универсальные солдаты?

CONTEXT-DRIVEN

Мы вечно забываем о том, что все зависит от контекста, и даже - тестирование. Потому что,

Если тестировать дороже, чем не тестировать, то тестировать - не нужно.

Именно поэтому: если вы используете Explaratory Testing, то опция про понятные и простые сценарии звучит неправдоподобно.

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

Именно поэтому: вся зацикленность на тяжелых RUP процессах в команде из 5 человек - в топку. И человека, который эти заблуждения принес - в лес.

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

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

Насколько сильно не хватает? Или быть может не хватает = не помешало бы, но нет бюджета? Что - опять будете выезжать на проактивности и самомотивации?

ДЬЯВОЛ В ДЕТАЛЯХ

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

Не хватает - Умения коммуницировать и договариваться (40%, 205 голосов)

Мы слишком легко используем термин коммуницировать в своей речи, и не всегда понимаем что это англоязычное слово значит. По Светлане Ивановой под коммуникабульностью уживаются:

Умение быстро устанавливать контакт с незнакомыми людьми

Вежливое, располагающее общение

Умение убеждать

Умение публично выступать

Постоянное желание общаться с людьми

Хорошо поставленная речь

Грамотная речь

Парочка вопросов:

Если у человека нет умения публично выступать - он плохой тестировщик? Это ему мешает?

Если он прямолинеен и говорит откровенно - он плохой тестировщик? От этого нужно избавляться?

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


Тогда, что значит пункт: Не хватает - Умения коммуницировать и договариваться (40%, 205 голосов)

Если специалист просел по одному из подпунктов - у него что, проблемы с умением коммуницировать?

Как это мерить?

Кто это мерил?

В чем проблема?

Не хватает - Умения программировать (41%, 209 голосов)

Что такое умение программировать?

Где эта тонкая грань, чтобы определить - умеет человек программировать и - как хорошо он умеет это делать?

А где эта тончайшая грань для тестировщика?

Умение писать на VBA макросы или использование паттернов проектирования при программировании на языках высокого уровя?

Писать скрипты для JMeter или написать на Java тестовый фреймворк  реализуя PageObject?

Использовать только Selenium IDE или использовать связку Java/DOJO/XPath?

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

И другой вопрос:

Зачем  вам плохой программист в тестировщиках? Подумайте какую пользу он принесет, и какой от него будет вред? Что перевесит? А если тестировщик хороший программист, - что делает хороший программист в тестировщиках?

Неужели пунктом "Не хватает - Умения программировать" можно оценить вообще и умение программировать, и насколько критично это для проекта, что этого навыка не хватает, конкретному тестировщику в конкретном проекте, и - насколько этого не хватает?

Я берусь предположить, что речь идет не о программировании, а вообще об общей компьютерной грамотности специалиста.

Работа с Bash.


Установить клиент к БД, подготовить и позапускать SQL.


Сравнить комиты в системе хранения версий.


Может быть - поставить систему с нуля.


Может быть настроить уровень логирования системы.


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

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

Понимание целей и задач процесса тестирования (50%, 254 голосов) 

Цели и задачи тестирования это наверное самый спорный вопрос в вопросах о тестировании. Усугубляет ситуацию противостояние школ тестирования. Я специально отдельно упомянул Context Driven. И до сих пор настаиваю, что

Цели и задачи тестировщиков могут меняться от проекта к проекту, сильно зависят от роли специалиста (в том числе тестировщика), и более того цели и задачи могут быть разными в зависимости от стадии разработки ПО

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

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

Разные специалисты, в разных проектах, в разное время имеют разные цели


Так какие именно цели, какие именно задачи, каких именно процессов в тестировании имелись в виду? В общем или в отдельном проекте? А может дело в том, что сами вопрошающие и отвечающие не понимают ни целей ни задач тестировщиков в своих проектах?

И кстати, еще один вопрос в копилку сомнений

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

Умения составлять удобные и простые тестовые сценарии (32%, 165 голосов)

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

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

И давайте еще вспомним Explaratory testing, где у нас есть карты, но нет шагов.


А еще вспомним чек листы и базы знаний в вики - когда тесты это просто названия.

Удобные для кого?

Простые для чего?

Что вы берете за шкалу измерения?

Если вы приходите к тестеру и говорите, что в его проекте он для своей команды тестировщиков имеющей определенную экспертизу в продукте пишет непонятные для вас сценарии... Ну вы поняли куда вы идете?

Так и хочется сказать грубость.

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

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

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

Не хватает - Квалификации и опыта в основных вопросах тестирования (33%, 166 голосов)

Что это за бред?

Нет честно. 

Меня смутило самое начало "квалификации и опыта", далее - я не читал и поставил плюс.  Кто эти остальные 33%?

Для начала я не понимаю - что такое основные вопросы тестирования? Кто их задает, кому их задают?

И сразу усложняем задачу - что такое опыт в основных вопросах тестирования?

Но даже если речь только о квалификации и опыте

Если вы покупаете специалиста за 40 штуко-рублей, вы думаете он будет работать как специалист за 100 штуко-рублей? И останется у вас в тестировщиках через год-полтора? Хей! Повзрослейте!!!

Если вы хотите найти мега супер кабана в тестировании, то сначала сделайте адекватные зарплаты. Это во первых.

А во вторых, если вы хотите найти мега супер кабанов в какой то бласти, то сначала найдите ацкого мега супер кабана в этой области, чтобы он нашел их.

В остальном - это проблема не тестировщиков, а человека формирующего команду. Есть замечательная цитата Noize MC:


"Давай с тобой договоримся тупо - твой поступок это твой поступок"

Поэтому наберите, растите, обучайте, продавайте (труд, конечно, только труд) - играйте в свою ферму проектов сами и не ругайте отрасль в целом. 

Проблемы - Излишняя концентрация на процессе, а не на результатах (40%, 202 голосов)
Проблемы - Настрой на философию качества, а не на продукт и его характеристики (36%, 180 голосов)

Я объединил оба пункта в один, потому что увидел очень сильное и опасное заблуждение, что процесс не влияет на результат.

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

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

Проблемы - Слабое вовлечение в процесс планирования (50%, 251 голосов)
Проблемы - Слабое вовлечение в процесс анализа требований (62%, 314 голосов)

Я опять объединил две проблемы. Поскольку по моим личным наблюдениями и ИМХ-ам все, на самом, деле упирается в бюджет и сроки.

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

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

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

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

В конце концов, вы же не будете упрекать дворника в том, что он слабо вовлечен в процесс ремонта подъезда? Хотя он мог бы найти время и заштукатурить то место, под окном второго этажа. 

Неумение отстаивать затраты на тестирование и свою точку зрения (46%, 231 голосов)

"Ты виноват лишь тем, что хочется мне кушать"

Ответ менеджера проекта менеджеру тестировщиков

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

Сразу отметаю фразу "свою точку зрения", как попытку совместить профессиональные навыки и личные - писал об этом подробно выше. О квалификации и цене - тоже писал.

Но вот по поводу "затраты на тестирования" хотелось бы побухчать.

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

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

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

Если менеджер проекта "верит" что история не повториться, то, наверное, менеджер проекта жуткий оптимист.  Жуткий - для команды.

ПОДВЕДЕНИЕ ИТОГОВ

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

Для начала подведу итог.

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

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

3. Нужно понимать, что каждый проект уникален, и также уникальны отдельные люди, работающие в проекте. Обобщать людей, даже в отдельных проектах, а уж тем более в целых отраслях - занятие пустое и бесперспективное. Средняя температура по больнице может составлять 36,6, но один сгорает от температуры, а другой лежит в морге.

4. Упомянутый конкретный опрос оперирует понятиями "проблемы"/"нехватки", в то же самое время не совсем очевидно, насколько данные недостатки критичны для конкретных проектов. Всегда есть требуемые и желаемые компетенции специалиста.

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

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

7. Получить из одного человека восемь шапок, наверное, можно, но всегда нужно понимать, что тратить время на каждую отдельную роль он по прежнему будет из какой то части рабочего времени. А это значит - меньше, чем если бы он тратил полностью 8 часов на одну роль, одну активность.

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

Поэтому возвращаясь к словам Макса

"По делу, но ничего нового"

"Самое сложное - договориться"

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

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

Ничего нового, просто - договориться. Это сложно. Но это правильно.

ПОЛЕЗНЫЙ БЕСПОЛЕЗНЫЙ ОПРОС. ЗАКЛЮЧЕНИЕ

Что же полезного нам может дать опрос?

Может ли?

Может.

Дело даже не в том, что опрос плохой (если переформулировать он может стать хорошим для отдельно взятых проектов), дело в том, что сделали большинство пользователей. Наверное 99,9% всех "опрошенных" даже не подумали как важны эти пункты опроса для них самих - и тестировщикам, и разработчикам, и менеджерам, и прочим-прочим-прочим.

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

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

Знаете какой самый популярный вопрос?

Есть ли изменение приоритетов для тестирования?

А знаете какой самый главный? Я задаю его разным людям, в разное время и использую разные формулировки, но подразумеваю одну мысль:

Что ты ожидаешь от меня, что я должен сделать, какие результаты ты ожидаешь получить и когда?

Главное не принимать ответы лично. Потому что они могут звучать как "Поменьше меня доставал глупыми вопросами" ;).


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

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