пятница, 26 сентября 2014 г.

Обзор-неконспект "Идеальная IT-компания. Как из гиков создать команду программистов"

По наводке Леши Пименова прочитал эту книжку.

Общее резюме (сразу в начале): книга ОБЯЗАТЕЛЬНА к прочтению менеджерами-новичками и теми, кто хочет ими стать.
Разработчикам-технарям тоже будет полезна (разработка - это командная работа) - надо выйти за рамки IDE и посмотреть на свою работу с другой стороны.

Те менеджеры, которые отработали уже от ~5 лет и выше, скорее всего, набили все шишки и к решениям из книги пришли самостоятельно. Они им или уже следуют, или идут своим "уникальным" путем.
Таким эта книжка покажется "попсовой": одни, правильные, менеджеры найдут там мало нового, другие, эээ "уникальные", менеджеры советам скорее всего не внемлют.

Мои заметки на полях (возможно сумбурно).

Разработка - командная работа. 
Строится на 3-х китах: Скромность, Уважение, Доверие.
Работа в команде без общения - нонсенс. Надо уметь правильно коммуницировать. Сихнронные vs Асинхронные коммуникации.

Про лидерство в команде
Вредные советы - чего делать категорически не нужно
Отрицательная обратная связь в виде "конфеты" (снаружи про положительное, потом (внутри) про отрицательное и снова про положительное) - по мнению авторов вредна. В книге используется модель сендвича, а не "конфеты", но сути не меняет. Вообще, я думаю, разговор не о пользе или вреде, а об умении пользоваться этим способом выражения своего мнения. И тут хорошо идет тема честности в книге.
Хороший вопрос для встреч "1:1" - "Есть что-нибудь, чего тебе не хватает?"

Про мотивацию
Описывается модель Пинка ("Драйв" - ждите моего отзыва, а пока вот обзор Леши и видео)

Как повысить внутреннюю мотивацию:
  • независимость
  • мастерство
  • цель
"Вредоносный" участник - кто, что и как с ними работать.
Тут просто цитата 
"Следует отфильтровывать именно поведение, а не отдельных личностей. Наивно думать, что человек на 100% хорош или плох; гораздо конструктивнее и практичнее обнаруживать недопустимое поведение и пресекать его."
И много полезных практических советов по конкретным ситуациям возникающих внутри команды или на уровне компании.

Про позиционирование команды в компании (искусство корпоративной манипуляции)
Тут замечены новые термины: "наступательная" и "оборонительная" работа команды.
"Наступательная" - работа по производству нового функционала
"Оборонительная" - работа по возврату технического долга и вспомогательные вещи.
Отличные метафоры - буду использовать.
Рекомендуемое соотношение: 1/3 от всего времени можно отводить на "оборону". Если больше - польза приносимая командой будет неочевидна.
Вспомнился этот твит:

(с) оригинал


Письмо начальнику: правило "3 пункта и призыв к действию". Отлично.

Ну и про отношение к пользователям вашего продукта. 
Не забывать про них! Важны эмоции. Паттерн "первая минута пользования"

Паттерны автоматизации тестирования

"Test Automation Patterns Wiki"

Просто ссылка.

Просто полезно. 

вторник, 23 сентября 2014 г.

Тестируем с помощью Fitnesse+PowerSlim. Часть 3. Advanced


Часть 1. Введение 
Часть 2. База 
Часть 3. Интересные возможности (эта статья)
Часть 4. Демо FitNesse + Jenkins
Часть 5. Пример трансформации PowerShell скрипта в тест

Прошло уже достаточно много времени с момента опубликования первых двух частей (часть 1, часть 2) про использование связки FitNesse+PowerSlim. Не скажу, чтобы статьи пользовались большой популярностью. Команда время от времени меня тролила и накручивала статистику блогу. Я вас обожаю :)

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

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


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

Давайте попробуем прикинуть набор тестов для проверки функционала нашего продукта, который контролирует возможность запуска виртуальной машины пользователем. Для старта машины пользователь должен выполнить несколько действий:
  • Аутентифицироваться на сервере авторизации и установить уровень сессии "Для служебного пользования"
  • Выполнить запуск виртуальной машины
