По результатам круглого стола тестировщиков екб - было интересно, кое-что может и взлететь.
Ну и да, в копилку ЧСВ из тви:
@xoposhiy #oseminar про тестирование: "после ухода Максима авто тестирование у нас в проекте пропало" "а у нас после прихода Максима - появилось!"
@xoposhiy #oseminar так всегда. Как бы кому не хотелось - процессы ничто, люди - все
Слово Канеру
Не ждите, что люди будут работать эффективно с несколькими проектами
Если у вас больше проектов, чем тестировщиков, у вас будет соблазн назначить несколько проектов на одного тестировщика. Остерегайтесь двух проблем:
- Некоторые люди берут несколько заданий, но в эту неделю (или месяц) будут работать только над одним. Остальные продукты чахнут в фоновом режиме.
- Тестировщик, активно работающий с двумя проектами тратит много времени на накладные административные задачи. В конечном итоге вы получаете кого-то работающего на нескольких проектах, участвующего в массе митингов, тратящего много времени на то, чтоб догнать команду (перечитывание записей, проверка последних ошибок, чтение отчетов о новых фичах, чтение почты и т. д.) для каждого проекта и мало делающего на любом их них (DeMarco and Lister 1999).
пятница, 30 ноября 2012 г.
Lesson 214
Фак е! Канер тоже считает, что заниматься только менеджерством, работой над процессами и прочими настройками и думаниями — не наш путь.
Нужно выполнять боевые задачи не только потому что больше негде брать ресурсы, но на сугубо постоянной основе.
Слово Канеру
Если вы действительно хотите знать, что происходит, тестируйте вместе с вашими сотрудниками.
Как менеджер, вы, наверное, не раз слышали, что «хороший менеджер делегирует». Конечно, вам придется делегировать большую часть работы вашей группы, и вам, вероятно, не удастся сыграть главную роль в любом проекте. Однако, если вы не работаете на проекте, вы со временем потеряете множество технических навыков, вы не увидите реальные проблемы, с которыми сталкиваются сотрудники, и вы поймете, что вам сложно судить о качестве работы вашего персонала. Участие в проекте может быть непрактичным, но, рассматривая свои приоритеты учтите возможность того, что активное участие хотя бы в одном проекте является достаточно важным, чтоб заслужить высокий приоритет.
Вы потеряете доверие со стороны сотрудников, если не можете хотя бы установить и запустить программное обеспечение, которое они тестируют. Мы призываем вас также воспроизводить некоторые дефекты, которые репортят в проекте. Создайте себе бэкграунд по продукту, чтоб ваши сотрудники могли говорить с вами на одном языке.
Нужно выполнять боевые задачи не только потому что больше негде брать ресурсы, но на сугубо постоянной основе.
Слово Канеру
Если вы действительно хотите знать, что происходит, тестируйте вместе с вашими сотрудниками.
Как менеджер, вы, наверное, не раз слышали, что «хороший менеджер делегирует». Конечно, вам придется делегировать большую часть работы вашей группы, и вам, вероятно, не удастся сыграть главную роль в любом проекте. Однако, если вы не работаете на проекте, вы со временем потеряете множество технических навыков, вы не увидите реальные проблемы, с которыми сталкиваются сотрудники, и вы поймете, что вам сложно судить о качестве работы вашего персонала. Участие в проекте может быть непрактичным, но, рассматривая свои приоритеты учтите возможность того, что активное участие хотя бы в одном проекте является достаточно важным, чтоб заслужить высокий приоритет.
Вы потеряете доверие со стороны сотрудников, если не можете хотя бы установить и запустить программное обеспечение, которое они тестируют. Мы призываем вас также воспроизводить некоторые дефекты, которые репортят в проекте. Создайте себе бэкграунд по продукту, чтоб ваши сотрудники могли говорить с вами на одном языке.
Lesson 213
У меня опять экзистенциальный (я правильно написал это слово не подглядывая в словари!) кризис, на почве поста SALar о вреде профессии.
Может и правда, стоило нанять вместо моей группы пять мануальных наташек и это бы решило больше проблем? Нет, ну ведь SALar в чем-то прав и говорит не просто так? Ну даже если поверить, что мои бойцы лучше, чем пять наташек, то остается открытым другой вопрос — лучше ли чем ноль? А то может и вовсе — мы тут величина явно отрицательная.
Как бы измерить-то, хм.
Слово Канеру
Оценивайте своих сотрудников как руководителей
Количество багов считается, в лучшем случае, бесполезной метрикой эффективности сотрудников. Она вводит в заблуждение и демотивирует, позволяет думать, что вы знаете больше, чем на самом деле. В худшем из за нее худшие сотрудники выглядят хорошо, а лучшие кажутся некомпетентными.
Количество багов выжило как метрика, так как менеджеры и руководители хотят хоть как-то оценивать эффективность сотрудников и они не знают, что еще можно использовать, кроме как количество найденных багов. Мы не можем предложить простых метрик, но мы могли бы предложить вам сделать кое-что полезное для оценки эффективности сотрудников:
- Читайте из багрепорты.
- Читайте их код.
- Читайте их тест-документацию.
- Собирайте комментарии программистов и других заинтересованных лиц о работе тестировщиков.
Рассмотрим следующий пример:
- What fights does he get into and why?
- Как он укладывается в сроки?
- Держит ли он свои обещания?
- Какие проблемы он пропустил?
- Как он помогал программистам и другим тестировщикам, чтоб сделать их работу более эффективной?
- Получает ли он новые навыки? Передает ли он их другим тестировщикам?
- Какие вопросы ставит он в рамках компании? How do these reflect on his business judgment and personal ethics?
Информация, которую вы получите, ответив на эти вопросы даст вам богатую картину работы вашего сотрудника и ситуации на проектах, в которых он принимал участие. Эту информацию нельзя преобразовать в простую цифру, но вы могли бы использовать ее для создания отчета. Представьте, что вы оцените тестировщика от 0 до 5 по каждому из параметров (отчеты об ошибках, код и т. п.). В результате отчет покажет картину сильных и слабых сторон (вашего их понимания). Многомерная информация, подобная этой, поможет вам разработать план обучения каждого из ваших сотрудников.
Многие компании используют самооценку как часть формальной оценки производительности и оценки размера оплаты (самооценка — сотрудник сам заполняет форму оценки своей деятельности). Она может быть полезна, но многие руководители слишком на нее полагаются и не тратят достаточно времени, чтоб узнать факты о работе сотрудника. Другой проблемой является то, что процедура формальной оценки слишком редка, раз в полгода или год. Мы призываем активно следить за работой сотрудников на постоянной основе (см. Deming 1986, 102ff для детального обсуждения). Обратите внимание, что мы не предлагаем заниматься микроуправлением: изучайте то, что делают ваши люди и занимайтесь их обучением на основе этих знаний, так как они отличаются от рассказа о том, как люди делают свою работу (Drucker 1985).
Может и правда, стоило нанять вместо моей группы пять мануальных наташек и это бы решило больше проблем? Нет, ну ведь SALar в чем-то прав и говорит не просто так? Ну даже если поверить, что мои бойцы лучше, чем пять наташек, то остается открытым другой вопрос — лучше ли чем ноль? А то может и вовсе — мы тут величина явно отрицательная.
Как бы измерить-то, хм.
Слово Канеру
Оценивайте своих сотрудников как руководителей
Количество багов считается, в лучшем случае, бесполезной метрикой эффективности сотрудников. Она вводит в заблуждение и демотивирует, позволяет думать, что вы знаете больше, чем на самом деле. В худшем из за нее худшие сотрудники выглядят хорошо, а лучшие кажутся некомпетентными.
Количество багов выжило как метрика, так как менеджеры и руководители хотят хоть как-то оценивать эффективность сотрудников и они не знают, что еще можно использовать, кроме как количество найденных багов. Мы не можем предложить простых метрик, но мы могли бы предложить вам сделать кое-что полезное для оценки эффективности сотрудников:
- Читайте из багрепорты.
- Читайте их код.
- Читайте их тест-документацию.
- Собирайте комментарии программистов и других заинтересованных лиц о работе тестировщиков.
Рассмотрим следующий пример:
- What fights does he get into and why?
- Как он укладывается в сроки?
- Держит ли он свои обещания?
- Какие проблемы он пропустил?
- Как он помогал программистам и другим тестировщикам, чтоб сделать их работу более эффективной?
- Получает ли он новые навыки? Передает ли он их другим тестировщикам?
- Какие вопросы ставит он в рамках компании? How do these reflect on his business judgment and personal ethics?
Информация, которую вы получите, ответив на эти вопросы даст вам богатую картину работы вашего сотрудника и ситуации на проектах, в которых он принимал участие. Эту информацию нельзя преобразовать в простую цифру, но вы могли бы использовать ее для создания отчета. Представьте, что вы оцените тестировщика от 0 до 5 по каждому из параметров (отчеты об ошибках, код и т. п.). В результате отчет покажет картину сильных и слабых сторон (вашего их понимания). Многомерная информация, подобная этой, поможет вам разработать план обучения каждого из ваших сотрудников.
Многие компании используют самооценку как часть формальной оценки производительности и оценки размера оплаты (самооценка — сотрудник сам заполняет форму оценки своей деятельности). Она может быть полезна, но многие руководители слишком на нее полагаются и не тратят достаточно времени, чтоб узнать факты о работе сотрудника. Другой проблемой является то, что процедура формальной оценки слишком редка, раз в полгода или год. Мы призываем активно следить за работой сотрудников на постоянной основе (см. Deming 1986, 102ff для детального обсуждения). Обратите внимание, что мы не предлагаем заниматься микроуправлением: изучайте то, что делают ваши люди и занимайтесь их обучением на основе этих знаний, так как они отличаются от рассказа о том, как люди делают свою работу (Drucker 1985).
среда, 28 ноября 2012 г.
Lesson 212
Прекрасное, с Хабра. Как тестируют самсунги. С 1:20 чад и угар.
Слово Канеру
Читайте багрепорты ваших сотрудников
Некоторые тест-менеджеры или руководители тестировщиков читают каждый багрепорт своих сотрудников (что несложно для группы из 7 человек, но это серьезное испытание, если в группе 30 сотрудников). Это поможет разобраться в состоянии продукта, узнать о сильных стороны и настроении сотрудников, о коммуникациях между ними и межличностных проблемах.
Для оценки качества работы сотрудников, вот несколько вопросов, которые можно задать относительно багрепорта:
- Хорошо ли он написан?
- Просто ли он определяет проблему?
- Он оставляет за собой дыры, которые повлекут последующее тестирование?
- Ошибку было сложно найти? Ошибка в стабильной части приложения? Она отражает удачу или упорство тестировщика, который ее нашел?
- Каков тон доклада?
- Будет ли отчет понятен программисту? Как программист прокомментировал репорт? Значит ли это, что программист и тестировщик сотрудничают или не смотрят друг на друга?
Слово Канеру
Читайте багрепорты ваших сотрудников
Некоторые тест-менеджеры или руководители тестировщиков читают каждый багрепорт своих сотрудников (что несложно для группы из 7 человек, но это серьезное испытание, если в группе 30 сотрудников). Это поможет разобраться в состоянии продукта, узнать о сильных стороны и настроении сотрудников, о коммуникациях между ними и межличностных проблемах.
Для оценки качества работы сотрудников, вот несколько вопросов, которые можно задать относительно багрепорта:
- Хорошо ли он написан?
- Просто ли он определяет проблему?
- Он оставляет за собой дыры, которые повлекут последующее тестирование?
- Ошибку было сложно найти? Ошибка в стабильной части приложения? Она отражает удачу или упорство тестировщика, который ее нашел?
- Каков тон доклада?
- Будет ли отчет понятен программисту? Как программист прокомментировал репорт? Значит ли это, что программист и тестировщик сотрудничают или не смотрят друг на друга?
вторник, 27 ноября 2012 г.
Lesson 211
Это ПЕАР.
У нас в городе грозит состояться круглый стол тестировщиков на тему: «нужны ли мы нам». Особенно приятно то, что инициатор не я.
Юля объявила его так:
В среду 28 ноября мы приглашаем прийти всех, кто занимается организацией процесса тестирования в Екатеринбурге. На семинаре не будет единого докладчика - мы просто поговорим о:
- Том, как построен процесс тестирования в разных компаниях и отделах,
- Почему это так (исторически сложилось или обусловлено какими-либо рациональными причинами)
- Что работает, а что нет
- С какими проблемами сталкивается тестировщик, работая в проектной команде, и какие есть пути преодоления
- Карьера тестировщика: откуда брать кадры и что делать с тем, чтобы они не уходили в системные аналитики :)
- Как можно сформировать сообщество тестировщиков Екатеринбурга, какие полезные мероприятия можно сделать. Расскажем, почему не получилась секция "Тестирование" в рамках конференции DUMP-2011 и можно ли что-то изменить в следующем году.
Мы не обещаем, что вы сможете узнать что-то новое на семинаре. Но приходите, если вам интересно то, в каком состоянии сейчас находится отрасль и каково положение тестировщиков в компаниях Екатеринбурга.
Дата: 28 ноября 2012 года
Место: Freelance cafe, ул 8 Марта 8/Д (ТЦ "МЫТНЫЙ ДВОР")
Вход: бесплатно по предварительной записи.
Время: c 19.00 до 22.00
Картинка для привлечения внимания:
Слово Канеру
Относитесь к сотрудникам как к руководителям.
Peter Drucker'а часто называют основателем современной теории управления. В одной из своих прекрасных книг «Эффективный руководитель», он учит, что руководитель это тот, кто управляет ценностью своего времени и влияет на способность организации работать. Most knowledge workers are executives. Drucker отмечает, что руководители всегда берут больше задач, чем, кажется, они могут сделать. Эффективные выбирают подмножество задач, которые они могут сделать хорошо и пропускают остальные. Неэффективные стараются сделать все, у них ничего не получается, и они не делают действительно хорошо почти все, что пытались делать. Разные руководители имеют разные сильные стороны и интересы. Дайте двум аналогичную работу (не задачу, а работу) и они покажут разную производительность.
Большинство тестировщиков — руководители в понимании Drucker's. Управляйте ими на основе этого. Не контролируйте их, как будто они фабричные рабочие, не тратьте свое время, пытаясь спроектировать работу подобно работе фабрики. Вместо этого управляйте людьми, которые имеют свои сильные и слабые стороны.
Когда мы это пишем не не просто говорим о старших тестировщиках. Когда мы создаем или управляем группой тестирования, мы нанимаем сочетания опыта и багажа. Новые тестировщики требуют более пристального внимания. Мы ждем, что вы будете вкладывать средства в обучение младшего персонала. Но наша цель в создании руководителей и мы показываем им, что уважаем обучение и самостоятельное мышление с первого дня. Мы ждем, что они быстро возьмут на себя ответственность, чтоб увидеть энтузиазм, to establish their credibility и развивать их навыки. Если они хотят найти менее требовательную работу, пусть ищут ее в другом месте.
У нас в городе грозит состояться круглый стол тестировщиков на тему: «нужны ли мы нам». Особенно приятно то, что инициатор не я.
Юля объявила его так:
В среду 28 ноября мы приглашаем прийти всех, кто занимается организацией процесса тестирования в Екатеринбурге. На семинаре не будет единого докладчика - мы просто поговорим о:
- Том, как построен процесс тестирования в разных компаниях и отделах,
- Почему это так (исторически сложилось или обусловлено какими-либо рациональными причинами)
- Что работает, а что нет
- С какими проблемами сталкивается тестировщик, работая в проектной команде, и какие есть пути преодоления
- Карьера тестировщика: откуда брать кадры и что делать с тем, чтобы они не уходили в системные аналитики :)
- Как можно сформировать сообщество тестировщиков Екатеринбурга, какие полезные мероприятия можно сделать. Расскажем, почему не получилась секция "Тестирование" в рамках конференции DUMP-2011 и можно ли что-то изменить в следующем году.
Мы не обещаем, что вы сможете узнать что-то новое на семинаре. Но приходите, если вам интересно то, в каком состоянии сейчас находится отрасль и каково положение тестировщиков в компаниях Екатеринбурга.
Дата: 28 ноября 2012 года
Место: Freelance cafe, ул 8 Марта 8/Д (ТЦ "МЫТНЫЙ ДВОР")
Вход: бесплатно по предварительной записи.
Время: c 19.00 до 22.00
Картинка для привлечения внимания:
 |
