Как узнать, что вы хорошо работаете

Автор: | 06.11.2010

Должны ли тестировщики уметь программировать?

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

Надо уметь автоматизировать свои рутинные задачи.

© Алексей Баранцев

Очень, очень крутое выступление главного редактора портала Software-testing.ru Алексея Баранцева на первой встрече московского клуба тестировщиков, 19 октября 2010 года.

Самые важные вопросы:

  1. Любят ли вас разработчики?
  2. Любите ли вы разработчиков?
  3. Советуются ли они с вами?
  4. Советуетесь ли вы с ними?
  5. Принимают ли ваши советы?
  6. Принимаете ли вы их советы?
  7. Делают ли что-то для вас?
  8. Делаете ли вы что-нибудь для них?
  9. Зовут ли в свой проект?
  10. Привлекаете ли вы их?
  11. Замечают ли ваше отсутствие?
  12. А?

Буду переслушивать.

А теперь можно и перечитывать 🙂

(на заднем фоне слышен легкий, нарастающий шум из области тестирования)

Как узнать, что вы хорошо работаете

Я не буду говорить о каких-то общих вещах, вроде того, что «Тестирование — это круто, да!», и что без тестирования самолеты падали бы на поезда, и что все это понимают, но всё равно относятся к тестировщикам наплевательски. Я расскажу о более приземлённых вещах.

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

Недавно я наткнулся на статью Джонатана Кола, замечательного консультанта в области тестирования, который сказал, что к нему часто обращаются с вопросом типа «Мы чувствуем свою ненужность, что нам делать? Нас, тестировщиков не любят и не ценят…» Он давал некоторые советы, которыми я сегодня тоже поделюсь.

Сейчас я немного переформулирую тему выступления – как понять, что вы качественно делаете свою работу. Да, точно так, как мы говорим о качестве софта, мы можем говорить и о качестве работы.

Начнем с определения качества 🙂

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

Так вот, Вайнберг дает следующее определение качества:

«Quality is the value to some person».

Качество — это ценность или значимость для некоторого человека. Джеймс Бах дополняет это утверждение, говоря, что качество это ценность для какого-то человека, мнение которого для нас важно.

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

Одна из вполне логичных претензий к тестированию заключается в том, что тестировщики ничего не производят. Но тестировщики, все-таки, кое-что производят — они производят информацию.

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

Для кого? Для кого мы можем создавать ценности?

Первое заинтересованное лицо — сам тестировщик

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

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

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

Как еще ощущается, что работа сделана хорошо: вы это ощущаете не только как внутреннее удовлетворение, но и можете это осознать — мозгом, сознанием, можете объяснить и доказать любому человеку, который вас спросит «Почему ты считаешь, что делаешь работу хорошо?».

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

Третий очень важный фактор — прогресс. Если вы делаете работу постоянно примерно одинаково, то в первый раз она будет приносить удовлетворение, второй раз принесет, и в третий, но потом, если вы не почувствуете, что вы делаете её лучше и быстрее, и нет движения — не будет жизни. В работе постоянно что-то должно улучшаться. Что именно — заранее неизвестно. Просто вы понимаете, что в прошлый раз вы тестировали вот так, а сейчас можете сделать это же лучше. Есть прогресс, есть дополнительная ценность внутри себя.

Коллеги

Я лютой ненавистью ненавижу легенду про «Черную команду» тестировщиков из книги Демарко, где он написал про тестировщиков, которые истязали программистов.

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

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

Времена изменились.

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

Тестировщики приносят разработчикам новости. Люди хотят получать положительные эмоции. А людей, которые приносят плохие вести, мало кто любит. Какому программисту бывает приятно ощущать, что работа была сделана плохо? А к нему приходит тестировщик и говорит: «Ты сделал работу плохо, лузер!» И в отношении тестировщика программист начинает занимать агрессивную позицию, начинает избегать диалогов с ним, вступает в конфронтацию — начинает защищаться.

