Один сотрудник о perfomance review.
- "Я просил рыбок, а они наняли еще двух hr'ов"
пятница, 26 июля 2013 г.
Рутина
Вот давно известно — мудаков, обычно, минимум двое. Если хоть кто-то не мудак, то вероятность того, что случится ебула падает в разы.
Отсюда вот:
http://vampa-odin.livejournal.com/39694.html
Отсюда вот:
http://vampa-odin.livejournal.com/39694.html
вторник, 23 июля 2013 г.
Lesson 279
Речь Барри Шварца. Речь которой аудитория апплодировала стоя.
Перевод от alexthunder
О мудрости, личной инициативе, морали, соблюдении и несблюдении инструкций. Настоятельно рекомендую.
Видео:
Цитата:
"Инстуркции нужны нам для того чтобы спасать нас от катастроф. И они спасают. Одновременно инструкция гарантирует что болван останется болваном."
Слово Канеру
Не позволяйте логистике и артефактам заслонить собой стратегию
Стратегия часто теряется в блеске частей плана тестирования. Мы видели документацию к плану тестирования, дающую подробное описание команды и артефактов, но не говорящую ничего о том, как будет тестироваться продукт. This seems backward. Это означает, что мы просто посадим тестировщика перед клавиатурой в нужное время. Не ожидайте, что ваши коллеги будут уважать то, что вы делаете, как тестировщик, если вы не говорите им об этом.
Перевод от alexthunder
О мудрости, личной инициативе, морали, соблюдении и несблюдении инструкций. Настоятельно рекомендую.
Видео:
Цитата:
"Инстуркции нужны нам для того чтобы спасать нас от катастроф. И они спасают. Одновременно инструкция гарантирует что болван останется болваном."
Слово Канеру
Не позволяйте логистике и артефактам заслонить собой стратегию
Стратегия часто теряется в блеске частей плана тестирования. Мы видели документацию к плану тестирования, дающую подробное описание команды и артефактов, но не говорящую ничего о том, как будет тестироваться продукт. This seems backward. Это означает, что мы просто посадим тестировщика перед клавиатурой в нужное время. Не ожидайте, что ваши коллеги будут уважать то, что вы делаете, как тестировщик, если вы не говорите им об этом.
четверг, 18 июля 2013 г.
Lesson 278
Сонный Ебург со своими продуктами, это, конечно, не высококонкурентный Киев, разрабатывающий софт для загнивающих пендосов по аутсорсу.
Но все же, где мои три штуки баксов?
Слово Канеру
Используйте план тестирования, чтоб зафиксировать выбор стратегии, логистики и артефакты.
Хороший план тестирования, задокументирован он или нет, состоит из набора решений по процессу тестирования. Нужно определиться с тремя основными категориями:
- Стратегия. Как вы будете покрывать продукт, чтоб найти быстро важные проблемы? Что именно вы будете тестировать? Какими способами вы будете создавать тесты? Как вы будете определять ошибки? Стратегия тестирования определяет связь между проектом тестирования и миссией тестирования.
- Логистика. Какие ресурсы вы используете для реализации стратегии? Кто будет тестировать? Когда они будут это делать? Что нужно для получения результата?
- Артефакты работы. Как вы представите работу заказчикам? Как вы будете отслеживать ошибки? Какую тестовую документацию создадите? Какие отчеты создадите?
Если вы не сделаете выбор явно, то вы сделаете его неявно в процессе работы. У вас нет возможности не делать выбор, пока вы не откажетесь от тестирования.
Но все же, где мои три штуки баксов?
Слово Канеру
Используйте план тестирования, чтоб зафиксировать выбор стратегии, логистики и артефакты.
Хороший план тестирования, задокументирован он или нет, состоит из набора решений по процессу тестирования. Нужно определиться с тремя основными категориями:
- Стратегия. Как вы будете покрывать продукт, чтоб найти быстро важные проблемы? Что именно вы будете тестировать? Какими способами вы будете создавать тесты? Как вы будете определять ошибки? Стратегия тестирования определяет связь между проектом тестирования и миссией тестирования.
- Логистика. Какие ресурсы вы используете для реализации стратегии? Кто будет тестировать? Когда они будут это делать? Что нужно для получения результата?
- Артефакты работы. Как вы представите работу заказчикам? Как вы будете отслеживать ошибки? Какую тестовую документацию создадите? Какие отчеты создадите?
Если вы не сделаете выбор явно, то вы сделаете его неявно в процессе работы. У вас нет возможности не делать выбор, пока вы не откажетесь от тестирования.
понедельник, 15 июля 2013 г.
Lesson 277
Пока я стонал, что мне мешал дождик, enlightened боец Raspberries забацала нехилый trip автостопом(!) по уралу и создала, между прочим, вот такенное поле:
Слово Канеру
Проектируйте ваш план тестирования так, чтоб он соответствовал контексту.
Один из способов видуализации плана тестирования показан на рисунке. Это Satisfice Context Model. Пять пузырей на лучах звезды представляют то, что у нас имеется: ресурсы и ограничения. Центр звезды — наше решение. Объект планирования — решения по процессу тестирования, которые позволяют в рамках ограничений среды проекта и используя ресурсы достичь целей миссии.
Пять сущностей на картинке:
- Разработка. Система, которую вы тестируете. Как вы получаете продукт? Как его можно тестировать?
- Требования. Критерии качества продукта. Риски продукта. Чье мнение о качестве важно.
- Команда тестирования. Люди, которые тестируют продукт. Вы нанимаете команду? Are they up to speed on the technology?
- Лаборатория тестирования. Системы, инструменты, материалы, которые позволяют вам делать вашу работу. Есть ли у вас необходимое оборудование? В каком состоянии ваш баг-трекер?
- Миссии. Проблемы, решение которых будет рассматриваться как успех вашими клиентами. Находите ли вы быстро критичные баги? Производите ли точную оценку качества?
У вас есть возможность провести переговоры, чтоб улучшить эти исходные данные. У вас есть возможность нанять персонал или убедить программистов сделать продукт более проверяемым. Тем не менее, вы не имеете право ожидать большего контроля над этими предустановками. Ваше управление в том и заключается — как вы реагируете на такую ситуацию: какова будет ваша стратегия, логистика и рабочий процесс?
 |
