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

Тестировщики и программирование Споры о том, должны ли тестировщики учиться программировать, не утихают. Этой теме посвящено множество статей в блогах разной степени свежести. Очень просто найти многочисленные мудрые комментарии на тему тестировщиков и их умения программировать. Так почему же столько умных людей продолжают и продолжают писать на эту тему? Разве эта тема ещё не закрыта, несмотря на то, что и написано, и наговорено уже немало?

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

Ещё от переводчика: замечания по поводу перевода, если не лень, присылайте на электронную почту rodion@goritskov.com

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

Нужно ли тестировщикам учиться программировать?

Споры о том, должны ли тестировщики учиться программировать, не утихают. Этой теме посвящено множество статей в блогах разной степени свежести. Я выбрал десять наиболее значительных из них [1, 2, 3, 4, 5, 6, 7, 8, 9, 10], чтобы вы имели представление о различных точках зрения. Конечно же, я мог бы привести куда больше примеров статей, но для понимания проблемы и этих вполне достаточно.

Пятого декабря 2013 года, в рамках конференции BCS SIGIST, проходившей в Лондоне, состоялась дискуссия на тему “Должны ли тестировщики уметь программировать?”. В дискуссии участвовали широко известные в сфере тестирования люди: Stuart Reid, Alan Richardson, Dot Graham. Имел честь принимать участие в этой дискуссии и ваш покорный слуга. Dot Graham записала ход дебатов и любезно предоставила их транскрипцию. Я немного привёл в порядок свои высказанные идеи, чтобы они стали более понятными, чем были в пылу дебатов (не знаю, собираются ли сделать то же самое другие участники). Некоторые мысли Alan Richardson в преддверии и после дебатов можно прочитать по следующей ссылке [11]. В этой статье я повторю некоторые свои тезисы из состоявшейся дискуссии.

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

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

Итак, если вы тестировщик и внезапно научились программировать, то:

a) Вы, по определению, перестаёте быть тестировщиком. Вы уже программист! и b) Вы перестаёте беcпристрастно оценивать продукт и становитесь менее эффективны как тестировщик.

Другое мнение состоит в том, что вы можете быть очень эффективным тестировщиком и без умения программировать. Это, безусловно, справедливо в случае, если функциональное тестирование и тестирование черного ящика - это всё, чем вы собиратесь заниматься.

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

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

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

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

Тестировщики ПО должны иметь представление о программном обеспечении, но совсем не должны быть экспертами в программировании.

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

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

Новые умения только прибавляют, они не могут отнимать.

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

Нужно ли заставлять тестировщиков учиться программировать?

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

Насколько тяжело научиться программировать? Когда лучше всего этому учиться?

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

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

Насколько тестировщики должны быть компетентны в программировании?

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

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

Делает ли умение программировать вас более хорошим тестировщиком?

Для начала рассмотрим обратный вопрос: плохо ли уметь программировать, если вы тестировщик? Не вижу ничего плохого. Конечно, вы можете поспорить, например: “Если вы научитесь программировать, то вы сразу же заразитесь той же болезнью, что и программисты - вы перестанете видеть свои собственные ошибки”. Но это не так, тестировщики (и даже те, кто не умеют программировать) точно так же часто не замечают своих ошибок. Вообще говоря, слепота по отношению к своим ошибкам - общечеловеческая, а не профессиональная проблема, и точно не проблема одних только программистов.

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

Не теряем ли мы в таком случае тестировщика в качестве связующего звена с конечным пользовтелем?

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

Dot Graham на мероприятии SiGIST высказала по этому поводу следующее мнение: “Главная причина отделить их (тестировщиков) была в получении независимого мнения о продукте и нахождении тех проблем, которых другие найти не смогли. Одна из презентаций на конференции EuroSTAR (2013) была от человека из agile-команды, в которой осознали, что тестировщики настолько сблизились с разработчиками, что перестали находить баги, критичные для пользователя. Команде пришлось искать пути для возвращения независимости тестировщиков”

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

Мудрый персонаж Гомер Симпсон сказал [12]: “Как обучение может дать мне почуствовать себя умнее? Наоборот, каждый раз, когда я обучаюсь чему-то новому, это новое выталкивает остальные знания из моей головы. Помните, как я прошёл курсы сомелье и после этого разучился водить машину?”

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

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

Что же такое - интеграция тестирования в разработку?

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

Сейчас множество компаний уже используют или только начинают использовать BDD, ATDD или TDD. В любом случае, нужен кто-то, кто будет составлять примеры использования программы, на которые будут опираться эти подходы. Кто ещё может написать их, если не тестировщик? В BDD и ATDD взаимодействие построено на пользовательских историях, которые используются для создания автоматизированных тестов.

Компании ищут возможности “встроить” тестировщиков в команду разработчиков, чтобы, в итоге, увеличить эффективность и тестирования, и разработки. На словах стратегия вовлечения тестировщиков в разработку звучит так: “Мы будем работать по Agile, поэтому мы внедрим TDD или BDD, и уговорим разработчиков лучше тестировать. Конечно же, разработчикам понадобится некоторая помощь в тестировании, для этого в команду будут введены несколько тестировщиков. Очевидно, что они должны быть технически подкованы.”

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

Много ли тестировщиков работают по BDD, ATDD или TDD?

