Чудес не бывает или я ошибаюсь?

По наводке Леши Пименова прочитал эту книжку . Общее резюме (сразу в начале): книга ОБЯЗАТЕЛЬНА к прочтению менеджерами-новичками и теми, кто хочет ими стать. Разработчикам-технарям тоже будет полезна (разработка - это командная работа) - надо выйти за рамки IDE и посмотреть на свою работу с другой стороны. Те менеджеры, которые отработали уже от ~5 лет и выше, скорее всего, набили все шишки и к решениям из книги пришли самостоятельно. Они им или уже следуют, или идут своим "уникальным" путем. Таким эта книжка покажется "попсовой": одни, правильные, менеджеры найдут там мало нового, другие, эээ "уникальные", менеджеры советам скорее всего не внемлют. Мои заметки на полях (возможно сумбурно) . Разработка - командная работа.  Строится на 3-х китах: Скромность, Уважение, Доверие. Работа в команде без общения - нонсенс. Надо уметь правильно коммуницировать. Сихнронные vs Асинхронные коммуникации. Про лидерство в команде Вредные советы - чег

" Test Automation Patterns Wiki " Просто ссылка. Просто полезно. 

Часть 1.  Введение  Часть 2.  База  Часть 3. Интересные возможности (эта статья) Часть 4.  Демо FitNesse + Jenkins Часть 5. Пример трансформации PowerShell скрипта в тест Прошло уже достаточно много времени с момента опубликования первых двух частей ( часть 1 , часть 2 ) про использование связки FitNesse + PowerSlim . Не скажу, чтобы статьи пользовались большой популярностью. Команда время от времени меня тролила и накручивала статистику блогу. Я вас обожаю :) Но прошел год с момента полномасштабного внедрения этой сладкой парочки у нас на продукте. Состоялся первый релиз и я наконец решил, что долги надо отдавать и стоит дописать обещанную статью про интересные фичи этого инструментария. Тем более, что опыт использования, на мой взгляд, больше положительный. Начну я с одного из мощнейших инструментов FitNesse - сценариев . PowerSlim поддерживает этот способ разработки тестов и в его примерах можно найти тесты использующие этот функционал. Если рассматривать

Краткое описание уровней Тест-сертификации команд разработчиков (из книги " Как тестируют в Google ") Уровень 1 Создать пакеты тестового покрытия. Установить систему непрерывной сборки. Ранжировать тесты на малые, средние и большие. Определить недетерминированные тесты. Создать набор смоук-тестов. Уровень 2 Не выпускать, пока не пройдут все тесты. Обязательно выполнять смоук-тесты до отправки кода. Инкрементальное покрытие всеми тестами не меньше 50%. Инкрементальное покрытие малыми тестами не меньше 10%. Хотя бы одна фича покрыта интеграционным тестом. Уровень 3 Создавать тесты для всех нетривиальных изменений Общее покрытие малыми тестами не меньше 50%. Важные новые фичи покрыты интеграционными тестами. Уровень 4 Смоук-тесты запускаются автоматически перед отправкой нового кода. Смоук-тесты проходят за время меньше 30 минут. Нет недетерминированных тестов. Общее тестовое покрытие не меньше 40%. Тестовое покрытие только малыми тестами не мен

"Тестированию, которое мы знаем и любим, приходит конец... Мир скоро изменится для всех тестировщиков. Примите эти изменения и управляйте ими, чтобы не потерять свою релевантность как тестировщиков"  Как тестируют в Google Давно я не отмечал столько интересностей Я припозднился с чтением этой книги . В инете уже полно обзоров, но одна из моих постоянных читательниц попросила меня прокомментировать содержимое. За что тебе, Катя, большое спасибо - мотивирует :) Ниже будет много букв, кому побыстрее - могу рекомендовать глянуть этот  пост, от Никиты Макарова (тезисы отдельно здесь ). Если еще короче - надо идти и читать. И не важно, делаете вы web-приложения, мобильные или десктопные. Советы в этой книге пригодятся всем: разработчикам, и тестировщикам, а также их начальникам. Книга, как и отмечают авторы, не для новичков. С другой стороны, совсем заскорузлые "гуру" найдут ее излишне попсовой что ли. Хотя, как можно увидеть на фото, я нашел в книжке мн

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

"You should automate 100% of the tests that should be automated"                           Алан Пейдж ( Alan Page ) ' The "A" word '. Уже не помню, как я наткнулся на эту книгу. Наконец дошли руки прочитать. По большому счету, это и не книга, а сборник постов из блога автора по теме автоматизации. И прочитать ее можно за час (если ваш английский это позволяет). И я настоятельно рекомендую вам потратить этот час. Это книга не расскажет вам про виды автоматических тестов, как их писать, какие инструменты и библиотеки использовать. Эта книга о философии автоматического тестирования: " how-to-think-about-testing-and-test-automation ". И мои мозги она встряхнула :) Все, что я читал до этого про автоматические тесты, касалось именно написания тестов, фактически кодирования. И большей частью это было тестирование для разработчиков, а оно отличается от просто тестирования - цели другие, как ни странно. Эта книжка про автоматизацию от тестир