Home

17-18 ноября Майкл Болтон приезжает в Санкт-Петербург, где проведет один из лучших тренингов по тестированию ПО «Rapid Software Testing», разработанный им совместно с Джеймсом Бахом.

Наш сайт уже публиковал переводы заметок Майкла, а к приезду Майкла мы решили сделать целую серию переводов.

Оригинал: Testers: Get Out of the Quality Assurance Business
Переводчик: Михаил Павлов

Недавно Кори Фой (Cory Foy) опубликовал в своем твиттере такой призыв: «Наличие отдела обеспечения качества – признак некомпетентности в отделе разработки. Обсудим?»

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

Осенью 2008 года на конференции AYE я помогал Фионе Чарльз (Fiona Charles) и Джерри Вайнбергу (Jerry Weinberg) проводить сессию под названием «Тестирование лжет». Джерри сидел у входа в аудиторию и, пока участники заходили и занимали места, я прислушался к тому, что он говорит людям, сидевшим рядом с ним.

- Вы занимаетесь обеспечением качества? - спросил он.
- Да, последовал ответ.
- Значит, вам позволено изменять исходный код программ, которые вы тестирует
- Нет, конечно, нет.
- Очень интересно. А как же тогда вы можете «обеспечить» качество?

Этот вопрос сразу напомнил мне об одном разговоре, который случился больше десяти лет назад. Осенью 1996 года Кем Канер (Cem Kaner) читал свой курс «Тестирование черного ящика» в компании Quarterdeck. Тогда я работал менеджером программ, но руководитель отдела обеспечения качества (т.е. тестирования) пригласил меня прослушать этот курс.

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

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

Мы не «владельцы» качества; мы помогаем людям, отвечающим за качество и за то, что оказывает на него влияние.

Содействие качеству — вот чем мы заняты.

Недавно в интервью Рою Ошероуву (Roy Osherove) Джеймс Бах (James Bach) также заметил, что мы, тестировщики, не контролируем качество. Мы не несем ответственности за качество больше, чем кто-либо еще, эта ответственность распространяется на всех, кто входит в группу разработки.

Когда довольно давно Джеймс Бах впервые был назначен тест-менеджером в Apple Computer, его возбуждала сама мысль о том, что он контролирует качество. «Позднее я пришел к пониманию, что это обижало всех вокруг, поскольку истинный смысл моего обращения к другим сотрудникам команды состоял в том, что «вы, ребята, на самом деле не заботитесь о качестве, не так ли? Вы не заботитесь о качестве так, как это делаю я. Я тестировщик, значит, я забочусь о качестве». Кроме разработчиков, нет никого, кто бы создавал качество; они делают так, чтобы качество появилось. Без разработчиков ничего бы не появилось; у вас было бы нулевое качество. Это звучит довольно обидно, и когда вы обижаете их таким образом, они не хотят работать с вами».

На прошлой неделе я был на конференции STAR East в Орландо. Ко мне много раз подходили тестировщики и тест-менеджеры и просили о помощи. Они хотели, чтобы я посоветовал им, как заставить программистов брать на вооружение "лучшие практики". Они хотели знать, каким образом повлиять на менеджеров, чтобы последние лучше работали. Они хотели знать, как навязать ту или иную процессную модель группе разработки. На одной из сессий тестировщики оплакивали качество требований, которые они получают от бизнеса (более того, повторяя общую ошибку, тестировщики говорили «требования», когда они имели в виду документы со спецификацией требований). В свою очередь, один из участников заявил, что когда он вернется на работу, тестировщики «возьмут на себя» обязанность написания требований.

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

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

Послушайте, если вы действительно хотите улучшить качество кода и думаете, что сможете это сделать, станьте программистом. Я так уже делал. Могу заверить вас, что если вы тоже так сделаете, вы быстро обнаружите, какое упорство и напряжение сил требуется, чтобы стать по-настоящему отличным программистом, поскольку, как любой инструмент, компьютер расширяет границы вашей некомпетентности также быстро и мощно, как он повышает вашу компетентность. Если вы хотите управлять проектом, станьте менеджером проектов. Так я тоже делал, и многого добился в этой профессии. Попробуйте себя в этой роли, и вы скоро обнаружите, что качество – это ценность (value) для некоторого человека или людей, мнение которых имеет значение для вас, а ваши собственные стандарты качества становятся значительно менее важными, чем стандарты качества тех, кто на практике использует продукт и оплачивает счета за него. Станьте менеджером проекта, и вы почти сразу поймете, что решение о выпуске продукта может сопровождаться информацией о технических проблемах, но это исключительно бизнес-решение на основе баланса стоимости продукта, включая ошибки, которые угрожают стоимости продукта, и потерь от отказа выпустить продукт.

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

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

• Скажите программистам, как предлагает в интервью Джеймс Бах, что ваша главная цель – помочь им хорошо выглядеть, а затем начните в это верить. Ваша работа – не стыдить, не обвинять и не выступать в роли зла. Я не думаю, что мы имеем право даже в шутку говорить об этом, поскольку это не смешно.
• Вы всегда являетесь носителем плохих новостей. Отдавайте себе в этом отчет, и доставляйте плохие новости с сочувствием и сдержанностью.
• Вы тоже можете ошибаться. Относитесь скептически к своим собственным выводам.
• Сосредоточьтесь на исследовании и изучении продукта, сборе сведений о нем, а не только на подтверждении фактов, которые нам уже известны о продукте.
• Информируйте о том, что вы узнали о продукте в формате, который определяет ценность продукта и выявляет угрозы этой ценности.
• Попытайтесь понять, как работает продукт на всех уровнях, которые вы можете представить, от самого высокого до самого низкого. Учитывайте, что продукт сложен; поэтому, когда возникает необдуманная идея о том, как просто исправить проблему или найти все ошибки в коде, у вас есть возможность остановиться и все обдумать.
• Проявляйте искренний интерес к тому, что делают программисты, и изучайте код, если это вам подходит. По крайней мере, узнайте хотя бы немного о том, как работает код и что он делает.
• Никогда не говорите программистам, как они должны программировать. Если вы действительно уверены, что это ваша роль, убедитесь, что вы не потеряли чувство реальности: как вам понравится, когда они будут давать такие советы вам?