С точки зрения теста мы должны: 
  • аутентифицировать пользователя, 
  • установить уровень сессии, 
  • попробовать запустить машину,
  • проверить - машина запустилась или нет (в зависимости от теста)
  • проверить, что факт попытки запуска и принятое решение (о разрешении или запрете) записаны в системе аудита
  • отключить пользователя от сервера авторизации
И этот набор действий надо выполнить во всех сочетаниях входных данных и результатов. Если к этому добавить еще и то, что кроме запуска мы должны контролировать все операции пользователя с виртуальной машиной (и не только с машиной, а вообще всей виртуальной инфраструктурой), то очевидно, что "аутентификация", "установка уровня сессии", "проверка аудита", "отключение пользователя" - хорошие кандидаты на превращение их в кубики, которые будут использованы во всех тестах.
Используя Scenario libraries в сюите можно добиться доступности сценариев во всех тестах сюиты без дополнительных действий.  
Наша иерархия "кубиков"
Есть другой способ переиспользования кода тестов: подключение страниц (include page). Это можно использовать например для возможности использования PowerShell функции написанной прямо внутри страницы (хотя тут же можно использовать и сценарий). PowerShell код по вызову Win32 API функции из kernel32.dll (страшная штука сама по себе) - отличный кандидат на такой "кубик".
Вообще PowerShell функции поддерживаются в PowerSlim и это еще один способ переиспользования кода в тестах.


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


Неочевидные преимущества PowerSlim:
1. Можно запустить несколько PowerSlim серверов на разных портах на одной машине. Зачем?
  • Надо иметь возможность обращаться и к 64, и к 32-битному PowerShell из теста.
  • Можно запустить несколько PowerSlim под разными Windows-пользователями на одной машине. При этом все действия на удаленной машине будут идти от "первого" лица - без наложенных преобразований, которые неизбежно возникают при использовании, например, PowerShell Remoting.
2. Так как это PowerShell и соответственно .Net, то у нас есть возможность, при желании, проверять функционирование UI с помощью уже готовых библиотек, например WhiteUI Automation PowerShell Extensions.

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

пример есть в PowerSlim сюите тестов ExampleS

4. Возможность запуска теста на нужном по сценарию количестве машин становится еще удобнее с фичей Symbols Sharing. Мы это используем в том случае, если прямо в тесте нам нужно создать виртуальную машину локально на сервере виртуализации, получить ее ID-идентификатор и использовать его при при проверке аудита на другом сервере.
пример есть в PowerSlim сюите тестов ExampleS
5. Правильно написанные тесты на FitNesse+PowerSlim дают возможность абстрагироваться от способа реализации фичи: тесту все равно какой способ аутентификации используется системой, какой транспорт используется для передачи служебной информации между компонентами тестируемой системы, какая база используется для хранения настроек, какой язык используется для написания продукт и так далее. В итоге автор тестов, большей частью, сконцентрирован на реализации проверки пользовательских сценариев. Тесты можно писать параллельно самому функционалу. Например, здесь все равно каким образом система контролирует свои файлы, тест просто удаляет файл настроек и проверяет реакцию


6. Это в свою очередь дает возможность писать тесты любому человеку знакомому с PowerShell. Это могут быть тестировщики, или сами разработчики (как у нас). Весь наш продукт написан на C++, иногда сложно переключаться между языками, но мозг тренирует. (Гусары, молчать :)

7. FitNesse+PowerSlim хорошо встраивается в Continuous Integration системы (TeamCity и Jenkins). Мы долгое время использовали готовый плагин к Jenkins (я пожалуй расскажу как-нибудь про нашу CI-систему). Но растущее количество запускаемых тестов, а также ряд проблем с этим плагином заставили нас написать свой "почти"-плагин, который закладывает результаты тестов и артефакты (логи) в базу и дает возможность быстро смотреть часть логов привязанную к конкретному тесту. Очень удобно.

Небольшое итого
на мой взгляд количество и качество существующих фреймворков, с помощью которых можно автоматически проверять функционал продуктов работающих на Windows-платформах, оставляет желать лучшего. Из бесплатных это, пожалуй, только Robot Framework (недавно появился неплохой guideline), FitNesse . Из известных мне платных: Visual Studio Test Professional.

