Чудес не бывает или я ошибаюсь?
Ниже будет много букв, кому побыстрее — могу рекомендовать глянуть этот пост, от Никиты Макарова (тезисы отдельно здесь).
Если еще короче — надо идти и читать. И не важно, делаете вы web-приложения, мобильные или десктопные. Советы в этой книге пригодятся всем: разработчикам, и тестировщикам, а также их начальникам.
Книга, как и отмечают авторы, не для новичков. С другой стороны, совсем заскорузлые "гуру" найдут ее излишне попсовой что ли. Хотя, как можно увидеть на фото, я нашел в книжке много интересных для себя моментов.
Да, пока не забыл, огромное спасибо Алене Васюхиной, Юлии Нечаевой, которые перевели книгу.
О чем эта книга? О том, как упертые товарищи воплотили в жизнь свое видение того, как должен строиться процесс тестирования. В чем он заключается и кто им должен заниматься. Начиналось все как обычно: никто ничего не хотел менять. Все всех устраивало. А проблемы были: бурно растущая компания, частые релизы, недостаток тестировщиков. Правда знакомые проблемы? Вот собственно то, как это решалось и что в итоге получилось, вы и найдете в этой замечательной книге.
- В Google культивируется правило «разработчики-отвечают-за-качество». Разработка строится вокруг тестирования. Именно разработчики должны принимать в нем самое непосредственное участие. Разработчики ошибаются, если считают, что тестирование — это не их работа.
- Ошибка разработчиков в тестировании в том, что они пытаются работать за разработчиков. Разработчики в тестировании должны помнить, что тестировать код — задача разработчика, а их задача — ввести тестирование в рабочий процесс разработчика. Должны создаваться условия, чтобы разработчик занимался сопровождением не только кода, но и тестов. Пусть разработчик в тестировании сосредоточится на ускорении выполнения тестов и предоставлении качественной диагностической информации.
- Ошибка инженеров в тестировании в том, что они начинают вести себя как разработчики в тестировании. Инженер по тестированию должен действовать глобально, контролировать весь продукт: смотреть на тесты с точки зрения пользователя, помогать обеспечивать эффективное использование всей тестовой инфраструктуры. Инструменты и средства диагностики, которые используют тестировщики, должны влиять на весь продукт.
- В Google тесты различают по размеру того, что тестируется. И условно делятся три группы: малые (это, например, юнит-тесты), средние (например, тесты для проверки взаимодействия компонентов) , большие (это когда проверяются реальные пользовательские сценарии).
- Малые тесты направлены на проверку качества кода, а средние и большие — на проверку качества всего продукта.
- На каждый вид тестов действует ограничение по времени выполнения и то, с чем они могут взаимодействовать. Тип теста должны быть обозначен в свойствах теста. От этого зависит поведение системы автоматического запуска тестов: максимальное время выполнение каждого типа отличается и система просто рубанет якобы "зависший" тест.
- Рекомендуемое соотношение количества тестов разных типов: 70 — 20 -10% (малые-средние-большие). Малые всегда автоматизируются, средние и большие — it depends.
Про поиск правильных людей
В книге много рекомендаций по тому, как найти правильных людей на ту или иную роль.
Также есть неплохая анкета позволяющая отличить тестировщика от разработчика в тестировании. Правда у меня получилось, что по анкете я больше тестировщик 🙂 Но на последующее тестовое задание ответил плохо. И кто я в итоге? 🙂 Гусары, молчать ))
Еще интересно: "Часто забывается, что тестирование — это по сути проверка. Делает ли приложение то, что должно делать? Большая часть работы по тестированию сводится к планированию и выполнению проверок. Да, приложение может падать в процессе, но добиться сбоя — не цель тестировщика. Давить на программу, пока она не сломается, интересно, но куда интереснее давить на нее понемногу, снова и снова, имитируя ее реальную эксплуатацию пользователем. А как приятно убедиться в том, что она не сломается при таких условиях! Мы ищем именно такой позитивный взгляд на тестирование, когда проводим собеседование"
Интересно про оценку и повышение:
"Решения о повышении основываются на том, какое влияние специалист оказал на свой проект. Во время ежегодных отчетов менеджеров просят описать ценность вклада своих подчиненных и перечислить, на что это повлияло. Мы ожидаем, что при движении по карьерной лестнице сотрудник влияет на все большее количество вещей".
Используются ежеквартальные и годовые OKR (Objectives and Key Results) — список целей и оценка успеха в достижении этих целей. "Google уделяет большое внимание количественно измеряемым метрикам успеха. То есть достижение 70-процентного успеха означает, что вы поставили достаточно высокие цели и усердно работали для их достижения, а 100-процентный успех говорит о том, что вы были недостаточно амбициозны".
Хорошая (на мой взгляд разработчика) глава про навыки тест-менеджера.
Одним из полезных навыков является способность работы в условиях дефицита (людей). Дефицит приносит ясность и умножает чувство ответственности у всех участников проекта. "Когда ресурсов не хватает, приходится оптимизировать весь процесс. Руководитель не может просто бросить всех людей на задачу, поэтому все действия оптимизируются. Автоматизация, не приносящая пользы, уничтожается. Тесты, не выявляющие регрессию, не пишутся. Если разработчики требуют от тестировщиков определенной деятельности, они должны сами в ней участвовать. Люди не придумывают себе работу, чтобы просто не сидеть без дела. Не нужно делать то, что сейчас не принесет ценности".
- Избегайте повествования, пишите списки.
- Оставьте продажи в покое. Тест-план — это не маркетинговый документ.
- Не лейте воду.
- Если какой-то пункт не важен и не требует действий, не включайте его в план.
- Пишите «от общего к частному». Каждый раздел плана должен расширять предыдущий, чтобы у читателя оставалась общая картина проекта в голове, даже если он прекратил читать.
- Направляйте процесс мышления. Хороший процесс планирования помогает участнику тщательно продумать функциональность и потребности тестирования.
- Итогом должны стать тест-кейсы.
- Создавайте инфраструктуру, в которой писать тесты будет легко. Тесты должно быть проще написать, чем пропустить.
- Примерно 20% всех сценариев использования отражают 80% самого использования. Автоматизируйте эти 20% и не беспокойтесь об остальных. Оставьте их для ручного тестирования.
Про умирание кода
"При переводе проекта в режим сопровождения качества важно снизить зависимость от участия людей в поддержании качества. У кода есть интересное свойство: если оставить его без внимания, он черствеет и ломается сам по себе. Это верно и для кода продукта, и для кода тестов".
Вот как то так. Получилось длинновато, но хотелось дать шанс ленивцам, которые не возьмутся найти время почитать книгу, получить хоть какую то информацию. Но не думайте, что тут все написано — книга гораздо толще и интересней 🙂
Кстати, неожиданный инсайт из другого источника, все что описано работает в таких вот условиях: "one monolithic C++ codebase, 4000+ engineers working on it, 30,000 commits a day" — по материалам конференции CppCon 2014. Для меня это действительно показатель.
Тестируемость
Разработчики в тестировании плотно работают вместе с разработчиками. Пока разработчики пишут код функциональности и тесты для него, разработчики в тестировании создают для них тестовые фреймворки, а заодно выполняют часть работы по ее сопровождению. Ответственность за качество делится между этими ролями поровну.
Основная цель разработчиков в тестировании — сделать продукт тестируемым. Они дают рекомендации, как выстроить структуру программы и стиль написания кода, чтобы упростить будущее юнит-тестирование. Они создают удобную среду тестирования, чтобы разработчики могли тестировать сами. Об этом чуть позже, а сейчас поговорим о том, как пишется код в Google.
Чтобы прийти к равноправной ответственности разработчиков и разработчиков в тестировании за исходный код, мы в Google строим процесс разработки вокруг код-ревью. О том, как рецензировать код, говорят даже больше, чем о том, как его писать.
Рецензирование кода — полноценный этап работы разработчиков. У него есть свои инструменты и своя культура, которая строится на концепции коммитеров, как в опенсорс-сообществах, где коммитить код в базу могут только самые надежные и доказавшие это право разработчики.
Google строит процесс разработки вокруг код-ревью. О том, как рецензировать код, говорят даже больше, чем о том, как его писать.
В Google любой инженер может стать коммитером. Мы пользуемся концепцией читаемости кода, чтобы отличать проверенных сотрудников от новичков. Вот как работает этот процесс.
Когда код написан, он упаковывается в пакет, который мы называем списком изменений. Дальше он отправляется для рецензирования в приложение, которое в Google называют Mondrian, в честь голландского художника, положившего начало абстрактному искусству. Mondrian отсылает код ответственному разработчику или разработчику в тестировании для окончательного утверждения.[20]
Блоки нового кода, изменения в существующем коде, исправления багов — все это может входить в список изменений. Размеры списков могут варьироваться от пары строк кода до нескольких сотен, причем большие списки почти всегда разбиваются на несколько мелких, чтобы рецензентам было удобнее.
Новички рано или поздно получают от коллег бейдж «спец по легкочитаемому коду», если постоянно коммитят качественные списки изменений. Эти бейджи — разные для разных языков программирования. Основные языки в Google — C++, Java, Python и JavaScript. Бейдж указывает нам опытного разработчика, который старается писать так, чтобы вся кодовая база однородной, будто ее писал один разработчик.[21]
Прежде чем список изменений попадет к рецензенту, он пройдет ряд автоматических проверок в Mondrian. Программа проверит выполнение простых условий, например насколько код соответствует гайдлайнам стиля программирования Google, и более сложных, например что все тесты, связанные с этим списком изменений, проходят. Тесты для списка почти всегда включены прямо в него — тестовый и функциональный код живут вместе. Выполнив проверку, Mondrian отправит рецензенту по электронной почте ссылку на списки изменений. В свою очередь рецензент проанализирует код и выдаст рекомендации его автору. Процесс повторяется до тех пор, пока все рецензенты не будут довольны и автоматическая проверка не будет проходить гладко.
Дальше код встает в очередь на отправку, цель которой — поддерживать сборку в состоянии «зеленый свет», в котором все тесты проходят. Это последняя линия защиты между системой непрерывной сборки проекта и системой контроля версий. Код собирается и тестируется на чистой среде, поэтому здесь отлавливаются баги, которые на машинах разработчиков могли не обнаружиться. Эти конфигурационные баги могли бы нарушить процесс непрерывной сборки или, хуже того, пробраться в систему контроля версий.
Очередь на отправку позволяет участникам больших команд совместно работать в ветке main дерева исходного кода. Больше не нужно замораживать код на время интеграции веток и прохождения тестов. Получается, что разработчики больших команд могут работать так же эффективно и независимо, как если бы команда была маленькая и гибкая. Только у разработчика в тестировании прибавляется работы — ведь скорость написания и заливки кода в репозиторий увеличивается.
Данный текст является ознакомительным фрагментом.
Продолжение на ЛитРес
Читайте также
Тестируемость браузера
Тестируемость браузера Именно через браузер пользователь оперирует основными элементами интерфейса и использует фичи Chrome OS. Бо?льшая часть компонентов BrowserUX либо не подходит для тестирования, либо может тестироваться только через низкоуровневые интерфейсы IPC AutomationProxy
А.2.5.4 Тестируемость (Testability)
А.2.5.4 Тестируемость (Testability) Атрибуты программного обеспечения, относящиеся к усилиям, необходимым для проверки модифицированного программного обеспечения.Примечание — Значения этой подхарактеристики могут быть изменены рассматриваемыми
Как тестируют в Google
Фраза «тестирование не определяет качество» уже настолько избита, что просто обязана быть правдой. В любой области разработки, от автомобилей до софта, не получится отточить продукт до совершенства, если он изначально неправильно сконструирован. Спросите любого автопроизводителя, который хоть раз отзывал партию своих машин, чего стоят запоздалые попытки прикрутить качество на готовое изделие. Делайте все правильно с самого начала, не создавайте себе лишних трудностей. Тем не менее это только звучит просто. С одной стороны, качество и не создается тестированием, с другой — без тестирования сделать качественный продукт невозможно. Как вы узнаете, насколько качественный ваш продукт, не проводя тестирование?
Эта головоломка решается легко: перестаньте рассматривать разработку и тестирование по отдельности. Тестирование и разработка идут рука об руку. Напишите немного кода и протестируйте его. Затем напишите еще чуть-чуть и снова протестируйте. Тестирование не отдельная практика, это часть самого процесса разработки. Одним только тестированием качества не добиться. Рецепт получения высокого качества: смешивайте разработку и тестирование в блендере, пока они не станут единой субстанцией.
В издательстве "ПИТЕР" вышла книга "Как тестируют в Google". Книга издана ограниченным тиражом.
В книге описано тестирование программных продуктов в Google: как устроены процессы, как организованы команды, какие техники используются, кто ответственен за качество. Принципы, на которых построено тестирование в Google, применимы в проектах и компаниях любого размера. Авторы книги сами работали над продуктами Google, создавая инструменты тестирования, настраивая процессы и занимаясь непосредственно тестированием.
Всего несколько дней вы можете приобрести ее в электронном виде по самым низким ценам.
Книга доступна в бумажном виде — 613 рублей
В формате PDF — 99 рублей
В формате EPUB — 99 рублей
«Как тестируют в Google» Джеймс Уиттакер, Джейсон Арбон, Джефф Каролло
Название: Как тестируют в Google
Автор: Джеймс Уиттакер, Джейсон Арбон, Джефф Каролло
Год: 2012
Жанр: Интернет, Программирование, Зарубежная компьютерная литература
О книге «Как тестируют в Google» Джеймс Уиттакер, Джейсон Арбон, Джефф Каролло
В книге описано тестирование программных продуктов в Google: как устроены процессы, как организованы команды, какие техники используются, кто ответственен за качество. Принципы, на которых построено тестирование в Google, применимы в проектах и компаниях любого размера. Авторы книги сами работали над продуктами Google, создавая инструменты тестирования, настраивая процессы и занимаясь непосредственно тестированием. Книга рассчитана на профессионалов из индустрии разработки программного обеспечения: специалистов по тестированию, программистов, менеджеров.
На нашем сайте о книгах lifeinbooks.net вы можете скачать бесплатно без регистрации или читать онлайн книгу «Как тестируют в Google» Джеймс Уиттакер, Джейсон Арбон, Джефф Каролло в форматах epub, fb2, txt, rtf, pdf для iPad, iPhone, Android и Kindle. Книга подарит вам массу приятных моментов и истинное удовольствие от чтения. Купить полную версию вы можете у нашего партнера. Также, у нас вы найдете последние новости из литературного мира, узнаете биографию любимых авторов. Для начинающих писателей имеется отдельный раздел с полезными советами и рекомендациями, интересными статьями, благодаря которым вы сами сможете попробовать свои силы в литературном мастерстве.
Скачать бесплатно книгу «Как тестируют в Google» Джеймс Уиттакер, Джейсон Арбон, Джефф Каролло
В формате fb2 : Скачать
В формате rtf : Скачать
В формате epub : Скачать
В формате txt : Скачать