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

Lesson 228

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


Слово Канеру

Не злоупотребляйте сверхурочными ваших сотрудников

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

Хроническая переработка ведет к выгоранию сотрудников, высокой текучести кадров, цинизму, политике, к небрежной и неэффективной работе. Мы призываем вас защитить персонал от всего этого.


Многим проектам нужна краткосрочная экстренная помощь в критические моменты. Это нормальная часть бизнеса. И это не то, о чем мы говорим. Помните, однако, что у сотрудников есть свой предел. У некоторых есть себейные обязательства или другие, которые могут не быть гибкими. Deal graciously with the reality of your situation.

У некоторых компаний и руководителей проектов хронически не хватает времени и они ждут, что их штат компенсирует разницу:
- Не составляйте графики в предположении, что ваши сотрудники будут сосредоточены на задачах по восемь часов в день. Они не будут. Они не смогут. Они ходят на митинги и тренинги, они пишут отчеты, памятки, заполняют глупые формы из hr. Если вам повезет, они тратят шесть из восьми часов на официальных задачах, работая остальное время над другими вещами, которые они должны делать.
- не соглашайтесь с нереальными графиками. Вместо этого оцените, сколько времени займут задачи, которые вы сможете сделать. Когда столкнетесь с графиком, в котором меньше времени, чем задач, спросите, какие из них вы должны сделать в первую очередь, а какие следует делать, если у вас появится время. Если вы столкнулись с менеджером, который настаивает на том, что нужно выполнить все задачи, спросите, какие можно делать менее тщательно. И попросите больше сотрудников. Иногда вам придется сталкиваться с руководителями, которые настаивают на том, что вы должны согласиться сделать все за нереальное время. Вы скажете: «Да» или «Может быть». Помните, что эти слова не являются магическими. Реальность прокатится по вашему проекту и по сотрудникам как паровой каток, вне зависимости от того, что вы пообещали. In the face of executives who will not listen to reason, manage your people sensibly, or you'll lose them.


Другой причиной переработки может быть менеджер, который вознаграждает людей за их наличие на рабочем месте. Тот, кто находится на рабочем месте 80 часов в неделю считается более преданным и заслуживающим большего, чем человек, работающий 45 часов в неделю, но делающий больше. Ваша задача в том, чтоб сделать результаты эффективнгой работы видимыми. Мы не сможем сказать вам в этой книге, как это сделать. То, что делали мы — работало для конкретных людей, руководителей и их сотрудников.

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

четверг, 20 декабря 2012 г.

lesson 227

Допустил ошибку, от которой предостерегаю программистов.
Слил в develop, не прогнав тесты. Считал, что у меня незначительное изменение. Всего лишь обновил selenium до 27 и firefox не стартанул.

А надо было дописать в pom.xml:


org.apache.httpcomponents
httpcore
4.2.2



Дурак, чо.

Слово Канеру

Не позволяйте собой злоупотреблять.

Менеджеры проектов и руководители иногда предъявляют необоснованные требования.


Вы не должны делать то, что не может быть сделано. Многие менеджеры пытаются выжать дополнительные 10 или 20 процентов работы их своих сотрудников, как бы те ни старались. Don't let yourself be guilt-tripped if you can't do the impossible, nor if you refuse to burn out yourself and your family making the impossible effort.

Разработка ПО — это не всегда работа с 9 до 5. Вы должны помогать вашей команде и иногда это требует сверхурочных в течении нескольких дней или недель. Иногда руководителю проекта требуется ваша помощь, чтоб вытащить проект и закончить его в срок. Безусловно, вы должны сделать все разумное, чтоб этого достичь. Но выберите свой собственный темп и обозначьте свои обязательства. Будьте добровольцем, а не жертвой.

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

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

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

Не позволяйте себе попасть на смертельный марш. Не тратьте время на обреченные проекты. Это никому не помогало и причиняло много эмоционального вреда. См. Yourdon (1997).

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

Lesson 226

Слово Канеру

Мораль сотрудников — важный актив

Как выразился Наполеон «отношение действенности моральной силы к физической составляет три к одному».

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

- Общайтесь вежливо и с уважением
- Обращайте внимание на их работу
- Хвалите хорошую работу, энтузиазм и честные усилия
- Если сотрудники работают допоздна, сами делайте так же. Не каждую ночь, не каждый выходной день, но достаточно часто, чтоб сотрудники чувствовали, что вы делите с ними нагрузку.
- Если возможно, давайте людям задачи, которые им интересны. Поощряйте их выражать интересы и обращайте на них внимание.
- Если тестировщик не может справиться с каким-любо заданием, назначьте кого-нибудь, чтоб помочь ему, научить или, если нужно, заменить (переместить на другие задачи).
- Дайте возможность обучаться. Покажите, что цените развитие навыков и профессионализма.
- Относитесь к сотрудникам справедливо и требуйте от других того же.
- Никогда не вводите в заблуждение ваших сотрудников. Если не знаете ответа на вопрос — так и скажите. Если у вас есть только догадка — так и скажите, не говорите, что знаете наверняка.
- Никогда не кричите на сотрудника. Не пользуйтесь вашей властью, чтоб запугать.
- Избегайте публичной критики сотрудника, указывайте на ошибки в частном порядке.
- не сплетничайте о ваших сотрудниках с другими.
- Не зовите подчиненных на свидания и будьте предельно осторожными, прося или принимая личные услуги или подарки., даже небольшие. Отдавайте больше, чем получаете.

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

Lesson 225

Декабрь - самый короткий месяц.

Слово Канеру

