Миф об образе мышления в тестировании

Значительную часть своей карьеры я провел в роли преданного своему делу специалиста по тестированию. Я работал в Microsoft, возглавляя различные межкорпоративные инициативы, когда у нас было 10 000 тестировщиков. Мы тесно сотрудничали с командами разработчиков и в то время добились значительных изменений в качестве продукции. Большую часть этого времени, разработчики, как правило, проводили небольшое тестирование, но наши группы тестирования выполняли подавляющее большинство всех усилий по тестированию, включая обширные наборы проверочных тестов, дополненных множеством диагностических инструментов и здоровой дозой исследовательского тестирования.

На каком-то этапе моего пути тестировщика, Microsoft перешла от набора тестировщиков с опытом программирования и без него к модели, в которой все тестировщики знали, как программировать, и я был просто мухой на стене, когда мы придумали название для печально известной роли SDET. Было много хороших (и несколько не очень) причин для этого шага, которые не рассматриваются в этом посте. Одна вещь, которую я помню от некоторых людей, выступавших против этого шага, заключалась в том, что тестировщики, которые знали, как программировать, не могли проводить эффективное тестирование, потому что они были «искажены» пониманием того, как работает код. У этих людей было ощущение, что мышление тестирования отделено от мышления разработки 🧠 – что если у вас есть одно, у вас не может быть другого.

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

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

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

Мышление и Навыки

Некоторые специалисты по разработке ПО считают, что создание продукта, и его тестирование - требуют разных мышлений.

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

Peter Drucker ввел термин "умственная работа", чтобы отличить работу, требующую решения проблем и критического мышления, от механического фабричного труда. Такие авторы, как Daniel Pink (A Whole New Mind), подробно описали влияние творческого мышления на работников, использующих умственный труд.

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

Набор Навыков Созидателей

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

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

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

Переключение внимания

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

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

Нам просто нужно сосредоточиться на этом 😉

Переведено командой QApedia. Подписывайтесь на наш канал.