К достоинству Robot Framework можно отнести его используемый язык программирования (Python, хотя есть расширения для IronPython и Jython) и, возможно, большая популярность, в сравнении с Fitnesse. Во всяком случае информации в интернете побольше будет.

Fitnesse+PowerSlim дает возможность использовать все, что есть в PowerShell - мощный инструментарий для настройки Windows, и так же сервисов Microsoft (Exchange, SharePoint, Hyper-V и тп). Для использования всего этого в Robot'e пришлось бы писать прослойки.
К недостаткам Fitnesse+PowerSlim можно отнести некоторую сложность внедрения (например, прекрасно автономно работающие PowerShell скрипты могут не работать внутри PowerSlim), неочевидность его преимуществ. Именно поэтому я решил написать эти статьи и добавить более жизненные примеры в сюиту примеров PowerSlim. Надеюсь, это поможет.

Visual Studio в редакции для тестировщиков я не рассматривал. Во-первых она платная и в нашу подписку не входит. Во-вторых, на момент внедрения автоматизации тестирования, функционал студии был достаточно слабый и в качестве платформы виртуализации использовался Hyper-V, что нам не подходит. Допускаю, что сейчас положение дел улучшилось. Но у open-source движков есть важное преимущество - их можно подтачивать под себя в случае необходимости. При этом базовые вещи уже реализованы.

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

Update: Записал screencast своей презентации на работе с демо того, что у нас получилось с Fitnesse и как он интегрируется в Jenkins

вторник, 16 сентября 2014 г.

Тест-сертификации команд разработчиков в Google

Краткое описание уровней Тест-сертификации команд разработчиков (из книги "Как тестируют в Google")

Уровень 1
  • Создать пакеты тестового покрытия.
  • Установить систему непрерывной сборки.
  • Ранжировать тесты на малые, средние и большие.
  • Определить недетерминированные тесты.
  • Создать набор смоук-тестов.

Уровень 2
  • Не выпускать, пока не пройдут все тесты.
  • Обязательно выполнять смоук-тесты до отправки кода.
  • Инкрементальное покрытие всеми тестами не меньше 50%.
  • Инкрементальное покрытие малыми тестами не меньше 10%.
  • Хотя бы одна фича покрыта интеграционным тестом.

Уровень 3
  • Создавать тесты для всех нетривиальных изменений
  • Общее покрытие малыми тестами не меньше 50%.
  • Важные новые фичи покрыты интеграционными тестами.

Уровень 4
  • Смоук-тесты запускаются автоматически перед отправкой нового кода.
  • Смоук-тесты проходят за время меньше 30 минут.
  • Нет недетерминированных тестов.
  • Общее тестовое покрытие не меньше 40%.
  • Тестовое покрытие только малыми тестами не меньше 25%.
  • Все важные фичи покрыты интеграционными тестами.

Уровень 5
  • Добавить тест к исправлению всех нетривиальных багов.
  • Активно использовать доступные средства анализа.
  • Общее тестовое покрытие не меньше 60%.
  • Тестовое покрытие только малыми тестами не меньше 40%.
Странно, что покрытие малыми тестами на уровне 4 уменьшается, а потом опять растет. У нас получается нечто среднее между 3, 4 и 5. На самом деле малых тестов у нас мало. А с остальным похоже все получше, что радует :)

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

Обзор-конспект "Как тестируют в Google"

"Тестированию, которое мы знаем и любим, приходит конец...
Мир скоро изменится для всех тестировщиков.
Примите эти изменения и управляйте ими, чтобы не потерять свою релевантность как тестировщиков" 

Как тестируют в Google


Давно я не отмечал столько интересностей
Я припозднился с чтением этой книги. В инете уже полно обзоров, но одна из моих постоянных читательниц попросила меня прокомментировать содержимое. За что тебе, Катя, большое спасибо - мотивирует :)

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

Если еще короче - надо идти и читать. И не важно, делаете вы web-приложения, мобильные или десктопные. Советы в этой книге пригодятся всем: разработчикам, и тестировщикам, а также их начальникам.