Не ставьте начинающих тестировщиков на почти завершенные проекты.

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

Новичок, однако, потребует гораздо больше ваших инструкций о том, как тестировать. Некоторые группы тестирования тратят огромное количество времени на написание пошаговых инструкций для новичков. Мы считаем, что было бы лучше для таких групп, если бы они потратили это время на поиск ошибок и их исправление. Мы считаем, что новички, использующие подобные инструкции, скорее всего, пропустят больше ошибок, так как они просто не знают о существовании определенного класса ошибок, так как для него нет инструкций, которые смогли бы передать необходимый диапазон наблюдения и навыки интерпретации.
Нанимайте новичков, когда у вас есть время, чтоб обучить их, or when you have tasks for them that take you very little time to prepare and delegate.
Не нанимайте новичков, когда вы не можете позволить себе не уделять им внимание. Не структурируйте вашу архитектуру тестов и документацию так, чтоб эта активность тратила значительное количество времени старших тестировщиков in the service of facilitating mediocre work by newcomers.

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

Lesson 224

В любой непонятной ситуации — переводи уроки Канера.

Слово Канеру

Пусть новые тестировщики займутся ретестом старых багов перед поиском новых.

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

Актуализация открытых ошибок Тестируя каждый баг, тестировщик может сообщить, что он все еще воспроизводится. При этом он отмечает дату, id сборки ПО, программную и аппаратную конфигурацию. Кроме того, тестировщик может сказать, что ошибка больше не воспроизводится — и тоже указать дату, билд и информацию о конфигурации.

Рестест закрытых багов Для выбранных багов тестировщик поверяет, не воспроизводятся ли ошибки, которые когда-то были исправлены. Эти ошибки, вероятно, уже закрыты. In most companies, no entry goes into the record unless the bug has reappeared, в таком случае (в зависимости от политики компании) тестировщик переоткроет существующий дефект или заведет новый, описывающий текущее поведение с перекрестной ссылкой на старый.

Ретест исправленных, но не закрытых багов Баг возвращается — исправленным, отложенным, невоспроизводимым или отклоненным каким любо другим способом. Тестировщики, которые о нем сообщили, будут повторно проверять его и закрывать. Новым тестировщикам также будет полезно исследовать такие ошибки. После его исследования пусть он поговорит с человеком, который нашел эту ошибку. Этот человек и вы могли бы дать новичку обратную связь о его подходе, тактике поиска багов, способу принятия решения о том, сколько времени нужно тратить на повторное тестирование ошибки. Когда вы будете удовлетворены его уровнем, разрешите ему самостоятельно закрывать баги.

четверг, 13 декабря 2012 г.

Lesson 223

Ко вчерашнему вопросу: А вдруг есть еще много таких ребят, один лучше другого и все лучше тебя? Ну что ты будешь делать, когда к тебе припрутся хорошие пацаны?

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

Есть хорошая книга «Я возьму сам» у Олди. И лейтмотив у нее замечательный. Хм.

Слово Канеру

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

Здесь новый тестировщик — это новый человек в тестировании, а не для вашего проекта. Он должен научиться основным навыкам тестирования, а не тому как проверять ваш продукт.

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

Когда вы будете удовлетворены и посчитаете, что новый тестировщик может писать разумные багрепорты — пусть пишет их. До этого момента, возможно, он не должен постить баги.


bret pettichord, cem kaner, chapter 9, james bach, lessons learned in software testing, лекции

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

Lesson 222

Давайте представим...
Тебе, да-да, именно тебе сказали, что в соседней стране соседней компании соседнем отделе соседней комнате работают лучше тебя.
- Кто? Они? Да они же нихрена не умеют.
- Умеют... смотри, багов пропущено меньше, времени потрачено всего ничего...
- Да у них таски никакие!
- Вообще-то ваши же таски брали, помогали вам, вот...

Короче - работают лучше тебя. Вон те. Ваша реакция? Ваши версии? Первые мысли. А?



Слово Канеру

Знакомьте новых тестировщиков с продуктом через позитивное тестирование

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

Цель этого заключается в том, чтоб помочь составить представление о продукте. Исходя из него он будет более информированным и эффективным критиком, когда он будет искать сбои.

Lesson 221

Слово Канеру

Заставьте новых тестировщиков проверять пользовательскую документацию

Новый тестировщик — новый человек в проекте, а не в тестировании. Он мог работать или не работать тестировщиком в другом проекте — неважно.

Один из способов познакомить новичка с продуктом — дать ему проверить соответствие пользовательской документации и программного обеспечения. К концу такого тестирования он узнает всю программу.

Это хорошая задача — тщательная проверка бумажной и интерактивной справки. Пользователи используют их, чтоб познакомиться с ПО или когда у них возникают проблемы. Кроме того, в продуктах массового рынка документация, скорее всего, гарантирует описываемое поведение продукта. От этого типа гарантии основанного на практически письменном заявлении производителя, нельзя отказаться или избавиться, как это иногда бывает можно в других контрактах. Все, что описано в документации, может быть использовано в качестве доказательства того, что в продукте есть дефект (Kaner 1995b and Kaner and Pels 1998).

Тестировщик должен проверить каждый факт (все, относительно чего можно сказать, истинно это или ложно). Кроме того, тестировщик должен проверить любые выводы, которые, как он считает, разумно было бы сделать из документации. Это обеспечит хорошую подготовку тестировщика и даст ему навыки поиска важных ошибок (Pettichord 2001b).

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

Lesson 220

Сегодня с утра прочитал половину «Цели» Голдратта, офигеннейшая штука.
Тем не менее самым полезным, что я узнал за декабрь — то, как завязывать шнурки, чтоб они постоянно не развязывались.
Вот оно как.

