Home

Автор: Шон Бойсе (Shaun Boyce)

Оригинал статьи: http://www.testingtrapezemagazine.com/wp-content/uploads/2017/10/TestingTrapeze-2017-October-v1.1.pdf

Перевод: Ольга Алифанова

Иногда я думаю о том, чего люди ожидают от вида тестировщика в процессе тестирования? Как, с их точки зрения, выглядит «тестирование»?

Если я заменю «тестировщика» на «программиста» или «разработчика» (а тестирование – на программирование или разработку), что вы себе представите? Когда я говорю, что я тестировщик, зачастую на меня тупо пялятся в ответ – как минимум тогда, когда я разговариваю с людьми, не работающими в сфере ПО. В результате я немного рассказываю про то, как я помогаю разрабатывать ПО и трачу время на выяснение, получат ли люди в итоге то, что на самом деле хотят – это определение, я надеюсь, легче для понимания. Дискуссия становится более прямолинейной, если мои собеседники тоже заняты в сфере ПО, но даже тогда я часто сталкиваюсь с целой линейкой предположений о том, что такое тестирование, или чем оно может быть.

К примеру, недавно я спросил команду (которая зарабатывает на жизнь разработкой ПО), что такое, с их точки зрения, тестирование. Вот какие ответы я получил:

«Поиск проблем до того, как их найдут клиенты».

«[Убедиться, что] Должная оценка [была произведена]»

«[Убедиться, что наше ПО] «Подходит» [для своих целей]»

«Не было нанесено вреда имеющейся системе [в результате внесенных в нее изменений]»

«Подтверждение, что [ПО] работает, как полагается, и все пути были проверены, чтобы убедиться, что ничего не упущено»

«Тестирование – это определение качества ПО»

«Поиск багов»

«Предоставление мнения и информации/доказательств о качестве»

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

Тестирование, однако, увидеть тяжело. Тестирование может быть тем, что происходит, когда человек сидит за столом, внутренне сфокусировавшись на чем-то, не воспринимаемом другими. Под «чем-то не воспринимаемым» я имею в виду хорошее, честное тестирование, которое происходит здесь – представьте, что я указываю на собственную голову, говоря все это.

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

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

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

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

Только шесть лет назад я начал слышать что-то о тестировании, управляемом контекстом. Я начал замечать людей, прокладывающих дорогу в этом направлении – по крайней мере тех, кто прокладывал ее в Веллингтоне: Брайан Осман, Катрина Клоки, Аарон Ходдер. Они помогали другим тестировщикам своими прекрасными постами в блогах, разговорами и встречами.

Я уже читал книги, затрагивающие концепцию управления через контекст – например, все еще полезную «Уроки тестирования» (Кейнер, Бах, Петтикорд), но живые люди в моем собственном городе, возможно, ведущие нас вперед своим личным примером – это было совсем другое дело. Заметьте, что я сказал «возможно, ведущие нас вперед», а не «легко ведущие». Но даже учитывая трудности, эти люди вдохновляли окружающих. Я думаю, во многом благодаря их усилиям и моим, менее публичным, попыткам учиться, в один прекрасный день, около двух лет назад, я совершил рывок и уволился со своей прекрасной, хорошо оплачиваемой работой. Настала пора попробовать что-то новое. Не совершил ли я ошибки?

Я скорее интроверт, и склонен к волнению. Если честно, мне нравится окружение, в котором ценится идея «лучших практик». Когда тебе обрисовали лучшую практику, легко понять, чего от тебя ожидают, и мое волнение исчезает. Штука тут в том, что ошибки, да, болезненны, а комфорт прекрасен, но на ошибках учатся. Проходит какое-то время, и комфорта уже недостаточно. Если увольнение было ошибкой, то, надеюсь, той, на которой можно чему-то научиться и вырасти профессионально.

В апреле 2016 года Кит Клайн очень здорово сформулировал в своей статье «Dr. Strangecareer» - «Тестировать сложно. Правильное тестирование – это противоречивая, неразмеченная дорога в море предвзятостей и экспериментов. Но как говорилось в фильме, «трудности – это то, что делает его замечательным».

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

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

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

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

Ошибка, которую я совершил – это отсутствие внятной видимости моей собственной работы.

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

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

Я все время концентрировался на общей картине и забыл об одном из базовых уроков консалтинга, полученных мною: конечно, важно понимать все «почему» и «как» (спасибо, Саймон Синек), но на восприятие людей сильно влияет то, что они видят перед собой ежедневно. Третий принцип «Семи базовых принципов школы тестирования, управляемого контекстом» гласит, что «Люди, работающие вместе – самая важная часть контекста любого проекта».

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

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

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