Книга, как и отмечают авторы, не для новичков. С другой стороны, совсем заскорузлые "гуру" найдут ее излишне попсовой что ли. Хотя, как можно увидеть на фото, я нашел в книжке много интересных для себя моментов.

Да, пока не забыл, огромное спасибо Алене Васюхиной, Юлии Нечаевой, которые перевели книгу.

Итак, поехали.

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

Тезисы:
"Качество ≠ Тестирование: перестаньте рассматривать разработку и тестирование по отдельности. Тестирование и разработка идут рука об руку...Тестирование не отдельная практика, это часть самого процесса разработки."

Роли  в разработке: разработчик, разработчик в тестировании, инженер по тестированию.
Особенности ролей
Разработчики часто глубоко погружены в код, который пишут, и сосредоточены на одной фиче продукта или даже ее части. Они принимают все решения исходя из локальной пользы, воспринимая продукт очень узко.
Хороший разработчик в тестировании должен делать ровно наоборот: смотреть на продукт широко и держать в голове общую картину продукта, со всеми его фичами... Не разработчики, а именно разработчики в тестировании обычно выявляют общие схемы для повторного использования кода и взаимодействия компонентов...
Инженеры по тестированию фокусируются на тестировании с точки зрения пользователя. Они занимаются общей организацией контроля качества, управляют выполнением тестов, интерпретируют их результаты и строят сквозную автоматизацию тестирования.
Ошибки в понимании ролей
  • В Google культивируется правило «разработчики-отвечают-за-качество». Разработка строится вокруг тестирования. Именно разработчики должны принимать в нем самое непосредственное участие. Разработчики ошибаются, если считают, что тестирование - это не их работа.
  • Ошибка разработчиков в тестировании в том, что они пытаются работать за разработчиков. Разработчики в тестировании должны помнить, что тестировать код - задача разработчика, а их задача - ввести тестирование в рабочий процесс разработчика. Должны создаваться условия, чтобы разработчик занимался сопровождением не только кода, но и тестов. Пусть разработчик в тестировании сосредоточится на ускорении выполнения тестов и предоставлении качественной диагностической информации. 
  • Ошибка инженеров в тестировании в том, что они начинают вести себя как разработчики в тестировании. Инженер по тестированию должен действовать глобально, контролировать весь продукт: смотреть на тесты с точки зрения пользователя, помогать обеспечивать эффективное использование всей тестовой инфраструктуры. Инструменты и средства диагностики, которые используют тестировщики, должны влиять на весь продукт.

Виды тестов
  • В Google тесты различают по размеру того, что тестируется. И условно делятся три группы: малые (это, например, юнит-тесты), средние (например, тесты для проверки взаимодействия компонентов) , большие (это когда проверяются реальные пользовательские сценарии). 
  • Малые тесты направлены на проверку качества кода, а средние и большие - на проверку качества всего продукта.
  • На каждый вид тестов действует ограничение по времени выполнения и то, с чем они могут взаимодействовать. Тип теста должны быть обозначен в свойствах теста. От этого зависит поведение системы автоматического запуска тестов: максимальное время выполнение каждого типа отличается и система просто рубанет якобы "зависший" тест.
  • Рекомендуемое соотношение количества тестов разных типов: 70 - 20 -10% (малые-средние-большие). Малые всегда автоматизируются, средние и большие - it depends.

Тест-сертификация
Система заданий по тестированию, которые должна выполнить команда, чтобы стать сертифицированной. Отличная тема, позволяющая оценить профессионализм команды разработчиков в общем то игровой форме. Тема достойна отдельного поста.
Могу ошибаться, но мы у себя в команде работаем по уровню 3-4 и даже выполняем часть 5 уровня. Но есть к чему стремиться.

Про поиск правильных людей
В книге много рекомендаций по тому, как найти правильных людей на ту или иную роль.
Также есть неплохая анкета позволяющая отличить тестировщика от разработчика в тестировании. Правда у меня получилось, что по анкете я больше тестировщик :) Но на последующее тестовое задание ответил плохо. И кто я в итоге? :) Гусары, молчать ))