Кстати, по сегодняшней лекции, правильно ли я перевел:


The mentor has no supervisory authority over the tester and does not report anything about the new staff member to you unless a serious problem occurs.


Если да, то интересный подход — наставник не из профессии. У нас бы он порвал шаблон. Но, ящетаю, был бы полезен. Люблю эксперименты над людьми.

Слово Канеру

Помогите новым тестировщикам быть успешными

Когда вы берете кого-нибудь в группу, сделайте несколько вещей, чтоб сделать их первые недели успешными:

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

четверг, 6 декабря 2012 г.

Lesson 219

Наша компания самая замечательная в мире и все остальные компании завидуют нам.
Всем сотрудникам бесплатно выдаются планшеты. Характеристики:
диагональ 15''
16 миллионов цветов.
Перьевой ввод, различает 400 степеней нажатия, возможность обработки наклона пера.
Мультитач до 50 касаний.
Сменные карты памяти.
Работает больше 20 часов без зарядки.
Корпус: металл, пластик.
Вес: 70г
Поддержка карт в offline режиме.
Интерфейс спроектирован для творческих людей.

Под катом фото запущенного планшета и в разобранном состоянии.

Альбом: office

и
Альбом: office



Слово Канеру

Просматривайте записи техсаппорта.

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

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

Lesson 218

"Окончательный диагноз" очень даже ок.
Теперь - ТОС Голдрат, за ним попробую "Та самая цель" он же.


Слово Канеру

Активно работайте над улучшением навыков

Недостаточно просто сказать «я сегодня буду осваивать cause-effect диаграммы». Если техника поиска багов, написания отчетов, оценки багов стоит изучения, то вам, вероятно, придется выполнить ряд задач для практики. Сложно улучшать навыки, когда изменяются технологии, рынок, средства разработки, продукты. Но даже если это не так просто, вы должны делать эту работу, чтоб оставаться в курсе событий и это является хорошей основой для вашего статуса в компании.

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

Lesson 217

Сегодня хороший день.
Много интересного, полезного и забавного общения.
Прочел во второй раз "death march" Йордана, начал читать "Окончательный диагноз" Хейли.

It Was a Very Good Year


Слово Канеру

Создайте экспертизу сотрудников по релевантным технологиям.

С ростом сложности аппаратного и программного обеспечения, возникает все больше проблем взаимодействия между нашим приложением и сторонними, с удаленными серверами, оборудованием — которое находится вне непосредственного контроля разработчика приложения. Nguyen (2000) introduces Web application testers to тестирования этих типов взаимодействий, и чтоб с успехом им заниматься, вы должны много знать о железе и софте (он дает полезные вводные материалы).

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

Lesson 216

Слово Канеру

Создавайте экспертизу сотрудников в предметной области.

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

Вы могли бы накапливать экспертизу несколькими путями:

- Читать журналы и книги, которые были написаны для людей, подобных вашим заказчикам.
- Идти на занятия (желательно на те, где учат сотрудников не только вашей компании) обучающие клиентов пользоваться вашим продуктом после того, как он будет готов.
- Идти на занятия, обучающие предметной области продукта. Например, если вы создаете софт для продажи недвижимости, пройдите обучение брокера по недвижимости, ипотечного брокера или оценщика.
- Работайте на объектах клиентов. Это может быть аренда сотрудника (например, ваша компания предоставляет важному клиенту своего сотрудника на несколько недель — время установки продукта и обучение ему) или работы на неполный рабочий день (убедитесь, что компания вам это позволит).
- Sell your software or your competitor's software. For example, while working as a software development manager at a consumer software company, one of us, Kaner, learned more about his product's market by selling software at a leading retail store for six months of Saturdays. The publisher and the retailer both knew his goals and encouraged him in this work.
- Отвечайте на звонки в техническую поддержку вашего продукта несколько часов в неделю. Сперва вам придется немного обучиться работе технической поддержки. В конце концов вы научитесь этому и узнаете много нового (если вы делали эту работу всерьез, задавая вопросы и исследуя жалобы, которые услышали).

пятница, 30 ноября 2012 г.

Lesson 215

По результатам круглого стола тестировщиков екб - было интересно, кое-что может и взлететь.

Ну и да, в копилку ЧСВ из тви:
@xoposhiy #oseminar про тестирование: "после ухода Максима авто тестирование у нас в проекте пропало" "а у нас после прихода Максима - появилось!"
@xoposhiy #oseminar так всегда. Как бы кому не хотелось - процессы ничто, люди - все



Слово Канеру

Не ждите, что люди будут работать эффективно с несколькими проектами

Если у вас больше проектов, чем тестировщиков, у вас будет соблазн назначить несколько проектов на одного тестировщика. Остерегайтесь двух проблем:

- Некоторые люди берут несколько заданий, но в эту неделю (или месяц) будут работать только над одним. Остальные продукты чахнут в фоновом режиме.
- Тестировщик, активно работающий с двумя проектами тратит много времени на накладные административные задачи. В конечном итоге вы получаете кого-то работающего на нескольких проектах, участвующего в массе митингов, тратящего много времени на то, чтоб догнать команду (перечитывание записей, проверка последних ошибок, чтение отчетов о новых фичах, чтение почты и т. д.) для каждого проекта и мало делающего на любом их них (DeMarco and Lister 1999).

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).

среда, 28 ноября 2012 г.

Lesson 212

Прекрасное, с Хабра. Как тестируют самсунги. С 1:20 чад и угар.



Слово Канеру