Хотите знать, как повлиять на менеджеров?

• Предоставьте им информацию, которая им требуется для принятия решений, а затем позвольте им принять эти решения.
• Полностью осознавайте, что они принимают не технические, а бизнес-решения.
• Помните, что продукт не обязательно должен соответствовать вашему стандарту качества.
• Ни менеджер разработки, ни кто-либо другой не обременен должностной обязанностью делать вас счастливым. Возможно, часть их работы — помочь вам работать более эффективно. Помогите им разобраться, как это сделать. В частности, обратите внимание на тот факт, что…
• Проблемы, которые замедляют тестирование, крайне важны, поскольку из-за них долго не обнаруживаются ошибки, и найти их становится все труднее. Поэтому сообщайте не только об ошибках в продукте, но и о проблемах, которые замедляют тестирование.
• Если вы хотите дать информацию для совершенствования процесса разработки, сообщите о том, как вы тратите свое рабочее время.
• Обратите внимание (поскольку это обычное дело), почему тестирование занимает столько времени – как мало времени вы тратите на собственно тестирование продукта, и как много времени вы тратите на исследование ошибок и отчетность, работы по настройке, совещания, решение организационных вопросов и другие работы, чтобы обеспечить тестовое покрытие.
• Концентрируйтесь на том, чтобы сделать отчеты точными (скажем, добиваясь точности 5-10%), а не сверхточными, поскольку значительную часть проблем в разработке программного обеспечения можно обнаружить и решить с помощью измерений первого порядка, а не при помощи анализа шести знаков после запятой, значения которых получены с помощью моделей, которые сами оказываются неверными.
• Покажите менеджерам, что большая часть проблем, которые вы находите, обнаруживается не при помощи бездумного повторения тестовых сценариев, а при помощи действий и наблюдений, которые не покроешь тестовыми сценариями, т.е. благодаря интеллектуальному изучению продукта.
• Помогите менеджерам, а также программистам осознать, что автоматизация тестирования - это больше, гораздо больше, чем создание программы, которая заставляет компьютер нажимать на клавиши.
• Помогите всем понять, что автоматизация расширяет возможности некоторых видов тестирования и значительно ограничивает другие.
• Постарайтесь, чтобы люди постоянно осознавали разницу между тестированием и проверкой. Помогите им разобраться в ценности каждого из подходов, и что хорошая проверка требует существенного овладения мастерством тестирования.
• Покажите, что ваша работа – это исследование продукта, требующее знаний, и разъясните менеджерам, как мы на самом деле обнаруживаем проблемы.
• Не дайте команде попасть в ловушку представления о разработке программного обеспечения как о линейном, а не органическом процессе.
• Помогите менеджерам и программистам избежать неверного понимания «фазы тестирования». На самом деле это: фаза исправления ошибок.

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

Хотите заслужить уважение команды?

• Оказывайте проекту сервис, а не будьте помехой. Вы поставляете информацию, а не насаждаете процессы.
• Прекратите попытки приватизировать качество и считайте по умолчанию, что все остальные участники проекта обеспокоены качеством, по крайней мере, так же, как и вы.
• Поймите, что ваша роль – критически мыслить (помочь избежать программистам и менеджерам заблуждений, а это начинается с того, чтобы избежать заблуждений вам самим).
• Увеличивайте разнообразие ваших навыков, возможностей вашей команды, и вашей тактики. Как говорил Карл Вейк (Karl Weick), «если вы хотите разобраться в чем-то сложном, вам нужно усложнить себя самого».
• Как говорит Джеймс Бах, изобретите тестирование для самого себя. Это значит не принимать на веру то, что говорят другие (включая меня); тестируйте услышанное относительно вашего опыта, знаний и навыков. Запишитесь в сообщество тестировщиков и посмотрите, что они делают.
• Если есть что-то, чему можно научиться, и это поможет улучшить ваши знания, или ваши ощущения, или ваши возможности тестирования, научитесь этому.
• Изучайте навыки тестирования, особенно навыки критического мышления, а также работайте над изучением системного и научного мышления, социальной жизнью информации, взаимодействия человек-компьютер, представления данных, программирования, математики, измерений…
• Тренируйте навыки, которые вам нужны и о которых вы прочли. Совершенствуйте навыки, вступив в движение Weekend Testing.
• Найдите себе опытного наставника. Если нет никого подходящего рядом, поищите в Интернете. Попросите о помощи!
• Не уступайте давлению стать товаром. Сертификация означает, что вы тратите деньги, чтобы стать неотличимым от сотен тысяч других людей. Оставьте свой след.
• Не забывайте, что процессные модели – это только модели, и что все процессные модели, особенно те, что описывают виды человеческой деятельности, например, разработку программного обеспечения, не включают огромное количество деталей о том, что действительно происходит.
• Сосредоточьте усилия на развитии личного набора навыков и образа мышления, чтобы вы могли адаптироваться к любой процессной модели, которая встретится на вашем пути.
• Поделитесь вашими экземплярами книг "Lessons Learned in Software Testing" и “Other Illusions About Testing”.

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

Обсудить в форуме