Архив за Октябрь, 2013

Тренды в автоматизированном тестировании

Пятница, Октябрь 11th, 2013

Курс естествознания.  Раздел психология.

Жили-были три бригады землекопов. И было в каждой по пять человек. Выкапывали они когда как. Иногда и 50 метров траншеи в день, а если грунт тяжелый попадется, то бывало и 20 с трудом делали. Но по легкому грунту 50 давали железно

Но вот, средь них один нашелся кто-то,
Сказал он: “Братцы, нет на вас креста!
Даешь автоматизацию работы!
Даешь производительность труда!”

Потом трудяги долго заседали
И составляли план работ на год,

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

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

  • в третьей бригаде целых пять человек
  • во второй двадцать
  • а в первой всего пятьдесят

Долго ли коротко они так работали, но тут соседнее хозяйство заказ крупный получило. Проектище! По прокладке пневмопочты между всеми населенными пунктами в районе. Чтоб значим, могла доярка парное молочко по этой почте сразу в город и переслать к завтраку. Ну что ж, нужно новое подразделение структурное открывать, начальника назначать да штат набирать. А взять то кого? Бригадира третьей бригады сразу забраковали – мануальщик, чего с него возьмешь! И естественно взяли бригадира из первой бригады. А он уже потом всех мужиков на работу оформил.

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

А мораль у этой басни такова: если автоматизация тестирования снижает эффективность процесса, то:
а) нужно ее внедрять
б) говорить о ее эффективности
Психология!

Справки:

Я видел пример, когда автоматизация тестирования снизила эффективность более, чем в десять раз.

В цикле статей «Тренды в автоматизированном тестировании в 2013 году» указано, что множество респондентов заявили о эффективности автоматизации тестировании, но ничего не сказано о том, как проводилось измерение изменения эффективности и ничего не сказано о результатах измерения. А учитывая психологию, тренд на 2013 прослеживается очень четко. Нехороший такой тренд.

PS. Очень показательный разбор ситуации с автоматизацией можно найти в книге «Цель». Там автоматизация (внедрение роботизированной линии) катастрофически ухудшила ситуацию и едва не привела к банкротству.

PSS. Я прекрасно понимаю, что автоматизация тестирования может быть эффективной. Но как говорится, покажите мне цифры.

Согласование требований с точки зрения теории вариаций

Вторник, Октябрь 8th, 2013

Курс естествознания по разработке программного обеспечения
Раздел “Вариации”

– Преамбула —————-
Согласование требований к ПО достаточно распространенная процедура, описанная во множестве источников. С точки зрения здравого смысла – все прекрасно. Действительно, ведь так мы должны уменьшить риски того, что продукт будет не слишком соответствовать ожиданиям. Все отлично в теории. Ну и в книгах.
– Конец преамбулы ——————–

Но практика показывает, что не всегда все бывает сильно хорошо. Иногда, а вернее чаще, чем просто иногда, согласование требований идет «Не совсем так, как в теории».

Рассмотрим этот процесс с точки зрения одного из раздела глубинных знаний, выделенных Демингом, с точки зрения теория вариации.

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

Антипаттерн. Один из лучших способов увеличить потери на вариациях (и уменьшить прибыль фирмы) – это включение дополнительного рабочего центра в процесс.

Тезис. Если нужно уменьшить время проекта (выполнения процессной работы), то следует, либо избегать согласования требований, либо кардинально перестраивать работу рабочих центров. Особенно больно бьет согласование требований по сопровождению существующей системы. То, что мы называем “саппорт”, страдает от этого подпроцесса очень сильно.