Читайте багрепорты ваших сотрудников

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

Для оценки качества работы сотрудников, вот несколько вопросов, которые можно задать относительно багрепорта:
- Хорошо ли он написан?
- Просто ли он определяет проблему?
- Он оставляет за собой дыры, которые повлекут последующее тестирование?
- Ошибку было сложно найти? Ошибка в стабильной части приложения? Она отражает удачу или упорство тестировщика, который ее нашел?
- Каков тон доклада?
- Будет ли отчет понятен программисту? Как программист прокомментировал репорт? Значит ли это, что программист и тестировщик сотрудничают или не смотрят друг на друга?

вторник, 27 ноября 2012 г.

Lesson 211

Это ПЕАР.


У нас в городе грозит состояться круглый стол тестировщиков на тему: «нужны ли мы нам». Особенно приятно то, что инициатор не я.

Юля объявила его так:

В среду 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).

пятница, 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). Вы смогли бы найти общие уроки в них, особенно в плане рекрутинга. Мы включили их потому, что мы получаем много вопросов о найме и о поиске работы, и обсуждение управления людьми было бы неполным без освещения этих вопросов.

четверг, 22 ноября 2012 г.

Lesson 209

Тестеры, есть вопрос.
Вам дали постановку, небольшая юзерстори/фича, 1-3 часа тестирования, 2 экрана постановки.



Ваше мнение очень важно для меня.

Слово Канеру

В полезном отчете по релизу перечислены 10 худших проблем, которые смогут найти критики.

Представьте, что вы выпускаете ПО для продажи. Перечислите 10 наихудших вещей, которые смогут сказать о нем рецензенты. Если проблемы достаточно серьезны, маркетологи компании (или другие сотрудники) могут задержать релиз. Это будет наиболее полезная оценка качества, которую вы можете предоставить (Заметим, что такой подход позволяет говорить с позиции критика ПО, не пытающегося дать объективную картину качества).

среда, 21 ноября 2012 г.

Lesson 208

Коллеги, кто-нибудь на проектах вообще делает еженедельник "статус продукта"?
Что в него пишете, что нет?

Или унылыми круговыми диаграммами jira дашбордиков перебиваетесь?


Слово Канеру

В финальном отчете по релизу укажите список неисправленных дефектов

Если вы готовите (или помогаете готовить) окончательный отчет по релизу, вы должны включить в него список неисправленных ошибок. Также включите отклоненные issue по архитектуре, которые вы считаете важными. Распространите этот список заранее, чтоб финальный отчет не содержал сюрпризов.

вторник, 20 ноября 2012 г.

Lesson 207

Слово Канеру

Если вы пишете отчет по релизу, описывайте проделанную работу по тестированию и ее результаты, а не ваше мнение о продукте.

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

Lesson 206

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

Было ок.
Отдельно хочу отметить няшныхручных тестировщиц которые с моего полпинка таки сделали доклад. В связи с чем процитирую организатора мероприятия:

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


Заемечательно ящетаю.
А выступать мы все еще подучимся, чо.

Слово Канеру

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

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

пятница, 16 ноября 2012 г.

Lesson 205

Слово Канеру

Не подписывайте разрешение на выпуск продукта.

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

Lesson 204

И сам не заметил как перевалил за вторую сотню...
Надеюсь, до лета успею перевести все.

Слово Канеру

Поэтапные отчеты полезны, когда этапы четко определены.

Некоторые компании ведут свои проекты по этапам и делают тщательную оценку статуса продукта на каждом этапе. Другие этого не делают.

Если ваша компания хочет оценок продукта на каждом этапе, вы должны понимать минусы такой оценки. Каким образом компания определяет этапы? Какие аспекты этапов стоит сравнивать? Например, если определение этапа гласит, что 50% фич закодированы, вы должны иметь возможность определить так ли это. Каким образом вы это сделаете?

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

Если вас попросили оценить прогресс относительно этапа у которого нет определения, мы предполагаем, что вы добьетесь от руководства согласия с определением и лишь затем дадите оценку относительно него. Если у вас просят совета по определению этапа, то можно сделать предположение, что этап это завершение итерации. Каковы критерии ее завершения? ( или каковы критерии начала следующей итерации?) Работа Lawrence и Johnson's (1998) в этом плане очень полезна и распространяется бесплатно.

См. http://www.coyotevalley.com/plc/builder.htm -полезные примеры подобных определений. Мы не считаем их «правильными» и мы не думаем, что Lawrence или Johnson считают их «правильными». Они лишь иллюстрируют критерии, которые могут быть применимы для определения этапов и которые являются хорошей отправной точкой для компаний, которые находятся на этапе создания своих определений.

Lesson 203

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

Слово Канеру

Дашборд проекта — еще один полезный способ показать статус проекта.

Дашборд это график на большой доске в конференц-зале, открытом для всех — команды проекта и всех кто в нем заинтересован. Он показывает состояние проекта, которое можно охватить одним взглядом (см. Bach 1999b для дальнейшего обсуждения).


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

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

Альбом: office

четверг, 15 ноября 2012 г.

Lesson 202

Слово Канеру

Вот примерная структура еженедельного отчета о состоянии продукта

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


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

Третья страница представляет собой статистику по ошибкам. Мы оставляем ее на третьей странице по той же причине, что газеты помещают спортивную статистику не на первой странице. Спортивные секции — самые читаемые части газеты. Если вы поместите статистику по дефектам внутрь то оставите первую страницу для новостей, которые вы считаете важными.

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

четверг, 8 ноября 2012 г.

Lesson 201