| Альбом: randompics4lj |
Слово Канеру
Относитесь к сотрудникам как к руководителям.
Peter Drucker'а часто называют основателем современной теории управления. В одной из своих прекрасных книг «Эффективный руководитель», он учит, что руководитель это тот, кто управляет ценностью своего времени и влияет на способность организации работать. Most knowledge workers are executives. Drucker отмечает, что руководители всегда берут больше задач, чем, кажется, они могут сделать. Эффективные выбирают подмножество задач, которые они могут сделать хорошо и пропускают остальные. Неэффективные стараются сделать все, у них ничего не получается, и они не делают действительно хорошо почти все, что пытались делать. Разные руководители имеют разные сильные стороны и интересы. Дайте двум аналогичную работу (не задачу, а работу) и они покажут разную производительность.
Большинство тестировщиков — руководители в понимании Drucker's. Управляйте ими на основе этого. Не контролируйте их, как будто они фабричные рабочие, не тратьте свое время, пытаясь спроектировать работу подобно работе фабрики. Вместо этого управляйте людьми, которые имеют свои сильные и слабые стороны.
Когда мы это пишем не не просто говорим о старших тестировщиках. Когда мы создаем или управляем группой тестирования, мы нанимаем сочетания опыта и багажа. Новые тестировщики требуют более пристального внимания. Мы ждем, что вы будете вкладывать средства в обучение младшего персонала. Но наша цель в создании руководителей и мы показываем им, что уважаем обучение и самостоятельное мышление с первого дня. Мы ждем, что они быстро возьмут на себя ответственность, чтоб увидеть энтузиазм, to establish their credibility и развивать их навыки. Если они хотят найти менее требовательную работу, пусть ищут ее в другом месте.
Lesson 210
Найдено в groovy скриптах группы АТ:
addSomeAttribute(METACLASS_FQN, 'Элемент справочника', 'catalogItem', 'true', 'false', 'false');
return 'И мы счастливы!';
Слово Канеру
Заурядность — самоисполняемое пророчество
- Если вы устраните творчество бесчеловечными процессами.
- Если ваша цель — сделать сотрудников шестеренками механизма
- Если вы стандартизируете работу персонала так, что каждый сможет делать то, что делают другие, таким же образом.
- Если вы оцениваете ваших сотрудников цифрами, не отражающими их творчество, суждения, чувства.
- Если вы отчуждаете сотрудников от результатов их работы, говорите им, что их работа — лишь сообщать об ошибках и кто-то другой будет решать, исправлять их или нет и не будете давать им слова на обсуждениях ошибок.
- Тогда не ждите от сотрудников, что они подарят вам свое сердце, когда это вам будет нужно.
- Не ждите, что они вслух скажут принципиально важное.
- Не ждите, что они будут работать по ночам, когда это будет необходимо проекту.
- Не ждите, что они разработают блестящие тесты для сложных, но критических ошибок.
- Не ждите, что они потеряют сон, пытаясь найти слова, чтоб объяснить критическую проблему менеджеру, которых их не понимает...
- И не ждите от них, что они будут лояльны вам или компании, когда это необходимо больше всего.
Если вы заявите, что в вашей компании вам не нужны герои, то они вам и не грозят.
Подробную информацию о том, что мы подразумеваем о героях см. Sims и Manz (1996) и Lebow (1990).
addSomeAttribute(METACLASS_FQN, 'Элемент справочника', 'catalogItem', 'true', 'false', 'false');
return 'И мы счастливы!';
Слово Канеру
Заурядность — самоисполняемое пророчество
- Если вы устраните творчество бесчеловечными процессами.
- Если ваша цель — сделать сотрудников шестеренками механизма
- Если вы стандартизируете работу персонала так, что каждый сможет делать то, что делают другие, таким же образом.
- Если вы оцениваете ваших сотрудников цифрами, не отражающими их творчество, суждения, чувства.
- Если вы отчуждаете сотрудников от результатов их работы, говорите им, что их работа — лишь сообщать об ошибках и кто-то другой будет решать, исправлять их или нет и не будете давать им слова на обсуждениях ошибок.
- Тогда не ждите от сотрудников, что они подарят вам свое сердце, когда это вам будет нужно.
- Не ждите, что они вслух скажут принципиально важное.
- Не ждите, что они будут работать по ночам, когда это будет необходимо проекту.
- Не ждите, что они разработают блестящие тесты для сложных, но критических ошибок.
- Не ждите, что они потеряют сон, пытаясь найти слова, чтоб объяснить критическую проблему менеджеру, которых их не понимает...
- И не ждите от них, что они будут лояльны вам или компании, когда это необходимо больше всего.
Если вы заявите, что в вашей компании вам не нужны герои, то они вам и не грозят.
Подробную информацию о том, что мы подразумеваем о героях см. Sims и Manz (1996) и Lebow (1990).
пятница, 23 ноября 2012 г.
Chapter 9
Ко вчерашнему опросу. Считаю, правильно - читать постановку полностью, составить себе модель функциональности и после этого смотреть реализацию. Иначе мы строим модель исходя из кода - а значит сложнее увидеть разницу между кодом и постановкой.
Провели очередную тест-сессию.
2 тестера, 2 стажера-тестера, я, аналитик, программист.
Самый суровый и правильный подход у программиста
Стажерам учить связи в системе до просветления.
Опытный тестер - это, мать его, опытный тестер. Дохрена интересных, годных кейсов.
И да, NullPointerException нашел только я.
В целом хорошо, ящетаю.
Слово Канеру
Управление группой тестирования
Эта глава посвящена проблемам управления группой тестирования. Разница между этой и предыдущей главой 8 «управление проектом тестирования»в том, что 8 глава сфокусирована на вопросах проекта. Как вы будете работать с другими членами команды разработки и прочими заинтересованными, чтоб выпустить продукт в срок и в рамках бюджета? А в этой главе мы рассмотрим группу людей, которые работают вместе от проекта к проекту, год за годом.
Choosing among our personal favorite lessons was difficult так как трое из нас имели большой опыт управления. Мы запускаем собственный бизнес и склонны писать длинные общие слова, обсуждая вопросы управления персоналом. Вместо этого мы предлагаем ссылки: Weinberg (1992, 1997a, 1997b, 1997c, 1998, and 2001), Humphrey (1997), Deming (1986), DeMarco (1997), DeMarco и Lister (1999), Brooks (1995), Constantine (1995), Black (1999), Drucker (1985), and Wiegers (1996). Вы смогли бы найти общие уроки в них, особенно в плане рекрутинга. Мы включили их потому, что мы получаем много вопросов о найме и о поиске работы, и обсуждение управления людьми было бы неполным без освещения этих вопросов.
Провели очередную тест-сессию.
2 тестера, 2 стажера-тестера, я, аналитик, программист.
Самый суровый и правильный подход у программиста
Стажерам учить связи в системе до просветления.
Опытный тестер - это, мать его, опытный тестер. Дохрена интересных, годных кейсов.
И да, NullPointerException нашел только я.
В целом хорошо, ящетаю.
Слово Канеру
Управление группой тестирования
Эта глава посвящена проблемам управления группой тестирования. Разница между этой и предыдущей главой 8 «управление проектом тестирования»в том, что 8 глава сфокусирована на вопросах проекта. Как вы будете работать с другими членами команды разработки и прочими заинтересованными, чтоб выпустить продукт в срок и в рамках бюджета? А в этой главе мы рассмотрим группу людей, которые работают вместе от проекта к проекту, год за годом.
Choosing among our personal favorite lessons was difficult так как трое из нас имели большой опыт управления. Мы запускаем собственный бизнес и склонны писать длинные общие слова, обсуждая вопросы управления персоналом. Вместо этого мы предлагаем ссылки: Weinberg (1992, 1997a, 1997b, 1997c, 1998, and 2001), Humphrey (1997), Deming (1986), DeMarco (1997), DeMarco и Lister (1999), Brooks (1995), Constantine (1995), Black (1999), Drucker (1985), and Wiegers (1996). Вы смогли бы найти общие уроки в них, особенно в плане рекрутинга. Мы включили их потому, что мы получаем много вопросов о найме и о поиске работы, и обсуждение управления людьми было бы неполным без освещения этих вопросов.
четверг, 22 ноября 2012 г.
Lesson 209
Тестеры, есть вопрос.
Вам дали постановку, небольшая юзерстори/фича, 1-3 часа тестирования, 2 экрана постановки.
Ваше мнение очень важно для меня.
Слово Канеру
В полезном отчете по релизу перечислены 10 худших проблем, которые смогут найти критики.
Представьте, что вы выпускаете ПО для продажи. Перечислите 10 наихудших вещей, которые смогут сказать о нем рецензенты. Если проблемы достаточно серьезны, маркетологи компании (или другие сотрудники) могут задержать релиз. Это будет наиболее полезная оценка качества, которую вы можете предоставить (Заметим, что такой подход позволяет говорить с позиции критика ПО, не пытающегося дать объективную картину качества).
Вам дали постановку, небольшая юзерстори/фича, 1-3 часа тестирования, 2 экрана постановки.
Ваше мнение очень важно для меня.
Слово Канеру
В полезном отчете по релизу перечислены 10 худших проблем, которые смогут найти критики.
Представьте, что вы выпускаете ПО для продажи. Перечислите 10 наихудших вещей, которые смогут сказать о нем рецензенты. Если проблемы достаточно серьезны, маркетологи компании (или другие сотрудники) могут задержать релиз. Это будет наиболее полезная оценка качества, которую вы можете предоставить (Заметим, что такой подход позволяет говорить с позиции критика ПО, не пытающегося дать объективную картину качества).
среда, 21 ноября 2012 г.
Lesson 208
Коллеги, кто-нибудь на проектах вообще делает еженедельник "статус продукта"?
Что в него пишете, что нет?
Или унылыми круговыми диаграммами jira дашбордиков перебиваетесь?
Слово Канеру
В финальном отчете по релизу укажите список неисправленных дефектов
Если вы готовите (или помогаете готовить) окончательный отчет по релизу, вы должны включить в него список неисправленных ошибок. Также включите отклоненные issue по архитектуре, которые вы считаете важными. Распространите этот список заранее, чтоб финальный отчет не содержал сюрпризов.
Что в него пишете, что нет?
Или унылыми круговыми диаграммами jira дашбордиков перебиваетесь?
Слово Канеру
В финальном отчете по релизу укажите список неисправленных дефектов
Если вы готовите (или помогаете готовить) окончательный отчет по релизу, вы должны включить в него список неисправленных ошибок. Также включите отклоненные issue по архитектуре, которые вы считаете важными. Распространите этот список заранее, чтоб финальный отчет не содержал сюрпризов.
вторник, 20 ноября 2012 г.
Lesson 207
Слово Канеру
Если вы пишете отчет по релизу, описывайте проделанную работу по тестированию и ее результаты, а не ваше мнение о продукте.
Группе тестирования сложно оценить общее качество продукта и то, как он будет продвигаться на рынке. У вас нет соответствующих данных. У вас есть сообщения об ошибке и попытки эти ошибки найти (тесты, которые продукт прошел). Опишите то, что знаете.
Если вы пишете отчет по релизу, описывайте проделанную работу по тестированию и ее результаты, а не ваше мнение о продукте.
Группе тестирования сложно оценить общее качество продукта и то, как он будет продвигаться на рынке. У вас нет соответствующих данных. У вас есть сообщения об ошибке и попытки эти ошибки найти (тесты, которые продукт прошел). Опишите то, что знаете.
Lesson 206
Намедни прошел очередной слет сотрудников компании, чтоб отдохнуть, рассказать друг другу доклады и всяко пообщаться в кулуарах.
Было ок.
Отдельно хочу отметитьняшныхручных тестировщиц которые с моего полпинка таки сделали доклад. В связи с чем процитирую организатора мероприятия:
Напишу-ка я про этот доклад много букв :)
Еще лет пять назад, когда мы нанимали тестировщиков, мы делали это в предположении, что вообще работа эта не очень квалифицированная (то есть большого ума не требует), но хороший старт в компании. Человек потестирует годик, а потом мы его (ну, чаще всего, ее:) переквалифицируем в аналитики или в менеджмент какой-нибудь. Ну, или в декрет проводим :) И, в общем-то, это устраивало обе стороны.
А теперь ситуация изменилась. Тестировщики стали хотеть заниматься тестированием и QA. В эту профессию приходят очень неглупые люди. С амбициями. Они активно учатся. У них получается. Они достигают в этом деле очень неплохого уровня в среднем, а кое-кто уже считает себя гуру :)
Теперь вопрос: а готова ли компания вообще и руководители разработки в частности к такому развитию событий?
Ну вот. Если бы не часть доклада под кодовым названием "откровения гуру", то я бы не смог написать эти "много букв" :)
Заемечательно ящетаю.
А выступать мы все еще подучимся, чо.
Слово Канеру
Подписывайтесь под тем, что тестирование продукта вас удовлетворяет.
Если кто-то настаивает на том, чтоб вы подписались под релизом продукта (форма, позволяющая менеджеру проекта выпустить продукт в производство или начать использовать ПО), сделайте так, чтоб всем было ясно, что ваша подпись значит, что вы адекватно проверили продукт (по вашему мнению), выполнили тестирование на согласованном уровне, ваша группа сделала хорошую работу за отведенное время. Вы могли бы пояснить это в дополнении (для руководителя проекта и команды) или разъяснить под вашей подписью.
Было ок.
Отдельно хочу отметить
Напишу-ка я про этот доклад много букв :)
Еще лет пять назад, когда мы нанимали тестировщиков, мы делали это в предположении, что вообще работа эта не очень квалифицированная (то есть большого ума не требует), но хороший старт в компании. Человек потестирует годик, а потом мы его (ну, чаще всего, ее:) переквалифицируем в аналитики или в менеджмент какой-нибудь. Ну, или в декрет проводим :) И, в общем-то, это устраивало обе стороны.
А теперь ситуация изменилась. Тестировщики стали хотеть заниматься тестированием и QA. В эту профессию приходят очень неглупые люди. С амбициями. Они активно учатся. У них получается. Они достигают в этом деле очень неплохого уровня в среднем, а кое-кто уже считает себя гуру :)
Теперь вопрос: а готова ли компания вообще и руководители разработки в частности к такому развитию событий?
Ну вот. Если бы не часть доклада под кодовым названием "откровения гуру", то я бы не смог написать эти "много букв" :)
За
А выступать мы все еще подучимся, чо.
Слово Канеру
Подписывайтесь под тем, что тестирование продукта вас удовлетворяет.
Если кто-то настаивает на том, чтоб вы подписались под релизом продукта (форма, позволяющая менеджеру проекта выпустить продукт в производство или начать использовать ПО), сделайте так, чтоб всем было ясно, что ваша подпись значит, что вы адекватно проверили продукт (по вашему мнению), выполнили тестирование на согласованном уровне, ваша группа сделала хорошую работу за отведенное время. Вы могли бы пояснить это в дополнении (для руководителя проекта и команды) или разъяснить под вашей подписью.
пятница, 16 ноября 2012 г.
Lesson 205
Слово Канеру
Не подписывайте разрешение на выпуск продукта.
Пусть менеджер продукта или проектной группы решает, когда выпускать продукт. Ваша задача — убедиться в том, что они имеют всю информацию (в лучшем виде, который может обеспечить тестирование) для принятия решения. Сообщайте о своих выводах честно, напрямую, точно и каждой заинтересованной стороне. Если они решат выпустить продукт, то что бы вы не сделали, это их выбор.
Не подписывайте разрешение на выпуск продукта.
Пусть менеджер продукта или проектной группы решает, когда выпускать продукт. Ваша задача — убедиться в том, что они имеют всю информацию (в лучшем виде, который может обеспечить тестирование) для принятия решения. Сообщайте о своих выводах честно, напрямую, точно и каждой заинтересованной стороне. Если они решат выпустить продукт, то что бы вы не сделали, это их выбор.
Lesson 204
И сам не заметил как перевалил за вторую сотню...
Надеюсь, до лета успею перевести все.
Слово Канеру
Поэтапные отчеты полезны, когда этапы четко определены.
Некоторые компании ведут свои проекты по этапам и делают тщательную оценку статуса продукта на каждом этапе. Другие этого не делают.
Если ваша компания хочет оценок продукта на каждом этапе, вы должны понимать минусы такой оценки. Каким образом компания определяет этапы? Какие аспекты этапов стоит сравнивать? Например, если определение этапа гласит, что 50% фич закодированы, вы должны иметь возможность определить так ли это. Каким образом вы это сделаете?
Если в вашей компании нет стандартного определения этапа, вы не можете определенно сказать, что, например, продукт готов к бета- тестированию. Ваше суждение, при отсутствии стандартов компании, будет скорее предпосылкой к политической склоке.
Если вас попросили оценить прогресс относительно этапа у которого нет определения, мы предполагаем, что вы добьетесь от руководства согласия с определением и лишь затем дадите оценку относительно него. Если у вас просят совета по определению этапа, то можно сделать предположение, что этап это завершение итерации. Каковы критерии ее завершения? ( или каковы критерии начала следующей итерации?) Работа Lawrence и Johnson's (1998) в этом плане очень полезна и распространяется бесплатно.
См. http://www.coyotevalley.com/plc/builder.htm -полезные примеры подобных определений. Мы не считаем их «правильными» и мы не думаем, что Lawrence или Johnson считают их «правильными». Они лишь иллюстрируют критерии, которые могут быть применимы для определения этапов и которые являются хорошей отправной точкой для компаний, которые находятся на этапе создания своих определений.
Надеюсь, до лета успею перевести все.
Слово Канеру
Поэтапные отчеты полезны, когда этапы четко определены.
Некоторые компании ведут свои проекты по этапам и делают тщательную оценку статуса продукта на каждом этапе. Другие этого не делают.
Если ваша компания хочет оценок продукта на каждом этапе, вы должны понимать минусы такой оценки. Каким образом компания определяет этапы? Какие аспекты этапов стоит сравнивать? Например, если определение этапа гласит, что 50% фич закодированы, вы должны иметь возможность определить так ли это. Каким образом вы это сделаете?
Если в вашей компании нет стандартного определения этапа, вы не можете определенно сказать, что, например, продукт готов к бета- тестированию. Ваше суждение, при отсутствии стандартов компании, будет скорее предпосылкой к политической склоке.
Если вас попросили оценить прогресс относительно этапа у которого нет определения, мы предполагаем, что вы добьетесь от руководства согласия с определением и лишь затем дадите оценку относительно него. Если у вас просят совета по определению этапа, то можно сделать предположение, что этап это завершение итерации. Каковы критерии ее завершения? ( или каковы критерии начала следующей итерации?) Работа Lawrence и Johnson's (1998) в этом плане очень полезна и распространяется бесплатно.
См. http://www.coyotevalley.com/plc/builder.htm -полезные примеры подобных определений. Мы не считаем их «правильными» и мы не думаем, что Lawrence или Johnson считают их «правильными». Они лишь иллюстрируют критерии, которые могут быть применимы для определения этапов и которые являются хорошей отправной точкой для компаний, которые находятся на этапе создания своих определений.
Lesson 203
Кстати, уроки Канера сугубо вовремя, запилил у нас еженедельник "статус продукта", уже было 2 выпуска ограниченным тиражом, посмотрим, взлетит или нет.
Слово Канеру
Дашборд проекта — еще один полезный способ показать статус проекта.
Дашборд это график на большой доске в конференц-зале, открытом для всех — команды проекта и всех кто в нем заинтересован. Он показывает состояние проекта, которое можно охватить одним взглядом (см. Bach 1999b для дальнейшего обсуждения).
На типичном дашборде перечислены лишь несколько направлений или областей работы. Даже на большие доски не может поместиться все, если вы, конечно, хотите, чтоб текст был читаемым. Для каждой области на доске показаны текущие направления работы, планируемое покрытие, текущее покрытие, оценка качества тестировщиками (высокое, среднее, низкое). Также есть место для ключевых комментариев тестировщиков относительно оценки.
Обычно дашборд обновляется раз в неделю в начале проекта, а затем каждый день или даже дважды в день по мере приближения даты окончания проекта. Он должен быть в достаточной степени актуален, чтоб менеджеры могли получать необходимую информацию.
Конкретная информация на нем меняется от компании к компании. Некоторые хотят, чтоб была подробная информация о каждой области, или определенное место на доске было зарезервировано для статуса продукта или ключевых фич недели.
Точные макеты не имеют значения, смысл в том, чтоб статус продукта был виден с первого взгляда.
Слово Канеру
Дашборд проекта — еще один полезный способ показать статус проекта.
Дашборд это график на большой доске в конференц-зале, открытом для всех — команды проекта и всех кто в нем заинтересован. Он показывает состояние проекта, которое можно охватить одним взглядом (см. Bach 1999b для дальнейшего обсуждения).
На типичном дашборде перечислены лишь несколько направлений или областей работы. Даже на большие доски не может поместиться все, если вы, конечно, хотите, чтоб текст был читаемым. Для каждой области на доске показаны текущие направления работы, планируемое покрытие, текущее покрытие, оценка качества тестировщиками (высокое, среднее, низкое). Также есть место для ключевых комментариев тестировщиков относительно оценки.
Обычно дашборд обновляется раз в неделю в начале проекта, а затем каждый день или даже дважды в день по мере приближения даты окончания проекта. Он должен быть в достаточной степени актуален, чтоб менеджеры могли получать необходимую информацию.
Конкретная информация на нем меняется от компании к компании. Некоторые хотят, чтоб была подробная информация о каждой области, или определенное место на доске было зарезервировано для статуса продукта или ключевых фич недели.
Точные макеты не имеют значения, смысл в том, чтоб статус продукта был виден с первого взгляда.
 |
