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