Наташа, как всегда, прекрасна.
Ее доклад, как обычно, не очень.

«Неполиткорректный рассказ про подбор тестировщиков»
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. Любая метрика, игнорирующая это и говорящая о полном покрытии дает недостоверную информацию, а следовательно, ложные надежды.»

Lesson 199

Прекрасно, ящетаю. Обнаружил dibr в книге М.Н. Алова.
Про тестировщиков, обратно же. В какой-то степени.


знаменитый среди обитателей Дальнего Космоса экспериментальный десантный шлем 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 багов в неделю, уточните, что этот расчет верен на больших числах, а когда число открытых дефектов невелико, то многие другие факторы проекта начинают иметь большое влияние на время до релиза.
- Когда вас просят о статистике на конкретных лиц (количество багов на тестировщика), говорите нет. Объясните, что как только вы начнете использовать баг-трекер для сбора информации о людях, характер данных в трекере изменится. Процесс сообщения об ошибке станет все более политизированным, состязательным и менее объективным.

четверг, 1 ноября 2012 г.

Lesson 197

Вот такую хрень из желудей и спичек из тыквы с бабушкиного огорода сотворила @akahha
Запаса свечек у меня хватит на месяц, а сегодня еще посмотрю, есть ли светодиоды, да поярче. Будет из нашего окошка подмигивать прохожим.
Раз:
Альбом: home


и два:
Альбом: home


Слово Канеру

Регулярные отчеты о статусе продукта — мощный инструмент.

Реальная сила группы тестирования — коммуникативная, а не административная. Вы убеждаете людей дать вам необходимые ресурсы, чтоб выполнить работу, которая им нужна and to reconsider releasing unsatisfactory products to customers.


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

- Всегда используйте ней тральный фактический тон. Воздержитесь от восклицательных знаков, больших букв, юмора.
- Избегайте индивидуализации. Говорите о результатах, ошибках и сроках, но фокусируйтесь на предметах, а не людях, с ними связанных.
- Примите стандартный формат, общий для всех проектов. Не делайте себя целью жалоб руководителя проекта (проект которого в беде) о том, что вы третируете его проект потому, что не любите его.
- Выпускайте отчет по расписанию. На ранних этапах проекта раз в две недели. Позже, можно будет выпускать раз в неделю. Ближе к концу проекта можно выпускать его ежедневно. Работайте с разными проектами по одному графику.
- Тщательно выбирайте содержание. Сохраняйте отчеты небольшими, упаковывайте информацию в несколько страниц.
- Распространяйте отчет за пределы проектной команды. Отправьте его боссу руководителя проекта, возможно даже боссу его босса. Отправьте его всем заинтересованным лицам компании. Менеджер проекта может возразить, что отчет слишком широко распространяется. Мы предлагаем два ответа: «Мы всегда рассылали подобные отчеты этим людям» или «Если этот отчет не подходит мистеру Х, пусть просто скажет нам об этом. Мы прекратим присылать ему отчет.»


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

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

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

Lesson 196

tester: Сборка тестов на миграцию не проходит, удалили бекап, который мигрируем.
support: Ой, я удалил. Понимаешь, бекап назвался test_migration. Это для вас test означает тестирование, для остальных это что-то временное и неважное.

В тему сегодняшней лекции - с подачи бывшего падавана поставил себе Task Timer. И коллегам советую. Посмотрим, что получится.

Слово Канеру

Используйте журналы активности, чтоб показать перерывы в работе тестировщиков.

Если вы думаете, что вам не нужно защищать тестировщиков от прерываний, начните вести журнал активности в течении недели или двух. В журнал записывайте каждый телефонный звонок (время, когда вы его приняли), время чтения электронной почты и время написания ответов на нее, каждый раз, когда кто-то заглядывает к вам в кабинет (куб) с вопросом, шуткой или ручной гранатой. Каков самый длинный отрезок времени, который вы на самом деле были готовы посвятить планированию или тестированию? Есть ли у вас промежутки разумных размеров в течении дня или вы вынуждены приходить на работу очень рано или уходить очень поздно, чтоб найти время поработать? (Для подробного обсуждения дробления времени см. Weinberg 1992, 284.)

Если вы, тест-менеджер, работаете с тестировщиком у которого есть проблема с производительностью или кто-то слишком часто работает сверхурочно, чтоб выдерживать нагрузку, то журнал активности — хороший способ, чтоб помочь тестировщику (и вам, чтоб понять, как вы могли бы помочь тестировщику) сосредоточиться и определить приоритеты работы. Мы не рекомендуем вам использовать это в качестве инструмента поддержания дисциплины или в качестве официального инструмента оценки производительности. Для этого сходите в отдел кадров вашей компании и попросите конкретных советов. Мы утверждаем, что люди перегружены. Если вы менеджер человека, который кажется разбитым, то мы надеемся, что вы рассмотрите некоторые инструменты и вещи, которые вы могли бы сделать, чтоб помочь сотруднику сосредоточиться на текущих задачах и использовать время более эффективно, очистить его от ненужных задач. Журнал активности — один из таких инструментов.

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

Lesson 195

Мужской вариант песни: Твоя нежность

Век двадцатый — век больших разлук…
И тебе сейчас трудней, чем мне, —
Ждать труднее, чем идти на риск…
Между нами миллиарды звёзд,
Между нами радиаций яростный дождь,
Но в небо
С далёкой земли
Долетает
Твоя нежность…

Может, надо улететь, чтоб знать,
Сколько в мире алых солнц и лун,
Может, надо улететь, чтоб знать,
Как беспомощно мала земля, —
Но огромна лишь одна земная любовь…
И здесь, во Вселенной,
Меня
Согревает
Твоя нежность.

