понедельник, 17 декабря 2012 г.

Немного ссылок о тестировании С++

Немного полезных ссылок про unit-тестирование C++

Кто такой хороший тестировщик?


Думаю, что вдогонку статье о разработчиках, нужно добавить что-нибудь интересное и для тестировщиков.

И какая удача, на глаза попалась статья о 10 причинах того, что вы не настоящий тестировщик (+ часть 2).
Так что я позволю себе, как и в прошлый раз, потренироваться в переводе, а заодно и переварить эти мысли. Перевод, как обычно, очень вольный (а местами и неполный) и по ходу повествования перемежается моими мыслями.

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

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

  • Вы не участвуете в процессе до тех пор, пока не получаете «по голове» готовым билдом с указанием «иди и проверь его».
Задумайтесь и ответьте себе на вопрос: Когда вы начинаете участвовать в процессе разработки? В теории мы должны начинать на этапе сбора и анализа требований, вместе с остальной командой. Но на деле, мы получаем очень мало информации ровно до того момента, когда получаем по голове первым билдом от разработчиков, желающих получить отзыв о том, что они наваяли.
Тут в оригинале идет предположение о том, что обычно у тестировщиков просто нет времени на то, чтобы тратить время на анализ. Я думаю, какая-то правда в этом есть, но чаще у тестировщиков просто не спрашивают их мнение. Будьте активней, добивайтесь участия в планировании функционала, обсуждении того, что и как будет делаться. Ваши знания нужны продукту!

  • Вы общаетесь с Заказчиком только тогда, когда служба поддержки просит вас воспроизвести багу.
Часть вашей работы – это проверка продукта на основе того, как он будет использоваться в продакшене, и поиск багов. Фактически ваша работа – это быть адвокатом Заказчика в команде разработчиков. Для планирования тестов и разворачивания окружения вам нужно понимать как, где и как продукт будет использоваться. Как вы будете это делать, если вы не будете общаться с Заказчиком?
Хочется отметить, что часто не только у тестеров, но и у разработчиков, аналитиков нет доступа непосредственно к Заказчику (в момент разработки продукта). Тут в качестве исходных данных могут выступить предыдущий опыт, общение с отделом продаж, анализ продуктов конкурентов.

  • Управление рисками для вас, это что-то из области страхования жизни.
На самом деле существует немного неоспоримых истин о тестировании. Одна из них - тестировщик никогда не будет иметь времени протестировать абсолютно все. Именно из-за этого, понимание основ управления рисками очень важно. Оно помогает нам правильно понять и расставить приоритеты. Что должно быть проверено в первую очередь, а качество чего можно оценить на основе результатов других тестов. Но, это только основная часть управления рисками. Другой, более интересной и не менее полезной является та, что напрямую даже не связана с тестированием! Каждый тестировщик знает, какие части его продукта подвержены большим рискам, части в которых больше всего багов и где команда срывает сроки из-за непредвиденных обстоятельств. Часть нашей работы как тестировщика, постоянно контролировать эти части и напоминать всей команде о них на всех стадиях нашего проекта.
По своему опыту скажу, что тестировщики, как правило, более пессимистичны при оценке сроков. Видимо это как раз и связано с тем, что они постоянно держат в голове все эти потенциальные проблемы. Точно на тему пессимизма :)

  • У вас нет плана как улучшить качество своего тестирования
Хмм, тут в статье мне как то не понравилось. Много воды. Имхо, надо просто читать больше книг по теории и практике тестирования. Общаться с коллегами из других компаний, перенимать интересный опыт. И постоянно смотреть на себя со стороны, пытаясь найти слабые места, которые можно улучшить. А пока у вас нет плана :) можете почитать о вреде тестирования и о градациях тестировщиков

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

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

  • Вы ставите свое эго превыше всего.
Хороший тестировщик – скромный тестировщик. Вы должны знать, как донести обратную связь и, что более важно, как получить обратную связь от команды и коллег.
Часто тестировщики очень расстраиваются, когда коллеги (особенно разработчики) высказывают мнение о качестве вашей работы, например, когда сами нашли баг, которые вы не нашли, или о тестах, которые не были запущены.
Многие тестировщики воспринимают это как персональную обиду, попытку подвергнуть сомнению их профессионализм. И отвечают неподобающим образом. Вы должны адекватно реагировать на критику от своих коллег. Никто не ожидает  того, что вы идеальны. Но они вправе рассчитывать на ваш  профессионализм и вашу адекватную реакцию на их мнение.

  • Вы не улучшаете свой набор инструментов
