ITBlogs

Сообщество IT-профессионалов
Welcome to ITBlogs Sign in | Join | Help
in Search

255 ступеней

  • ТОП-8 ошибочных парадигм операционного менеджмента и отсутствие глубинных знаний

    Интересная статья Мартина Пауэлл, Director Goldratt UK (www.toc-goldratt.com)

    Перевод на tocpeople.com

    Сам список:

    1. Простаивание ресурсов является главным источником потерь
    2. Эффективность является лучшим показателем производительности и прибыльности
    3. Время выполнения заказа постоянно
    4. Сокращение количества переналадок сокращает затраты
    5. Партия в обработке = передаточная партия
    6. Все должны быть экспедиторами
    7. Поток зависит, главным образом, от фактического размещения
    8. Прием заказов с ускоренным времени выполнения повышает доходность

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

    За время своего трудового стажа я видел эти ошибки так часто, что если бы я мог получать деньги за обнаружение этих ошибок, то мне стоило бы бросить свою текущую работу и стать миллионером. Как часто эти ошибки порождают схемы демотивации сотрудников! Но люди не уделившие достаточно времени время глубокому изучению  работ Шухарта, Деминга, Голдратта; таких дисциплин, как теорвер, статистическое управление, теория массового обслуживания, искренне не понимают какой вред наносят фирме.

    В дополнени к списку ТОП-8 ошибочных парадигм стоит упомянуть “Смертельные болезни менеджмента”, описанные Эдвардом Демингом.

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

  • Тонны кода

    Довольно распространенная фраза. Любят ей блеснуть на конференциях или в статьях. Давайте попробуем прикинуть, сколько это - тонна кода.

    Популярная некогда идея платить за строчки кода привела к закидонам вроде:

    for (i=1;i
    {
    x=x*i;
    }

    Или еще хуже:

    for
    (
    i=1;
    i
    i++
    )
    {
    x=x*i;
    }

    Чтобы привести первый и второй вариант к "единому знаменателю" проведем "нормализацию" кода. Все "белые пробелы" (переход на другую строку, табуляция) заменим одним пробелом.

    Получившееся, отформатируем согласно одному из РД. 14 кегль, 30 строк на страницу, 60 символов в строке. Итого примерно 1800 байт исходного кода с комментариями (комментарии является частью поставляемого продукта отвечающий за такой атрибут качества, как анализируемость) на страницу.

    Печать один лист - одна страница.

    Стандартный лист А4, 80 ден - 4 грамма

    Итого:

    • один килобайт - 2,2 грамма
    • один мегабайт - 2,2 килограмма
    • один гигабайт - 2,2 тонны

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

  • “Обе белые”

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

    О фильме: статья в википедии.

  • Классификация видов автоматизированного функционального тестирования

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

    На мой скромный взгляд (IMHO), безоглядное, чуть ли не повальное увлечение автоматизированным тестированием через GUI не слишком оправдано. Хотя сама по себе автоматизацию вполне имеет право на существование. “Потому что функциональное автоматизированное тестирования бывает разное” (с) Капитан Очевидность. “И в зависимости от ситуации оправдано применение того или иного” и снова спасибо Кэпу.

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

    • “кто пишет.[программист | тестировщик]”;
    • “когда.[до кода(test first) | плюс-минус пара минут от кода (TDD) | после кода (регрессионное тестирование)]”;
    • “кто выполняет.[ программист |  тестировщик ]”;
    • “интерфейс[ GUI | API ]”.

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

    Так вот, IMHO, комбинация {пишет.тестировщик; когда.после кода; выполняет.тестировщик; интерфейс.GUI} самая бестолковая и одновременно безумно популярная.

    Лирическое отступление. Почему эти тесты и наиболее бестолковые и наиболее популярные одновременно? Как один из вариантов объяснения: “Это позволяет тестлиду раздуть команду”. Действительно, пусть для того, чтобы продукт “N” стал хорошим, в нем нужно найти и исправить 2000 дефектов. И сделать это надо в течение года. При мануальном тестировании нормальная “цена” нахождения 1000 дефектов - это один человекогод. Значит нужно двое тестировщиков. С учетом неравномерности загрузки трое-четверо. А вот если ввести 100% автоматизацию посредством тесткомплита или там селениума, то понадобится уже 10-20 человек. Если же тестлид по настоящему талантлив, то при поиске следующей работы в его резюме будет красоваться гордая надпись: “Руководил отделом автоматизации тестирования в 50 человек”. Ну, понятно продавать себя надо уметь. Этому сейчас даже учат. Оно конечно можно налететь на грамотного рекрутера, который воскликнет: “Восхитительно! А позвольте полюбопытствовать, сколько дефектов за год нашли эти замечательно бравые полсотни человек?”

    Но не будем искать злой умысел там, где достаточно простых объяснений. Причины могут быть и другие. Ведь на первый взгляд все выглядит просто замечательно. Мы покроем тестами всю функциональность и при выпуске новой версии эти тесты будут быстро находить дефекты. Прямо таки идиллия. А теперь откинемся на диван и немного подумаем. Думать тоже иногда надо. Говорят это помогает. С чего бы тесты будут находить ошибки? Наверное, потому, что изменилась функциональность (спасибо Кэпу). Но если изменилась функциональность, то наверное нужно на конкретно эту функциональность поменять тесты? Логично. Смотрите, что получается:

    1. Софт ушел на тестирование, а тестировщики вместо того, чтобы предоставить информацию о дефектах начинают лихорадочно править тесты. Учитывая, что написание кода тестов сравнимо с написанием собственно кода, софт проведет в очереди довольно много времени. Это потери. Это ухудшение потока.
    2. Когда ошибки таки будут найдены программист будет полностью вне контекста и потратит прилично времени на переключение.

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

    Т.е. перед тем как внедрять  {пишет.тестировщик; когда.после кода; выполняет.тестировщик; интерфейс.GUI} внедрите {пишет.тестировщик; когда.до кода; выполняет.программист; интерфейс.GUI}. Такой подход действительно по настоящему эффективен. Из третьих рук я слышал, что по настоящему эффективная фирма (годовой проход в расчете на сотрудника порядка $1 000 000) придерживается именно этого подхода. Конечно, чтобы перейти к такому методу нужно серьезно поднять культуру разработки, что уже само по себе сильно помогает (спасибо Кэп). Придется внедрить стандарт именования локаторов, что дополнительно сделает тесты нехрупкими (Кэп?! но как вы догадались?!). Придется ввести процедуру проектирования пользовательского интерфейса, что дополнительно сильно улучшит качество ПО. Вообще такой подход прямо таки вынуждает “мыть руки перед кодированием”. Если начать с него, то потом можно и о регрессионном тестировании подумать. База тестов-то в любом случае останется.

    Прочие варианты с GUI в качестве интерфейса не слишком интересны. Наверное, можно представить себе “полуторное” программирование, при котором два программиста за одним ПК пишут интерфейс пользователя, а потом один идет писать реализацию, а другой тесты, но как то в это верится с трудом.
    Комбинация {пишет.программист; когда.плюс-минус пара минут от кода; выполняет.программист; интерфейс.API} популярна, скорее, в коллективах кросфункциональщиков, где нет выделенной роли тестировщиков. Там, же где роль тестировщиков выделена, программисты пытаются от написания автоматизированных тестов уйти. Впрочем, и там где тестировщиков нет, там тоже часто эта практика часто умирает. Я полагаю, что это связано с одной из форм прокрастинации:

    Посылка 1. Кодер лучше умеет писать код, нежели проектировать тестовые наборы.

    Посылка 2. Человек склонен откладывать “на потом” (на практике “навсегда”) то, что он умеет не слишком хорошо.

    Вывод. Кодеры будут стараться отказаться от практики юнит тестирования.

    А уж причин для отказа можно придумать массу. Пойдет и такая: “написание кода тестов занимает примерно столько же времени, сколько и написание кода”. Люди умеющие логически мыслить легко отклоняют эту причину. Ведь то что, написание юнит тестов заняло 100 часов и написание кода заняло 100 часов вовсе не означает, что стало 200 вместо 100. А вот то, что стало 200 часов вместо первоначальных 300 без юнит тестов вполне вероятно.

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

    Прежде чем двинуться дальше стоит сказать вот о чем. Капитан О: “API оно разное бывает”. Под юнит тестированием часто подразумевают тестирование отдельных классов и функций. Но гораздо интереснее, когда речь идет об интерфейсе предоставляемым сервисом и/или компонентом. Будет это SOAP, или обмен по ftp, или еще что-то не слишком важно. Гораздо большее влияние оказывает число компонент и/или сервисов используют один и тот же интерфейс, тем выгоднее становятся тесты {пишет.???; когда.до кода; выполняет.не важно; интерфейс.API}. Сначала спроектировать и описать протокол, потом тесты и только потом код. Так делать выгодно. Более того иногда это чуть ли не единственный способ сдать проект. Но об этом явно в другой статье.

    PS. Я рассмотрел только интересные с моей точки зрения виды тестов. Классификацию можно расширить и рассмотреть еще какие-то виды. Но потом.

    PSS. Я убежден, что найдется множество людей, которые выступят в защиту тестов вида: “{пишет.тестировщик; когда.после кода; выполняет.тестировщик; интерфейс.GUI}”. Вероятно они будут приводить казуистические доводы типа: “Эти тесты не для того, чтобы находить ошибки, а для того чтобы предотвратить их попадание в продакшен”. Мой ответ: “сами поняли чего сказали? Не поняли, так идите перечитайте.” И встречный ответ. ROI таких автотестов считается очень простым способом - это число дефектов найденных при прогоне этих тестов деленное на число человеколет вложенных в разработку и поддержку этих тестов. Какой у вас ROI? 20 дефектов на выброшенный год? Свободны. Это смешно.

  • Метрики в тестировании

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

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

    metrtest.PNG
    Примечание. Я исхожу из чрезвычайно редко используемой модели “риск-оптимумов”, которая подразумевает, что слишком хорошие показатели должны инициировать аудиторскую проверку, точно так же, как слишком плохие. Более подробно, но тоже очень коротко, описано в моей статье “Различные подходы к риск менеджменту. Краткий экскурс.”  http://www.software-testing.ru/library/around-testing/engineering/208  Так же где-то было видео с семинара на эту тему. Ну, или гуглите. Шутка. Материалов на русском, считайте, что нет.

    Понятно, что эти цифры не стоит применять к проектам “for fun / just for lulz” или “угроза жизни”. Понятно, что цифры будут плавать в зависимости от размера проекта. Давайте будем считать, что мои оценки относятся к типичным корпоративным информационным системам, юзкейсов на 500.

    PS. Я бы пособирал статистику по фирмам, но как правило, ее или не ведут, или это: “Очень страшный секрет, потому что у нас все плохо”.

  • Фатальная ошибка автоматизации тестирования

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

    Ерунда все это. Это всего лишь симптомы. Истинная причина краха в другом и определяется тривиально.

    “Мы начали автоматизацию с регрессионного тестирования.” Это приговор. Больше можно ничего не изучать и не спрашивать.

  • Пример плана тестирования

    Предисловие.

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

    Документ показал свою высокую полезность. Но. На то чтобы научиться пользоваться этим типом документом нужно время. Чтобы научиться его писать нужно еще больше времени.

    Пробуйте. Возможно вам этот тип документа окажется полезен. А может и нет.

    Да еще. Размер и форма должны выбираться в зависимости от размера и типа проекта. Расширенная форма приведенная ниже неплохо подходит для проектов размером “десятки человеколет” - “несколько человековеков”. Для проекта поменьше я использовал форму “две страницы А4 цветными ручками в тетради”. Тоже хорошо работало. Не факт, что приведенный ниже документ использовался в реальном проекте. Но факт, что использовались похожие документы.
    Термин “план” используется в значении близком к “стратегия”. Это не календарный график и не перечень тестовых примеров.


    План тестирования системы

    Версия 1.1

    История исправлений

    Дата    Версия    Описание    Автор
    02.01.20хх    1.0    Создан
    07.01.20хх    1.1    Подготовлен черновик

    Содержание

    1    Введение
    1.1    Цель
    1.2    Состав документа
    1.3    Нотации, аббревиатуры и определения принятые в документе
    1.4    Комплексные показатели качества по ГОСТ Р ИСО/МЭК 9126-93
    1.5    Ссылки
    2    Идентификация объектов тестирования
    3    Стратегия тестирования
    4    Виды проводимых тестов
    4.1    Функциональное тестирование
    4.2    Тестирование бизнес цикла
    4.3    Конфигурационное тестирование
    4.4    Тестирование производительности
    4.5    Стресс тестирование
    4.6    Юзабилити тестирование
    4.7    Тестирование инсталляции
    5    Требования к численности и квалификации персонала
    5.1    Оценка объема работ
    5.2    Распределение по ролям и квалификации
    6    Необходимые ресурсы
    6.1    Программные средства

    1    Введение
    1.1    Цель

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

    1.2    Состав документа
    Документ содержит описание общих для подсистем стратегии, подходов и видов тестов. Также определяет численные и квалификационные требования к персоналу, необходимые для успешного тестирования; необходимое программное и аппаратное обеспечение.
    Информация, специфическая для отдельных подсистем, описывается в отдельных планах тестирования для каждой конкретной подсистемы.

    1.3    Нотации, аббревиатуры и определения принятые в документе

    TBD (To Be Defined) - будет определено в дальнейшем. Указывает, что данный раздел документа еще не разработан.

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

    Описание дефекта - формализованное описание, составленное в той или иной системе учета дефектов. Дефект существует вне зависимости от того описали его или нет и от того нашли его или нет.

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

    Контроль качества продукта  - более широкое определение, нежели тестирование, включающее в себя, в том числе тестирование. Так например просмотр кода, также называемый code review или статическим тестированием обеспечивает контроль такой метрики как “Сопровождаемость->Изменяемость” (в классификации ГОСТ 9126), но при этом  не используется прогон программы. Кроме, собственно, программы (исполняемого кода) контролю качества подвергаются другие конечные артефакты: руководство пользователя, руководство администратора, …
    Также может контроль качества может применяться не к конечным, а рабочим артефактам (ЧТЗ, прототипы интерфейсов, …)

    QA (Quality assurance) - работы по улучшению и поддержанию процессов, контролю соответствия процессам. Не имеют отношения к тестированию.

    Метрика программного обеспечения (англ. software metric) - это мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций.

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

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

    Тестирование методом свободного поиска (exploratory testing) - также называется тестированием на основе сеансов. Не предполагает жестко заданных, формализованных сценариев тестирования. Часто, проводится в парах.

    1.4    Комплексные показатели качества по ГОСТ Р ИСО/МЭК 9126-93
    А.2.1 Функциональные возможности (Functionality)
    А.2.1.1 Пригодность (Suitability)
    Атрибут программного обеспечения, относящийся к наличию и соответствию набора функций конкретным задачам.
    Примечание - Примерами соответствия является состав функций, ориентированных на задачу, из входящих в него подфункций и объемы таблиц.

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

    А.2.1.3 Способность к взаимодействию (Interoperability)
    Атрибуты программного обеспечения, относящиеся к способности его взаимодействовать с конкретными системами.
    Примечание - Способность к взаимодействию используется вместо совместимости для того, чтобы избежать возможной путаницы с взаимозаменяемостью (см. А.2.6.4).

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

    А.2.1.5 Защищенность (Security)
    Атрибуты программного обеспечения, относящиеся к его способности предотвращать несанкционированный доступ, случайный или преднамеренный, к программам и данным.

    А.2.2 Надежность (Reliability)
    А.2.2.1 Стабильность (Maturity)
    Атрибуты программного обеспечения, относящиеся к частоте отказов при ошибках в программном обеспечении.

    А.2.2.2 Устойчивость к ошибке (Fault tolerance)
    Атрибуты программного обеспечения, относящиеся к его способности поддерживать определенный уровень качества функционирования в случаях программных ошибок или нарушения определенного интерфейса.
    Примечание - Определенный уровень качества функционирования включает возможность отказобезопасности.

    А.2.2.3 Восстанавливаемость (Recoverability)
    Атрибуты программного обеспечения, относящиеся к его возможности восстанавливать уровень качества функционирования и восстанавливать данные, непосредственно поврежденные в случае отказа, а также к времени и усилиям, необходимым для этого.

    А.2.3 Практичность (Usability)

    А.2.3.1 Понятность (Understandability)
    Атрибуты программного обеспечения, относящиеся к усилиям пользователя по пониманию общей логической концепции и ее применимости.

    А.2.3.2 Обучаемость (Learnability)
    Атрибуты программного обеспечения, относящиеся к усилиям пользователя по обучению его применению (например оперативному управлению, вводу, выводу).

    А.2.3.3 Простота использования (Operability)
    Атрибуты программного обеспечения, относящиеся к усилиям пользователя но эксплуатации и оперативному управлению.

    А.2.4 Эффективность (Efficiency)

    А.2.4.1 Характер изменения во времени (Time behavior)
    Атрибуты программного обеспечения, относящиеся к временам отклика и обработки и к скоростям выполнения его функций.

    А.2.4.2 Характер изменения ресурсов (Resource behavior)
    Атрибуты программного обеспечения, относящиеся к объему используемых ресурсов и продолжительности такого использования при выполнении функции.

    А.2.5 Сопровождаемость (Maintainability)

    А.2.5.1 Анализируемость (Analysability)
    Атрибуты программного обеспечения, относящиеся к усилиям, необходимым для диагностики недостатков или случаев отказов или определения составных частей для модернизации.

    А.2.5.2 Изменяемость (Changeability)
    Атрибуты программного обеспечения, относящиеся к усилиям, необходимым для модификации, устранению отказа или для изменения условий эксплуатации.

    А.2.5.3 Устойчивость (Stability)
    Атрибуты программного обеспечения, относящиеся к риску от непредвиденных эффектов модификации.

    А.2.5.4 Тестируемость (Testability)
    Атрибуты программного обеспечения, относящиеся к усилиям, необходимым для проверки модифицированного программного обеспечения.
    Примечание - Значения этой подхарактеристики могут быть изменены рассматриваемыми модификациями.

    А.2.6 Мобильность (Portability)

    А.2.6.1 Адаптируемость (Adaptability)
    Атрибуты программного обеспечения, относящиеся к удобству его адаптации к различным конкретным условиям эксплуатации, без применения других действий или способов, кроме тех, что предназначены для этого в рассматриваемом программное обеспечении.

    А.2.6.2 Простота внедрения (Installability)
    Атрибуты программного обеспечения, относящиеся к усилиям, необходимым для внедрения программного обеспечения в конкретное окружение.

    А.2.6.3 Соответствие (Conformance)
    Атрибуты программного обеспечения, которые заставляют программу подчиняться стандартам или соглашениям, относящимся к мобильности.

    А.2.6.4 Взаимозаменяемость (Replaceabilily)
    Атрибуты программного обеспечения, относящиеся к простоте и трудоемкости его применения вместо другого конкретного программного средства в среде этого средства.
    Примечания

    1. Взаимозаменяемость используется вместо совместимости для того, чтобы избежать возможной путаницы со способностью к взаимодействию (см. А.2.1.3).
    2. Взаимозаменяемость с конкретным программным средством не предполагает, что данное средство заменимо рассматриваемым программным средством.
    3. Взаимозаменяемость может включать атрибуты простоты внедрения и адаптируемости. Понятие было введено в качестве отдельной подхарактеристики из-за его важности.

    1.5    Ссылки
    [1]    Рекомендации по конфигурационному управлению в части инстансов (стендов)
    [2]    Описание стендов (аппаратная и программная части, сетевые адреса, протоколы, адреса, логины и пароли).
    [3]    ГОСТ 9126

    2    Идентификация объектов тестирования
    Контролю качества должны быть подвергнут программно-аппаратный комплекс в целом, а также его отдельные части.

    Так в частности, должно быть проведено тестирование:

    • Приложения в целом, развернутом в промышленной среде
    • Программно - аппаратный комплекс (без установленного приложения)
    • Отдельные компоненты программы на тестовых стендах
    • Руководство пользователя
    • Руководство администратора
    • Другие документы, являющиеся частью программного продукта
    • Пользовательские данные (результат миграции)

    3    Стратегия тестирования

    Текущий подход к контролю качества подразумевает следующие вехи проекта:
    Подсистема готова к демонстрации заказчику
    Подсистема готова к промышленной эксплуатации

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

    tre1.PNG

    Для проверки готовности прототипа служат приемо-сдаточные испытания. Критерий готовности - акт сдачи прототипа подписанный приемо-сдаточной комиссией. Приемо-сдаточные испытания описываются в отдельном документе. Либо как раздел шесть частного технического задания, согласно ГОСТ 34.602-89, либо в отдельном документе содержащем программу и методику испытаний.

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

    4    Виды проводимых тестов
    4.1    Функциональное тестирование
    Используется для контроля качества “Функциональных возможностей” в части “Пригодности”, “Правильности” и “Способности к взаимодействию”.
    Функциональное тестирование является основным видом тестирования. Проводится вручную через интерфейс пользователя. Использование средств автоматизации в 20хх году не предполагается.
    При подготовке прототипа рекомендуется использовать тестирование методом свободного поиска (exploratory testing).
    При подготовке системы (подсистемы) к промышленной эксплуатации рекомендуется использовать стандартное промышленное тестирование, с оценкой полноты тестового покрытия.

    4.2    Тестирование бизнес цикла
    Используется для контроля качества “Функциональных возможностей” в части “Пригодности”, “Правильности” и “Способности к взаимодействию”.
    В первую очередь применяется для оценки готовности прототипа и оценки полноты функциональных требований.
    Подготовка к этому виду тестирования проводится в рамках команды разработки, а само тестирование проводится в присутствии заказчика.

    4.3    Конфигурационное тестирование
    Используется для контроля качества “Мобильности” в части “Адаптируемости”
    Должна быть проверена работоспособность приложения для:

    Различных видов ОС:

    • WinXP - обязательно
    • Vista - обязательно
    • Win7 - обязательно

    Различных БД:

    • MSSQL 2000
    • MSSQL 2005

    Различных разрешениях монитора рабочего места

    • 1280х1024 - обязательно
    • 1600х900 - обязательно
    • 1024х768 - желательно
    • 1680х1050 - желательно

    Может проводиться как выделенный вид тестирования методом визуального контроля при выполнении юзкейсов классов read и list.
    Рекомендованный метод - объединение с функциональным тестированием. В этом случае на каждом рабочем месте тестировщика рекомендуется установка своей конфигурации.

    4.4    Тестирование производительности
    Используется для контроля качества “Эффективности”.
    Для первичного анализа производительности серверной части используется ручное тестирование. Для оценки пригодности системы к промышленной эксплуатации на реальных объемах данных с заданным числом пользователей используется автоматизированное тестирование.
    Для  анализа поведения пользовательского интерфейса на реальных объемах данных используется ручное тестирование.

    4.5    Стресс тестирование
    Используется для контроля качества “Надежности” в части “Стабильности” и “Устойчивости к ошибке”.

    4.6    Юзабилити тестирование
    Используется для контроля качества “Практичности” в части “Понятности”, “Обучаемости”, “Простоты использования”.

    4.7    Тестирование инсталляции
    Используется для контроля качества “Мобильности” в части “Простоты внедрения”.
    Проводится вручную.
    5    Требования к численности и квалификации персонала
    5.1    Оценка объема работ
    Существует несколько способов оценок трудозатрат на тестирование. Проведем оценку по числу программистов
    Для системы такого класса нормальным считается что 20-25% от трудоемкости проекта приходится на тестирование. Расчеты показывают, что трудоемкость проекта порядка   300 человеколет. Следовательно трудоемкость тестирования 60-75 человеколет. Учитывая неравномерность поглощаемой трудоемкости тестирования в зависимости от фазы проекта и целевой показатель создания системы в три года, в пике на проекте должно быть ___ тестировщиков.

    5.2    Распределение по ролям и квалификации
    tre.PNG

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

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

    6    Необходимые ресурсы
    Рекомендации к тестовому и прочим стендам описаны в [1]. В разное время, в зависимости от потребностей, могут существовать одновременно несколько тестовых стендов.
    Так для тестирования:

    • переносимости и инсталляции - рекомендуется использовать стенд с изоляцией на уровне сети,
    • производительности  - стенд, с характеристиками, максимально близкими к промышленной среде
    • проблем заказчика - должен быть стенд класса “Образ заказчика”.

    Описание стендов и прав доступа можно найти в [2]
    6.1    Программные средства

    Управление тестированием   TrackStudio
    Трекинг дефектов    TrackStudio
    Управление проектом    TBD
    Работа с BD    TBD
    Профилирование работы сети    TBD
    Профилирование работы сервера приложений    TBD

  • Рекомендации к чтению

    На прошлой неделе в фирму прибыло несколько килограммов книг.

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

    Прибыло не все, что хотели (некоторых книг нет в продаже).

    Часть книг уже разобрали.

    imag0172.jpg

  • Краткий план типового рассказа про Agile

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

    1. Для начала немного истории - для тех, кто не в курсе. Agile методологии разработки родились в противовес классическим моделям, в которых результата пытались достичь за счет процессов, процедур и регламентов.
    2. Естественно получалось фуфло.
    3. Мы у себя внедрили Agile.
    4. Сейчас я вам расскажу, какие классные процессы, процедуры и регламенты мы у себя внедрили.
    5. Далее перечисляется некий набор процессов, процедур и регламентов, в зависимости от автора.

    – Конец плана —————–

    Коллеги, это только я вижу некое несоответствие в этих пунктах?

  • Никто тебя не должен развивать?

    Нужны дли тренинги по развитию сотрудников? Кто должен их инициировать? Как выделять время? Кто оплачивает?

    Мнения на этот счет есть. И они очень разные, эти мнения.

    Есть мнения, что тренинги - это часть компенсации.

    - При приеме на работу мы сообщаем сотрудникам, что они могут сами набрать тренингов на определенную сумму в течение года. Это неплохо стимулирует и мотивирует.

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

    - Мы их научим, а они уйдут
    - Будет хуже, если вы их не научите, а они останутся.

    Сейчас крен больше идет в ту сторону, что сотрудник должен развиваться сам. И на это есть причины. Серьезные причины:

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

    Или:

    - Мы не против посылать на тренинги и даже их оплачивать. Но пусть сотрудник и сам занимается саморазвитием.

    Но, споря, коллеги приводят доводы за и против принципиально разных тренингов.

    - Что значит выражение: “В огороде бузина, а в Киеве дядька!”?
    - Выражение используется, когда беседуют два человека, но в их разговоре нет общей темы, то есть каждый говорит о своём, не слушая при этом собеседника.
    Синонимичное выражение, но с несколько другим оттенком: “Я тебе про Фому, а ты мне про Ерёму”.

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


    Но хотелось не только играть в бисер, но и делом иногда заниматься. Нужна стройная система. Хотя бы относительно стройная. Задумаемся: а где собственно этот вопрос может быть раскрыт достаточно хорошо? Разумно покопаться в книгах великих менеджеров. Не буду развивать интригу, ответ есть в работах Деминга. К сожалению, книга «Выход из кризиса» написана достаточно тяжеловесным языком, поэтому откроем книгу Генри Нива «Пространство доктора Деминга» (недавно эта книга была переиздана под другим, очень странным названием «Организация как система»). Нам нужны главы 24 и 31.

    • Глава 24. Пункт 6: введите в практику подготовку и обучение персонала на рабочем месте.
    • Глава 31 Пункт 13: поощряйте стремление к образованию

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

    Подготовка и обучение:
    •    Нацелены на создание и развитие навыков
    •    Сотрудники должны обучаться тому, как выполнить конкретную работу определенным образом.
    •    Можно сформулировать четкие цели.
    •    Имеет несомненную ценность для организации.
    •    Имеет границы. С некоторого момента обучение становится бесполезным. Более точно: «Как только рабочий довел свою работу до состояния статистической управляемости, дальнейшее обучение ему не поможет».
    •    Цель обучения и подготовки – развить навыки, необходимые для работы.
    •    Вред от неправильно организованного обучения окажется долговременным.

    Образование:
    •    Нацелено на развитие знаний.
    •    Образование не может быть конкретным. Когда речь идет об образовании, вопрос: «Как ты будешь применять это в работе?» - бесполезен.
    •    Не имеет границ.
    •    Невозможно или очень сложно измерить эффективность траты денег на обучение.

    Деньги, потраченные на обучение, в отличие от денег, потраченных на оборудование, не дают осязаемого вклада в стоимость материальных активов в рамках традиционной бухгалтерской политики. Но мало какое вложение может сравниться с адаптационным тренингом для всех новых сотрудников по величине ROI. Каждый час, потраченный на рассказ о методах использования средств коллективной работы, используемых в компании шаблонов артефактов и стандартов, - оборачивается десятками, а то и сотнями сэкономленных часов. И помните. Если вы не обучите сотрудника сразу, он обучится сам. И его навыки будут неожиданно не такими, какие нужны фирме для успеха. Внезапно. А переучивать дорого. Избавлять от вредных привычек гораздо дороже, нежели от отсутствия привычек. Именно поэтому на японских менеджеров иногда накладывают финансовое ограничение – это минимальная сумма, которую они должны потратить на обучение сотрудников.

    Полагаю, что обучение - это очень, очень выгодное для организации вложение денег.
    Для образования выгода не так очевидна. Но: «Управление качеством начинается с образования и кончается образованием». И: «То, в чем нуждается организация, – это не просто хорошие люди; ей нужны люди, которые совершенствуются благодаря образованию».

    Для справки. Сертифицированный менеджер теряет свой сертификат PMP, если за полтора года он тратит на свое образование менее 80 часов. Что логично. Я полагаю, что то же самое верно и по отношению к инженерам. Инженер, не получающий образования, – деградирует. Вашей компании нужны лузеры?

    Если сотрудник стремится к образованию, то следует, как минимум, не мешать ему.
    А диалог:

    - Ну, я хочу прочитать книгу про нагрузочное тестирование…»
    — А нафига оно тебе?
    - Нуууу, я хочу стать более профессиональным тестировщиком, чем сейчас…
    — А в функциональном тестировании ты уже все Джомолунгмы покорил? И как часто ты будешь заниматься нагрузочным тестированием на своем проекте? Оно у вас вообще применяется?
    - Нет, не применяется, но…

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

    По данным Листера и Демарко навык кодирования на любом языке тренируется за два года. «Среди программистов, изучающих какой либо язык программирования более 2 лет, не было выявлено заметной разницы в скорости и качестве написания кода». Логично. Обучение конечно, образование пределов не имеет. Для того чтобы из кодера стать программистом, нужно получать образование. Вашей фирме нужны кодеры или программисты?

    PS. В книге описано Генри Нива еще много тонкостей, связанных с обучением и образованием. Рекомендую.

  • Пятница тринадцатое или прикладное неестествознание в старый новый год

    Байка для оруженосца - 3 

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

    ————————————-
    Действующие лица:

    Q - Белая королева (Queen). По некоторым версиям красная (червонная).

    A - оруженосец (Armiger)
    CC - Чеширский Кот (Cheshire Cat)

    MH - Мартовский заяц, (March Hare)

    H - Шляпник (Hatter)

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

    CC. Ваше Величество, вы светитесь, как будто вы Ваша Светлость. Нет, даже как Ваше Сиятельство.

    Q. О, да, мой вечно исчезающий друг. На этой неделе мне удалось прибить две дюжины вампиров!

    CC. Отличный результат! На прикладе вашего плюсомета скоро не останется места для новых отметок.

    A. Какие вампиры?

    CC. Вампиры, молодой человек это такие создания, которые пьют кровь или жизненные силы.

    A. Спасибо, кэп. Но все таки?

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

    A. А второе?

    Q. Как?! Ты прослушал?! Ты прослушал “Второе правило”?! Тогда слушай внимательно еще раз и не говори, что не слышал. Молодежь попробует вести эти карточки в вики, трекстудии или в праймовере. Это само по себе не плохо. Но только настоящие, посвященные шаманы знают, что отпугивающим эффектом обладает лишь бумажная карточка, которая лежит в папке “Сумера” в тумбочке “Галант” с наклеенным цветным стикером резолюции.

    A. Почему “Сумера?!

    H. Потому что коза -  Зойка. В этом деле мелочей не бывает -  раздалось с углового стола.

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

    A. Вы сказали бесполезные? А что бывают вредные?

    Q. Сколько угодно.

    A. Против них этот амулет действует?

    Q. Нет. Против вредных проектов нужно более сильное колдунство. Кроме того есть еще проекты-зомби. Их также сложно отпугнуть этим амулетом.

    A. Мадам, а не могли бы вы показать пример карточки?

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

    CC. К счастью у меня завалялась парочка. - Чеширский кот с видом фокусника достал шляпу, отданную ему шляпников в обмен на услугу. - Вуаля! - и он вручил оруженосцу листок формата A4.

    cardproject.PNGМартовский Заяц и Шляпник вскочили и в панике забегали по кухне.

    H&MH. Карточка! Карточка! Караул, карточка!

    Q. Фигляры, - неодобрительно бросила королева. Впрочем, строгость была напускная. Королева прекрасно знала силу этого тандема. Эта парочка аналитик-программист давала фору команде из двух десятков человек. Хотя получать лулзы от их закидонов умели далеко не все. Королева умела. За что ее особенно ценило руководство. Ходили слухи, что руководитель департамента разработки бросил пить после того, как королева забрала этот тандем к себе.  И отменил еженедельные отчеты. Чем поверг всю организацию в ступор. Ну, отчеты ладно, с кем не бывает.  Но бросить пить!

    Армигер начал внимательно рассматривать листок, а Чеширский кот в это время комментировал.

    CC. Оформление делается шрифтами Verdana  или Tahoma, 12-ым кеглем. В исключительных случаях для проектов с высоким коэффициентом полезности допускается 11-й кегль.

    A. Но здесь же катастрофически мало места! Почему бы не расширить на две-три страницы?

    CC. Если карточка проекта будет оформлена на двух страницах, то она немедленно отправится в корзину.

    A. А почему здесь нет больших проектов?

    CC. Большому проекту - большую торпеду. A3.

    MH.  Убил. - немедленно откликнулся Безумный Мартовский Заяц.

    A. А если полезность будет на границе, то значит можно считать не целое число, а 0.1, 1.5

    CC. Не стоит.

    A. Почему?

    Q. Ты соврал в резюме, что учился в институте? - спросила королева ледяным тоном.

    A. Э-э-э…

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

    Армигер смутился.

    A.  А вот здесь ошибка.  Коэффициент полезности должен вычисляться, как одно делить на другое. А здесь минус…

    Q.  Я уже сказала “Головы с плеч”? - глядя в пространство спросила королева.

    H&MH. Нет, моя госпожа - синхронно ответили Шляпник и Заяц и также синхронно втянули головы в плечи изображая крайний испуг.

    CC. Ну же, мон шер - Чеширский Кот был сама любезность, - вы же учили математику.

    A.  Да - смущенно признался армигер - Матан, Теорвер, ТФКП, …

    CC.  Вздор - прервал его Кот, - здесь вполне хватит школьной программы.

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

    MH. Чу! Cлышу! У него скрипят шестеренки!

    H. Их необходимо срочно смазать.

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

    MH. Королева сегодня сурова.

    H. Что ты, королева - добрая душа. Я помню, три дня назад тут поймали японского шпиона…

    Дружный хохот наполнил кухню. Новый года в компании начинался нормально.

  • Стимулятор прохождения заказов по производственным цепочкам

    Видео: http://www.youtube.com/watch?feature=player_embedded&v=HQHt01e3Lns

    Виртуальная машина с предустановленным софтом: http://www.oracle.com/technetwork/middleware/soasuite/learnmore/vmsoa-172279.html

    Поиграл 10 минут. Штука очень любопытная. Однозначно “обязательна для изучения”. Не выясненные моменты:
    * Есть ли возможность установить связь между временем выполнения заказа и его стоимостью?
    * Есть ли расчет потерь, связанных со связанным капиталом?
    * Есть ли вообще расчет прибыли/убытка?
    * Можно ли сделать несколько точек старта и финиша (для имитации потоков V,A,T типа)
    И т.д и т.п.

    Коллеги, кто нибудь изучал этот симулятор?

  • Идеальное состояние багтрекера

    Normal 0 false false false RU X-NONE X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:”Обычная таблица”; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:”"; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin-top:0cm; mso-para-margin-right:0cm; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0cm; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:”Calibri”,”sans-serif”; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:”Times New Roman”; mso-bidi-theme-font:minor-bidi; mso-fareast-language:EN-US;}

    Идеальная техническая система -это когда системы нет, а ее функция выполняется.

    (с) ТРИЗ

    Ряд авторов называют наличие бактрекера в качестве одного из признаков зрелости команды разработчиков ПО.

    Действительно, множество растущих команд (компаний) в какой-то момент сталкиваются примерно с одной и той же проблемой. Список дефектов растет и в какой-то момент требуется специализированное средство для управлением порядком исправления. С пятком багов можно легко справиться при помощи почтового клиента. Полсотни багов можно вести в Excel. Но когда их пара тысяч – это уже многовато. И каждый «настоящий» инженер по качеству ПО (в просторечии тестировщик) знает, что по настоящему бороться за качество без бактрекера нельзя. Это догмат. Доктрина веры. Нет бактрекера – нет настоящих инженеров по качеству ПО. Чистая кристальная истина, в которой нельзя усомниться ни на секунду, как нельзя не услышать звук хлопка одной ладонью. А если 20 лет назад выпускались великолепные программы, без использования багтрекинга, то это просто ошибка наблюдения.

    Но иногда встречаются «не настоящие».

    Из книги Мэри и Тома Поппендик «Бережливое производство программного обеспечения»:

    …возможны две разновидности контроля: контроль с целью обнаружения дефекта (когда он уже имеется) и контроль с целью его предотвращения…

    Системы …[багтрекеры] – это очереди незавершенных работ; если угодно, очереди работ, … [на] исправление. Очень часто мы полагаем, что если дефект помещен в очередь, все в порядке, он уже никуда не денется. Однако с точки зрения концепции бережливой разработки программного обеспечения, очереди – это коллекторы непроизводительных затрат. Целью является не иметь в очереди ни одного дефекта, а еще более «целесообразная цель» - не иметь такой очереди совсем. Если вы считаете, что это невозможно представить, познакомьтесь с трехгодичным опытом работы Нэнси Ван Шундерворт над проектом по разработке сложного и часто изменяющегося встроенного программного обеспечения. За три года был в целом обнаружен 51 дефект после блочного (или модульного) тестирования, причем каждый раз выявлялось не более двух дефектов сразу. Кому нужна система отслеживания для всего двух дефектов?

    Примечание. Перевод я немного поправил. Совсем чуть-чуть. Только явные ляпы.

    Действительно, зачем фиксировать дефект в трекере?! Его не фиксировать надо, а исправлять. Нашли и сразу дустом его, дустом. Чтобы не размножался. На первый взгляд остается непонятным, что делать с тестировщиками. Основной артефакт, который выдают тестировщики – это список расхождений между ожиданиями и реальностью. Но пусть вас не смущает этот вопрос. Там где по настоящему пекутся о качестве, там работают не тестировщики, а инженеры по качеству ПО, которые преимущественно занимаются верификацией не скомписированного кода, но других артефактов, таких как: «требования», «диаграммы архитектуры», «исходный код».

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

    Благодарности.

    Спасибо Мери и Тому Попендик, Элияху Голдратту, Тайичи Оно и Капитану Очевидность.

  • Одним предложением

    Таити Оно изобретатель производственной системы Toyota и технологии Канбан: ‘Моя система вообще не имеет смысла, но слава Богу, она работает’.

    Если вы по какой-то причине хотите завалить проект и остаться чистеньким - выполняйте все требования заказчика.

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

    Хорошо, когда с прошлой работы тебя ищут только для того, чтобы премию отдать.

  • Правила нарушения трудовой дисциплины

    В первый раз публиковалось на 1 апреля, так что …
    С другой стороны, можно использовать как шаблон (рыбу) для написания регламентов, подобно “СМК от питерских
    ———————————————–
    Каждый работник имеет право на проступок.

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

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

    Соответственно:
    Каждый сотрудник должен каждый месяц совершить несколько проступков. Например:

    • Использовать внутрикорпоративную почту для рекламы гербалайфа
    • Предлагать клиентам фирмы прикупить журнал плейбой или комиксы про человека-паука
    • Обедать в течение всех 9 часов
    • И, даже, иногда, высказывать в приватных беседах неверие в судьбу фирмы

    Контроль за регулярным и своевременным нарушением порядка всеми сотрудниками фирмы возлагается на офис менеджера.

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

    Свободу Анжеле Девис!
    От Анжелы Девис руки!
    Дайте свободу Анжеле,
    Дайте свободу буки!!!

    Каждый сотрудник имеет право оказать посильную помощь в разработке правил нарушения дисциплины.

    Получение и чтение подобных писем является нарушением трудового распорядка. Так что вы только что совершили два должностных проступка.
    ;-)

More Posts Next page »

This Blog

Syndication

Powered by Community Server (Personal Edition), by Telligent Systems