Еще интересно: "Часто забывается, что тестирование — это по сути проверка. Делает ли приложение то, что должно делать? Большая часть работы по тестированию сводится к планированию и выполнению проверок. Да, приложение может падать в процессе, но добиться сбоя — не цель тестировщика. Давить на программу, пока она не сломается, интересно, но куда интереснее давить на нее понемногу, снова и снова, имитируя ее реальную эксплуатацию пользователем. А как приятно убедиться в том, что она не сломается при таких условиях! Мы ищем именно такой позитивный взгляд на тестирование, когда проводим собеседование"

Интересно про оценку и повышение:
"Решения о повышении основываются на том, какое влияние специалист оказал на свой проект. Во время ежегодных отчетов менеджеров просят описать ценность вклада своих подчиненных и перечислить, на что это повлияло. Мы ожидаем, что при движении по карьерной лестнице сотрудник влияет на все большее количество вещей".
Используются ежеквартальные и годовые OKR (Objectives and Key Results) - список целей и оценка успеха в достижении этих целей. "Google уделяет большое внимание количественно измеряемым метрикам успеха. То есть достижение 70-процентного успеха означает, что вы поставили достаточно высокие цели и усердно работали для их достижения, а 100-процентный успех говорит о том, что вы были недостаточно амбициозны".

Хорошая (на мой взгляд разработчика) глава про навыки тест-менеджера.
Одним из полезных навыков является способность работы в условиях дефицита (людей). Дефицит приносит ясность и умножает чувство ответственности у всех участников проекта. "Когда ресурсов не хватает, приходится оптимизировать весь процесс. Руководитель не может просто бросить всех людей на задачу, поэтому все действия оптимизируются. Автоматизация, не приносящая пользы, уничтожается. Тесты, не выявляющие регрессию, не пишутся. Если разработчики требуют от тестировщиков определенной деятельности, они должны сами в ней участвовать. Люди не придумывают себе работу, чтобы просто не сидеть без дела. Не нужно делать то, что сейчас не принесет ценности".

Есть в книге и про тест-план, как его делать, что он из себя должен представлять. В основе лежит ACC-анализ
Основные принципы ACC-анализа (Attribute Component Capability)
  • Избегайте повествования, пишите списки. 
  • Оставьте продажи в покое. Тест-план — это не маркетинговый документ.
  • Не лейте воду. 
  • Если какой-то пункт не важен и не требует действий, не включайте его в план.
  • Пишите «от общего к частному». Каждый раздел плана должен расширять предыдущий, чтобы у читателя оставалась общая картина проекта в голове, даже если он прекратил читать. 
  • Направляйте процесс мышления. Хороший процесс планирования помогает участнику тщательно продумать функциональность и потребности тестирования.
  • Итогом должны стать тест-кейсы. 

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

Про автоматизацию
  • Создавайте инфраструктуру, в которой писать тесты будет легко. Тесты должно быть проще написать, чем пропустить.
  • Примерно 20% всех сценариев использования отражают 80% самого использования. Автоматизируйте эти 20% и не беспокойтесь об остальных. Оставьте их для ручного тестирования.
Про метрики качества кода (например покрытие кода)
"Измеряйте все, что плохо лежит, но доверяйте людям. При этом все равно будьте реалистом: можно сколь угодно тщательно тестировать продукт внутри компании, но он все равно окажется в руках пользователя. Во внешней среде работают другие законы, вы не можете их ни предсказать, ни воспроизвести".

Про умирание кода
"При переводе проекта в режим сопровождения качества важно снизить зависимость от участия людей в поддержании качества. У кода есть интересное свойство: если оставить его без внимания, он черствеет и ломается сам по себе. Это верно и для кода продукта, и для кода тестов".

Вот как то так. Получилось длинновато, но хотелось дать шанс ленивцам, которые не возьмутся найти время почитать книгу, получить хоть какую то информацию. Но не думайте, что тут все написано - книга гораздо толще и интересней :)

Кстати, неожиданный инсайт из другого источника, все что описано  работает в таких вот условиях: "one monolithic C++ codebase, 4000+ engineers working on it, 30,000 commits a day"- по материалам конференции CppCon 2014. Для меня это действительно показатель.