Я лечу, и на меня глядят
Воспалённые зрачки планет;
Слышу ласковое пенье звёзд, —
Светел голос неземных светил…
Только в мире нет любви
Сильнее земной,
И здесь, во Вселенной,
Меня окрыляет
Твоя нежность…

А тебе ещё осталось ждать
Ровно столько, сколько мне летать…



Слово Канеру

Тестируйте сессиями.

Сессия — защищенный блок времени, от 60 до 90 минут. Во время сессии тестировщик сфокусирован на одной задаче. Если вы тест-менеджер, то защитите целостность сеанса и повесите большую табличку «Не беспокоить» около тестировщика, которую каждый, включая вас, будет уважать, unless a serious problem must be addressed urgently.

Тестировщики, которые не могут найти способ защитить свое время, часто работают короткими отрезками, так как часто отвлекаются на вопросы и митинги.

Lesson 194

dev: это видимо в ветке develop баг, т.к. я вижу еще одну сборку, у которой этот тест упал
tester: Выводы?
dev: Найти и наказать! :)
tester: Я думал, взять и исправить. Ты точно программист?

Слово Канеру

Регламентируйте сессии тестирования, особенно исследовательского.

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

Преимущество регламента в том, что он помогает сосредоточиться на тестировании и не отвлекаться на непродуктивные направления. Тестировщик не привязан к регламенту. Если он увидит что-нибудь подозрительное или у него появится гениальная идея, он может им следовать. Но во время перерыва он возвращается к регламенту, если нет ничего более интересного и актуального.

We think it is particularly valuable to come up with an explicit charter when two testers are working together as a pair.

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

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

суббота, 27 октября 2012 г.

Lesson 193

Забавно, но эти переводы читает кто угодно, кроме тех, для кого я это делаю.

Все кроме моей команды, кроме тестировщиц нашего отдела.
Мда.

Слово Канеру

Назначьте в проекте охотника за багами

Охотник за багами — опытный энтузиаст тестировщик-исследователь. Вот несколько способов тестирования, которые он мог бы использовать:

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

пятница, 26 октября 2012 г.

Lesson 192

Вчера написал в чат группы ссылку на пост Алименкова:
(24.10.2012 19:15:15) mz: http://xpinjection.com/2012/10/24/code-degradation-and-xp-practices/
Человек пишет о проблемах, близких к нашим

Как вы думаете, что у меня спросили потом лично?
Может быть: «как при тех же кадрах повысить приоритет автоматизации, ведь не все мануальщики умеют, а некоторые и не хотят?»
Или может быть «что автор предлагает делать с демотивирующим влиянием усложненных регламентов тестирования фичи на разработчиков?»
Ну, тогда наверное «как продать рефакторинг топам во время дедлайна?»

Нет! Ни хренышка подобного!

Меня, ЧСХ, спросили: «А где ты находишь время все это читать? Мы вот работаем и не успеваем.»

Пиздец.
Потому и не успеваете.
У меня есть встречный вопрос: «а почему вы — ничего этого не читаете?»
Я вот не успеваю читать публикации ориджинал контента по моей профессии, но хотя бы за книгами слежу.
Или может быть наша профессия столь ничтожна, что ей не нужно учиться?

Гугл по запросу Famous Testers ведет нас на страничку
http://www.ranker.com/list/list-of-famous-software-testers/reference
где из 17 человек я слышал имена шестерых, книги трох — читал, четвертого — собираюсь прочесть.

А, да, все не так плохо. Зато все героически прочли дотком Савина.

Как с этим у вас?




Слово Канеру

Попробуйте парное тестирование

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

Парное тестирование отличается от других видов парной работы, так как тестирование — деятельность по генерации идей, а не выполнении работы по плану. Тестирование — эвристический поиск в открытом многомерном пространстве. Пара поощряет каждого тестировщика объяснять и реализовывать идеи. Когда тестировщик объясняет свои мысли другому, то сам процесс формулирования порождает новые идеи. Если работать добросовестно, то мы верим, что этот процесс ведет к большему количеству лучших идей и тестов.

Мы настоятельно рекомендуем согласовать устав парного тестирования, прежде чем начинать тест-сессии. Чтоб создать устав нужно потратить 5-10 минут времени не у компьютера (а, возможно, у доски), договориться о направлении, в котором вы будете следовать ближайшие 2 часа. Можно сосредоточиться на рисках, попытаться предсказать ошибки, выбрать фичи для тестирования и инструменты. Это будет общее руководство, а не список тестов. Тестировщики могут свободно отходить от устава, чтоб исследовать что-то новое (например для отслеживания обнаруженного подозрительного поведения, включающего в себя работу с несколькими фичами). Однако, когда они выполнят эту задачу, они остановятся, чтоб заглянуть в устав и узнать, что делать дальше. Без устава пары могут потерять фокус.


Также мы верим, что парное тестирование помогает сосредоточиться на задаче, делает проще воспроизведение и анализ ошибки, помогает тестировщику сохранять движение, пока другой делает перерыв или отвлекается. Также мы подозреваем, что при парном тестировании у остальных будет меньше возможностей отвлечь, что тоже не так плохо.
Мы подозреваем, что пара тестировщиков как минимум более эффективна, чем два тестировщика, работающие в одиночку. Они получают больше за меньшее время. Это новая область для работы. Попробуйте тестирование в парах. Посмотрите, как это работает в вашей компании. Можно делать это для определенного класса задач, для определенного круга людей.

четверг, 25 октября 2012 г.