Задайте себе вопросы. Вы хорошо знаете те инструменты (утилиты), которые вы используете?
Что бы вам нужно было улучшить, обновить, попросить приобрести для того, чтобы улучшить качество вашей работы.
Тестирование это, без сомнения, мастерство (искусство, если хотите). И без правильных инструментов вам будет сложно создать требуемый продукт.

  • Вы думаете только о том, чтобы стать менеджером или уйти в другую сферу
Многие люди начинают заниматься тестированием, полагая, что это хорошая возможность уйти потом в разработчики. Другие просто не знают, что такое тестирование и думают что это просто «игра» с приложением целыми днями. После этого наверно трудно хорошо работать…
Часть их них становиться хорошими тестировщиками, но большинство в конечном итоге разочаровываются и считают дни до того момента, когда они смогут заняться чем-нибудь другим. Многие не понимают всю мощь и силу тестирования и думают, что единственный путь двигаться дальше - это начать управлять людьми.
Я думаю, что если вы постоянно думаете о чем то другом и не сфокусированы на том, как протестировать лучше, то у вас нет шансов стать профессионалом в этой области. Так что подумайте, на правильном ли вы месте и может пора подыскать себе более подходящее?


Хотите стать профессионалом? Начните смотреть на тестирование как на профессию
Первый шаг – начинаем рассматривать тестирование как нашу профессию.
Второй – посмотрите, чего вам не хватает, чтобы стать лучше? Что вы должны развивать? Как вам нужно подходить к работе и к взаимодействию с заказчиками и коллегами. Что мы должны сделать СЕЙЧАС для улучшения качества нашей работы.
Важно понимать, что изменение должно происходить изнутри, а не под воздействием какого-то указания сверху. И это не зависит от вашей текущей должности, начните с себя.

Вот так вот позитивненько :)

пятница, 14 декабря 2012 г.

Software Project Management Conference - 2

В этом году на SPM съездить не получилось. Жалею. В прошлом году мне понравилось.

Из уже опубликованных слайдов могу порекомендовать посмотреть следующие доклады.

Вика Придатко Про сердитого PM
Как обычно зажигательно, про общение HR и PM. Интересно :)

Было много докладов про Scrum.  Тема уже заезжена, поэтому сложно сделать интересный доклад. Если судить по слайдам, это получилось у Владимира Доброва с докладом "Типичные ошибки внедрения Scrum"

Почетное первое место занимает Макс Дорофеев. Менеджеры, цифры, сено, особая причина и модели (нет, не те про которые вы подумали :). Полный треш (18+) в докладе "Гигиена количественного управления". Макс уже сделал слайдкаст из своего выступления (часть 1, часть 2). 

среда, 12 декабря 2012 г.

Отзыв-конспект "Критическая цепь" Э.Голдратт

По наводке @pimenaus прочитал "Критическая цепь" Э.Голдратта.

Отлично. Читается легко.

Правильный отзыв читайте у pimenaus'а, тут просто конспект с умными мыслями из книги.

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

Сфокусированность
"Что такое в нашем понимании «сфокусированность»? Это принцип Парето. Сфокусируйтесь на двадцати процентах важных проблем, и вы получите восемьдесят процентов выгоды. Это статистическое правило. Но те, кто преподают статистику, знают, что правило «двадцать на восемьдесят» применимо только к системам, состоящим из независимых переменных. Оно применимо только к миру затрат, где каждое звено управляется индивидуально... Поскольку наши организации состоят более чем из пяти звеньев, очевидно, что улучшение двадцати процентов цепи означает, что многие из этих улучшений не внесут вклад в улучшение организации как целого."

Алгоритм поиска того, на чем надо сфокусироваться:

  1. НАЙТИ компонент-ограничение системы.
  2. Решить, каким образом МАКСИМАЛЬНО ИСПОЛЬЗОВАТЬ компонент-ограничение системы.
  3. ПОДЧИНИТЬ все остальное принятому решению: бессмысленно развивать остальные части системы, если они зависят от того компонента, который является ограничением
  4. РАЗВИТЬ (расширить) ограничение системы: сделать так чтобы оно перестало им быть или уменьшить его влияние

"сфокусированность и процесс непрерывного улучшения — это одно и то же."