| Альбом: Ingress |
Слово Канеру
Проектируйте ваш план тестирования так, чтоб он соответствовал контексту.
Один из способов видуализации плана тестирования показан на рисунке. Это Satisfice Context Model. Пять пузырей на лучах звезды представляют то, что у нас имеется: ресурсы и ограничения. Центр звезды — наше решение. Объект планирования — решения по процессу тестирования, которые позволяют в рамках ограничений среды проекта и используя ресурсы достичь целей миссии.
 |
| Альбом: bug |
Пять сущностей на картинке:
- Разработка. Система, которую вы тестируете. Как вы получаете продукт? Как его можно тестировать?
- Требования. Критерии качества продукта. Риски продукта. Чье мнение о качестве важно.
- Команда тестирования. Люди, которые тестируют продукт. Вы нанимаете команду? Are they up to speed on the technology?
- Лаборатория тестирования. Системы, инструменты, материалы, которые позволяют вам делать вашу работу. Есть ли у вас необходимое оборудование? В каком состоянии ваш баг-трекер?
- Миссии. Проблемы, решение которых будет рассматриваться как успех вашими клиентами. Находите ли вы быстро критичные баги? Производите ли точную оценку качества?
У вас есть возможность провести переговоры, чтоб улучшить эти исходные данные. У вас есть возможность нанять персонал или убедить программистов сделать продукт более проверяемым. Тем не менее, вы не имеете право ожидать большего контроля над этими предустановками. Ваше управление в том и заключается — как вы реагируете на такую ситуацию: какова будет ваша стратегия, логистика и рабочий процесс?
воскресенье, 14 июля 2013 г.
Кино
Спасибо Транку, теперь и я рекомендую фильм Memento.
Фильм про жесткий таск менеджмент и контроль над жизнью, что ли.
У мужика кратковременная память минут десять... и не пишется в долговременную.
Мне кажется, Максиму cartmendum должно понравиться.
Фильм про жесткий таск менеджмент и контроль над жизнью, что ли.
У мужика кратковременная память минут десять... и не пишется в долговременную.
Мне кажется, Максиму cartmendum должно понравиться.
суббота, 13 июля 2013 г.
Lesson 276
Ingress и прочие велопоездки накрылись погодой.
Слово Канеру
Реальный план тестирования тест это набор идей, которым следует процесс тестирования.
План тестирования — основная идея всего, что вы делаете. Иметь эту идею очень важно. Документировать ли эту идею или нет — тема отдельного разговора.
Всякий раз, когда вы слышите аргументацию о том, что нужно задокументировать то, что вы намерены сделать, помните о цену создания документации. Должна это быть хорошая или плохая документация? Большинство людей согласятся с тем, что плохую документацию создавать не стоит. Проблема в том, что хорошую документацию создать и поддерживать очень дорого.
Есть очень много литературы, в которой говорится, что вы не сможете хорошо протестировать без письменного плана тестирования. По нашему опыту, основной положительный эффект от такого совета — гарантия занятости для производителей тонера и бумаги. Мы видели массу хороших тестов, которые провели без соблюдения записанных планов. Время для совета получше.
Не путайте содержимое плана и объекты, с которыми вы работаете и которыми вы управляете с помощью плана. У вас есть много других возможностей работать, кроме написания трактата: устный план, план на доске, одностраничный план, несколько писем, рисунки. Делайте то, что выполнит миссию.
Слово Канеру
Реальный план тестирования тест это набор идей, которым следует процесс тестирования.
План тестирования — основная идея всего, что вы делаете. Иметь эту идею очень важно. Документировать ли эту идею или нет — тема отдельного разговора.
Всякий раз, когда вы слышите аргументацию о том, что нужно задокументировать то, что вы намерены сделать, помните о цену создания документации. Должна это быть хорошая или плохая документация? Большинство людей согласятся с тем, что плохую документацию создавать не стоит. Проблема в том, что хорошую документацию создать и поддерживать очень дорого.
Есть очень много литературы, в которой говорится, что вы не сможете хорошо протестировать без письменного плана тестирования. По нашему опыту, основной положительный эффект от такого совета — гарантия занятости для производителей тонера и бумаги. Мы видели массу хороших тестов, которые провели без соблюдения записанных планов. Время для совета получше.
Не путайте содержимое плана и объекты, с которыми вы работаете и которыми вы управляете с помощью плана. У вас есть много других возможностей работать, кроме написания трактата: устный план, план на доске, одностраничный план, несколько писем, рисунки. Делайте то, что выполнит миссию.
пятница, 12 июля 2013 г.
Lesson 275
Слово Канеру
Существует много возможных стратегий тестирования
Стратегия тестирования это набор вариантов. Вы можете использовать несколько:
- Мы выпустим продукт для лояльных пользователей, после короткой внутренней проверки, которая позволит найти самые серьезные проблемы. Лояльные пользователи расскажут о изменениях в продукте, которые они хотели предложить после недолгой эксплуатации.
- Мы определим сценарии использования продукта в виде последовательностей действий с продуктом. Эти сценарии опишут все действия, которые нормальные пользователи совершают. Мы расширим тесты стресс-тестированием и тестированием ненормального использования (некорректные данные и условия). Нашим приоритетом будет поиск фундаментальных отклонений от зафиксированного поведения, но также мы посвятим время поиску нарушений ожидаемого поведения. Надежность также является проблемой, но мы еще не решили, как ее оценить.
- Мы будем осуществлять параллельное развитие исследовательского тестирования и автоматизированного регрессионного тестирования. Исследовательское тестирование будет основано на рисках и покрывать критичные участки. Их мы будем переопределять участки раз в неделю. Регрессионное автоматизированное тестирование будет сосредоточено на проверке основных функций (дающих возможность тестировать), чтоб обеспечить возможность раннего предупреждения о сбоях в основной функциональности. Мы будем готовы с большим объемам случайного тестирования.
Каждый из этих пунктов — стратегия. Обратите внимание, что все они разные. У каждой есть свой акцент. Каждая рассказывает небольшую историю о том, что мы будем проверять. Хорошая стратегия рассказывает интересные истории, объясняющие и оправдывающие то, как будет проведено тестирование. Так же, как существует много интересных историй, которые можно рассказать, существует много стратегий тестирования.
Отметим, что каждая стратегия весьма универсальна. На реальном проекте мы воспользуемся знаниями о архитектуре продукта для создания специфичной стратегии. Тем не менее, эти общие пункты показывают, что стратегия тестирования это нечто большее, чем набор методов, но меньшее, чем полномасштабный план тестирования.
Существует много возможных стратегий тестирования
Стратегия тестирования это набор вариантов. Вы можете использовать несколько:
- Мы выпустим продукт для лояльных пользователей, после короткой внутренней проверки, которая позволит найти самые серьезные проблемы. Лояльные пользователи расскажут о изменениях в продукте, которые они хотели предложить после недолгой эксплуатации.
- Мы определим сценарии использования продукта в виде последовательностей действий с продуктом. Эти сценарии опишут все действия, которые нормальные пользователи совершают. Мы расширим тесты стресс-тестированием и тестированием ненормального использования (некорректные данные и условия). Нашим приоритетом будет поиск фундаментальных отклонений от зафиксированного поведения, но также мы посвятим время поиску нарушений ожидаемого поведения. Надежность также является проблемой, но мы еще не решили, как ее оценить.
- Мы будем осуществлять параллельное развитие исследовательского тестирования и автоматизированного регрессионного тестирования. Исследовательское тестирование будет основано на рисках и покрывать критичные участки. Их мы будем переопределять участки раз в неделю. Регрессионное автоматизированное тестирование будет сосредоточено на проверке основных функций (дающих возможность тестировать), чтоб обеспечить возможность раннего предупреждения о сбоях в основной функциональности. Мы будем готовы с большим объемам случайного тестирования.
Каждый из этих пунктов — стратегия. Обратите внимание, что все они разные. У каждой есть свой акцент. Каждая рассказывает небольшую историю о том, что мы будем проверять. Хорошая стратегия рассказывает интересные истории, объясняющие и оправдывающие то, как будет проведено тестирование. Так же, как существует много интересных историй, которые можно рассказать, существует много стратегий тестирования.
Отметим, что каждая стратегия весьма универсальна. На реальном проекте мы воспользуемся знаниями о архитектуре продукта для создания специфичной стратегии. Тем не менее, эти общие пункты показывают, что стратегия тестирования это нечто большее, чем набор методов, но меньшее, чем полномасштабный план тестирования.
вторник, 9 июля 2013 г.
Lesson 274
Намедни купили и повесили на стену большие карты Екатеринбурга и области. А еще попросил на работе много много синих и зеленых... гм.. булавок? Втыкалок в карту, короче.
Теперь можно делать вид, что мы оперативный штаб Enlightened и собирать всякую развединформацию. Если бы рисунок распределения сил менялся не так часто - можно было бы хоть нитки натягивать.
Слово Канеру
Три основных вопроса о стратегии тестирования «Зачем?», «Кому это нужно?» и «Сколько?»
В конечном счете, есть только одна причина, по которой вы тестируете: что-то важное может пойти не так. Ваш процесс тестирования существует для выявления, исследования и отчета о рисках, благодаря которым продукт может провалиться. Вот почему важно задать три вопроса о вашей стратегии тестирования:
- «Зачем?» Тестирование очень дорого. Не включайте в стратегию активности, которые не обращены к риску, достаточно важному, чтоб ради него проводить тестирование.
- «Кому это нужно?» Причины тестирования не являются законами природы, они коренятся в чувствах и ценностях людей, которым это важно. Не включайте в свою деятельность активности, если они не служат чьим-либо интересам.
- «Сколько?» Некоторые стратегии гораздо легче озвучить, чем реализовать. Мы протестируем все комбинации функций принтера — короткое предложение, включающее в себя тысячи (или сотни тысяч) тестов. Сколько из них вы в действительности проведете?
Теперь можно делать вид, что мы оперативный штаб Enlightened и собирать всякую развединформацию. Если бы рисунок распределения сил менялся не так часто - можно было бы хоть нитки натягивать.
Слово Канеру
Три основных вопроса о стратегии тестирования «Зачем?», «Кому это нужно?» и «Сколько?»
В конечном счете, есть только одна причина, по которой вы тестируете: что-то важное может пойти не так. Ваш процесс тестирования существует для выявления, исследования и отчета о рисках, благодаря которым продукт может провалиться. Вот почему важно задать три вопроса о вашей стратегии тестирования:
- «Зачем?» Тестирование очень дорого. Не включайте в стратегию активности, которые не обращены к риску, достаточно важному, чтоб ради него проводить тестирование.
- «Кому это нужно?» Причины тестирования не являются законами природы, они коренятся в чувствах и ценностях людей, которым это важно. Не включайте в свою деятельность активности, если они не служат чьим-либо интересам.
- «Сколько?» Некоторые стратегии гораздо легче озвучить, чем реализовать. Мы протестируем все комбинации функций принтера — короткое предложение, включающее в себя тысячи (или сотни тысяч) тестов. Сколько из них вы в действительности проведете?
Глава 11
В тему Канера, из рабочего канала тестировщиков:
/w: план тестирования и стратегия тестирования
/w: Задание на 3: правильно ответить, какое из этих двух понятий включает в себя другое
/w: Задание на 4: объяснить разницу между ними, не используя выражения "в целом" и "в общем"
/w: Задание на 5, бонус - печенька: дать две ссылки в локальной вики на эти артефакты
Слово Канеру
Глава 11 Планирование стратегии тестирования
План тестирования является набором идей, ведущих за собой процесс тестирования. Мы используем термин стратегия тестирования для обозначения набора идей, определяющих дизайн тестов на протяжении всего проекта. Стратегия тестирования является частью хорошего плана тестирования. Именно это является связью между собственно тестированием и вашей миссией. В учебниках много сказано о логистике и артефактах тестирования, но не о той стратегии, о которой пойдет речь в этой главе.
/w: план тестирования и стратегия тестирования
/w: Задание на 3: правильно ответить, какое из этих двух понятий включает в себя другое
/w: Задание на 4: объяснить разницу между ними, не используя выражения "в целом" и "в общем"
/w: Задание на 5, бонус - печенька: дать две ссылки в локальной вики на эти артефакты
Слово Канеру
Глава 11 Планирование стратегии тестирования
План тестирования является набором идей, ведущих за собой процесс тестирования. Мы используем термин стратегия тестирования для обозначения набора идей, определяющих дизайн тестов на протяжении всего проекта. Стратегия тестирования является частью хорошего плана тестирования. Именно это является связью между собственно тестированием и вашей миссией. В учебниках много сказано о логистике и артефактах тестирования, но не о той стратегии, о которой пойдет речь в этой главе.
понедельник, 8 июля 2013 г.
Lesson 273
Черт побери, я 8 level ingress. Viva enlightened.
Для непосвященных, это примерно 1000 км с мая на велике.
Слово Канеру
О лицензировании инженеров ПО
Должны ли инженеры ПО (включая тестировщиков) быть лицензированы? Другие виды инженеров получают лицензии, может быть, мы тоже должны.
На практике лицензии инженерам предоставляет правительство. В США вы получаете лицензию правительства штата, так что, если вы практикуете в двух штатах — вы получаете две лицензии. От лицензированных специалистов ожидают, что они будут соблюдать этический кодекс и им может быть предъявлен иск за злоупотребление служебным положением.
Сейчас предпринимаются усилия для того, чтоб разработчики ПО подлежали лицензированию. Они достигли успеха в Texas, British Columbia, и Ontario. Отчет можно посмотреть в Construx Web page on Software Engineering Professionalism, http://www.construx.com/profession/home.htm. Mead (2001) дает продуманные аргументы в пользу лицензирования.
Организация Software Engineering Coordinating Committee (SWECC) занимается созданием Software Engineering Body of Knowledge (SWEBOK). SWECC это совместный комитет инженеров Institute for Electrical and Electronics Engineers Computer Society (IEEECS) и Association for Computing Machinery (ACM). Целью проекта SWEBOK является достижение консенсуса по уровню знаний, которые инженеры По должны иметь.
ACM не поддерживающая лицензирование инженеров ПО и вышла в июне 2000 в результате усилий SWEBOK от SWECC.
Позиция ACM заключается в том, что уровень наших знаний в разработке ПО слишком незрел, чтоб подлежать лицензированию. Кроме того Совет ACM считает, что лицензирование не будет эффективным в плане предоставлении гарантий качества и надежности ПО. Кроме того, совет заключил, что фреймворк лицензирования инженера, изначально разработанный для инженеров строителей не соответствует практикам разработки ПО. Подобная практика лицензирования даст лживые заверения в компетентности, даже если объем знаний будет достаточным. Также они исключит многих наиболее квалифицированных инженеров. Because SWECC has become so closely identified with licensing of software engineers under a professional engineer model, the ACM Council decided to withdraw from SWECC. (ACM 2000)
SWEBOK является важным аспектом движения по лицензированию. SWEBOK должен представлять интерес для вас, так как тестирование ПО является одной из областей SWEBOK, как и качество ПО. Вы могли бы загрузить SWEBOK по http://www.swebok.org.
Чтоб получить лицензию в качестве инженера разработчика вам придется сдать экзамен. Экзамен должен быть основан на знаниях и практиках, широко применяемых в нашей области. Лицензированному специалисту может быть предъявлен иск за злоупотребление положением. Профессионалы злоупотребляют положением когда причиняют вред клиентам (клиенты получают физические травмы, причиняется ущерб их имуществу, они терпят убытки) вследствие неприменения навыков или знаний в своей области. Если SWEBOK будет принят как основа знаний по разработке ПО, то законодатели, создатели экзаменов, судьи, адвокаты, присяжные и репортеры будут ссылаться на SWEBOK, когда захотят понять стандарты, определяющие, что инжернеры разработчики должны знать и уметь.
Мы критиковали SWEBOK в предисловии Главы 6, «Документирование тестирования». Мы не одни. Более подробно см. Notkin et al.'s (2000) отчет совету ACM.
База знаний инженерии ПО (IEEE Computer Society, Trial version 0.95) указывает в предислови, что:
Цель данного руководства — достижение консенсуса по способу подтверждения качеств и навыков разработчиков ПО и обеспечение доступа к актуальной совокупности необходимых для этого знаний...
===
Дальше еще три страницы байды в этом духе и очень мало слов о тестировании. При всем уважении к труду авторов - мне лень переводить.
Для непосвященных, это примерно 1000 км с мая на велике.
Слово Канеру
О лицензировании инженеров ПО
Должны ли инженеры ПО (включая тестировщиков) быть лицензированы? Другие виды инженеров получают лицензии, может быть, мы тоже должны.
На практике лицензии инженерам предоставляет правительство. В США вы получаете лицензию правительства штата, так что, если вы практикуете в двух штатах — вы получаете две лицензии. От лицензированных специалистов ожидают, что они будут соблюдать этический кодекс и им может быть предъявлен иск за злоупотребление служебным положением.
Сейчас предпринимаются усилия для того, чтоб разработчики ПО подлежали лицензированию. Они достигли успеха в Texas, British Columbia, и Ontario. Отчет можно посмотреть в Construx Web page on Software Engineering Professionalism, http://www.construx.com/profession/home.htm. Mead (2001) дает продуманные аргументы в пользу лицензирования.
Организация Software Engineering Coordinating Committee (SWECC) занимается созданием Software Engineering Body of Knowledge (SWEBOK). SWECC это совместный комитет инженеров Institute for Electrical and Electronics Engineers Computer Society (IEEECS) и Association for Computing Machinery (ACM). Целью проекта SWEBOK является достижение консенсуса по уровню знаний, которые инженеры По должны иметь.
ACM не поддерживающая лицензирование инженеров ПО и вышла в июне 2000 в результате усилий SWEBOK от SWECC.
Позиция ACM заключается в том, что уровень наших знаний в разработке ПО слишком незрел, чтоб подлежать лицензированию. Кроме того Совет ACM считает, что лицензирование не будет эффективным в плане предоставлении гарантий качества и надежности ПО. Кроме того, совет заключил, что фреймворк лицензирования инженера, изначально разработанный для инженеров строителей не соответствует практикам разработки ПО. Подобная практика лицензирования даст лживые заверения в компетентности, даже если объем знаний будет достаточным. Также они исключит многих наиболее квалифицированных инженеров. Because SWECC has become so closely identified with licensing of software engineers under a professional engineer model, the ACM Council decided to withdraw from SWECC. (ACM 2000)
SWEBOK является важным аспектом движения по лицензированию. SWEBOK должен представлять интерес для вас, так как тестирование ПО является одной из областей SWEBOK, как и качество ПО. Вы могли бы загрузить SWEBOK по http://www.swebok.org.
Чтоб получить лицензию в качестве инженера разработчика вам придется сдать экзамен. Экзамен должен быть основан на знаниях и практиках, широко применяемых в нашей области. Лицензированному специалисту может быть предъявлен иск за злоупотребление положением. Профессионалы злоупотребляют положением когда причиняют вред клиентам (клиенты получают физические травмы, причиняется ущерб их имуществу, они терпят убытки) вследствие неприменения навыков или знаний в своей области. Если SWEBOK будет принят как основа знаний по разработке ПО, то законодатели, создатели экзаменов, судьи, адвокаты, присяжные и репортеры будут ссылаться на SWEBOK, когда захотят понять стандарты, определяющие, что инжернеры разработчики должны знать и уметь.
Мы критиковали SWEBOK в предисловии Главы 6, «Документирование тестирования». Мы не одни. Более подробно см. Notkin et al.'s (2000) отчет совету ACM.
База знаний инженерии ПО (IEEE Computer Society, Trial version 0.95) указывает в предислови, что:
Цель данного руководства — достижение консенсуса по способу подтверждения качеств и навыков разработчиков ПО и обеспечение доступа к актуальной совокупности необходимых для этого знаний...
===
Дальше еще три страницы байды в этом духе и очень мало слов о тестировании. При всем уважении к труду авторов - мне лень переводить.
вторник, 2 июля 2013 г.
Переводы пока не выкладываю, там длинный урок попался, зараз не успеваю.
Но выложу например пару картинок велопоездки к Балтыму, что была на выходных.
Туда:
На неэлекетрифицированной железной дороге нашли станцию. На станции двух смотрителей и злую собаку, привязанную к вагону.
Представить себе не могу, как скучно на этой станции, судя по виду смотрителей, интернета у них нет. И WoT не установлен, да...
Мост через ЕКАД.
Кстати, а потом мы еще нашли подземный переход черезЕКАД своротку с ЕКАДа на серовский тракт, короче трасса какая-то. Удобно.
Рекомендую дорогу обратно, 5 км по пустынной дороге, потом 15 вдоль жд путей.
Итог, примерно 60 км, туда и обратно.
Но выложу например пару картинок велопоездки к Балтыму, что была на выходных.
Туда:
 |