Ништячог

ЫЫЫЫЫ!!!!!
Аргументация и контроль на новом уровне:
Альбом: office

вторник, 23 октября 2012 г.

Lesson 191

I must gain worth. Thank you for your kindness.
I must gain worth. Thank you for your kindness.
I must...

I must not... gain worth. There's no kindness in your eyes.


Слово Канеру

Производите ротацию тестировщиков по фичам.

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

Fran McKain предлагает оценку контекста:
Вот некоторые предостережения. Некоторые наборы фич являются настолько большими, что очень много времени займет изучение этой области для эффективного тестирования. Ротация будет поддерживать лишь низкое качество тестирования.

Мы согласны с важностью специализации, но задаемся вопросом: как управлять рисками, ею созданными: Возможно, одним из способов будет парное тестирование, сопрядение специалиста с другими тестировщиками группы.

Lesson 190

Слово Канеру

Продайте или передайте задачу другому тестировщику, если первый плохо выполняет ее.

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

четверг, 18 октября 2012 г.

Lesson 189

Слово Канеру

Нет правильного соотношения количества тестировщиков и разработчиков

Люди часто спрашивают, каково верное соотношение тестировщиков и разработчиков. Мы считаем, что это неправильный вопрос (Kaner и соавт. 2000 и Hendrickson 2001a).
Во-первых, два человека могут иметь ввиду разные вещи, говоря, что у них соотношение один к одному. В разных компаниях считают разные люди, это делает невозможным сравнение компаний по такому признаку.

Во-вторых, соотношение акцентирует внимание на количестве, а не на работе, которая выполняется. Предположим, что на последнем проекте программист потратил 16 человеко-месяцев на проектирование и написание кода, а тестировщик провел 24 человеко-месяца, занимаясь поиском ошибок. Соотношение 24 к 16 или 3 к 2 является точным, но не информативным. Измените количество нового кода, количество сторонних компонент, объем кода с прошлого проекта, который может быть использован, баланс ответственности за устранение проблем, и массу других переменных — и соотношение окажется неверным. Вместо того, чтоб говорить о соотношениях, говорите о работе, которую вам нужно сделать и людях, которые понадобятся для этого.

Lesson 188

Слово Канеру

Человек, который будет делать работу должен сказать вам, сколько времени она займет.

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

Сказав это, мы подумали, что вы могли бы прочесть вдумчивый ответ Pat McGee.

«Человек, который будет делать работу должен сказать вам, сколько времени...» Мне сильно не нравится эта практика. Я считаю, что многие люди не уделяют достаточно внимания тому, как они дают оценки. Я видел ситуацию, когда программист дал оценку в 2 недели, менеджер сказал, что это должно занять не более двух дней и оно\, действительно, заняло полтора дня. It passed review on the first attempt, too. Но также я наблюдал и обратные ситуации, когда работа заняла намного больше времени. Я считаю, что оценку должен давать тот, кто больше других обращает внимание на то, сколько времени занимает та или иная работа. Иногда это менеджер. Иногда сотрудник. Иногда такого человека нет. Несмотря на все это, я считаю, что ваше оригинальная идея упрощена до полной бесполезности.

Разница между нашими подходами в том, что Pat получает оценку от лучше проинформированного человека. Мы же берем оценку от человека, который столкнется с последствиями, если оценка будет неправильной (и который заинтересован в том, чтоб получить качественные оценки). Оба подхода кажутся нам разумными и оба гораздо лучше, чем распространенный подход — выдавать желаемое за действительное.

вторник, 16 октября 2012 г.

Lesson 187

Как вы все, конечно же, помните, недавно у нас самопровелась одна тест-сессия.

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

Что особенно приятно, сегодня ее организовала с моей подачи новенькая. А то чо все я да я?

По результатам победила дружба выяснилось:
1. Что аналитики едят свой хлеб не зря. Некоторые не зря мажут на него икру. Не было ничего сверхъестественного, и в конечном счете, например я бы тоже все нашел. Но за отведенный час именно аналитик нашел больше.

2. Что тестировщиков нанимают не зря. Потому что программисты тестировать могут. И базовый минимум дефектов находят. Но не хотят и сдаются через полчаса.

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

4. Что не можешь занять первое место — займись лучше организацией.

5. Что некоторые постановки лучше даже не читать. Целее будешь.

Пикрандом.


Слово Канеру

Чтоб запланировать набор задач, оцените количество времени, необходимое для выполнения каждой из них.

Ваша работа состоит из выполнения большого количества задач. Составьте их список (см. Канер, 1996b и любые другие книги по управлению проектами, охватывающие работы по оценке). Некоторые задачи можно описать только в общих чертах; другие можно разбить на мелкие части. По мере возможностей, создавайте отдельные задачи на все, что может занять больше дня. Оцените (предположите) сколько времени займет задача, прибавьте 25 процентов (больше или меньше в зависимости от компании) для совещаний, обучения и других работ вне проекта и используйте полученное значение, как время, необходимое для решения задачи.

Этот метод выглядит проще, чем на самом деле. Составление списка задач — не так тривиально, очень легко пропустить задачи или недооценить их.

Пробуйте и другие методы для оценок:
- Если вы делали и другие проекты, подобные этому, возьмите за основу время, которое они заняли.
- If you have a sense of the length and complexity of the program and a model based on data in your current company that relates length and complexity to duration of testing, apply the model to derive an estimate.
- Если вы чувствуете, что существуют риски, связанные с проектом, оцените время для проверки этих рисков
- Другие факторы, которые вы могли бы оценить. Например, если вы знаете, что программисты особенно хорошо знают этот тип приложений, то, вероятно, потребуется меньше времени на тестирование. Если этот конкретный программист делает много ошибок, чем остальные, то, возможно, понадобится больше времени на тестирование. Если пользовательская документация уже написана четко и ясно, если известен образ действий и входные данные пользователей, то тестировать будет проще.


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