| Альбом: office |
четверг, 15 ноября 2012 г.
Lesson 202
Слово Канеру
Вот примерная структура еженедельного отчета о состоянии продукта
Представьте себе четырехстраничный документ, на первой странице которрого перечислены такие ключевые вопросы, как:
- Необходимые решения Например, как мы должны расставить приоритеты фич, какое оборудование для тестирование нам необходимо, нам нужен новый сотрудник или нет?
- Ошибки, которые нужно исправить Все, что мешает вашей работе должно быть закреплено с высоким приоритетом
- Ожидаемые события (например, обещанные документы, оборудования, фичи, инструменты) и сроки этих событий. Они появляются в списке до наступления срока и остаются после того, как были просрочены. Удаляйте все произошедшие события. Это список того, чего еще нет, а не общий список работ. Выделите то, что задерживает вашу работу, например доступ к оборудованию, создание фичи и т.п..
- Неожиданные проблемы например отчет о снижении эффективности тестирования из за текучки кадров, неработоспособность ключевого инструмента, необходимость обучения людей и так далее.
Вторая страница описывает прогресс вашей группы в работе над запланированными задачами. Например, вы могли бы перечислить области, которые вы тестируете, сколько времени вы на них заложили, чего достигли в каждой из них, сколько уже потратили времени на работу. Например, вы потратили 10% бюджета двухнедельного тестирования и отстаете от графика. Этим списком вы передаете общее впечатление от прогресса (или его отсутствия) в отношении плана и графика.
Третья страница представляет собой статистику по ошибкам. Мы оставляем ее на третьей странице по той же причине, что газеты помещают спортивную статистику не на первой странице. Спортивные секции — самые читаемые части газеты. Если вы поместите статистику по дефектам внутрь то оставите первую страницу для новостей, которые вы считаете важными.
На последней странице перечислены ошибки, которые были отложены на этой неделе. Список, скорее всего, будет включать только номер ошибки, заголовок и приоритет. Подробную информацию читатель увидит в баг-трекере.
Вот примерная структура еженедельного отчета о состоянии продукта
Представьте себе четырехстраничный документ, на первой странице которрого перечислены такие ключевые вопросы, как:
- Необходимые решения Например, как мы должны расставить приоритеты фич, какое оборудование для тестирование нам необходимо, нам нужен новый сотрудник или нет?
- Ошибки, которые нужно исправить Все, что мешает вашей работе должно быть закреплено с высоким приоритетом
- Ожидаемые события (например, обещанные документы, оборудования, фичи, инструменты) и сроки этих событий. Они появляются в списке до наступления срока и остаются после того, как были просрочены. Удаляйте все произошедшие события. Это список того, чего еще нет, а не общий список работ. Выделите то, что задерживает вашу работу, например доступ к оборудованию, создание фичи и т.п..
- Неожиданные проблемы например отчет о снижении эффективности тестирования из за текучки кадров, неработоспособность ключевого инструмента, необходимость обучения людей и так далее.
Вторая страница описывает прогресс вашей группы в работе над запланированными задачами. Например, вы могли бы перечислить области, которые вы тестируете, сколько времени вы на них заложили, чего достигли в каждой из них, сколько уже потратили времени на работу. Например, вы потратили 10% бюджета двухнедельного тестирования и отстаете от графика. Этим списком вы передаете общее впечатление от прогресса (или его отсутствия) в отношении плана и графика.
Третья страница представляет собой статистику по ошибкам. Мы оставляем ее на третьей странице по той же причине, что газеты помещают спортивную статистику не на первой странице. Спортивные секции — самые читаемые части газеты. Если вы поместите статистику по дефектам внутрь то оставите первую страницу для новостей, которые вы считаете важными.
На последней странице перечислены ошибки, которые были отложены на этой неделе. Список, скорее всего, будет включать только номер ошибки, заголовок и приоритет. Подробную информацию читатель увидит в баг-трекере.
четверг, 8 ноября 2012 г.
Lesson 201
Наташа, как всегда, прекрасна.
Ее доклад, как обычно, не очень.
«Неполиткорректный рассказ про подбор тестировщиков»
http://www.slideshare.net/NatalyaRukol/itbrunch-14563527
Слово Канеру
Используй систему сбалансированных показателей, докладывая о статусе нескольких направлений.
Сбалансированные системы показателей часто используются для оценки здоровья бизнеса (Kaplan и Norton 1996, но см. Austin 1996). Простых метрик недостаточно.
- Например, если вы сосредоточитесь на квартальной прибыли, то скорее всего, будете поощрять поведение, максимизирующее ее. В краткосрочной перспективе, вы повысите прибыль, пожертвовав исследованиями и работой с людьми. Компания будет делать прибыль два года, а затем обанкротится, так как у нее не будет ничего нового, чтоб продать.
- Вместо этого, возможно, вы захотите подсчитать количество новых патентов, но эта дорога ведет к чрезмерным инвестициям в исследования и недостаточным — в создание товара.
Несколько различных метрик могут нести полезную информацию о состоянии бизнеса, но каждая из них, рассматриваемая в отрыве от остальных может нанести вред и привести к побочным эффектам. Ключевая цель измерений — обсудить их и побудить людей улучшить показатели, поэтому люди, которые делают свою работу хорошо найдут способы увеличить счет. И их методы могут быть не теми, которые предполагал создатель метрик. Например, увольнение научных сотрудников для повышения краткосрочной прибыли может быть не тем, чего ждет человек, добивавшийся роста квартальной прибыли. Но это может быть хорошим ответом на требование ее увеличить.
Возможным решением проблемы эффекта измерения является использование нескольких измерений, уравновешивающих побочные эффекты. Например система показателей, сообщающая о краткосрочной прибыли, количестве патентов, текучке кадров выделит неудачи в исследованиях при наличии краткосрочной прибыли.
Хорошо сбалансированная система показателей может стать объективным критерием здоровья бизнеса, хотя ни один из ее компонентов не может считаться справедливым или безопасным.
Мы считаем, что эти же рассуждения можно применить к прогрессу проекта и процессу тестирования. Вы могли бы измерять прогресс по следующим показателям:
- Какая часть продукта протестирована?
- Какая часть запланированных тестов проведена?
- Какая часть обнаруженных проблем не решена?
- Уверены ли мы в качестве тестирования (мы должны сомневаться в качестве тестирования, если бета-тестеры находят грубые ошибки, которые пропустили тестировщики)?
- Сколько работ по тестированию блокируется из за неисправленных дефектов, отсутствия оборудования или решения?
Хороший отчет о статусе использует показатели каждого типа. Информация, которую они предоставляют, не вписывается в одно простое число. Но суммой показателей можно руководствоваться при принятии решения.
Ее доклад, как обычно, не очень.
«Неполиткорректный рассказ про подбор тестировщиков»
http://www.slideshare.net/NatalyaRukol/itbrunch-14563527
Слово Канеру
Используй систему сбалансированных показателей, докладывая о статусе нескольких направлений.
Сбалансированные системы показателей часто используются для оценки здоровья бизнеса (Kaplan и Norton 1996, но см. Austin 1996). Простых метрик недостаточно.
- Например, если вы сосредоточитесь на квартальной прибыли, то скорее всего, будете поощрять поведение, максимизирующее ее. В краткосрочной перспективе, вы повысите прибыль, пожертвовав исследованиями и работой с людьми. Компания будет делать прибыль два года, а затем обанкротится, так как у нее не будет ничего нового, чтоб продать.
- Вместо этого, возможно, вы захотите подсчитать количество новых патентов, но эта дорога ведет к чрезмерным инвестициям в исследования и недостаточным — в создание товара.
Несколько различных метрик могут нести полезную информацию о состоянии бизнеса, но каждая из них, рассматриваемая в отрыве от остальных может нанести вред и привести к побочным эффектам. Ключевая цель измерений — обсудить их и побудить людей улучшить показатели, поэтому люди, которые делают свою работу хорошо найдут способы увеличить счет. И их методы могут быть не теми, которые предполагал создатель метрик. Например, увольнение научных сотрудников для повышения краткосрочной прибыли может быть не тем, чего ждет человек, добивавшийся роста квартальной прибыли. Но это может быть хорошим ответом на требование ее увеличить.
Возможным решением проблемы эффекта измерения является использование нескольких измерений, уравновешивающих побочные эффекты. Например система показателей, сообщающая о краткосрочной прибыли, количестве патентов, текучке кадров выделит неудачи в исследованиях при наличии краткосрочной прибыли.
Хорошо сбалансированная система показателей может стать объективным критерием здоровья бизнеса, хотя ни один из ее компонентов не может считаться справедливым или безопасным.
Мы считаем, что эти же рассуждения можно применить к прогрессу проекта и процессу тестирования. Вы могли бы измерять прогресс по следующим показателям:
- Какая часть продукта протестирована?
- Какая часть запланированных тестов проведена?
- Какая часть обнаруженных проблем не решена?
- Уверены ли мы в качестве тестирования (мы должны сомневаться в качестве тестирования, если бета-тестеры находят грубые ошибки, которые пропустили тестировщики)?
- Сколько работ по тестированию блокируется из за неисправленных дефектов, отсутствия оборудования или решения?
Хороший отчет о статусе использует показатели каждого типа. Информация, которую они предоставляют, не вписывается в одно простое число. Но суммой показателей можно руководствоваться при принятии решения.
Lesson 200
И о политике.
Было плохо им обоим менее полмесяца, а потом Иван просрался, а Сергей повесился. ЧиЖ «Диалог»
Слово Канеру
Чем более независимые измерители покрытия вы используете, тем больше вы знаете.
У вас есть возможность измерить протестированность продукта во многих аспектах: ошибки, требования, код, конфигурации, история изменений, разработчики, тестировщики, данные и так далее. Ни одно измерение не является достаточным
Например, часто рекомендуют измерять процент строк кода (линии, ветви или другие варианты) которые выполнялись во время тестирования.
Вместе с количеством ошибок, покрытие строк кода считается полезным для демонстрации того, как далеко вы находитесь от полного покрытия. Если вы проверили только 10% строк кода, вы не должны иметь уверенность в надежности ПО. Но когда вы получили 100% покрытие - это не значит, что вы близки к релизу. Это значит, что согласно этому измерению, продукт недалеко от релиза. (See Marick 1999 для дополнительных комментариев по этому показателю)
Предположим, что вы разрабатываете продукт для массового рынка. Вы решили проверить его на десятках различных версий Windows, под десятью разными браузерами, использующих 10 разных видов соединений (модемы с разной скоростью, Ethernet и т. д.), и так для нескольких других значений переменных конфигурации. Программа должна быть совместима со всем и протестирована на все сто.
- После того, как вы проверили продукт на первых нескольких конфигурациях запущенные тесты уже не смогут выполнить ни одну лишнюю строку или ветку кода. Если мы считаем, что строки кода являются мерой полноты тестирования, то нам нужно отменить конфигурационное тестирование. Это решение, вероятно, было бы губительным для массового рынка.
- Если существуют 100 конфигураций, а вы проверили 30 из них, то у вас есть еще одна метрика покрытия, не зависящая от строк кода, но по-прежнему важная. Вы протестировали 30 процентов конфигураций.
Метрики покрытия включают отношения набора тестов данного типа, которые вы проводите ко всем возможным тестам данного типа. Вы могли бы измерять покрытие количеством выполненных тестов по отношению к тестам, которые вы планировали выполнить в сравнении с общим количеством тестов, которые были бы вам интересны.
Любой процент может быть полезен. Ни один из них не измеряет что-то большее, чем ваш прогресс по какому-либо измерению, будь то линии кода, проверенные конфигурации, потоки, риски (деление на ноль, ошибка заключается в отсутствии кода для перехвата) или что-либо иное. Вы можете придумать сотни измерений для каждого класса отказов (Kaner 1995a and 2000a).
Даже это является упрощением. Один наш обозреватель, Noel Nyman, объяснил: «Это значит, что все наши тесты имеют равную стоимость, равную единице. Тесты, так же как и дефекты, имеют разную критичность, время выполнения. We may have run 80% of our tests and still have 50% of our most important tests remaining to be done. Любая метрика, игнорирующая это и говорящая о полном покрытии дает недостоверную информацию, а следовательно, ложные надежды.»
Было плохо им обоим менее полмесяца, а потом Иван просрался, а Сергей повесился. ЧиЖ «Диалог»
Слово Канеру
Чем более независимые измерители покрытия вы используете, тем больше вы знаете.
У вас есть возможность измерить протестированность продукта во многих аспектах: ошибки, требования, код, конфигурации, история изменений, разработчики, тестировщики, данные и так далее. Ни одно измерение не является достаточным
Например, часто рекомендуют измерять процент строк кода (линии, ветви или другие варианты) которые выполнялись во время тестирования.
Вместе с количеством ошибок, покрытие строк кода считается полезным для демонстрации того, как далеко вы находитесь от полного покрытия. Если вы проверили только 10% строк кода, вы не должны иметь уверенность в надежности ПО. Но когда вы получили 100% покрытие - это не значит, что вы близки к релизу. Это значит, что согласно этому измерению, продукт недалеко от релиза. (See Marick 1999 для дополнительных комментариев по этому показателю)
Предположим, что вы разрабатываете продукт для массового рынка. Вы решили проверить его на десятках различных версий Windows, под десятью разными браузерами, использующих 10 разных видов соединений (модемы с разной скоростью, Ethernet и т. д.), и так для нескольких других значений переменных конфигурации. Программа должна быть совместима со всем и протестирована на все сто.
- После того, как вы проверили продукт на первых нескольких конфигурациях запущенные тесты уже не смогут выполнить ни одну лишнюю строку или ветку кода. Если мы считаем, что строки кода являются мерой полноты тестирования, то нам нужно отменить конфигурационное тестирование. Это решение, вероятно, было бы губительным для массового рынка.
- Если существуют 100 конфигураций, а вы проверили 30 из них, то у вас есть еще одна метрика покрытия, не зависящая от строк кода, но по-прежнему важная. Вы протестировали 30 процентов конфигураций.
Метрики покрытия включают отношения набора тестов данного типа, которые вы проводите ко всем возможным тестам данного типа. Вы могли бы измерять покрытие количеством выполненных тестов по отношению к тестам, которые вы планировали выполнить в сравнении с общим количеством тестов, которые были бы вам интересны.
Любой процент может быть полезен. Ни один из них не измеряет что-то большее, чем ваш прогресс по какому-либо измерению, будь то линии кода, проверенные конфигурации, потоки, риски (деление на ноль, ошибка заключается в отсутствии кода для перехвата) или что-либо иное. Вы можете придумать сотни измерений для каждого класса отказов (Kaner 1995a and 2000a).
Даже это является упрощением. Один наш обозреватель, Noel Nyman, объяснил: «Это значит, что все наши тесты имеют равную стоимость, равную единице. Тесты, так же как и дефекты, имеют разную критичность, время выполнения. We may have run 80% of our tests and still have 50% of our most important tests remaining to be done. Любая метрика, игнорирующая это и говорящая о полном покрытии дает недостоверную информацию, а следовательно, ложные надежды.»
Lesson 199
Прекрасно, ящетаю. Обнаружил dibr в книге М.Н. Алова.
Про тестировщиков, обратно же. В какой-то степени.
знаменитый среди обитателей Дальнего Космоса экспериментальный десантный шлем DH24-11.
Шлем этот отличался обилием электронных устройств, реагирующих на мимику и движение глаз человека и, соответственно, очень высокими требованиями к человеческой мимике. Насколько мне известно, использование этих шлемов в космосе было запрещено, потому что все без исключения испытатели в ходе стендовых испытаний "условно погибли" из-за ошибок обращения с шлемом. Но часть испытателей тем не менее осталась сторонниками опасного новшества, мотивируя свою позицию словами типа "условно погиб я один раз, а условно выкрутился - раз десять". Противники убедительно отвечали в духе "погиб ты в ситуации, встречающейся чуть ли не каждый день, а выкручивался из ситуаций, которых в нормальной жизни не должно быть".
"Условно погиб в ситуации, случающейся каждый день" - это было мягко сказано. На самом деле поток "условных смертей" начался с подачи самого опытного из испытателей, Вандерхузе-старшего, который, в третьем своем воплощении оказался неожиданно ехиден. После победоносных испытаний типа "полет через лабиринт", "посадка во время урагана" и "кратер вулкана", Вандерхузе предложил "в скафандр попали муравьи", "Десантник неудержимо чихает" и "Десантник спешит в туалет" и превратил испытания в поток условных смертей и источник анекдотических ситуаций.
И еще:
- Климатическое кондиционирование на необитаемых планетах. Можно отгородить часть территории, скажем, четверть Марса и с помощью нескольких климатических установок создать земной климат. Защита от низкоэнергетических излучений, эээ... а также...
- Низкоэнергетические это?.. - начал вопрос Комов.
- Ну там от звезды, от ядерной бомбы, - махнул рукой Патрик.
Уж кто-кто, а Комов на излучения насмотрелся. И натерпелся. Его волновали лингвистические нюансы. Для физика-лазерщика энергия - это энергия пучка. Высокоэнергетическим лазером можно уничтожить город. А вот для ядерщика разделение высокоэнергетический - низкоэнергетический идет по энергии одной частицы. А одна частица даже и сверхвысокой энергии вполне безопасна. Волновики оказались ближе к ядерщикам. Низкоэнергетическими у них являются излучения звезд и ядерных бомб.
- А можно ли с помощью стоячей Волны укрыться от враждебной цивилизации? - продолжил Комов.
- Разве что от цивилизации докосмического периода. Максимум - от водородных бомб. У Волны хорошая проницаемость в длинноволновом диапазоне. Из опытов профессора Лю...
- Длинноволновый - это?
Слово Канеру
Будьте осторожны, измеряя прогресс проекта с точки зрения количества ошибок.
Количество дефектов — один из любимых показателей для измерения прогресса проекта. К сожалению, его часто недостаточно и он часто вводит в заблуждение.
Количество дефектов полезно для демонстрации того, как проект далек от релиза. Если команда проекта может исправлять 40 багов в неделю и 400 открытых ошибок должны быть исправлены до релиза, вы сможете привести убедительные доводы о том, что продукт не будет готов в ближайший месяц.
Количество дефектов бесполезно для демонстрации того, что проект близок к качеству, необходимому для релиза. Если количество открытых дефектов невелико это значит то, что продукт является стабильным или то, что команда тестирования тратит слишком много времени на написание отчетов, написание регрессионных тестов, которые находят слишком мало ошибок, демонстрацию продукта на выставках и другие виды деятельности, которые не ориентированы на поиск новых ошибок. Мы не сможем определить это по количеству ошибок.
Мы особенно огорчены статистическими моделями количества появляющихся ошибок (сколько ошибок найдено в единицу времени) в качестве инструментов управления проектами, так как у нас нет оснований считать, что предположения, лежащие в основе вероятностных моделей соответствуют реальности проекта. Simmonds (2000) дает четкое, недвусмысленное заявление о таких моделях. Hoffman (2000) дает несколько замечательных примеров фиаско таких моделей.
Про тестировщиков, обратно же. В какой-то степени.
знаменитый среди обитателей Дальнего Космоса экспериментальный десантный шлем DH24-11.
Шлем этот отличался обилием электронных устройств, реагирующих на мимику и движение глаз человека и, соответственно, очень высокими требованиями к человеческой мимике. Насколько мне известно, использование этих шлемов в космосе было запрещено, потому что все без исключения испытатели в ходе стендовых испытаний "условно погибли" из-за ошибок обращения с шлемом. Но часть испытателей тем не менее осталась сторонниками опасного новшества, мотивируя свою позицию словами типа "условно погиб я один раз, а условно выкрутился - раз десять". Противники убедительно отвечали в духе "погиб ты в ситуации, встречающейся чуть ли не каждый день, а выкручивался из ситуаций, которых в нормальной жизни не должно быть".
"Условно погиб в ситуации, случающейся каждый день" - это было мягко сказано. На самом деле поток "условных смертей" начался с подачи самого опытного из испытателей, Вандерхузе-старшего, который, в третьем своем воплощении оказался неожиданно ехиден. После победоносных испытаний типа "полет через лабиринт", "посадка во время урагана" и "кратер вулкана", Вандерхузе предложил "в скафандр попали муравьи", "Десантник неудержимо чихает" и "Десантник спешит в туалет" и превратил испытания в поток условных смертей и источник анекдотических ситуаций.
И еще:
- Климатическое кондиционирование на необитаемых планетах. Можно отгородить часть территории, скажем, четверть Марса и с помощью нескольких климатических установок создать земной климат. Защита от низкоэнергетических излучений, эээ... а также...
- Низкоэнергетические это?.. - начал вопрос Комов.
- Ну там от звезды, от ядерной бомбы, - махнул рукой Патрик.
Уж кто-кто, а Комов на излучения насмотрелся. И натерпелся. Его волновали лингвистические нюансы. Для физика-лазерщика энергия - это энергия пучка. Высокоэнергетическим лазером можно уничтожить город. А вот для ядерщика разделение высокоэнергетический - низкоэнергетический идет по энергии одной частицы. А одна частица даже и сверхвысокой энергии вполне безопасна. Волновики оказались ближе к ядерщикам. Низкоэнергетическими у них являются излучения звезд и ядерных бомб.
- А можно ли с помощью стоячей Волны укрыться от враждебной цивилизации? - продолжил Комов.
- Разве что от цивилизации докосмического периода. Максимум - от водородных бомб. У Волны хорошая проницаемость в длинноволновом диапазоне. Из опытов профессора Лю...
- Длинноволновый - это?
Слово Канеру
Будьте осторожны, измеряя прогресс проекта с точки зрения количества ошибок.
Количество дефектов — один из любимых показателей для измерения прогресса проекта. К сожалению, его часто недостаточно и он часто вводит в заблуждение.
Количество дефектов полезно для демонстрации того, как проект далек от релиза. Если команда проекта может исправлять 40 багов в неделю и 400 открытых ошибок должны быть исправлены до релиза, вы сможете привести убедительные доводы о том, что продукт не будет готов в ближайший месяц.
Количество дефектов бесполезно для демонстрации того, что проект близок к качеству, необходимому для релиза. Если количество открытых дефектов невелико это значит то, что продукт является стабильным или то, что команда тестирования тратит слишком много времени на написание отчетов, написание регрессионных тестов, которые находят слишком мало ошибок, демонстрацию продукта на выставках и другие виды деятельности, которые не ориентированы на поиск новых ошибок. Мы не сможем определить это по количеству ошибок.
Мы особенно огорчены статистическими моделями количества появляющихся ошибок (сколько ошибок найдено в единицу времени) в качестве инструментов управления проектами, так как у нас нет оснований считать, что предположения, лежащие в основе вероятностных моделей соответствуют реальности проекта. Simmonds (2000) дает четкое, недвусмысленное заявление о таких моделях. Hoffman (2000) дает несколько замечательных примеров фиаско таких моделей.
понедельник, 5 ноября 2012 г.
О рефлексии
О рефлексии пост.
Мир жутко сложен, нечернобел и описываем дифурами далеко не первого порядка.
Но.
Был такой эксперимент:
... пример моделирования борьбы автоматов за кормушки (программа автомата – съесть максимум корма; количество корма в кормушках и максимальное количество автоматов у каждой кормушки регламентировано). Автоматы нулевого уровня умеют учитывать только ситуацию (конфигурацию кормушек, число автоматов). Автоматы первого уровня учитывают кроме ситуации еще и предполагаемое поведение других автоматов (считая их автоматами нулевого уровня). Автоматы второго уровня учитывают поведение других автоматов, считая их автоматами первого уровня.
Результаты эксперимента: в большинстве случаев автоматы нулевого уровня проигрывают автоматам первого уровня, автоматы первого уровня – автоматам второго уровня. Но автоматы второго уровня проигрывают автоматам нулевого уровня. Иначе говоря, нужно быть рефлексивнее противника, но не намного – иначе рискуешь запутаться в собственных сетях.
К чему это я?
Если все вокруг дофига умные, необычные и непростые, то можно попробовать стать намного проще окружающих, позволить себе не рефлексирвать и видеть мир черно-белым.
Мир жутко сложен, нечернобел и описываем дифурами далеко не первого порядка.
Но.
Был такой эксперимент:
... пример моделирования борьбы автоматов за кормушки (программа автомата – съесть максимум корма; количество корма в кормушках и максимальное количество автоматов у каждой кормушки регламентировано). Автоматы нулевого уровня умеют учитывать только ситуацию (конфигурацию кормушек, число автоматов). Автоматы первого уровня учитывают кроме ситуации еще и предполагаемое поведение других автоматов (считая их автоматами нулевого уровня). Автоматы второго уровня учитывают поведение других автоматов, считая их автоматами первого уровня.
Результаты эксперимента: в большинстве случаев автоматы нулевого уровня проигрывают автоматам первого уровня, автоматы первого уровня – автоматам второго уровня. Но автоматы второго уровня проигрывают автоматам нулевого уровня. Иначе говоря, нужно быть рефлексивнее противника, но не намного – иначе рискуешь запутаться в собственных сетях.
К чему это я?
Если все вокруг дофига умные, необычные и непростые, то можно попробовать стать намного проще окружающих, позволить себе не рефлексирвать и видеть мир черно-белым.
суббота, 3 ноября 2012 г.
Lesson 198
Ненависть.
В последнее время бесят конструкции:
- Можно сделать X.
- Надо сделать Y.
- А давайте сделаем Z.
Бесит то, что после произнесения этих слов нихера не меняется.
Последний год босс учит вместо обезличенных конструкций использовать «Я сделаю». Последние полгода приучает к более сложным вида «Я сделаю к среде при этом не проебу остальное». С последними у меня как-то не очень, хех.
Да еще намечается проблема — формулировка «можно сделать» приобретает насмешливо иронический оттенок. Часто понимают неправильно.
Игра слов, игра смыслов, ага.
Отрывки из книги «Волоколамское шоссе»:
Устав Красной Армии предписывает командиру
говорить о своей части "я". "Я" командира - его солдаты.
Слово Канеру
Нет ничего более опасного, чем вице-президент со статистикой
Когда делаете отчет по статусу продукта (или проводите иные измерения), относитесь осторожно к тому, что вы считаете и с кем делитесь информацией. Топ-менеджеры, в частности, склонны к принятию решений на основании данных, которые они не понимают. По определению, измерение — тонкий срез всей картины. Любое измерение уменьшает всю картину до одной цифры и является грубым упрощением. Если вы понимаете контекст измерения, у вас есть надежда использовать результаты измерения продуктивно. Топ-менеджмент часто не в курсе этого контекста.
Мы рекомендуем вам поэкспериментировать с измерениями. Мы используем измерения для изучения продукта, чтоб изучить его качество. Руководители используют измерения(метрики) не для обучения, но в первую очередь для установления контроля над чем-то, чего они не понимают.
Это значит, вы не должны предоставлять информацию руководству? Это нереально во многих компаниях. Но вы могли бы быть более осторожными с тем, что рассказываете, мы могли бы предвидеть недоразумения и заранее обозначить проблемы или не предоставлять определенную информацию. Например:
- Не штурмуйте офис руководителей с информацией о том, что средний программист исправляет баг 1,4 недели, а Джо нужно для этого 5,3. After you volunteer individual performance data from the bug-tracking system, you'll be asked for a lot of it.
- Когда вы пишете, что вам потребуется по крайней мере 5 недель на исправление багов, так как у вас 200 открытых дефектов, а программисты исправляют по 40 багов в неделю, уточните, что этот расчет верен на больших числах, а когда число открытых дефектов невелико, то многие другие факторы проекта начинают иметь большое влияние на время до релиза.
- Когда вас просят о статистике на конкретных лиц (количество багов на тестировщика), говорите нет. Объясните, что как только вы начнете использовать баг-трекер для сбора информации о людях, характер данных в трекере изменится. Процесс сообщения об ошибке станет все более политизированным, состязательным и менее объективным.
В последнее время бесят конструкции:
- Можно сделать X.
- Надо сделать Y.
- А давайте сделаем Z.
Бесит то, что после произнесения этих слов нихера не меняется.
Последний год босс учит вместо обезличенных конструкций использовать «Я сделаю». Последние полгода приучает к более сложным вида «Я сделаю к среде при этом не проебу остальное». С последними у меня как-то не очень, хех.
Да еще намечается проблема — формулировка «можно сделать» приобретает насмешливо иронический оттенок. Часто понимают неправильно.
Игра слов, игра смыслов, ага.
Отрывки из книги «Волоколамское шоссе»:
Устав Красной Армии предписывает командиру
говорить о своей части "я". "Я" командира - его солдаты.
Слово Канеру
Нет ничего более опасного, чем вице-президент со статистикой
Когда делаете отчет по статусу продукта (или проводите иные измерения), относитесь осторожно к тому, что вы считаете и с кем делитесь информацией. Топ-менеджеры, в частности, склонны к принятию решений на основании данных, которые они не понимают. По определению, измерение — тонкий срез всей картины. Любое измерение уменьшает всю картину до одной цифры и является грубым упрощением. Если вы понимаете контекст измерения, у вас есть надежда использовать результаты измерения продуктивно. Топ-менеджмент часто не в курсе этого контекста.
Мы рекомендуем вам поэкспериментировать с измерениями. Мы используем измерения для изучения продукта, чтоб изучить его качество. Руководители используют измерения(метрики) не для обучения, но в первую очередь для установления контроля над чем-то, чего они не понимают.
Это значит, вы не должны предоставлять информацию руководству? Это нереально во многих компаниях. Но вы могли бы быть более осторожными с тем, что рассказываете, мы могли бы предвидеть недоразумения и заранее обозначить проблемы или не предоставлять определенную информацию. Например:
- Не штурмуйте офис руководителей с информацией о том, что средний программист исправляет баг 1,4 недели, а Джо нужно для этого 5,3. After you volunteer individual performance data from the bug-tracking system, you'll be asked for a lot of it.
- Когда вы пишете, что вам потребуется по крайней мере 5 недель на исправление багов, так как у вас 200 открытых дефектов, а программисты исправляют по 40 багов в неделю, уточните, что этот расчет верен на больших числах, а когда число открытых дефектов невелико, то многие другие факторы проекта начинают иметь большое влияние на время до релиза.
- Когда вас просят о статистике на конкретных лиц (количество багов на тестировщика), говорите нет. Объясните, что как только вы начнете использовать баг-трекер для сбора информации о людях, характер данных в трекере изменится. Процесс сообщения об ошибке станет все более политизированным, состязательным и менее объективным.
четверг, 1 ноября 2012 г.
Lesson 197
Вот такую хрень из желудей и спичек из тыквы с бабушкиного огорода сотворила @akahha
Запаса свечек у меня хватит на месяц, а сегодня еще посмотрю, есть ли светодиоды, да поярче. Будет из нашего окошка подмигивать прохожим.
Раз:
и два:
Слово Канеру
Регулярные отчеты о статусе продукта — мощный инструмент.
Реальная сила группы тестирования — коммуникативная, а не административная. Вы убеждаете людей дать вам необходимые ресурсы, чтоб выполнить работу, которая им нужна and to reconsider releasing unsatisfactory products to customers.
Отчеты о статусе продукта — мощный инструмент для того, чтоб донести ваши мысли. Вот несколько советов по максимизации своей власти.
- Всегда используйте ней тральный фактический тон. Воздержитесь от восклицательных знаков, больших букв, юмора.
- Избегайте индивидуализации. Говорите о результатах, ошибках и сроках, но фокусируйтесь на предметах, а не людях, с ними связанных.
- Примите стандартный формат, общий для всех проектов. Не делайте себя целью жалоб руководителя проекта (проект которого в беде) о том, что вы третируете его проект потому, что не любите его.
- Выпускайте отчет по расписанию. На ранних этапах проекта раз в две недели. Позже, можно будет выпускать раз в неделю. Ближе к концу проекта можно выпускать его ежедневно. Работайте с разными проектами по одному графику.
- Тщательно выбирайте содержание. Сохраняйте отчеты небольшими, упаковывайте информацию в несколько страниц.
- Распространяйте отчет за пределы проектной команды. Отправьте его боссу руководителя проекта, возможно даже боссу его босса. Отправьте его всем заинтересованным лицам компании. Менеджер проекта может возразить, что отчет слишком широко распространяется. Мы предлагаем два ответа: «Мы всегда рассылали подобные отчеты этим людям» или «Если этот отчет не подходит мистеру Х, пусть просто скажет нам об этом. Мы прекратим присылать ему отчет.»
Некоторые обозреватели отметили, что последний совет в определенных компаниях может быть опасен и контрпродуктивен. Мы понимаем, что в некоторых компаниях информационный поток носит ограниченный характер и руководители требуют больше прав для управления потоками информации. С другой стороны, ваша эффективность ограничена, если вы не можете проинформировать других участников проекта о проблемах, которые для себя открыли. Возможно, вам помогут эти советы:
- Если вы только вводите понятие отчетов о статусе продукта в вашей группе проекта, распространяйте отчет так широко, как позволяют вам возможности и смелость, с учетом культурных особенностей вашей компании. Используйте неофициальные каналы, чтоб как можно больше людей знали о существовании этих отчетов, пусть они просят менеджера проекта включить их в список рассылки. В конце-концов, если ваши отчеты полезны, у вас появится большой список людей, который вы сможете использовать в других проектах. В какой-то момент это станет корпоративной практикой. Именно в этот момент вы сможете позволить себе сказать руководителю проекта: «Мы всегда рассылали эти отчеты этим людям.»
- Если вы предоставляете сервис только одному руководителю проекта и не имеете больше обязанностей в компании, у вас нет оснований распространять эти отчеты за его спиной. С другой стороны, если вы можете быть привлечены к ответственности за недонесение информации о проблемах ключевым фигурам в компании, то вам открыт канал для передачи этих отчетов.
Запаса свечек у меня хватит на месяц, а сегодня еще посмотрю, есть ли светодиоды, да поярче. Будет из нашего окошка подмигивать прохожим.
Раз:
 |