| Альбом: home |
На неэлекетрифицированной железной дороге нашли станцию. На станции двух смотрителей и злую собаку, привязанную к вагону.
 |
| Альбом: home |
Представить себе не могу, как скучно на этой станции, судя по виду смотрителей, интернета у них нет. И WoT не установлен, да...
Мост через ЕКАД.
 |
| Альбом: home |
Кстати, а потом мы еще нашли подземный переход через
Рекомендую дорогу обратно, 5 км по пустынной дороге, потом 15 вдоль жд путей.
 |
| Альбом: home |
 |
| Альбом: home |
Итог, примерно 60 км, туда и обратно.
вторник, 25 июня 2013 г.
Lesson 272
vs: максимальная премия должна быть за "сделал чудо", и она должна быть действительно большой
/w: Ага, а следующий шаг - вменить в обязанность и написать инструкцию
Слово Канеру
Вы рискуете получить черный пояс за пару недель, не участвуя в боях
Люди могут делать деньги на сертификации — ревью курсов, советы по прохождению экзаменов. Многие заинтересованы в сертификации, не имеющий ничего общего с успешной работой инженера.
Некоторые сертификаты кажутся нам дутыми. Мы с подозрением рассматриваем все программы, которые говорят, что они могут сделать из вас мастера, эксперта или обладателя черного пояса за пару недель.
В боевых искусствах получение черного пояса занимает много времени. Первый этап — желтый пояс, который инструктор даст вам, когда решит, что вы представляете больше опасности для других, чем для себя. Даже это обычно занимает больше времени, чем две недели.
Может быть, дисцплина так проста, что вы освоите ее за две недели. Если так, берите черный пояс. Но не попадайте в драки.
/w: Ага, а следующий шаг - вменить в обязанность и написать инструкцию
Слово Канеру
Вы рискуете получить черный пояс за пару недель, не участвуя в боях
Люди могут делать деньги на сертификации — ревью курсов, советы по прохождению экзаменов. Многие заинтересованы в сертификации, не имеющий ничего общего с успешной работой инженера.
Некоторые сертификаты кажутся нам дутыми. Мы с подозрением рассматриваем все программы, которые говорят, что они могут сделать из вас мастера, эксперта или обладателя черного пояса за пару недель.
В боевых искусствах получение черного пояса занимает много времени. Первый этап — желтый пояс, который инструктор даст вам, когда решит, что вы представляете больше опасности для других, чем для себя. Даже это обычно занимает больше времени, чем две недели.
Может быть, дисцплина так проста, что вы освоите ее за две недели. Если так, берите черный пояс. Но не попадайте в драки.
пятница, 21 июня 2013 г.
среда, 19 июня 2013 г.
Lesson 271
Вот тут короткая, понятная, проверяемая мысль Юли: не начинайте описание вакансии с требований. Начните с описания работы. Мне нравится. Посмотрите, в докладе еще есть хорошее.
Еще ссылка Наталья Желнова, аналитик, делится знаниями. Хороший доклад, приличный спикер, рекомендую. Но, как всегда, есть нюанс.
Наталья перечисляет обязанности аналитика и:
… управление изменениями...
Какая классная и емкая штука, не находите? Очень мало видов деятельности, даже не связанных с IT, не подходят под это определение. Найм уборщика, как и мытье полов, например, подходят. Такой штукой вообще часто грешат все докладчики.
А еще Наталья перечисляет обязанности Старшего аналитика и там есть:
... пишет программный код...
Я даже картинку нарисовал, поясняющую мысль:
Слово Канеру
Подумайте о получении сертификатов
Kaner - American Society Quality-Certified Quality Engineer (CQE). Quality Assurance Institute
Quality Assurance Institute предлагает возможность сертифицироваться в области тестирования ПО и качества ПО. British Computer Society разрабатывает новую схему сертификации для тестировщиков. Также есть возможность пройти сертификацию группами. Время от времени экзаменационные вопросы выкладывают в интернет.
Но стоит ли?
Мы считаем, что сертификационные экзамены не так сложны для прохождения. Вопросы часто достаточно предсказуемы. Если вы прошли курсы подготовки к экзаменам, то, скорее всего, сдадите их. Судя по тому, что видели мы, вопросы там стандартные с несколькими вариантами ответов или просто определения из книг. Они часто проверяют знания словаря и относительно простые понятия, базовые навыки. Тот факт, что кто-то является сертифицированным специалистом еще не означает, что он эксперт.
Многие из тех, кто получает сертификаты, делают это после того, как они прошли целый ряд курсов, а не только обзорный. Они используют подготовку к сертификации как возможность для получения образования. По нашему опыту, такие люди ценят свои сертификаты и чувствуют, как много они получили от этого процесса.
Сертификат может быть полезен для резюме. Он может рассказать вашему потенциальному работодателю, что вы достаточно серьезны для занятий самообразованием и сдачи экзамена на сертификат. Это отличает вас от остальных, претендующих на эту должность. Тем не менее, если вы сертифицированы (но не программист), а кто-то еще не сертифицирован, но является программистом, то не удивляйтесь, что именно он получит работу, связанную с автоматизацией тестирования. Ваш сертификат помогает вам только до определенного момента.
В целом, мы считаем, что сертификация в тестировании полезна. Она побудила многих людей изучить классические книги и статьи в их области, освоить новые методы, увеличила уровень из работы с ПО и вопросами качества.
We are not endorsing the bodies of knowledge or the perspectives of the certifiers. У нас есть с ними разногласия, но они имеют право высказакть свое мнение and to qualify people as being knowledgeable in their approaches. Существеенная разница между сертификацией (против которой мы не возражаем) и лицензированием (which we do object to) в том, что сертификация является более скромной. У вас есть возможность практиковать, не являясь сертифицированным специалистом. У вас есть возможность выбрать такое подтверждение ваших навыков, которое кажется вам наиболее подходящим. It is an educational vehicle and not a regulatory vehicle (см. Lesson 273, "A warning about the efforts to license software engineers").
Мы должны поднять одну проблему. Если вы получили сертификат и являетесь независимым консультантом или подрядчиком, будьте осторожны, продавая свои услуги. Если вы презентуете себя, как сертифицированного QA специалиста (или специалиста другой специальности), то у вас могут потребовать определенный уровень знаний и вы будете вынуждены оказывать услуги указанном уровне. Если вы сделаете работу плохо, то клиентам будет проще подать на вас в суд за халатность или злоупотребление служебным положением (Kaner 1996a). Поэтому, даже если вы сертифицированы, не стоит выбирать вариант продажи себя таким образом.
Еще ссылка Наталья Желнова, аналитик, делится знаниями. Хороший доклад, приличный спикер, рекомендую. Но, как всегда, есть нюанс.
Наталья перечисляет обязанности аналитика и:
… управление изменениями...
Какая классная и емкая штука, не находите? Очень мало видов деятельности, даже не связанных с IT, не подходят под это определение. Найм уборщика, как и мытье полов, например, подходят. Такой штукой вообще часто грешат все докладчики.
А еще Наталья перечисляет обязанности Старшего аналитика и там есть:
... пишет программный код...
Я даже картинку нарисовал, поясняющую мысль:
 |
