http://bodhipbaha.livejournal.com/672334.html Парень еще будет летать, нельзя у таких забирать крылья.
UPD Фейк :(
четверг, 17 января 2013 г.
вторник, 15 января 2013 г.
Lesson 233
Отец купил себе игрушку:
Без баллона, накачка.
Аж три вида пуль:
Занятная штука. Кстати, отстрел серых ворон не запрещен, но приветствуется.
Слово Канеру
Старайтесь не брать людей, которых не приняли в другие группы
Есть люди, которые не могут работать в одних группах, но отлично справляются с работой в тестировании. Но таких людей немного. Чем больше неудачников вы примете в группу, тем вероятней, что ваша группа получит репутацию неудачников. Активно противодействуйте усилиям руководства спихнуть к вам в группу сотрудника, который не внушает вам доверия. Даже если этот «подарок» является для вас бесплатным (он не отнимает время текущих сотрудников и не занимает вакансию), он вам помешает, когда вы захотите нанять еще людей в следующий раз (вы только что получили человека, зачем вам кто-то еще?). Люди вокруг вас ждут, что потенциал вашей группы возрастет пропорционально увеличению размера персонала. Новый тестировщик требует задач для себя. Если вы получили новые задачи, но новый тестировщик не выполняет их, остальным в группе становится сложно работать.
 |
| Альбом: home |
Без баллона, накачка.
Аж три вида пуль:
 |
| Альбом: home |
Занятная штука. Кстати, отстрел серых ворон не запрещен, но приветствуется.
Слово Канеру
Старайтесь не брать людей, которых не приняли в другие группы
Есть люди, которые не могут работать в одних группах, но отлично справляются с работой в тестировании. Но таких людей немного. Чем больше неудачников вы примете в группу, тем вероятней, что ваша группа получит репутацию неудачников. Активно противодействуйте усилиям руководства спихнуть к вам в группу сотрудника, который не внушает вам доверия. Даже если этот «подарок» является для вас бесплатным (он не отнимает время текущих сотрудников и не занимает вакансию), он вам помешает, когда вы захотите нанять еще людей в следующий раз (вы только что получили человека, зачем вам кто-то еще?). Люди вокруг вас ждут, что потенциал вашей группы возрастет пропорционально увеличению размера персонала. Новый тестировщик требует задач для себя. Если вы получили новые задачи, но новый тестировщик не выполняет их, остальным в группе становится сложно работать.
Lesson 232
Кстати, вот так непафосно выглядит мое домашнее новогонднее настроение.
Слово Канеру
Наймите подрядчиков, чтоб получить передышку во время рекрутинга.
Используйте временную помощь, чтоб не торопиться во время поиска нужного человека. Даже в компаниях, строго ограничивающих использование подрядчиков, этот способ часто работает.
 |
| Альбом: home |
Слово Канеру
Наймите подрядчиков, чтоб получить передышку во время рекрутинга.
Используйте временную помощь, чтоб не торопиться во время поиска нужного человека. Даже в компаниях, строго ограничивающих использование подрядчиков, этот способ часто работает.
понедельник, 14 января 2013 г.
Lesson 231
 |
| Альбом: randompics4lj |
В связи со слухами о ЖЖкапце хочу продублировать свой бложик на альтернативной платформе. А может и переехать.
Варианты:
wordpress
blogger
tumblr
Требования:
1. Импорт из жж. Здесь в выдаче гугла по 700к ссылок для wordpress и blogger, 300к для tumblr. Вывод очевиден.
2. Поддержка опенайди и прочей авторизации. Везде есть.
3. Поддержка rss. Везде есть.
4. Простота ведения. Хм, я думаю, что осилю.
5. Клиент под андроид. Нашел все три, какой из них удобней?
6. Возможность формировать ленты из других блогов, списки интересных блогов итпх.
7. Очень не хочу терять френдов, я вас всех очень ценю и читаю. Несколько лет собирал.
Наверняка вам есть что выразить по этому поводу. От жж-юзеров жду как минимум не-уходи-постой.
Слово Канеру
Ваши решения о найме — самые важные
Найм неподходящего для работы человека — одна из худших ошибок, которые вы сможете сделать в качестве менеджера. Вы застрянете с этой ошибкой на длительное время.
Сделайте все возможное, чтоб нанять хороших людей.
суббота, 12 января 2013 г.
Lesson 230
Вот туточки okiseleva пишет как у нее происходило сессионное тестирование.
Почитайте, интересно.
И у нас было такое кино, но на свой коленкор.
Были у нас сессии массового тестирования, раз и два - это когда несколько человек берут и колбасят одну задачку, но каждый за своим компом, а затем обсуждают что получилось. Проходило это с целью обучения стажеров, меряния багами, обсуждения кейсов и взрыва мозга программиста, которому выкладывали здоровенный список баг. Ибо искали яростно.
Неоднократно занимались мы с наташами тестированием парным, когда они мануально тестят хитрую фичу, я смотрю, конспектирую кейсы для автоматики и даю ценные советы.
Получилось тоже неплохо.
А под новый год мы затеяли совсем-совсем массовое тестирование. Мне лень описывать, поэтому просто процитирую письмо ПМа по результатам.
29 декабря в последний рабочий день года при корпоративе 28го как нельзя хочется встать под знамя с надписью "Что угодно, только не работать!". Но мы пошли другим путем! Мы решили провести мероприятие под кодовым названием "Массовый тест".
Правила игры были такими: участники случайным образом разбиваются на пары, в которой один - представитель команды тестировщиков а второй - представитель второй команды (разработчики + аналитики). Пара берет понравившуюся ей задачу с доски, садится за один компьютер и ее тестирует. Потом берет следующую. И еще. И еще. Пока совсем ничего не останется.
Чего хотелось получить от этой акции:
- приведения в порядок досок (уборка перед НГ, все дела), в т.ч. тестирования задач, которые ждут этого по нескольку недель;
- взаимного обучения участников;
- их синергии: разработчик может предположить источник бага и указать эту информацию при его регистрации; аналитик - немедленно внести в постановку необходимые правки и т.д. и т.п.;
- ну и много-много радости, а как же иначе.
В результате с 11 до 16-17 часов (пары заканчивали в разное время) восемью парами участников было протестировано 35 задач. (а это сильно дофига, прим w_bf)Ура-ура! Не проверили только то, что мешали проверить непреодолимые причины типа воспроизведения дефекта исключительно на рабочем приложении клиента.
Вот что участники говорили об акции (разобрано мной с листочка после опроса участников. Возможна гнусная ложь и отсебятина):
- Это эффективно, потому что оба работают.
- Помогает систематизировать знания.
- Понравилось наблюдать за процессом тестирования и придумывать для него кейсы.
- Плохо, что Коли не было.
(колоритная личность, прим w_bf)
- Тестировать вдвоем интереснее, продуктивнее и просто весело. А тестировать с разработчиком - вдвойне.
- Мы очень много всего сделали.
- Было полезно, узнали много нового.
- Получила ценные идеи, как можно упростить работу.
- Хорошо, что разобрали задачи, которые висели по 2 месяца.
- Очень полезно для знакомства с интерфейсом.
- Было бы здорово провести в формате "2 тестировщика в команде: ведущий и ведомый".
- Разработчики придумывают интересные кейсы.
- Интересный обмен опытом, причем, в обе стороны.
- Понравилось просто тестирование без всякой бюрократии.
- Здорово, что аналитики и разработчики уделяют время таким задачам.
- Хорошо бы проводить такое мероприятие 2 раза в год как PR.
Ну и общее мнение: ПОНРАВИЛОСЬ.
Я, как организатор сего действа, в заключение хочу сказать большое спасибо всем его участникам, а также начальству, разрешившим весь этот беспредел в рабочее время.
Со своей стороны хочу сказать, что я ходила с блокнотом, спрашивала всех "Как?", люди говорили "Понравилось", а я им верила. Потому что лица у всех в процессе были действительно очень увлеченные и заинтересованные. А это главное, пожалуй.
С Новым 2013 годом! В нем мы обязательно придумаем что-нибудь еще.
(Цитата неточная, убрал фамилии и сугубо нашу специфику)
Фот фотка доски с задачками в процессе:
А вот после:
Слово Канеру
Создайте возможности для обучения
Организуйте еженедельные или ежемесячные встречи. Цель в чтении статей или глав книг каждую неделю и их обсуждение (сотрудники обсуждают, вы присутствуете, но много не говорите). Сделайте участие в таких встречах добровольным, не принуждайте присутствовать. Но найдите способ наградить людей, которые вносят свой вклад в обсуждения и регулярно посещают встречи (предоставляйте книги тем, кто показал, что будет их читать).
Организуйте собрания-обучения. Раз в неделю или два раза в месяц. На них — расскажите сами о чем-нибудь новом, иногда можно приносить гостя-спикера (тест-менеджера из другой компании). Вы могли бы найти кого-нибудь, кто мог бы сделать это бесплатно, если вы сами проведете лекцию для его сотрудников. Иногда кто-нибудь из ваших сотрудников может выступить с докладом о технике тестирования или о проблемах в тестировании определенного устройства или приложения. Иногда можно делать упражнения для тренировки навыков.
Если ваша компания возмещает деньги на обучение, найдите курсы, предлагаемые местными университетами или онлайн-курсы, желательно связанные с разработкой ПО. Кроме того выясните, какие конференции по тестированию применимы к проектам компании. Поговорите с сотрудниками лично, помогите им спланировать непрерывное обучение. Этот разговор — отличная возможность обсудить долгосрочные цели сотрудника (примите эти цели во внимание, когда будете распределять следующую волну задач). Don't tell someone what courses to take but do point out courses you think are well-taught and relevant to the company's current projects or to the career interests of your staff member.
Главное правило — отправлять сотрудников на курсы (особенно профессиональные семинары) и конференции в парах и тройках. Они будут говорить друг с другом о том, чему научились. Пусть они сделают презентацию для вас и группы тестирования о том, чему они научились, когда вернутся.
Почитайте, интересно.
И у нас было такое кино, но на свой коленкор.
Были у нас сессии массового тестирования, раз и два - это когда несколько человек берут и колбасят одну задачку, но каждый за своим компом, а затем обсуждают что получилось. Проходило это с целью обучения стажеров, меряния багами, обсуждения кейсов и взрыва мозга программиста, которому выкладывали здоровенный список баг. Ибо искали яростно.
Неоднократно занимались мы с наташами тестированием парным, когда они мануально тестят хитрую фичу, я смотрю, конспектирую кейсы для автоматики и даю ценные советы.
Получилось тоже неплохо.
А под новый год мы затеяли совсем-совсем массовое тестирование. Мне лень описывать, поэтому просто процитирую письмо ПМа по результатам.
29 декабря в последний рабочий день года при корпоративе 28го как нельзя хочется встать под знамя с надписью "Что угодно, только не работать!". Но мы пошли другим путем! Мы решили провести мероприятие под кодовым названием "Массовый тест".
Правила игры были такими: участники случайным образом разбиваются на пары, в которой один - представитель команды тестировщиков а второй - представитель второй команды (разработчики + аналитики). Пара берет понравившуюся ей задачу с доски, садится за один компьютер и ее тестирует. Потом берет следующую. И еще. И еще. Пока совсем ничего не останется.
Чего хотелось получить от этой акции:
- приведения в порядок досок (уборка перед НГ, все дела), в т.ч. тестирования задач, которые ждут этого по нескольку недель;
- взаимного обучения участников;
- их синергии: разработчик может предположить источник бага и указать эту информацию при его регистрации; аналитик - немедленно внести в постановку необходимые правки и т.д. и т.п.;
- ну и много-много радости, а как же иначе.
В результате с 11 до 16-17 часов (пары заканчивали в разное время) восемью парами участников было протестировано 35 задач. (а это сильно дофига, прим w_bf)Ура-ура! Не проверили только то, что мешали проверить непреодолимые причины типа воспроизведения дефекта исключительно на рабочем приложении клиента.
Вот что участники говорили об акции (разобрано мной с листочка после опроса участников. Возможна гнусная ложь и отсебятина):
- Это эффективно, потому что оба работают.
- Помогает систематизировать знания.
- Понравилось наблюдать за процессом тестирования и придумывать для него кейсы.
- Плохо, что Коли не было.
(колоритная личность, прим w_bf)
- Тестировать вдвоем интереснее, продуктивнее и просто весело. А тестировать с разработчиком - вдвойне.
- Мы очень много всего сделали.
- Было полезно, узнали много нового.
- Получила ценные идеи, как можно упростить работу.
- Хорошо, что разобрали задачи, которые висели по 2 месяца.
- Очень полезно для знакомства с интерфейсом.
- Было бы здорово провести в формате "2 тестировщика в команде: ведущий и ведомый".
- Разработчики придумывают интересные кейсы.
- Интересный обмен опытом, причем, в обе стороны.
- Понравилось просто тестирование без всякой бюрократии.
- Здорово, что аналитики и разработчики уделяют время таким задачам.
- Хорошо бы проводить такое мероприятие 2 раза в год как PR.
Ну и общее мнение: ПОНРАВИЛОСЬ.
Я, как организатор сего действа, в заключение хочу сказать большое спасибо всем его участникам, а также начальству, разрешившим весь этот беспредел в рабочее время.
Со своей стороны хочу сказать, что я ходила с блокнотом, спрашивала всех "Как?", люди говорили "Понравилось", а я им верила. Потому что лица у всех в процессе были действительно очень увлеченные и заинтересованные. А это главное, пожалуй.
С Новым 2013 годом! В нем мы обязательно придумаем что-нибудь еще.
(Цитата неточная, убрал фамилии и сугубо нашу специфику)
Фот фотка доски с задачками в процессе:
 |
| Альбом: office |
А вот после:
 |
| Альбом: office |
Слово Канеру
Создайте возможности для обучения
Организуйте еженедельные или ежемесячные встречи. Цель в чтении статей или глав книг каждую неделю и их обсуждение (сотрудники обсуждают, вы присутствуете, но много не говорите). Сделайте участие в таких встречах добровольным, не принуждайте присутствовать. Но найдите способ наградить людей, которые вносят свой вклад в обсуждения и регулярно посещают встречи (предоставляйте книги тем, кто показал, что будет их читать).
Организуйте собрания-обучения. Раз в неделю или два раза в месяц. На них — расскажите сами о чем-нибудь новом, иногда можно приносить гостя-спикера (тест-менеджера из другой компании). Вы могли бы найти кого-нибудь, кто мог бы сделать это бесплатно, если вы сами проведете лекцию для его сотрудников. Иногда кто-нибудь из ваших сотрудников может выступить с докладом о технике тестирования или о проблемах в тестировании определенного устройства или приложения. Иногда можно делать упражнения для тренировки навыков.
Если ваша компания возмещает деньги на обучение, найдите курсы, предлагаемые местными университетами или онлайн-курсы, желательно связанные с разработкой ПО. Кроме того выясните, какие конференции по тестированию применимы к проектам компании. Поговорите с сотрудниками лично, помогите им спланировать непрерывное обучение. Этот разговор — отличная возможность обсудить долгосрочные цели сотрудника (примите эти цели во внимание, когда будете распределять следующую волну задач). Don't tell someone what courses to take but do point out courses you think are well-taught and relevant to the company's current projects or to the career interests of your staff member.
Главное правило — отправлять сотрудников на курсы (особенно профессиональные семинары) и конференции в парах и тройках. Они будут говорить друг с другом о том, чему научились. Пусть они сделают презентацию для вас и группы тестирования о том, чему они научились, когда вернутся.
пятница, 11 января 2013 г.
четверг, 10 января 2013 г.
Lesson 229
Отличная периодическая таблица методов визуализации.
Обнаружил у Александра Селяева.
Да, а о праздниках пост писать просто лень. Они, внезапно, были. Работал я из них не больше пары дней, что тоже нетипично.
Потом напишу. С фотками, может даже.
Слово Канеру
Не позволяйте злоупотреблять вашими сотрудниками
Люди иногда плохо обращаются с тестировщиками, запугивают, называют дураками, лжецами и так далее. Если вы тест менеджер и ваши сотрудники работают в жестких проектах, то вам, скорее всего, придется гнуть свою линию. Будьте готовы оказать сотрудникам эмоциональную поддержку и дать отпор противникам.
Парное тестирование также может быть хорошим способом обеспечить поддержку тестировщикам.
В окружении, которое оказывает высокое давление, некоторые ваши сотрудники могут сделать то, о чем пожалеют. Не делайте выговоры публично. Расскажите о недопустимости поведения в личной беседе. Если же поступок повторяется — проведите обычные дисциплинарные процедуры принятые в компании.
Обнаружил у Александра Селяева.
 |
| Альбом: office |
Да, а о праздниках пост писать просто лень. Они, внезапно, были. Работал я из них не больше пары дней, что тоже нетипично.
Потом напишу. С фотками, может даже.
Слово Канеру
Не позволяйте злоупотреблять вашими сотрудниками
Люди иногда плохо обращаются с тестировщиками, запугивают, называют дураками, лжецами и так далее. Если вы тест менеджер и ваши сотрудники работают в жестких проектах, то вам, скорее всего, придется гнуть свою линию. Будьте готовы оказать сотрудникам эмоциональную поддержку и дать отпор противникам.
Парное тестирование также может быть хорошим способом обеспечить поддержку тестировщикам.
В окружении, которое оказывает высокое давление, некоторые ваши сотрудники могут сделать то, о чем пожалеют. Не делайте выговоры публично. Расскажите о недопустимости поведения в личной беседе. Если же поступок повторяется — проведите обычные дисциплинарные процедуры принятые в компании.
вторник, 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 большая текучесть кадров среди менеджеров. Реорганизация случится. Дураки приходят и уходят. Ваша задача — уменьшить влияние таких людей, как они, на персонал.
С виду ок, только с именем небольшая беда, но будем потихоньку приучать отзываться на Наташу.
Пыщ-пыщ!
Слово Канеру
Не злоупотребляйте сверхурочными ваших сотрудников
Многие группы тестирования постоянно работают сверхурочно. В некоторых компаниях тестировщики работают по гораздо более экстремальным графикам, чем разработчики.
Хроническая переработка ведет к выгоранию сотрудников, высокой текучести кадров, цинизму, политике, к небрежной и неэффективной работе. Мы призываем вас защитить персонал от всего этого.
Многим проектам нужна краткосрочная экстренная помощь в критические моменты. Это нормальная часть бизнеса. И это не то, о чем мы говорим. Помните, однако, что у сотрудников есть свой предел. У некоторых есть себейные обязательства или другие, которые могут не быть гибкими. 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).
Слил в 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.
Слово Канеру
Не ставьте начинающих тестировщиков на почти завершенные проекты.
Если вы должны добавить сотрудника в проект, близкий к завершению, не назначайте новичка. Назначьте человека. Который много знает о тестировании. Опытный тестировщик знает, как читать матрицы тестирования, диаграммы границ и остальную документацию тестирования (или сможет быстро разобраться). Все что вы должны будете сказать ему — что тестировать, а не как проводить каждый тест. Ему понадобится время, чтоб познакомиться с продуктом, но он сможет стать продуктивным, не занимая слишком много вашего времени и времени коллег.
Новичок, однако, потребует гораздо больше ваших инструкций о том, как тестировать. Некоторые группы тестирования тратят огромное количество времени на написание пошаговых инструкций для новичков. Мы считаем, что было бы лучше для таких групп, если бы они потратили это время на поиск ошибок и их исправление. Мы считаем, что новички, использующие подобные инструкции, скорее всего, пропустят больше ошибок, так как они просто не знают о существовании определенного класса ошибок, так как для него нет инструкций, которые смогли бы передать необходимый диапазон наблюдения и навыки интерпретации.
Нанимайте новичков, когда у вас есть время, чтоб обучить их, 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, в таком случае (в зависимости от политики компании) тестировщик переоткроет существующий дефект или заведет новый, описывающий текущее поведение с перекрестной ссылкой на старый.
Ретест исправленных, но не закрытых багов Баг возвращается — исправленным, отложенным, невоспроизводимым или отклоненным каким любо другим способом. Тестировщики, которые о нем сообщили, будут повторно проверять его и закрывать. Новым тестировщикам также будет полезно исследовать такие ошибки. После его исследования пусть он поговорит с человеком, который нашел эту ошибку. Этот человек и вы могли бы дать новичку обратную связь о его подходе, тактике поиска багов, способу принятия решения о том, сколько времени нужно тратить на повторное тестирование ошибки. Когда вы будете удовлетворены его уровнем, разрешите ему самостоятельно закрывать баги.
Слово Канеру
Пусть новые тестировщики займутся ретестом старых багов перед поиском новых.
Полезно познакомить новых тестировщиков с багами в трекере путем повторного тестирования дефектов. Мы используем три класса задач. Каждая из них может помочь тестировщику изучить продукт, узнать, как он ломается, как это нужно проверять и что об этом можно узнать в трекере.
Актуализация открытых ошибок Тестируя каждый баг, тестировщик может сообщить, что он все еще воспроизводится. При этом он отмечает дату, 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, лекции
Я грешен теми же ответами, что и вы. Оправдания найти и защищаться.
Но надо, ящетаю, надо как-то идти к тому, чтоб первым вопросом был: "А как они это делают?"
Есть хорошая книга «Я возьму сам» у Олди. И лейтмотив у нее замечательный. Хм.
Слово Канеру
Дайте начинающим тестировщикам проверку старых багрепортов перед тем как разрешить писать новые.
Здесь новый тестировщик — это новый человек в тестировании, а не для вашего проекта. Он должен научиться основным навыкам тестирования, а не тому как проверять ваш продукт.
Один из способов тренировки нового тестировщика — актуализация старых дефектов и их переформулирование, чтоб сделать более понятными и эффективными. Они включает в себя формулирование проблемы и ее воспроизведение (поиск более серьезной проблемы первопричины и более широкого круга обстоятельств, в которой проявляется дефект. Дайте тестировщику обратную связь по тону его формулировок, их ясности и его творческому подходу к воспроизведению.
Когда вы будете удовлетворены и посчитаете, что новый тестировщик может писать разумные багрепорты — пусть пишет их. До этого момента, возможно, он не должен постить баги.
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).
Заставьте новых тестировщиков проверять пользовательскую документацию
Новый тестировщик — новый человек в проекте, а не в тестировании. Он мог работать или не работать тестировщиком в другом проекте — неважно.
Один из способов познакомить новичка с продуктом — дать ему проверить соответствие пользовательской документации и программного обеспечения. К концу такого тестирования он узнает всю программу.
Это хорошая задача — тщательная проверка бумажной и интерактивной справки. Пользователи используют их, чтоб познакомиться с ПО или когда у них возникают проблемы. Кроме того, в продуктах массового рынка документация, скорее всего, гарантирует описываемое поведение продукта. От этого типа гарантии основанного на практически письменном заявлении производителя, нельзя отказаться или избавиться, как это иногда бывает можно в других контрактах. Все, что описано в документации, может быть использовано в качестве доказательства того, что в продукте есть дефект (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.
Если да, то интересный подход — наставник не из профессии. У нас бы он порвал шаблон. Но, ящетаю, был бы полезен. Люблю эксперименты над людьми.
Слово Канеру
Помогите новым тестировщикам быть успешными
Когда вы берете кого-нибудь в группу, сделайте несколько вещей, чтоб сделать их первые недели успешными:
- Выберите место для тестировщика и обеспечьте его всем необходимым: компьютерами, программным обеспечением, проектной документацией — до приезда самого тестировщика.
- Планируйте потратить по крайней мере день на встречу нового сотрудника. Проведите его по отделу, представьте всем, с кем он будет работать, поговорите с ним о ваших надеждах и ожиданиях относительно него.
- Назначьте ему наставника. Наставник покажет тестировщику все, ответит на его вопросы, предложит что нужно, сходить с ним на обед несколько раз, как правило, тоже полезно. Наставник не контролирует тестировщика и не сообщает ничего о нем вам, если только не возникает серьезная проблема. Некоторые компании привлекают наставников из других отделов (наставником может быть программист или маркетолог). Преимущество такого подхода — установление связи между отделами. Недостаток — наставник не может тренировать технические навыки для работы тестировщика.
Тем не менее самым полезным, что я узнал за декабрь — то, как завязывать шнурки, чтоб они постоянно не развязывались.
Вот оно как.
Кстати, по сегодняшней лекции, правильно ли я перевел:
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 режиме.
Интерфейс спроектирован для творческих людей.
Под катом фото запущенного планшета и в разобранном состоянии.
и
Слово Канеру
Просматривайте записи техсаппорта.
Чтоб получить представление о типах проблем, которые появятся после установки и начала работы программы, читайте жалобы клиентов вашей компании (записи телефонных разговоров, письма). Спросите себя, что вы могли бы сделать, чтоб уменьшить вероятность появления этих звонков. Спросите себя, какие типы тестов могут выявить общие проблемы, если таковые имеются, на стадии тестирования.
Всем сотрудникам бесплатно выдаются планшеты. Характеристики:
диагональ 15''
16 миллионов цветов.
Перьевой ввод, различает 400 степеней нажатия, возможность обработки наклона пера.
Мультитач до 50 касаний.
Сменные карты памяти.
Работает больше 20 часов без зарядки.
Корпус: металл, пластик.
Вес: 70г
Поддержка карт в offline режиме.
Интерфейс спроектирован для творческих людей.
Под катом фото запущенного планшета и в разобранном состоянии.
 |
| Альбом: office |
и
 |
| Альбом: office |
Слово Канеру
Просматривайте записи техсаппорта.
Чтоб получить представление о типах проблем, которые появятся после установки и начала работы программы, читайте жалобы клиентов вашей компании (записи телефонных разговоров, письма). Спросите себя, что вы могли бы сделать, чтоб уменьшить вероятность появления этих звонков. Спросите себя, какие типы тестов могут выявить общие проблемы, если таковые имеются, на стадии тестирования.
среда, 5 декабря 2012 г.
Lesson 218
"Окончательный диагноз" очень даже ок.
Теперь - ТОС Голдрат, за ним попробую "Та самая цель" он же.
Слово Канеру
Активно работайте над улучшением навыков
Недостаточно просто сказать «я сегодня буду осваивать cause-effect диаграммы». Если техника поиска багов, написания отчетов, оценки багов стоит изучения, то вам, вероятно, придется выполнить ряд задач для практики. Сложно улучшать навыки, когда изменяются технологии, рынок, средства разработки, продукты. Но даже если это не так просто, вы должны делать эту работу, чтоб оставаться в курсе событий и это является хорошей основой для вашего статуса в компании.
Теперь - ТОС Голдрат, за ним попробую "Та самая цель" он же.
Слово Канеру
Активно работайте над улучшением навыков
Недостаточно просто сказать «я сегодня буду осваивать cause-effect диаграммы». Если техника поиска багов, написания отчетов, оценки багов стоит изучения, то вам, вероятно, придется выполнить ряд задач для практики. Сложно улучшать навыки, когда изменяются технологии, рынок, средства разработки, продукты. Но даже если это не так просто, вы должны делать эту работу, чтоб оставаться в курсе событий и это является хорошей основой для вашего статуса в компании.
вторник, 4 декабря 2012 г.
Lesson 217
Сегодня хороший день.
Много интересного, полезного и забавного общения.
Прочел во второй раз "death march" Йордана, начал читать "Окончательный диагноз" Хейли.
It Was a Very Good Year
Слово Канеру
Создайте экспертизу сотрудников по релевантным технологиям.
С ростом сложности аппаратного и программного обеспечения, возникает все больше проблем взаимодействия между нашим приложением и сторонними, с удаленными серверами, оборудованием — которое находится вне непосредственного контроля разработчика приложения. Nguyen (2000) introduces Web application testers to тестирования этих типов взаимодействий, и чтоб с успехом им заниматься, вы должны много знать о железе и софте (он дает полезные вводные материалы).
Кроме того, вашей группе пойдет на пользу, если некоторые ваши сотрудники поймут технологии, с которыми работают программисты. Например, было бы полезно, если некоторые ваши тестировщики больше узнают о библиотеке компонент, используемой программистами и то, как писать программы для тестирования этих компонент через API.
Много интересного, полезного и забавного общения.
Прочел во второй раз "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.
- Отвечайте на звонки в техническую поддержку вашего продукта несколько часов в неделю. Сперва вам придется немного обучиться работе технической поддержки. В конце концов вы научитесь этому и узнаете много нового (если вы делали эту работу всерьез, задавая вопросы и исследуя жалобы, которые услышали).
Создавайте экспертизу сотрудников в предметной области.
Эффективность сотрудников возрастет, когда они узнают больше о внешних фактах, ограничивающих архитектуру продукта, о том, как люди используют (или не используют) продукты, такие как ваш, какие проблемы для них важны, как они решают эти проблемы, о том, что пишут о использовании этого вида продуктов.
Вы могли бы накапливать экспертизу несколькими путями:
- Читать журналы и книги, которые были написаны для людей, подобных вашим заказчикам.
- Идти на занятия (желательно на те, где учат сотрудников не только вашей компании) обучающие клиентов пользоваться вашим продуктом после того, как он будет готов.
- Идти на занятия, обучающие предметной области продукта. Например, если вы создаете софт для продажи недвижимости, пройдите обучение брокера по недвижимости, ипотечного брокера или оценщика.
- Работайте на объектах клиентов. Это может быть аренда сотрудника (например, ваша компания предоставляет важному клиенту своего сотрудника на несколько недель — время установки продукта и обучение ему) или работы на неполный рабочий день (убедитесь, что компания вам это позволит).
- 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.
- Отвечайте на звонки в техническую поддержку вашего продукта несколько часов в неделю. Сперва вам придется немного обучиться работе технической поддержки. В конце концов вы научитесь этому и узнаете много нового (если вы делали эту работу всерьез, задавая вопросы и исследуя жалобы, которые услышали).
Подписаться на:
Сообщения (Atom)