| Альбом: home |
и два:
 |
| Альбом: home |
Слово Канеру
Регулярные отчеты о статусе продукта — мощный инструмент.
Реальная сила группы тестирования — коммуникативная, а не административная. Вы убеждаете людей дать вам необходимые ресурсы, чтоб выполнить работу, которая им нужна and to reconsider releasing unsatisfactory products to customers.
Отчеты о статусе продукта — мощный инструмент для того, чтоб донести ваши мысли. Вот несколько советов по максимизации своей власти.
- Всегда используйте ней тральный фактический тон. Воздержитесь от восклицательных знаков, больших букв, юмора.
- Избегайте индивидуализации. Говорите о результатах, ошибках и сроках, но фокусируйтесь на предметах, а не людях, с ними связанных.
- Примите стандартный формат, общий для всех проектов. Не делайте себя целью жалоб руководителя проекта (проект которого в беде) о том, что вы третируете его проект потому, что не любите его.
- Выпускайте отчет по расписанию. На ранних этапах проекта раз в две недели. Позже, можно будет выпускать раз в неделю. Ближе к концу проекта можно выпускать его ежедневно. Работайте с разными проектами по одному графику.
- Тщательно выбирайте содержание. Сохраняйте отчеты небольшими, упаковывайте информацию в несколько страниц.
- Распространяйте отчет за пределы проектной команды. Отправьте его боссу руководителя проекта, возможно даже боссу его босса. Отправьте его всем заинтересованным лицам компании. Менеджер проекта может возразить, что отчет слишком широко распространяется. Мы предлагаем два ответа: «Мы всегда рассылали подобные отчеты этим людям» или «Если этот отчет не подходит мистеру Х, пусть просто скажет нам об этом. Мы прекратим присылать ему отчет.»
Некоторые обозреватели отметили, что последний совет в определенных компаниях может быть опасен и контрпродуктивен. Мы понимаем, что в некоторых компаниях информационный поток носит ограниченный характер и руководители требуют больше прав для управления потоками информации. С другой стороны, ваша эффективность ограничена, если вы не можете проинформировать других участников проекта о проблемах, которые для себя открыли. Возможно, вам помогут эти советы:
- Если вы только вводите понятие отчетов о статусе продукта в вашей группе проекта, распространяйте отчет так широко, как позволяют вам возможности и смелость, с учетом культурных особенностей вашей компании. Используйте неофициальные каналы, чтоб как можно больше людей знали о существовании этих отчетов, пусть они просят менеджера проекта включить их в список рассылки. В конце-концов, если ваши отчеты полезны, у вас появится большой список людей, который вы сможете использовать в других проектах. В какой-то момент это станет корпоративной практикой. Именно в этот момент вы сможете позволить себе сказать руководителю проекта: «Мы всегда рассылали эти отчеты этим людям.»
- Если вы предоставляете сервис только одному руководителю проекта и не имеете больше обязанностей в компании, у вас нет оснований распространять эти отчеты за его спиной. С другой стороны, если вы можете быть привлечены к ответственности за недонесение информации о проблемах ключевым фигурам в компании, то вам открыт канал для передачи этих отчетов.
Lesson 196
tester: Сборка тестов на миграцию не проходит, удалили бекап, который мигрируем.
support: Ой, я удалил. Понимаешь, бекап назвался test_migration. Это для вас test означает тестирование, для остальных это что-то временное и неважное.
В тему сегодняшней лекции - с подачи бывшего падавана поставил себе Task Timer. И коллегам советую. Посмотрим, что получится.
Слово Канеру
Используйте журналы активности, чтоб показать перерывы в работе тестировщиков.
Если вы думаете, что вам не нужно защищать тестировщиков от прерываний, начните вести журнал активности в течении недели или двух. В журнал записывайте каждый телефонный звонок (время, когда вы его приняли), время чтения электронной почты и время написания ответов на нее, каждый раз, когда кто-то заглядывает к вам в кабинет (куб) с вопросом, шуткой или ручной гранатой. Каков самый длинный отрезок времени, который вы на самом деле были готовы посвятить планированию или тестированию? Есть ли у вас промежутки разумных размеров в течении дня или вы вынуждены приходить на работу очень рано или уходить очень поздно, чтоб найти время поработать? (Для подробного обсуждения дробления времени см. Weinberg 1992, 284.)
Если вы, тест-менеджер, работаете с тестировщиком у которого есть проблема с производительностью или кто-то слишком часто работает сверхурочно, чтоб выдерживать нагрузку, то журнал активности — хороший способ, чтоб помочь тестировщику (и вам, чтоб понять, как вы могли бы помочь тестировщику) сосредоточиться и определить приоритеты работы. Мы не рекомендуем вам использовать это в качестве инструмента поддержания дисциплины или в качестве официального инструмента оценки производительности. Для этого сходите в отдел кадров вашей компании и попросите конкретных советов. Мы утверждаем, что люди перегружены. Если вы менеджер человека, который кажется разбитым, то мы надеемся, что вы рассмотрите некоторые инструменты и вещи, которые вы могли бы сделать, чтоб помочь сотруднику сосредоточиться на текущих задачах и использовать время более эффективно, очистить его от ненужных задач. Журнал активности — один из таких инструментов.
support: Ой, я удалил. Понимаешь, бекап назвался test_migration. Это для вас test означает тестирование, для остальных это что-то временное и неважное.
В тему сегодняшней лекции - с подачи бывшего падавана поставил себе Task Timer. И коллегам советую. Посмотрим, что получится.
Слово Канеру
Используйте журналы активности, чтоб показать перерывы в работе тестировщиков.
Если вы думаете, что вам не нужно защищать тестировщиков от прерываний, начните вести журнал активности в течении недели или двух. В журнал записывайте каждый телефонный звонок (время, когда вы его приняли), время чтения электронной почты и время написания ответов на нее, каждый раз, когда кто-то заглядывает к вам в кабинет (куб) с вопросом, шуткой или ручной гранатой. Каков самый длинный отрезок времени, который вы на самом деле были готовы посвятить планированию или тестированию? Есть ли у вас промежутки разумных размеров в течении дня или вы вынуждены приходить на работу очень рано или уходить очень поздно, чтоб найти время поработать? (Для подробного обсуждения дробления времени см. Weinberg 1992, 284.)
Если вы, тест-менеджер, работаете с тестировщиком у которого есть проблема с производительностью или кто-то слишком часто работает сверхурочно, чтоб выдерживать нагрузку, то журнал активности — хороший способ, чтоб помочь тестировщику (и вам, чтоб понять, как вы могли бы помочь тестировщику) сосредоточиться и определить приоритеты работы. Мы не рекомендуем вам использовать это в качестве инструмента поддержания дисциплины или в качестве официального инструмента оценки производительности. Для этого сходите в отдел кадров вашей компании и попросите конкретных советов. Мы утверждаем, что люди перегружены. Если вы менеджер человека, который кажется разбитым, то мы надеемся, что вы рассмотрите некоторые инструменты и вещи, которые вы могли бы сделать, чтоб помочь сотруднику сосредоточиться на текущих задачах и использовать время более эффективно, очистить его от ненужных задач. Журнал активности — один из таких инструментов.
Подписаться на:
Сообщения (Atom)