Оценка сроков или почему "5 + 5 = 13"
"большинство людей ведут себя в соответствии с тем, как измеряется их деятельность"
"Основное влияние на оценки по времени оказывает то, насколько сотрудник опоздал с завершением задания в прошлый раз"

Три механизма того, как подстраховка закладывается почти в каждый элемент проекта:
  1. оценка по времени основана на негативном опыте и оказывается в конце кривой распределения вероятности. 
  2. чем больше уровней менеджмента вовлечено в оценку по времени реализации проекта, тем выше окончательная оценка, так как каждый уровень добавляет свою подстраховку. 
  3. те, кто делают оценку, закладывают дополнительную подстраховку от глобального «урезания». 
Если суммировать, получается, что подстраховка составляет большую часть предполагаемого времени реализации проекта.

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

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

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

Как предлагается решать все указанные выше проблемы планирования, используя понятие критической цепи ?
  • Оценки с вероятностью 50% как правило достаточно при составлении плана
  • Резерв времени создавайте в виде буфера в конце критической цепи и контролируйте его изменение.
  • При параллельных ветках задач используйте буферы в местах слияния с критической цепью. Они также должны контролироваться.
  • Важный элемент - буферы ресурсов, которые защищают от недостатка ресурсов.

Чистую теорию можно почитать здесь. И пару раз перечитайте книжку :)

У @pimenaus'а можно найти еще обзоры книжек про теорию ограничений и про то, в какой последовательности их лучше читать.

вторник, 11 декабря 2012 г.

Отзыв-конспект "Вверх! Практический подход к карьерному росту"

Неплохая книга. После других отзывов ожидал большего, но все равно было интересно.

Книга больше для руководителей, настоящих и будущих, но можно найти много полезного не только им :)

Тезисы:

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

"Почти всегда предпочтительнее нанять не того, кто лучше подходит "под требования момента", а того кто умен, хорошо мыслит, адекватен в общении, амбициозен и, главное, в прошлом стабильно добивался хороших результатов и регулярно осваивал новые области".
Супер, отлично сказано. Абсолютно согласен.

Будьте честны и реалистичны на собеседовании.

Как в итоге принять решение о кандидате? Инна приводит интересное мнение пилота авиакомпании United, с которым вместе училась на MBA.
"В конце из длинного списка остается пара человек, у которых примерно одинаковое количество часов вылетов, лет выслуги и формальных навыков. Окончательный выбор определяется тем, кому ты больше доверяешь в кресле второго пилота и с кем можешь провести восемь часов в кабине". Хорошо, жаль у нас выбор не настолько богатый :)

Про переписку
"Если диалог требует больше трех вопросов-ответов или реально аргументированного спора, лучше назначить встречу". Да, согласен. Часто почта - это зло.

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

Книга не лишена юмора :)
Интересная история: система IBM AS400, которой занималась Инна еще работая в Москве, не принимала русскую букву "Х", считая ее за команду переноса строки.
Дальше по тексту "На мой запрос в лабораторию пришел ответ: А насколько важна буква Х в русской речи?" - "Примерно как f в английском!" :)

Советы, как правильно начать работать на новом месте:
 - Начать с отдыха (в оригинале "перекура", но не будем пропагандировать плохие привычки :). Имеет смысл взять несколько свободных дней до начала нового дела.
- Медленно запрягать: не спешить. Главное что следует понять - это в чем, собственно, состоит новая работа.
- Определить приоритеты
- Оценить политический ландшафт: составить список тех, с кем нужно поговорить, чтобы войти в курс дела.
- Быть готовым представиться, "рассказать кто вы, чем занимались раньше, что хотите сделать на новом месте"
- Инна рекомендует книгу Майкла Уоткинса "Первые 90 дней".
- Не переживать по поводу временных проблем, тех, что явно "рассосутся" через несколько месяцев

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

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

"Человек, говорящий медленно, воспринимается как более уверенный в себе". Е-хе-хе, мне этому еще учиться, говорю быстро. Значит не уверен в себе? :)

Про выбор места учебы (про MBA)
"Дело не в самом образовании, а в том, что человек с ним делает."

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

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

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

В общем книжка на 4+, возможно я изначально был настроен на получение чего-то другого. А может не дорос еще. Надо будет перечитать через полгодика. Читается легко и приятно.

суббота, 8 декабря 2012 г.

О справедливом Code-review