| Альбом: bug |
Слово Канеру
Подумайте о получении сертификатов
Kaner - American Society Quality-Certified Quality Engineer (CQE). Quality Assurance Institute
Quality Assurance Institute предлагает возможность сертифицироваться в области тестирования ПО и качества ПО. British Computer Society разрабатывает новую схему сертификации для тестировщиков. Также есть возможность пройти сертификацию группами. Время от времени экзаменационные вопросы выкладывают в интернет.
Но стоит ли?
Мы считаем, что сертификационные экзамены не так сложны для прохождения. Вопросы часто достаточно предсказуемы. Если вы прошли курсы подготовки к экзаменам, то, скорее всего, сдадите их. Судя по тому, что видели мы, вопросы там стандартные с несколькими вариантами ответов или просто определения из книг. Они часто проверяют знания словаря и относительно простые понятия, базовые навыки. Тот факт, что кто-то является сертифицированным специалистом еще не означает, что он эксперт.
Многие из тех, кто получает сертификаты, делают это после того, как они прошли целый ряд курсов, а не только обзорный. Они используют подготовку к сертификации как возможность для получения образования. По нашему опыту, такие люди ценят свои сертификаты и чувствуют, как много они получили от этого процесса.
Сертификат может быть полезен для резюме. Он может рассказать вашему потенциальному работодателю, что вы достаточно серьезны для занятий самообразованием и сдачи экзамена на сертификат. Это отличает вас от остальных, претендующих на эту должность. Тем не менее, если вы сертифицированы (но не программист), а кто-то еще не сертифицирован, но является программистом, то не удивляйтесь, что именно он получит работу, связанную с автоматизацией тестирования. Ваш сертификат помогает вам только до определенного момента.
В целом, мы считаем, что сертификация в тестировании полезна. Она побудила многих людей изучить классические книги и статьи в их области, освоить новые методы, увеличила уровень из работы с ПО и вопросами качества.
We are not endorsing the bodies of knowledge or the perspectives of the certifiers. У нас есть с ними разногласия, но они имеют право высказакть свое мнение and to qualify people as being knowledgeable in their approaches. Существеенная разница между сертификацией (против которой мы не возражаем) и лицензированием (which we do object to) в том, что сертификация является более скромной. У вас есть возможность практиковать, не являясь сертифицированным специалистом. У вас есть возможность выбрать такое подтверждение ваших навыков, которое кажется вам наиболее подходящим. It is an educational vehicle and not a regulatory vehicle (см. Lesson 273, "A warning about the efforts to license software engineers").
Мы должны поднять одну проблему. Если вы получили сертификат и являетесь независимым консультантом или подрядчиком, будьте осторожны, продавая свои услуги. Если вы презентуете себя, как сертифицированного QA специалиста (или специалиста другой специальности), то у вас могут потребовать определенный уровень знаний и вы будете вынуждены оказывать услуги указанном уровне. Если вы сделаете работу плохо, то клиентам будет проще подать на вас в суд за халатность или злоупотребление служебным положением (Kaner 1996a). Поэтому, даже если вы сертифицированы, не стоит выбирать вариант продажи себя таким образом.
вторник, 11 июня 2013 г.
Про ответственность.
У себя в блоге Наташа Руколь дает определение ответственности через примеры. Два вообще не в тему, а вот третий пример просто отличен, прочитайте.
Вообще, тема ответственности меня перманентно радует уже много лет. Не так давно слышал от менеджера в сторону коллеги такую фразу, цитирую:
- Ты за это отвечаешь, ты не должна ничего делать
Исключительно с целью личной радости я спросил у всех до кого дотянулся - а как они понимают ответственность? Само собой, и у Наташи.
Вообще, тема ответственности меня перманентно радует уже много лет. Не так давно слышал от менеджера в сторону коллеги такую фразу, цитирую:
- Ты за это отвечаешь, ты не должна ничего делать
Исключительно с целью личной радости я спросил у всех до кого дотянулся - а как они понимают ответственность? Само собой, и у Наташи.
 |