Эти механизмы ухода в защиту достаточно хорошо описаны в последней книге Джерри Вайнберга «Perfect Software and Other Illusions About Software Testiing» Там три главы посвящены именно тому, как разработчики реагируют на те или иные слова со стороны тестировщиков, какие приемы защиты они применяют, и как тестировщикам следует действовать, чтобы эти приемы аккуратно обойти и наладить нормальные отношения, а не вступать в конфликт.

Разработчики хотят получать положительные эмоции от своей хорошо сделанной работы. И тестировщики должны им помогать именно в этом. Если программист где-то ошибся — мы ему помогли, поддержали, сделали так, что ошибка не ушла куда-то к пользователям. Если об ошибке программиста узнает пользователь — это будет очень неприятно, гораздо неприятнее, чем если об этой ошибке узнает брат-тестировщик. Брату можно довериться. Другу можно показать какие-то свои слабости. А пользователю показывать слабости нельзя. Поэтому отношение должно быть доверительным.

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

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

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

Но надо пытаться.

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

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

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

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

Как это сделать? Подойти и спросить: «Вася, чего ты ожидаешь от тестирования, какую информацию ты хочешь получить?»

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

Как можно принести человеку удовлетворение, если он не знает, чего хочет, а вы ему неизвестно что даете? Нет стыковки…

Как определить, насколько у вас хорошие отношения с коллегами, и насколько они вас ценят? Вот чек-лист:

1. Любят ли вас разработчики?

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

3. Принимают ли ваши советы? Это может быть формальным делом, когда по процессу положено согласовать требования с тестировщиками. Высказали вы свои претензии к архитектуре, они сказали «Да, да, да, да!», потом все в стол засунули, ничего не поправили, потому, что мнение тестировщиков просто не принимают во внимание. Ну, насоветовали они там чего-то, но мы же сами знаем, как надо. Этот момент очень важен — принимают ли всерьез советы тестировщиков?

4. Делают ли что-то для вас? Еще один способ понять, относятся ли к вам хорошо. Это реакция, например, программистов на какие-то ваши просьбы. Если они реагируют хорошо, и помогают — вас ценят.

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

6. Замечают ли ваше отсутствие? Самый простой способ — уйти в отпуск или заболеть. И выяснить, заметил ли это кто-то. Есть вы, нет вас — есть разница?

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

– Почему багов нет?

– Ну, вы все хорошо написали.

– Оооо, круто!

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

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

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

Руководство

Несмотря на то, что я выделил руководство отдельно, здесь применимо всё вышесказанное о коллегах. Они тоже коллеги, хотя почему-то так говорить не принято.

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

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

Руководство иногда вынуждает тестировщиков работать плохо. Потому, что оно что-то умное читало, и знает, как надо тестировать по-настоящему. К ним приходят тестировщики и говорят: «Да так вообще уже никто не тестирует!» Они говорят: «Нет, нет, ты давай, делай так, так правильно».

Руководство надо воспитывать примерно так же, нужно формировать правильный заказ, чтобы они знали, чего они хотят от тестировщиков. Перед руководством вам чаще и в большей мере приходится защищать свою работу, чем перед программистами или аналитиками. Руководство конкретно спрашивает: «Почему вы сделали так? Почему вы это тестировали, а это не тестировали?» Вы должны четко и грамотно защищать свою позицию. Если вы это умеете делать, то руководство будет прислушиваться к вашему мнению. Если не умеете — то вам будут говорить, что вам нужно делать, и будут хотеть от вас плохое.

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

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

Пользователи

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

