четверг, 28 августа 2014 г.

Rapid Software Testing for Programmers

Недавно наткнулся на интересный тренинг, который проводит Джеймс Бах (James Bach) "Rapid software testing for programmers".

Там Джеймс пытается рассказать разработчикам, что тестирование - это не только и не столько юнит-тесты, TDD и тому подобные вещи. Насколько я понимаю, сам тренинг основан на другом тренинге, который проводит Джеймс - "Rapid Testing Framework"

Я бы с удовольствием сходил на нечто похожее здесь. Может программный комитет SQADays сможет как-нибудь организовать такое мероприятие? :)

А мы пока давайте посмотрим подробнее на цели, которые должны быть достигнуты после тренинга:

  • научится (а скорее попробовать научится) думать как тестировщик (разработчики действительно думают по-другому)
  • понять, что тестирование нельзя автоматизировать. Также как и разработку. Неожиданно, правда? :)
  • а вот фактические проверки автоматизировать можно. Опаньки - вот оно че, Семен Семеныч :)
  • узнать, почему представление тестирования как просто набора проверок - это плохо.
  • понять, в чем разница между тестировщиком и разработчиком, который сам тестирует свой код
  • "Perform exploratory test design, using focusing and defocusing heuristics" - вот тут я сдаюсь с переводом, боюсь в терминах напутать
  • понять что такое "тестируемость", почему это важно и как это внедрять (взращивать).
Со своей стороны могу заметить, что зачастую роль тестировщика глазами разработчика видится весьма упрощенно - это некто, кто проверяет. Ну и, в особо тяжелых случаях, тот кто отвечает за качество. То есть как раз то, что хочет выбить из разработчиков Бах.
Кто в таком положении дел виноват сказать сложно. Скорее всего, часть вины лежит и на тестировщиках, которых сами себя так видят. Интересно, что в книжке "Как тестируют в Google" на это тоже обращают внимание.

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

Пару лет назад я рассказывал про то, что такое тестировщик в моем представлении - радует, что это совпадает с вышеописанным.

Иногда, пока я про такое слышал только в отношении крупных компаний типа Google, Microsoft, появляется новая роль "разработчик в тестировании". Эти люди помогают писать тесты, помогают делать код тестируемым, разрабатывают утилиты для тестирования. Что то близкое я слышал и про команды тестирования в Яндексе или группу спецназа автоматического тестирования в Одноклассниках (Никита, привет :) ).

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

А кто-нибудь из читателей был на тренинге про Rapid Testing Framework? 

среда, 27 августа 2014 г.

И снова про code review или новая единица измерения качества (WTF/minute)

Интересная статья про инспекцию (рецензирование) кода (code review). Джим приводит интересную статистику и
дает советы по тому, как не тратить время во время code review.

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

1. Сам процесс должен быть легким. Групповое (когда назначается совещание и команда совместно смотрит код) ревью малоэффективно. Только 4% ошибок находится во время такого способа проведения инспекции. Лучше это делать по запросу по email или с помощью специальных инструментов. Тут наша горячо любимая Visual Studio отличилась. Ее возможность Code Review и так не ахти. А если вы храните ваши исходники в git-репозитории, то у вас нет даже ее. Приходится опять смотреть на сторонние инструменты. Недавно попробовали Upsource от Jetbrains работает в TFS-git. Пока завелось.

2. Сколько людей в команде надо привлекать к ревью? Джим считает, что всех приглашать не нужно - бесполезная трата денег. Некоторые исследования показывают, что разработчик глядя на свой код находит половину всех дефектов. Считается, что двое ревьеверов делают работу эффективнее, чем четверо. Возможно имеет эффект "размытия ответственности" - каждый думает "остальные точно проверят качественно".

3. Кроме количества ревьюверов важны еще и их навыки, а также то, как они разбираются в предметной области, к которой относится код. Иначе основным результатом ревью являются замечания по code-style и форматированию. У нас в команде действительно получается так, что специфичные области требующие углубленных знаний плохо инспектируются - тяжело смотреть код без понимания того, что и зачем он делает. Возможно парное программирование или некое его подобие облегчит проблему?

4. Используйте статический анализ. Он поможет улучшить качество ревью.

5. Критические области кода, на которые нужно обращать внимание при ревью:
  • Сетевое API
  • Код библиотек
  • Критическая бизнес-логика
  • Код по управлению, реализующий административный функционал
  • Критичные по безопасности и производительности места
  • Старый код, код, в котором раньше было много дефектов, переписываемый многими людьми
  • Код, который правят новички
  • Большие изменения (новое в старом коде)
  • Большой рефакторинг (изменения старого кода)
6. Получите от code review больше
Если вы неправильно его внедряете - вреда от него может быть больше, чем пользы. Но так как польза очевидна, то надо действовать аккуратно :)
Как уже упоминалось никаких совещаний, никаких наказаний. Старайтесь избегать замечаний по форматированию и code style. Не надо брать разработчиков за яйца - боюсь им это не понравится и в следующий раз ревью превратится или в фикцию, или попытку доказать кто тут на самом деле умный.
Инспекции кода - это не единственный инструмент обеспечения качества. Попробуйте делать просто больше тестов :) 

Удачи!

вторник, 26 августа 2014 г.

Немного интересных ссылок про C++ из новостной ленты #2

Вторая серия ссылок долго ждала очереди и поэтому их накопилось много. Первая серия.

Свежее
Релиз С++14
Подробнее о том, что нового и как это было: лаконично и без растекания по древу. Хотя постов в интернете много.