четверг, 11 октября 2012 г.

Lesson 186

Слово Канеру

Никогда не планируйте бюджет только для 2 циклов тестирования

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

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


Время от времени мы наблюдаем бюджеты на два цикла тестирования, в которые затем не укладываются. Поскольку изначальное предположение нереально, а задержки в графике неизбежны, то каждое изменение графика трактуется как провал и задержка группы тестирования.

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

Lesson 185

Слово Канеру

«Достаточно тестировать» значит «моим клиентам достаточно информации для принятия правильного решения»

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

Вот несколько факторов, влияющих на принятие решение о завершении тестирования(обеспечивающий низкий шанс появления ранее не обнаруженных баг ):

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


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


Ваша способность понимать, что информации достаточно, будет улучшаться по мере приобретения опыта тестирования продукта. Не грех в тестировании — пропустить ошибку. Грех — быть легкомысленным, беззаботным, не учиться на своем опыте.

Lessin 184

Слово Канеру

Нет универсальной формулы, чтоб сказать, когда хватит тестировать.

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

Так что не беспокойтесь о формуле. Беспокойтесь о том, как использовать вашу голову.

четверг, 4 октября 2012 г.

Lesson 183

В рамках инициативы «все что угодно, лишь бы не работать» провели эксперимент — обмен опытом с легким налетом фаллометрии.

Взяли задачу на тестирование, которая обычно делается одним тестером 2-4 часа и дали ее всем на час.
Все — это моя группа автоматизаторов, я и один ручной тестер у которого лицо выражением не напоминало «язанятанеподходи».

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

По результатам: я и ручной тестер нашли две одинаковые ошибки. Один АТ не нашел баг. Другой ат сперва придумывал реально крутые нетипичные и многообещающие кейсы, а потом нашел очевидный баг, который никто не заметил.

Выводы. Опыт полезный, руководителю ручных тестеров порекомендовал ставить его на поток в таком виде:
Берется большая задача. На 4 часа, на 2 дня — неважно. Назначается ответственный. Он собирает народ, все вместе ее тестируют 1 час, затем собираются, обсуждают. Ответственный записывает все результаты этого брейнсторма и дальше пилит сам.
Больше велосипедов, хороших и разных.

И да, у нас появились еще две тестировщицы, ня. Не наташи, но вопрос решается.

Пикрандом по запросу "Наташа":



Слово Канеру

Возможность для тестирования возникает каждый раз, когда артефакт разработки переходит из одних рук в другие

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

Lesson 182

Сегодня было снежное замечательное утро.
Вот пруфпик снега:
Альбом: office


Вот пруфпики замечательности - раз:
Альбом: office


два:
Альбом: office


и три:
Альбом: office


Слово Канеру

Качественное планирование тестирования делает последующие изменения легкими.

Если изменения на поздних этапах неизбежны, наша задача — создать процесс тестирования, который сможет с ними работать. Вот несколько советов:

- Вместо разработки большого набора тестов до начала тестирования, разрабатывайте тесты тогда, когда они вам нужны. Если дальнейшие изменения в продукте сделают их устаревшими, то они будут полезными хотя бы какое-то время.
- Не создавайте огромных документов по тестированию, требующих больших эксплуатационных расходов, таких как подробные сценарии тестирования. Держите документы настолько маленькими, насколько это возможно.
- Не привязывайте ручные или автоматизированные тесты к специфике GUI, кроме тестов, специально для этого предназначенных. Даже если вы тестируете в качестве конечного пользователя, обязательно работающего через интерфейс, не завязывайте ваши тесты на мелкие детали интерфейса, так как они могут меняться.
- Проектируйте автоматизированные тесты так, чтоб максимизировать их ремонтопригодность и переносимость между платформами. (См. часть 5, «Автоматизация тестирования»)
- Создайте набор тестов, следящих за действиями, которые повторяются в программе постоянно. Это сохранит время на планирование и упростит делегирование, когда будуту добавлены фичи или функциональность будет изменена.
- Создайте качественный набор Smoke тестов, для быстрого обнаружения сбоев в ПО. Если программисты вносят значительные изменения, то они, вероятно, часто пересобирают ПО и с удовольствием будут высылать вам новые билды как можно чаще. Smopke-тесты дешево находят плохие сборки, что делает их полезными для того, чтоб справиться с частыми билдами.
- Всерьез рассмотрите возможность использования техник экстремального программирования для разработки автоматизированных тестов (Beck 1999 и Jeffries в 2000). В частности мы рекомендуем разработать общую архитектуру для автоматизированных тестов, а затем итеративно дорабатывать их код, минимизируя риски проекта (здесь проект автоматизации рассматривается как подпроект продукта). Попробуйте программирование в парах, общайтесь с заинтересованными лицами (другими тестировщиками, менеджерами) чтоб определить направления работы.
- Разработайте модель пользователя продукта, определите пользу, которую хочет получить пользователь от продукта. Создайте комплексные тесты на основе этой модели. Большинство таких тестов не будет быстро меняться, так как они ориентированы на цели пользователя, а не на детали реализации.
- Помогите программистам создать большой набор юнит-тестов и других тестов, проверяющих базовую функциональность продукта. Они могут запускаться каждый раз при изменении кода, перед отправкой в тестирование.

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