Программист и менеджер.
П: Я буду эти тесты писать четыре дня, долго.
М: Все равно пиши.
П: Что важнее, тесты или функциональность?
М: Тесты. Так как функциональность без тестов — не работает, а значит вредна.
Несмотря на то, что тесты без функциональности это, конечно, ноль, функциональность без тестов (в контексте = не работающая) величина явно отрицательная.
Дискас?
Слово Канеру
Как могут лгать тест-кейсы
Если вы соберете все портфели в компании и сложите в кучу, вы ничего не узнаете о том, что внутри них. У вас есть 37 портфелей, они вместе весят 384 фунта, что это говорит о будущем компании? Ничего. Тем не менее, их содержание может иметь большое значение для вас. Вопрос решить можно только открыв портфели и разложив содержимое по полкам.
Тест-кейсы как портфели. Их подсчет без учета содержания ничего не говорит. Подсчет соотношения проходящих и падающих тестов тоже ничего не говорит: 90% тестов проходят, это хорошо или ужасно? Никто не ответит, не зная содержания тестов. Вычисление соотношения запланированных и написаных кейсов также ничего не говорит, может быть самое важное отложено на потом и последние 10% займут половину времени для создания. Или может случиться, что общее количество запланированных тестов недостаточно для покрытия рисков.
Иногда менеджеры тестирования согласны с этим, но они чувствуют, что у них нет альтернатив. Альтернатива есть: ничего. Гораздо лучше знать мало и иметь дело с реальностью, чем знать мало и притворяться, что знаешь много. Есть и еще одна альтернатива: разговор о рисках и покрытии. Другими словами — обсудить содержание тестов.
Тестировщики, использующие непонятные, неизмеримые метрики для тестов для объяснения объема тестирования клиентам вольно или невольно обманывают их.
Johanna Rothman считает нашу позицию по этому поводу слишком экстремальной. Она пишет: «У нас есть еще одна альтернатива. Например, если количество прошедших тестов уменьшилось с 98% до 30% в начале проекта, тор вы должны беспокоиться? Скорее всего нет. Но, если вы за неделю до беты или запуска продукта, то да, вам стоит беспокоиться. Почему? В начале проекта вы вообще не будете проводить многие тесты. Но в конце проекта вам придется провести большую часть испытаний, если не все. Можно использовать эти цифры, чтоб обсудить проблемы, например, нехватки ресурсов. Вы могли бы использовать эти данные, чтоб объяснить вашу озабоченность.»
Jeff Bleiberg пишет: «Как правило, есть необходимость обеспечить прозрачность процесса тестирования. Этому помогут метрики. Но, независимо от того, насколько они «надежны» и «говорят сами за себя» люди будут понимать их неправильно. Одно из моих правил состоит в том, что я не распостраняю свои отчеты и веду записи встреч, в которых отражаю значение метрик.»
вторник, 30 июля 2013 г.
пятница, 26 июля 2013 г.
вторник, 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 км, туда и обратно.
Подписаться на:
Сообщения (Atom)