Lambda-expressions in C++14
Lambda-expression is the most interesting feature in C++11 that challenges the long-used way of defining functions. C++14 proposes two major supplements to this famous feature.

Draft of Effective Modern C++
Уже можно купить электронный вариант релиз-кандидата книжки Скотта Мейерса или заказать печатный вариант. Ценник немаленький, но эта книжка станет классикой.

"Yet another threading framework: асинхронная разработка на C++ под мобильные устройства"
В докладе Дмитрий Жестилевский представляет подход к написанию понятного и производительного асинхронного кода на С++, который применяется в разработке библиотек для мобильных геоприложений в Яндексе.
Видео и слайды

Awesome C/C++
Кладезь ресурсов и информации по С++

An overview of data serialization techniques in C++
Небольшой пост про сериализацию

Классика
Серия постов от Герба Саттера про уменьшение зависимостей во время компиляции.
Задача 1. Решение 1
Задача 2. Решение 2
Задача 3. Решение 3

Почему С++  :)

Удачи в освоении нового!

Галерея работ жены

Решили наконец фотографировать работы жены. А то обычно все быстро расходится по подаркам. Хотя в новой квартире появилось место картины вешать, чем сейчас и занимаемся.

Сделал небольшой бложик. Там, если любопытно, можно посмотреть работы с описанием материала и размеры.

Особенно мне нравятся эти





понедельник, 25 августа 2014 г.

Интервью с Робертом C. Мартином по мотивам книги "The Clean Coder: A Code of Conduct for Professional Programmers"

The only way to go fast, is to go well
Robert C. Martin














Наткнулся на интервью Дяди Боба по мотивам его книги "The Clean Coder: A Code of Conduct for Professional Programmers"

Понравившиеся выдержки из Части 1

Говорите "Нет" вместо "Я попробую".
Вопрос здесь не о том, врать или говорить правду. "Я попробую" - это, в какой то степени, коварная ложь, потому это одновременно и правда.
Если ты говоришь "я попробую", то ты конечно попробуешь. Но, к сожалению, маловероятно, что твое поведение изменится потому, что ты сказал "попробую". А скорее всего ты продолжишь делать то, что и делал до этой фразы. А слова подразумевали какое то изменение. И в этом ложь.
Почему мы говорим эту ложь? Для того, чтобы закончить дискуссию, если она нам некомфортна. И мы говорим что то бессмысленное типа "попробую" в надежде уйти от этого дискомфорта. Это эгоистично, по-детски и непрофессионально.

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

Про оценку или как менеджеры могут быть уверены, что разработчики не добавляют слишком большой запас к их оценкам.
Прямой ответ - менеджеры должны ожидать этот запас, если они хотят получить обязательства (commitments). А если они просят оценку (estimates), то они должны ожидать неопределенность (uncertainty). Другого не дано.

Из части 2

Про командную дисциплину и одиночек.
Команда решает каким правилам она должна следовать. Если итроверты (одиночки) с ними не согласны и не находят из удобными для себя, то им придется покинуть команду. Или быть исключенными.

Лучший способ измерить качество кода
Лучший тест для качества кода - это удовлетворенность пользователя (заказчика). При этом мы говорим о двух формах такой удовлетворенности: удовлетворенность в настоящее время и на протяжении какого то продолжительного срока

PS книжка уже в моей антибиблиотеке (что это), ждет очереди.

Как отлаживать (дебажить) оптимизированный код в Visual Studio 2013 (2012)

Недавно был анонсирован релиз Visual Studio 2013 Update 3.

Одной из полезных фичей стала опция компилятора /Zo, которая облегчает отладку оптимизированного кода.

Обратите внимание, что в ранней версии документации к Update-у эта опция была указана неверно: /Z0. Правильно использовать маленькую (латинскую :) ) 'o'. Сейчас все поправлено (во всяком случае в kb-шке).

Но и это еще не все. Важно, чтобы был выключена опция "Edit and Continue" для native кода.

Больше подробностей, а также магический ключ компиляции для Visual Studio 2012 здесь.

среда, 13 августа 2014 г.

Technology Radar - июль 2014

Новый выпуск радара (pdf).

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

Powershell BDD style testing framework - не уверен что скрипты на PowerShell нужно писать через BDD, но как набор интересных скриптов можно посмотреть.

Snap - Hosted Continuous integration

Go CD - еще один тул для Continuous Delivery. Надо вглубь посмотреть. Why Go?

Flyway is an open-source database migration tool. It strongly favors simplicity and convention over configuration. Жаль, что на Java :(

Ну из грустного: TFS в "hold" (The Hold Ring is for things that are getting attention in the industry, but we don't think are ready for use).

"Ненасильственное управление творческими коллективами" - Г.Бакунов

Хорошее выступление Григория Бакунова на CodeFest 2014 про управление творческими коллективами.

Основная метафора: творческие люди - как дети, и надо действовать как родители :)

Как?
  • будь стабильным 
  • защищай тех, кто под твоей опекой 
  • будь предсказателем или удивляй 
  • неси максимум позитива
  • работай совместно с командой
  • награждай только достойных и делай это так, чтобы все знали
  • шоковая терапия (использовать очень аккуратно и редко)
  • знай всё о каждом
  • управляй не дергая за ниточки
  • помни, у тебя тоже есть босс
Слайды



Видео


Тема не нова, уже слышал ее раньше. "Общаться с ребенком. Как?" упоминается в вопросах-ответах.