понедельник, 8 сентября 2014 г.

О книге "Когда я говорил... Об образовании, ИТ и не только"

(с) из статьи о книге
Очередная книжка популярного в последнее время у меня формата "сборник блог-статей":  "Когда я говорил... Об образовании, ИТ и не только" (дубликат на хабре)
Александр Краковецкий

Если смотреть по выставленным мною тегам к этому посту, то в книге рассмотрен широкий спектр вопросов. Да это и по оглавлению видно:
  • Нужно ли учиться в университете?
  • Кто хочет, тот ищет возможности, кто не хочет — ищет причины
  • Эффект бабочки
  • Дилеммы молодого преподавателя
  • Пишем кандидатскую работу
  • Немного слов об интеллектуальной собственности и здравом смысле
  • Возможности для студентов, о которых вы, возможно, не знали
  • О проблеме продвижения научных работ и исследований
  • Возвращаясь к теме высшего образования
  • Нужна ли аспирантура?
  • Философия науки, или Почему мы доверяем науке?
  • Как я учил английский
  • А ваши сотрудники продуктивные?
  • Правильно ли использовать сотрудников только по назначению?
  • Главные причины перехода в другую компанию
  • Когда я говорил…
  • Тренды, возведенные в культ
  • Как отпугнуть высококлассных специалистов. Руководство для компаний
  • Что нужно делать начинающему специалисту
  • Действительно ли нужны головоломки на собеседованиях?
  • Про вред молчания
  • Об идеальном коде и суровой реальности
  • Несколько слов о продуктивности
  • И еще немного мыслей на тему методологий управления проектами
  • Книги для тимлидов и руководителей проектов
  • О мотивации в ИТ
  • О конкурентных преимуществах, или Не заставляйте заказчика чувствовать себя идиотом
  • О журналистах, социальных сетях и здравом смысле
  • Собеседуем IT-специалистов: 8 рекомендаций работодателям
  • Где можно получить знания, которые пригодятся при устройстве на работу в IT-компанию
  • Где лучше работать: в сервисной или продуктовой компании?
  • Что мешает отечественным программистам повторить успех Цукерберга
  • Как организовать мероприятие
  • О бесплатных и платных конференциях
  • Я устал, я ухожу…
  • Почему ДОУ уже не тот…
  • ИТ-цирк уехал, клоуны остались

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

Читается легко и быстро. Рекомендуется большинству, начиная со студентов (must read) и заканчивая бодрыми динозавриками.

Update: но есть и другой, я бы так сказал, более критичный взгляд на эту книгу. Можно глянуть и его, чтобы не разочароваться :)


пятница, 5 сентября 2014 г.

The "A" Word - Подноготная автоматизации тестирования


"You should automate 100% of the tests that should be automated"
                          Алан Пейдж (Alan Page) 'The "A" word'.


Уже не помню, как я наткнулся на эту книгу. Наконец дошли руки прочитать.

По большому счету, это и не книга, а сборник постов из блога автора по теме автоматизации. И прочитать ее можно за час (если ваш английский это позволяет).

И я настоятельно рекомендую вам потратить этот час.

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

Эта книга о философии автоматического тестирования: "how-to-think-about-testing-and-test-automation". И мои мозги она встряхнула :)

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

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

Если вам интересует автоматизация тестирования, то просто возьмите и почитайте.

Что там будет?
- Должны ли тестировщики уметь кодировать
- Надо ли автоматизировать тестирование UI
- С чего автоматизация должна начинаться
- Вопросы после ответа на которые, вы поймете, как у вас обстоят дела с автоматизацией тестирования
- Могут ли регрессионные автоматические тесты считаться автоматизацией тестирования
- Test Design и его влияние на автоматизацию
- Да, там есть повторения из-за того, что это компиляция отдельных статей.

Чего там не будет?
- Утверждений, что автор во всем прав и делать надо только так

PS Книжку можно просто скачать, а можно купить за любое количество денег, которые будут переведены на счет Фонда борьбы с раком. У меня та же история, что и Алана, поэтому я ее купил.