В марте прошла конференция для уральских разработчиков, на которой одна из секций была посвящена тестированию. Чтобы расшевелить слушателей и вывести на диалог как можно больше людей, мы устроили выступление, на котором задавали вопросы участникам. Знакомство с тестировщиками, вопросы, интересующие местное сообщество, вполне ожидаемые ответы. С одним лишь исключением. Накануне эти же вопросы были заданы участнику коммьюнити с другого края света, признанному специалисту в области тестирования — Джеймсу Баху. Надо признать, это не только подогрело интерес аудитории, но и помогло взглянуть по-новому на некоторые привычные вещи в тестировании.
Представляю вашему вниманию текст и видеозапись интервью с Джеймсом Бахом.
Джеймс, вы довольно долго занимаетесь тестированием, не возникало ли у вас желания сменить профессию?
Началом моей карьеры было программирование. Я начинал программировать видео игры и в итоге разочаровался. Я устал заниматься этим все время. Мне нравится программировать, но это не то, что мне бы хотелось делать постоянно. Для меня тестирование стало замечательным открытием, потому что позволяло использовать все мои навыки общения и , а так же и навыки программирования, но при этом не было необходимости заниматься одним и тем же слишком долго.
Затем я обнаружил, что люблю учить, и я стал учителем тестировщиков. Сейчас я занимаюсь тестированием, но так же люблю учить и консультировать людей. Есть много разных вещей которыми я занимаюсь, и этого разнообразия мне хватает.
Но если отвечать на твой вопрос прямо, то сначала я хотел стать математиком или физиком. Но у меня не было достаточно терпения для посещения учебных заведений и общения в научных кругах. Затем я хотел стать военным, но у меня не хватало терпения, чтобы выполнять приказы. Потом я подумал, что хочу быть шпионом, но я не умею хранить секреты. Я не люблю хранить секреты. Но очевидно, что будучи шпионом, тебе придётся это делать.
По правде говоря, тестирование — это единственное что осталось.
Что вы находите самым интересным в тестировании?
Самая интересная вещь в тестировании для меня — это психология . Как люди думают, как у них появляются идеи, как они управляют своими мыслями, как люди могут помочь друг другу находить идеи. Этот лабиринт бесконечно увлекателен – психология и наука о , что лежат в основе тестирования.
Есть ещё одна небольшая вещь, относящаяся к практической деятельности, которую я считаю наиболее интересной — это, когда я могу работать с очень большими объёмами данных. Многими тысячами или миллионами знаков и символов, это крайне захватывающе. Я люблю подбирать методы визуализации входных и выходных данных, генерировать их с помощью некоторых инструментов, для меня это развлечение.
Что для вас является самым сложным в тестировании?
Мне очень быстро наскучивает делать что-либо педантично и по расписанию. Я люблю работать с идеями, головоломками, решать их. Быть где-либо в определённое время или делать что-либо, о чем ни в коем случае нельзя забыть — это не для меня. Я бы предпочёл, чтобы кто-то делал за меня вещи, которые требуют дисциплинированности.
Я решатель головоломок.
Как вы проводите ретроспективу ошибок в своих проектах?
Я хочу знать, почему возникла каждая, отдельно взятая, проблема, почему она ускользнула от меня, и хочу предотвратить её повторное появление. Я всегда принимаю на свой счёт пропуск любой ошибки.
И если под ретроспективой дефектов ты подразумеваешь попытку понять, почему проблема произошла в первый раз, и как предотвратить повторное появление — увы, я не часто вовлечён в такого рода расследования. У меня не так много мыслей по этому поводу, но я всегда обеспокоен когда проблема проскальзывает мимо меня.
Как часто стоит проводить подобные расследования?
Я думаю это зависит от ошибки. При нахождении некоторых багов, таких как дыры в безопасности, мы должны всё остановить и спросить что же произошло? Потому что может быть ещё тысяча таких же.
Это как насекомые в реальной жизни. Если вы видите муху на кухне, это значит к вам залетела муха. Но если вы видите муравья, это значит, что скоро колония муравьев пробралась к вам на кухню. Это значит к вам заползёт тысяча или сто тысяч муравьев.
Когда вы видите муху или муравья, вы реагируете по-разному. Поэтому я по-разному реагирую, когда вижу дефекты, указывающие на большую проблему в процессе разработки, и на дефекты, которые могут быть просто опечатками или непреднамеренными ошибками.
Некоторым тестировщикам профессиональный рост видится лишь как переход в обеспечение качества – работа над процессами, создание новых инструментов. Что скажете на этот счёт?
Почему ты не продолжаешь дальше? Почему вместо траты времени на обеспечение качества, ты должен посвящать своё время обучению людей бережному обращению с компьютерами, или решению проблем мирового голода. Ведь очевидно, голод гораздо важнее. Или мировое просвещение, создание мира, возделывание земли.
Думаю, ты можешь сказать, что если ты устал от тестирования, ты можешь делать много вещей. Но это не будет тестированием, вот в чем проблема! Тестирование – это изучение продукта, его исследование и понимание, есть ли в нём проблемы.
Представь, что ты охранник. Представь, что ты охранник на военной базе, и ты говоришь: «Вместо того, чтобы охранять базу, на самом деле я должен пытаться понять, почему люди хотят проникнуть на военную базу, и начать изучать это в университете». Значит ли это, что ты не должен охранять военную базу? КОНЕЧНО ТЫ ДОЛЖЕН ЕЁ ОХРАНЯТЬ!
Поэтому если кто-то хочет заниматься обеспечением качества, предотвращением багов и тому подобным, что конечно же является целесообразным занятием, ты должен понимать, что это не уменьшает необходимости удостовериться, что мы нашли все те баги. И я не думаю, что мы должны бросать тестирование просто потому, что предотвращать баги тоже интересное занятие.
И ещё кое-что по этому поводу. Разумное оправдание сокращения тестирования — это снижение риска появления серьёзных багов. Если с помощью процесса обеспечения качества, которому вы следуете, вы можете сократить количество дефектов, наносящих вред, и убедиться, что технология теперь содержит меньше ошибок, и меньше багов может появиться, тогда, конечно, вы можете сократить тестирование. Вы не можете меньше тестировать, пока этот риск реально не снизится, вот моё мнение. Вы не можете сократить тестирование, потому что вы НАДЕЕТЕСЬ, что в продукте не будет багов. Вы сокращаете тестирование, потому что у вас есть веская причина БЫТЬ УВЕРЕННЫМ, что багов нет.
И тогда вы МОЖЕТЕ себе позволить меньше охранников.
Многих волнует финансовая сторона данного подхода. Что же делать тестировщику, который желает лишь тестировать и не хочет заниматься обеспечением качества? За что повышать зарплату человеку, который продолжает заниматься одним и тем же?
Вы должны очень-очень хорошо тестировать очень сложные вещи. Вы должны развивать ваши навыки общения, ваши технические навыки. Необходимо узнать больше о различных технологиях. Думаю, в общем говоря, вы так же должны работать над навыками программирования, хотя этому есть альтернативы.
Вы не должны быть кодером, вы так же можете быть учителем или тест-консультантом.
Так же есть тестировщики, которых я называю test jumper. Они так хороши в тестировании, что могут запрыгнуть в проект, как коммандос, наладить тестирование, помочь другим людям и после этого уйти дальше, в следующий проект. Стать внутренним или внешним консультантом по тестированию — вот что вы можете сделать.
По существу, это то чем я занимаюсь. Я люблю тестировать, но за что мне на самом деле платят на текущий момент — так это за обучение тестировщиков. Я должен заниматься тестированием, обычно бесплатно, чтобы тренировать мои навыки, лишь тогда смогу быть очень хорош в обучении тестированию. На самом деле, деньги которые я получаю за обучение тестированию финансируют моё самообразование, моё непрерывное обучение как тестировщика. Если бы мне платили за то, что я тестировщик, мне бы платили недостаточно. Мне надо значительно больше денег нежели я могу заработать обычным тестировщиком, чтобы обеспечивать мою семью.
Я бы хотел быть лишь тестировщиком, который учит других, но способ, которым я могу осуществить это — консалтинг.
Какое самое важное, по вашему мнению, событие в мире тестирования произошло за последние годы?
Наиболее значимая вещь, случившаяся в моем сообществе тестировщиков — это открытие систематизированных методов обсуждения и развитие того, что называется неявным знанием (tacit knowledge). Это произошло благодаря социологу, которого зовут Гарри Коллинз (Harry Collins), чья работа повлияла на меня и Майкла Болтона (Michael Bolton), а так же на некоторых других людей из Context-Driven Testing Community.
До того, как кто-либо стал говорить о неявном знании, у нас не было систематизированного, хорошего способа объяснить разницу между явным знанием (explicit knowledge) и неявным. И поэтому неявное знание оставалось в некотором роде мистической штукой, о которой нельзя поговорить. Теперь мы чувствуем, что у нас появились довольно хорошие инструменты для обсуждения. И это значит, что мы можем защитить неявное знание от менеджеров и других людей, которые ничего об этом не знают.
Мы получили важные инструменты, чтобы осознанно ухватиться за более глубокие навыки тестирования. И это самая захватывающая вещь за последние годы для меня.
Tacit and Explicit Knowledge by Harry Collins
Продолжаете ли вы проводить бесплатные уроки по Skype?
Для меня очень важно тренировать тестировщиков, которые стучатся ко мне в Skype, и я занимаюсь этим довольно часто в любое свободное время. Я люблю это делать, и даже откладываю вещи, за которые мне платят, ради обучающих сессий.
Одну из таких сессий я проводил как раз прошлой ночью. Хотя я провожу запланированные сессии, обычно люди приходят ко мне в Skype и говорят: «Я слышал, вы проводите подобные уроки». И если у меня есть свободное время, я предлагаю провести их прямо сейчас. Иногда это тренировки, иногда это наставления, я занимаюсь и тем и другим.
И я должен это делать, потому что мои навыки должны быть отточены. Только практика позволяет держать себя в тонусе. Я совершенствую идеи, и для этого я должен общаться с людьми.
Чему вы обычно обучаете на этих занятиях?
Иногда они приходят ко мне с конкретной проблемой. Зачастую это вопросы о составлении отчётов. Об улучшении отчётов о проведённом тестировании для своих начальников. Иногда это конкретная техника, к примеру комбинаторное тестирование, и они хотят понять как проводить тестирование всех попарных сочетаний.
Так же я пытаюсь вовлечь их в свои текущие исследования. Я часто придумываю новые упражнения, потирая руки, говорю: «Я попробую моё новое упражнение на тебееее!». Затем даю им некоторый сайт, который они должны протестировать, после чего мы проводим обсуждение проделанной работы. Так я получаю новый материал для моих статей и презентаций.
С какими наиболее распространёнными заблуждениями вы встречаетесь на этих сессиях?
Самое большое заблуждение состоит в том, что люди путают тестирование и проверку фактов. Они думают, что тестирование — это проверка некоторых фактов о продукте. Я же показываю им, что тестирование это нечто гораздо большее. Оно включает в себя такие вещи как проверка фактов, но это лишь малая часть того, что должны делать тестировщики. Поэтому я постоянно объясняю им это.
Так же я вынужден объяснять людям, что тестирование — это не обеспечение качества, и это не подтверждение наличия качества. Мы не делаем это. Мы ищем проблемы. Вот что мы делаем. И это приемлемо, если делать работу хорошо.
Обеспечение качества же это нечто другое. Хотя тестировщики тоже могут заниматься этим.
Специалисты по автоматизированному тестированию изучают новые фреймворки, технологии. А чему учиться ручному тестировщику?
Я не могу принять постановку твоего вопроса. В первую очередь, не бывает автоматизированных или ручных тестировщиков. Нет таких вещей. Ты хочешь разделить тестировщиков на тех, кто пишет код во время своей работы, и тех, кто этого не делает. Но все они используют туловины. Использование разного рода инструментов является обычным делом для тестировщика.
К примеру, ты можешь использовать Excel. Если тестировщик не является тестировщиком, пишущим код, это не значит, что он не может изучить все об Excel, верно? Он должны знать как Excel работает, и как он может работать в нем с данными, анализировать их и тому подобное.
Поэтому изучение инструментов и технологий одинаково для всех тестировщиков, несмотря на то, пишете вы код или нет. Конечно, если вы пишете код, вы должны узнавать об этом больше. Разные вещи, что вы можете делать с кодом — конечно же это важно, не говоря уже о технологиях и изучении пользователей.
Главное чему должны учиться тестировщики это:
• рассуждение,
• построение моделей
• и построение экспериментов.
И это то, чему должны учиться тестировщики несмотря на то, пишут они код или нет.
Кажется, что довольно мало тестировщиков имеют чёткое представление о том, как поставить эксперимент. Что крайне важно, потому что тесты — это и есть эксперименты. Вы должны знать как ставить эксперименты и как моделировать продукт. Составить мысленное описание продукта, а затем превратить его в явную модель, с которой вы работаете здесь и сейчас. Явная это или же мысленная модель, тестировщики работают с моделями продукта и делают выводы об этих моделях, ставят эксперименты в соответствии с этими моделями. А так же проверяют правдивость этих моделей. Вот чем занимаются тестировщики. И это довольно важно.
По крайней мере эти два навыка мы должны развивать.
Хочу выразить благодарность Ольге Котковой и Наталье Платоновой за помощь в подготовке статьи.
Автор: vaha