| Альбом: office |
Рутина
На митинге:
- M:Вчера твой украинец допоздна в офисе тесты писал.
- T:Молодец какой.
- M:Просто у него девушка до девяти работает.
- T:Какая правильная девушка.
- M:Какой правильный украинец.
- П:Какая хорошая пара.
По мотивам ссылки:
20 вещей, которые я действительно бы хотел знать в 20 лет
2.Не доверяйте на 100% всему тому, чему вас учат в высших учебных заведениях. - После окончания вы ничего не будете знать из того, что происходит в реальной жизни. Ничего страшного. Главное, что у вас есть диплом. Без диплома не устроиться на нормальную работу. OMGWTF, у 99% студентов не хватает мозгов понять, как много может дать ВУЗ. А диплом не нужен.
3.Читайте как можно больше книг. - Читай больше УМНЫХ книг! Эмануэль и разные "попаданцы" это не умные книги! Словарь и справочник - умные книги.
4.Поддерживайте связь со всеми. - Общайся с теми кто выше тебя. Хоть в чем нибудь. Не трать время на идиотов.
15.Учитесь готовить - Научись готовить одно блюдо офигенно. И никому не говори рецепт. Пусть тебя зовут и просят приготовить. Отличная мысль.
19.Узнать об одной вещи - Занимайся вещами по 2 причинам: 1. Это тебе нравится 2. Это тебе приносит деньги. Если не 1 и не 2. Делегируй! Опять ошибка. Две причины: 1. Тебе это нравится. 2. Тебе это нравится и приносит деньги.
Но все это херня полная. Почти все эти вещи нам талдычат с 14 до 18 лет мудрые родители, но мы все равно их не слушаем.
А вот 20 вещей, которые я действительно хотел бы знать в 20 лет:
1. 2006, Италия, 1:1 (5:3, пенальти)
2. 2008, Испания 1:0
3. 2010, Испания, 1:0 (доп. время)
4. 2012, Испания, 4:0
...
Ну вы поняли.
- M:Вчера твой украинец допоздна в офисе тесты писал.
- T:Молодец какой.
- M:Просто у него девушка до девяти работает.
- T:Какая правильная девушка.
- M:Какой правильный украинец.
- П:Какая хорошая пара.
По мотивам ссылки:
20 вещей, которые я действительно бы хотел знать в 20 лет
2.
3.
4.
15.
19.
Но все это херня полная. Почти все эти вещи нам талдычат с 14 до 18 лет мудрые родители, но мы все равно их не слушаем.
А вот 20 вещей, которые я действительно хотел бы знать в 20 лет:
1. 2006, Италия, 1:1 (5:3, пенальти)
2. 2008, Испания 1:0
3. 2010, Испания, 1:0 (доп. время)
4. 2012, Испания, 4:0
...
Ну вы поняли.
понедельник, 3 июня 2013 г.
Lesson 270
Разработчики и тестировщики совместными усилиями доделали фичу:
P.S. Оля, заходи, забирай, коробка на подоконнике, если спросят, скажи - я разрешил.
Слово Канеру
Улучшайте навыки публичных выступлений
Вы могли бы найти курсы публичных выступлений во многих университетах и колледжах. Кроме того, рассмотрите вопрос о вступлении в Toastmasters (http://www.toastmasters.org). Эта грубба обеспечит вам безопасную и доброжелательную среду для изучения и практики в этом направлении. Many Toastmasters clubs are good places to network; вы будете удивлены тем, кто еще посещает их (руководители, менеджеры, другие инженеры и так далее).
 |
| Альбом: office |
P.S. Оля, заходи, забирай, коробка на подоконнике, если спросят, скажи - я разрешил.
Слово Канеру
Улучшайте навыки публичных выступлений
Вы могли бы найти курсы публичных выступлений во многих университетах и колледжах. Кроме того, рассмотрите вопрос о вступлении в Toastmasters (http://www.toastmasters.org). Эта грубба обеспечит вам безопасную и доброжелательную среду для изучения и практики в этом направлении. Many Toastmasters clubs are good places to network; вы будете удивлены тем, кто еще посещает их (руководители, менеджеры, другие инженеры и так далее).
Подписаться на:
Сообщения (Atom)