Примерно треть аудитории конференции SIGIST (из, примерно, восьмидесяти человек) подняла руки, когда я спросил их об этом. Эти подходы актуальны в данный момент. Многие компании и раньше не имели выделенного отдела тестирования, поэтому число команд, использующих BDD, ATDD и TDD может в реальности оказаться намного больше.

Не должны ли программисты сами тестировать свой код?

Glen Myers в своей книге [13] заявлял: “Программист должен избегать попыток самостоятельного тестирования собственной программы”. Возможно, что мы слишком сильно зависели от этого принципа и даже, не исключено, строили весь подход к тестированию на нём. Слишком много тестировщиков тратят своё время на бюрократическую возню, написание тестовых сценариев, неправильных и устаревших, на обработку инцидентов, которые никак не влияют на качество продукта. Индустрия тестирования раздута и владельцы компаний видят в избавлении от этих “лишних” тестировщиков возможность экономии средств. Встраивание тестирования в разработку - это пересмотр ответственности за тестирование.

Разработчики могут и должны тестировать свой собственный код. Но, без сомнения, это не всё тестирование, которое должно выполняться.

Нужно ли тестировщикам переучиваться?

Наличие технических умений может позволить вам стать тестировщиком более высокого уровня. С умением программировать вы получаете возможность более плотной работы с разработчиками, вплоть до парной работы с ними. (Конечно же, не стоит забывать и о более плотной работе с бизнес-аналитиками).

Тестировщикам ещё есть, что предложить командам, в которых они работают. Мы уже знаем, что обособленные команды работают не лучшим образом, а Agile напомнил нам о том, что взаимодействие и получение быстрой реакции на изменения улучшает процесс разработки. Но кто же предоставляет реакцию на изменения? В большинстве случаев именно мы, тестировщики. У нас есть необходимые умения и они востребованы. Поэтому, несмотря на то, что потребность в “старых-добрых функциональных тестировщиках” снижается, у нас, как никогда, есть возможность меняться и делать ещё более крутое ПО. Нужно пользоваться этим шансом.

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

Alan Richardson: “Мы должны трезво смотреть на вещи и прислушиваться к мнению специалистов в индустрии. Разработчики могут тестировать больше и лучше, чем сейчас, также как и бизнес-аналитики. Весь процесс разработки и тестирования может быть улучшен. Здесь мы говорим о тестировщиках, потому что это конференция для тестировщиков. Я не знаю, обсуждают ли схожие вопросы на других конференциях, но разработчики в последнее время стали намного сильнее в тестировании, несмотря на их споры о самом процессе. Я призываю вас прочитать несколько современных книг о разработке, например “Growing Object-Oriented Software Guided by Tests” [14] или книгу Kent Back [15]. Эти книги именно о том, как разработчики начинают больше думать о тестировании и об уроках, которые они извлекают в процессе.”

Бесспорно, тестировщики должны понимать, как test-driven подходы (BDD, TDD и им подобные) меняют отношение разработчиков к тестированию. Стратегия тестирования должна учитывать преимущества этих подходов.

Итоги

В этой статье я обозначил следующие основные тезисы:

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

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

Ссылки

  1. Do Testers Have to Write Code?, Elizabeth Hendrickson, http://testobsessed.com/2010/10/testers-code/
  2. Cem Kaner, comments on blog above http://testobsessed.com/2010/10/testers-code/comment-page-1/#comment-716
  3. Alister Scott, Do software testers need technical skills?, http://watirmelon.com/2013/02/23/do-software-testers-need-technical-skills/
  4. Markus Gartner, Learn how to program in 21 days or so, http://www.associationforsoftwaretesting.org/2014/01/23/learn-how-to-program-in-21-days-or-so/
  5. Schmuel Gerson, Should/Need Testers know how to Program, http://testing.gershon.info/201003/testers-know-how-to-program/
  6. Alan Page, Tear Down the Wall, http://angryweasel.com/blog/?p=624, Exploring Testing and Programming, http://angryweasel.com/blog/?p=613
  7. Alessandra Moreira, Should Testers Learn to Code? http://roadlesstested.com/2013/02/11/the-controversy-of-becoming-a-tester-developer/
  8. Rob Lambert, Tester’s need to learn to code, http://thesocialtester.co.uk/testers-need-to-learn-to-code/
  9. Rahul Verma, Should the Testers Learn Programming?, http://www.testingperspective.com/?p=46
  10. Michael Bolton, At least three good reasons for testers to learn how to program, http://www.developsense.com/blog/2011/09/at-least-three-good-reasons-for-testers-to-learn-to-program/
  11. Alan Richardson, SIGIST 2013 Panel – Should Testers Be Able to Code, http://blog.eviltester.com/2013/12/sigist-2013-panel-should-testers-be.html
  12. 50 Funniest Homer Simpson Quotes, http://www.2spare.com/item_61333.aspx
  13. Glenford J Myers, The Art of Software Testing
  14. Steve Freeman and Nat Pryce , Growing Object-Oriented Software Guided by Tests, http://www.growing-object-oriented-software.com/
  15. Kent Beck, Test-Driven Development by Example
  16. A Survey of Literature on the Teaching of Introductory Programming, Arnold Pears et al., http://www.seas.upenn.edu/~eas285/Readings/Pears_SurveyTeachingIntroProgramming.pdf

comments powered by Disqus