Как узнать, что вы хорошо работаете: 13 комментариев

  1. Vita

    “С руководством та же ситуация — они не знают, чего им хотеть от тестировщиков, а иногда бывает, что они хотят чего-то странного, или даже плохого. Руководство иногда вынуждает тестировщиков работать плохо. Потому, что…”
    Причин может быть куда более чем описано выше.
    Например, потому что, по мнению руководителя, тестировать вообще не нужно, от заказчика ведь не было нареканий. Или потому что на тестирование времени нет, полно другой работы, и разработчики сами все могут сделать – так, что понравится пользователям и будет им “ценно” и т.д.
    Спасибо, почитала с удовольствием – правдиво. А.Баранцева еще не слушала 🙂

  2. Vita

    “Руководство иногда вынуждает тестировщиков работать плохо”.
    Интересно то, что заставить работать плохо – нельзя. Можно делать попытки. Ограничивать во времени, стоять над душой, и пытаться полностью все контролировать…
    Так для “положительного” тестировщика усложняются внешние условия, а его работа по сложности переходит неформально на уровень выше. В условиях такой сложности “всегда” – работать не хочется, а вот временно приобрести положительный опыт – весьма интересно.
    Так же не просто работать в “очень комфортных условиях” – когда нет контроля, нет сроков, нет четких требований. Не просто суметь сохранить форму, не дать себе расслабиться и находить полезные зоны для деятельности и саморазвития.

  3. Mikalai Alimenkou

    На протяжении чтения этого поста меня не покидало ощущение, что автор больше видит роль тестировщиков как контролирующего органа, ответственного за конечное качество продукта. При такой формулировке достаточно естественно чувство неприязни у разработчиков. Согласитесь, мы все не очень любим контроль со стороны. Да и с точки зрения начальства тестировщики становятся “козлами отпущения”. Основная зедача тестировщиков должна заключаться в предотвращении проблем, в обеспечении качества продукта в момент его разработки. И в такой формулировке очень просто ответить на заданные в посте вопросы. Если команда и руководство видят вклад тестировщика в качество, то никогда не откажутся от его усилий. А если тестировщик будет просто пытаться донести мысль о том, что он “необходимый контроль, который всем пойдет на пользу”, то ничего не изменится и все описанные проблемы останутся.

  4. Mikalai Alimenkou

    Хотел добавить пару слов по поводу навыков программирования у тестировщиков. “Автоматизация рутинных задач” не всегда требует умения программировать, а если и требует, то для этого есть команда профессиональных разработчиков, которые справятся с задачей гораздо быстрее и качественнее. Зачем им это делать? Чтобы оптимизировать работу всей команды в целом и ускорить весь процесс разработки.

  5. Albert Gareev

    Основная задача тестировщиков должна заключаться в предотвращении проблем, в обеспечении качества продукта в момент его разработки. И в такой формулировке очень просто ответить на заданные в посте вопросы.
    Не спорю, формулировка звучит красиво.
    Но что (или вернее – кто) реально стоит за проблемами? – Люди, и решения, которые они принимают.
    Причем, это далеко не только программисты, но и бизнес-аналитики, сисадмины, и начальники всех рангов. И что, теперь тестировщику уподобляться Гераклу, коий по легенде победил многоглавую гидру? Да его скорее загонят обратно в конюшни (авгиевы) или посадят в одну компанию с Сизифом…
    С другой стороны, тестировщик может, подобно хитроумному Одиссею, смутить разум как программиста, так и начальника, в нужный момент задав правильный вопрос, заставив задуматься над проблемой, и этим мягко подтолкнув к ее решению.
    Одиссей хорошо рубился на мечах, но не был таким непревзойденным мечником, как Аякс или Ахиллес; водил колесницу, но не мог поспорить в этом искусстве с Диомедом; и, конечно, не обладал такой властью, как Агамемнон. Однако, именно Одиссей уговорил Ахиллеса последовать на осаду Трои; сумел переспорить Аякса; а Диомед считал его лучшим дургом.
    Более того, именно Одиссей успешно разрешил логически стройные, и индуктивно нерешаемые проблемы, такие, как пророчество “первый, ступивший на эту землю, погибнет” (см. высадка на берег Трои), и, собственно, проникновение за неприступные стены Трои с помощью придуманной им статуи коня.
    Вот таким, я считаю, профессиональный тестировщик и должен быть – специалистом широкого профиля, с острым умом и нестандартным мышлением, умением эффективно общаться как с технарями, так и с чайниками. Правда, Одиссей был еще и крутой стрелок из лука… Что ж, зачтем за это дело автоматизацию 😉

  6. Albert Gareev

    Похоже, к списку умений я еще забыл добавить “умение не делать опечатки”:)

  7. Alexei Barantsev

    Михаил, мне кажется, здесь слишком много всего намешано, и мне приписаны мысли и чувства, которых у меня не было, и которые я не разделяю.
    меня не покидало ощущение, что автор больше видит роль тестировщиков как контролирующего органа, ответственного за конечное качество продукта.
    Как человек, не чуждый логики, я в принципе не могу занимать такую позицию.
    Потому что ни при каких условиях контролирующий орган не может нести ответственность за качество продукта. Разделять ответственность — да, может. Но принимать такую ответственность на себя — не может. И дело не в избегании ответственности, а в объективном отсутствии нужной степени влияния на это самое качество.
    Чтобы пояснить это, я переверну картинку вверх ногами. Представьте себе, что тестировщик решил стать саботажником и изо всех сил стремится ухудшить качество продукта. Скажите, сильно ли он в этом преуспеет, если программисты будут делать свою работу хорошо?
    А теперь представьте себе, какой урон может нанести программист-саботажник.
    Вот это и показывает степень влияния, и, соответственно, степень ответственности за качество продукта.
    Не надо пытаться принимать ответственность за то, что не находится в зоне влияния, ничего хорошего из этого не выйдет.
    Более того, я даже не считаю, что тестировщики являются контролирующим органом. “Этот билд выпускать нельзя, потому что он полон багов” — это не контроль, это каприз.
    Полноценный контроль предполагает возможность влияния на то, что происходит, и должную степень информированности. Но что тогда будет делать менеджер проекта?

  8. Alexei Barantsev

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

  9. Уведомление: Расшифровка доклада Алексея Баранцева « Московский клуб тестировщиков

  10. Алексей Лупан

    В записи на промежутке 29:03 – 23:27 сделано это лирическое отступление про умение программировать.
    Вообще там было сказано следующее: “…даже секретарши должны уметь в Excel программировать, а уж тестировщикам-то точно надо уметь автоматизировать рутинные задачи…
    Надо ему написать парсер лог-файла – что он, будет бежать к программисту “Напиши мне парсер лог-файла!”? Нет, дорогой товарищ тестировщик, напиши сам!
    ” 🙂
    Просто это лирическое было настолько отступлением, что в контексте общего текста или следовало таки сделать довольно ощутимую “смысловую паузу”, или вырезать все “лишнее”.
    Вырезать слегка не хотелось, но не хотелось и контекст разрывать. Фраза полетела в конец текста (у меня иногда в конце рабочего текста лежат всякие беспризорные фразы, которые имеют какую-то ценность, но в контекст не укладываются).
    А после завершения всего я для нее места так и не нашел, поэтому я сделал из нее выжимку, и передвинул её в самое начало. Она и самостоятельная, и знаковая, и даже может служить идентификатором докладчика.

  11. Alexei Barantsev

    Я от авторства не отказываюсь 🙂
    Но если посмотреть на текст, не зная, что там происходило на двадцать четвёртой минуте, то эпиграф всё же выглядит несколько оторванным от всего остального.
    По существу вопроса имею сказать следующее.
    Да, я считаю, что негоже по пустякам беспокоить богов разработчиков. Квалификации тестировщиков должно хватать на то, чтобы относительно простые задачи, требующие умения программировать, решать самостоятельно. Одиссей хоть и хуже Аякса рубился, но всё таки знал, за какой конец меч держать.

  12. Albert Gareev

    Квалификации тестировщиков должно хватать на то, чтобы относительно простые задачи, требующие умения программировать, решать самостоятельно.
    Как нельзя более к теме.
    David Christiansen
    “Why Testers Should At Least Consider Learning to Code”
    http://www.techdarkside.com/why-testers-should-at-least-consider-learning-to-code

Добавить комментарий

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