Начал разбирать свои favorites в твиттере.
Нашел очень полезные советы Саши Калугина о том, как проводить Code-review, объективно и справедливо.

Очень рекомендую

Часть 1
Часть 2


вторник, 4 декабря 2012 г.

Почему C++ возвращается... не возвращаясь?

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow away your whole leg!
— Bjarne Stroustrup
"Why C++ Is Not “Back”?" - отличная статья про то, почему нельзя назвать нынешнее положение дел с C++, его возрождением или возвращением.

Действительно, соглашусь с автором. Если немного остыть и подумать, то часто, после прочтения очередной рюшки из С++11 ловлю себя на мысли "ну наконец-то, теперь я могу это делать в С++". Хмм, это значит, что до этого я уже мог это делать в знакомых мне C# или Python. Звучит не очень...

Недавно, анализируя источники трафика к постам, обнаружил, что на один из постов шел активный трафик с rsdn. Выяснилось, что на форуме обсуждался вопрос "стоит ли учить С++".  А пост, на который в качестве доказательства необходимости изучения дали ссылку, это интервью Kate Gregory и Steve Tiexeira. Там они обсуждают о том, почему сейчас важно опять начинать работать с C++. 

Вопрос о том, нужно ли или нет учить C++, действительно интересный. Особенно с учетом этого:

"It seems that many of the seasoned developers have forgotten why we stopped using C++ and moved on to Java, C# and other modern languages."

Автор статьи дает 3 ответа на вопрос "Почему я должен учить С++"
- вы серьезно заботитесь о производительности и при этом вам нужен язык с ОО подходом
- вы пишете код, который напрямую работает с железом
- вы серьезно заботитесь о распределении памяти и вам важна возможность иметь полный контроль над ней.
Это все.

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

Есть над чем подумать:
I held out for a long time trying to believe that all the investment I had made in C++ was not lost, but it turned out that C# simplified things to such a great degree that the extra power C++ gave me was not worth the extra responsibility.
В качестве бонуса, в статье есть отличный набор вопросов к собеседованию по C++
  1. Какие есть способы инициализации примитивных типов данных в С++?
  2. Почему деструктор нужно объявлять виртуальным?
  3. Что такое перегрузка (overloading) в C++?
  4. Какие примеру перегрузки вы знаете?
  5. Что такое кодирование имен (name mangling) в С++ и зачем оно используется?
  6. Что такое абстрактный базовый класс?
  7. Что такое RTTI?
  8. Как можно получить доступ к переменной, которая скрыта другой переменной с таким же именем? (тут похоже большое пространство для вариантов)
  9. Что такое namespace и для чего используется?
  10. Какая разница между классом и структурой в С++? А что в С?
  11. Что такое шаблоны и для чего используются?
  12. Что такое конструктор копирования, когда используется, чем отличается от оператора "="?
  13. В чем разница между shallow и deep копированием?
  14. Для чего используется const оператор?
  15. Передача по ссылке, значению, указателю - в чем разница?
  16. Когда можно, а когда нет возвращать результат по ссылке?
  17. В чем разница между переменными созданными в куче и на стеке?
  18. Как вы освобождаете динамически выделенную память для массива? Что будет если просто вызвать delete?
  19. Для чего используется множественное наследование?
  20. Чистая виртуальная функция - что такое?
  21. Для чего используется ключевое слово mutable?
  22. Для чего используется ключевое слово volatile?
  23. Что такое STL?
  24. Что такое vector?
  25. Что включает в себя <algorithms>?
  26. В чем разница между #include <iostream.h> и #include <iostream>?
  27. В чем отличие "++i" и "i++"?
  28. Что такое "быстрое сравнение" и как оно может быть использовано? В чем опасность?
  29. Что делает оператор ","?
  30. Что такое и как используется тернарный оператор?
  31. Что такое const для фунции-члена класса и как она может быть после этого использована?
  32. Использование try|catch в С++?
  33. Почему нельзя бросать исключения в деструкторе?
  34. Для чего используется ключевое слово explicit?
  35. Как правильно приводить к типу в С++?
  36. Для чего используется inline?
Но в конце концов, автор дает еще один плюс от изучения С++
If you can program in C++, you can program in any programming language.  If you understand how stack and heap memory work, pointers and references and all the low level details that make C++ so tricky, it will help you when you are working at higher abstractions and in understanding how computers work in general.
Дерзайте :)