Про книгу "Как тестируют в Google"
Оригинал записи
До сих пор книги по тестированию софта (под софтом для простоты я понимаю и десктопные программы, и сайты) меня обходили стороной. Разумеется, тесты я пишу, в основном это юнит-тесты, но после того как в последнее время начал "пописывать" сайты на Django, вопросы тестирования встали более остро.
Поэтому я решил наверстать упущенное в этой области и для начала почитать "Как тестируют в Google", в девичестве "How Google Tests Software". Честно говоря, книга вызвала у меня неоднозначное впечатление. С одной стороны, она читается легко и даже интересно, но с точки зрения пользы примерно половину книги можно было бы выкинуть.
Вся книга описывает то, как поставлено тестирование в Google, приводится несколько интервью с сотрудниками Google различных уровней. Но эта книга совсем не техническая, она делает упор именно на организационные моменты и часто скатывается к расхваливанию работы в Google (для контраста можно почитать статью Каково это - работать в Google?) и тому, как компания заботится о качестве своих продуктов.
Тестирование как выделенная проверка не работает, тестировать должен каждый участник проекта, качество нужно встраивать на все уровни разработки.
Основные моменты раскрываются в первых главах книги, а дальше они описываются более детально. Основной момент организации написания софта в Google состоит в том, что разработчики не отделяются (или не сильно отделяются) от тестировщиков. Здесь я несколько упрощаю ситуацию, поскольку в Google кроме должности разработчика существуют такие должности как "разработчик в тестировании", "инженер по тестированию" и "тест-менеджер". Эти должности перечислены по мере удаления их ролей от разработчика и смещения в сторону пользователя, точнее смещения их взгляда на продукт, поскольку тестировщики тоже пишут код, но скорее всего этот код будет относиться к отдельным утилитам для тестирования.
Во время чтения обратил внимание на такой момент:
Большая часть кода Google хранится в едином репозитории и использует общие инструменты. Все процессы сборки и выпуска построены вокруг этих инструментов и репозитория. Каждый инженер Google знает эту среду как свои пять пальцев, поэтому любой участник команды независимо от своей роли может залить новый код, создать и запустить тест, собрать версию и т.д.
...
Весь исходный код доступен любому инженеру. Разработчики веб-приложений могут посмотреть интересующий их код браузера, не спрашивая ни у кого разрешения.
...
Можно взять код для повторного использования на уровне модулей или даже на уровне структур контролов или данных.
В принципе, это полностью соответствует тому, о чем писал Брукс в своем Мифическом человеко-месяце. Но в то же время, именно от этого пункта он отказался через 20 лет в новом издании книги. Это не упрек в адрес Google, просто мысли, если в Google этот принцип работает - замечательно.
В оригинале книга вышла в 2012 году, у нас ее издали в 2014, т.е. достаточно быстро. Но несмотря на это она успела немного устареть. Дело в том, что по ходу всей книги упоминается такая особенность компании, что любой сотрудник Google работает 80% времени на определенный проект, а 20% времени (например, один день в неделю) на другой проект, который ему нравится. Но даже в самой книге в примечаниях переводчика сказано, что сейчас эта система уже отменена, а многие организационные моменты были построены именно вокруг этих 20%. Например, в компании поощряются переходы из одного проекта в другой каждые 18 месяцев, а перед окончательным переходом работник часто работал в это 20%-ое время над новым для себя (или просто новым) проектом.
Из технической части книги может оказаться полезным описание софта, который используют в Google, в основном написанный ими и выложенный в виде открытых исходников. И даже несмотря на то, что это описание довольно поверхностное и не даст "проникнуться" этим софтом, это повод задуматься, а можно ли применить что-то подобное для своих задач.
Я пользовался процесом DDD (Defect-Driven Development - разработка через дефекты). Я объявлял WebDriver бездефектным, а когда пользователь находил баг, я его исправлял и снова объявлял продукт бездефектным.
Из интервью с разработчиком инструментов Тедом Мао.
Поскольку в книге идет описание того, как это устроено конкретно в Google, то скорее всего вся ценность книги как раз и состоит в том, чтобы задуматься о том, какие идеи можно перенять.
Если оценивать книгу со своей "технарской" колокольни, то я бы ей поставил четверку. Если в первых главах я подчеркивал для себя много интересных моментов, то затем просто читал. Читал не без интереса, поэтому потраченного времени не жалею, но может быть для менеджеров эта книга будет более полезна.
До сих пор книги по тестированию софта (под софтом для простоты я понимаю и десктопные программы, и сайты) меня обходили стороной. Разумеется, тесты я пишу, в основном это юнит-тесты, но после того как в последнее время начал "пописывать" сайты на Django, вопросы тестирования встали более остро.
Поэтому я решил наверстать упущенное в этой области и для начала почитать "Как тестируют в Google", в девичестве "How Google Tests Software". Честно говоря, книга вызвала у меня неоднозначное впечатление. С одной стороны, она читается легко и даже интересно, но с точки зрения пользы примерно половину книги можно было бы выкинуть.
Вся книга описывает то, как поставлено тестирование в Google, приводится несколько интервью с сотрудниками Google различных уровней. Но эта книга совсем не техническая, она делает упор именно на организационные моменты и часто скатывается к расхваливанию работы в Google (для контраста можно почитать статью Каково это - работать в Google?) и тому, как компания заботится о качестве своих продуктов.
Тестирование как выделенная проверка не работает, тестировать должен каждый участник проекта, качество нужно встраивать на все уровни разработки.
Основные моменты раскрываются в первых главах книги, а дальше они описываются более детально. Основной момент организации написания софта в Google состоит в том, что разработчики не отделяются (или не сильно отделяются) от тестировщиков. Здесь я несколько упрощаю ситуацию, поскольку в Google кроме должности разработчика существуют такие должности как "разработчик в тестировании", "инженер по тестированию" и "тест-менеджер". Эти должности перечислены по мере удаления их ролей от разработчика и смещения в сторону пользователя, точнее смещения их взгляда на продукт, поскольку тестировщики тоже пишут код, но скорее всего этот код будет относиться к отдельным утилитам для тестирования.
Во время чтения обратил внимание на такой момент:
Большая часть кода Google хранится в едином репозитории и использует общие инструменты. Все процессы сборки и выпуска построены вокруг этих инструментов и репозитория. Каждый инженер Google знает эту среду как свои пять пальцев, поэтому любой участник команды независимо от своей роли может залить новый код, создать и запустить тест, собрать версию и т.д.
...
Весь исходный код доступен любому инженеру. Разработчики веб-приложений могут посмотреть интересующий их код браузера, не спрашивая ни у кого разрешения.
...
Можно взять код для повторного использования на уровне модулей или даже на уровне структур контролов или данных.
В принципе, это полностью соответствует тому, о чем писал Брукс в своем Мифическом человеко-месяце. Но в то же время, именно от этого пункта он отказался через 20 лет в новом издании книги. Это не упрек в адрес Google, просто мысли, если в Google этот принцип работает - замечательно.
В оригинале книга вышла в 2012 году, у нас ее издали в 2014, т.е. достаточно быстро. Но несмотря на это она успела немного устареть. Дело в том, что по ходу всей книги упоминается такая особенность компании, что любой сотрудник Google работает 80% времени на определенный проект, а 20% времени (например, один день в неделю) на другой проект, который ему нравится. Но даже в самой книге в примечаниях переводчика сказано, что сейчас эта система уже отменена, а многие организационные моменты были построены именно вокруг этих 20%. Например, в компании поощряются переходы из одного проекта в другой каждые 18 месяцев, а перед окончательным переходом работник часто работал в это 20%-ое время над новым для себя (или просто новым) проектом.
Из технической части книги может оказаться полезным описание софта, который используют в Google, в основном написанный ими и выложенный в виде открытых исходников. И даже несмотря на то, что это описание довольно поверхностное и не даст "проникнуться" этим софтом, это повод задуматься, а можно ли применить что-то подобное для своих задач.
Я пользовался процесом DDD (Defect-Driven Development - разработка через дефекты). Я объявлял WebDriver бездефектным, а когда пользователь находил баг, я его исправлял и снова объявлял продукт бездефектным.
Из интервью с разработчиком инструментов Тедом Мао.
Поскольку в книге идет описание того, как это устроено конкретно в Google, то скорее всего вся ценность книги как раз и состоит в том, чтобы задуматься о том, какие идеи можно перенять.
Если оценивать книгу со своей "технарской" колокольни, то я бы ей поставил четверку. Если в первых главах я подчеркивал для себя много интересных моментов, то затем просто читал. Читал не без интереса, поэтому потраченного времени не жалею, но может быть для менеджеров эта книга будет более полезна.