Перейти к содержимому

Фотография

QA в инженерных отраслях.


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 35

#21 LeshaL

LeshaL

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 094 сообщений
  • ФИО:Алексей Лянгузов
  • Город:Saint-Petersburg


Отправлено 30 января 2008 - 08:22

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

А я и не пытался доказать такую связь :) Возможно я не понял изначального вопроса...
Я пытался показать, что работа над процессами - это не просто затраты для фирмы, т.е wasting денег. Иногда это оборачивается вполне неплохой прибылью. Для этого и был пример. Причем я сам интересовался вопросом, а зачем вообще нужна сертификации по СММ или ISO. Вот мне недавно такой факт рассказали.
И еще, я нигде не писал, про "высокое качество продукции неназванной компании". Я его не оценивал. Я написал, что команда несколько лет работала "не для сертификации, а для выпуска качественных продуктов". Видно качество этих продуктов было good enough, как принято говорить, раз с ними захотели заключить контракт. Может оно было и высоким - не знаю.

Т.е. где переход от "у нас есть вылизанные процессы" к "мы делаем качественную продукцию"

Переход неочевиден, согласен. И доказать его сложно. Надо насобирать статистику. На разных тренингах\курсах рассказывают что связь есть, приводят примеры (success stories) каких-то компаний (тоже неназываемых, зачастую). Мой вопрос, на одном из курсов, про то, каков процент таких success stories, по отношению к общему числу фирм, получавших сертификаты - остался без ответа :(
На пальцах объяснить можно так. Предположим, есть кондитерская. Пекут пирожки, булочки. Каждый день им привозят одни и теже ингредиенты. Но у них нет процесса и нет рецептов. То в духовке передержат, то тесто недосолят итд. Но иногда получается. Будете покупать у них пирожки? А если они нарушают правила СЭС - нет сан.книжек и не моют посуду? Правильно - вы у таких пирожки покупать не будете.
А теперь представим, что у них все блестит и СЭС придраться не к чему. Рецепты сложились годами, а технологический процесс соотвествует ГОСТам. Есть гарантия, что пирожки у них качественые? Гарантии - нет, но вероятность того, что они лучше, чем у фирмы где ничего этого нету - намного выше.
  • 0
Regards,
Alexey

#22 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 30 января 2008 - 09:40

Пекут пирожки, булочки.

Какое это отношение имеет к инженерии? Или к "крупной" проектной деятельности?
Я не отрицаю, что QA успешно применяется при массовом производстве и обслучивании. Там даже слово "процесс" имеет смысл сходный с тем, который применяется в слупах. См. например здесь. Эти методы мне в целом ясны и я их, кстати, применяю профессионально, т.к. нагрузочные тестировщики по долгу службы часто работают с процессами массового обслуживания и (пусть иногда воображаемыми) control chart-ами.
А вот то, как SEI или кто там ещё этим делом занимается подтягивает его к денежным в настоящий момент областям, при этом ещё и осваивая федеральные фонды, действительно выглядит непонятно (и путаница в терминологии во многом из-за этого и возникла, как я могу судить). Ну а то, как это дело поняли и могут объяснить консультанты по тестированию и QA, вообще выглядит смехотворно.
  • 0

#23 Boltick

Boltick

    Специалист

  • Members
  • PipPipPipPipPip
  • 596 сообщений
  • ФИО:Алексей
  • Город:планета Земля

Отправлено 30 января 2008 - 10:06

Добрый день,
решил и от себя кое чего добавить.

Работал я как-то на одну ГОСконтору в славном городе Минск, причем это было в те времена, когда я даже не представлял себе что такое тестирование и QA. Вызывает меня начальник и говорит:
- Алексей, надо написать программу для отдела А.
Я согласился, и начал работу. Сходил в отдел, поговорил с теми, кому нужна была та программа, они все рассказали. Я в принципе был готов начать писать ее. Пришел получить добро от начальника. А он мне:
- не, так дела не делают. Сначала напиши ТЗ, затем подпиши его у начальника отдела, службы, участка, главного инженера и у меня. Вот когда все это будет готово, приходи и поговорим.
Пошел я писать ТЗ. Написал из головы документ, принес начальнику показать. Он посмотрел, порвал его и сказал, что документ не по ГОСТу. Пришлось искать гост и писать по нему весь док.
Написал ТЗ, потом еще 2 месяца его визировал, каждый подписывающий считал своим долгом делать замечания, дополнения и т.д. В итоге когда все было подписано у меня было ТЗ страниц на 150, включающее задание, требования, экранные формы и т.д.
По которым просто можно было сесть и кодировать приложение.

Т.е. получается в этой гос конторе был налаженный процесс производства ПО. И что-то мне кажется, процессы там стояли за каждым шагом, каждого сотрудника.
  • 0
Алексей Булат
Про Тестинг

#24 Green

Green

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 30 января 2008 - 10:29

В одной классной статье прочитал про историю развития качества. (Потом искал ее, искал в Интернете. Не нашел. А жаль, очень мне понравилась статья.) Ниже привожу краткое резюме статьи со своими добавлениями.

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

2. Контроль качества "на выходе" каждого этапа обработки.
Однако, при таком подходе большая часть продукции могла идти с браком. Для того, что бы повысить степень выхода продукции был придуман новый подход к контролю качества. Он звучит примерно так, если делать качественно на каждом этапе обработки, то в результате некачественный промежуточный вариант будет отбракован сразу же, по допущению брак. В результате бракованная деталь не поступает в дальнейшую обработку и не будет выпущен продукт с бракованным элементом внутри.

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

4. Контроль качества "на входе" поставщиков.
Японцы первыми предложили модель работы, когда поставщики комплектующих соглашаются ввести правила своего заказчика по проверке комплектующих "на входе" своего производства. Именно благодаря такому подходу при сравнимом производстве компания Тойота в Японии имеет всего лишь десяток поставщиков, а компания Дженерал Моторс - более 3000. Последней приходится контролировать всех своих поставщиков, а японской компании - только прямых поставщиков, так как она уверена в том, что поставщики ее поставщиков выполняют все требования Тойота по обеспечению качества.

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

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

Если все выше сказанное перевести на ИТ область, то станет понятным главная идея стандартизации - берите в качестве примера обобщенные методики успешных компаний и, может быть, вы так же получите положительный результат.
  • 0
Гринкевич Сергей

#25 Green

Green

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 30 января 2008 - 10:35

Кстати, в начале каждого стандарта нужно обязательно добавлять фразу:

"Настоящим вы соглашаетесь с тем, что использование настоящего стандарта осуществляется исключительно на ваш страх и риск. Авторы стандарта ответственности за негативные последствия, а равно и за не наступление положительных последствий, ответственности не несут."
:acute:
  • 0
Гринкевич Сергей

#26 LeshaL

LeshaL

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 094 сообщений
  • ФИО:Алексей Лянгузов
  • Город:Saint-Petersburg


Отправлено 30 января 2008 - 10:56

Пекут пирожки, булочки.

Какое это отношение имеет к инженерии? Или к "крупной" проектной деятельности?

Пирожки прямого отношения к инженирии не имют, разве что инженеры их иногда едят.
А это называется аналогия.
Замените булочки на ПО, кондитерскую - на софтверную контору, рецепты - на бест практиз, тех.процес - на процеес производства ПО (RUP, SCRUM или какой нравится), СЭС - на организацую, проводящую аудит. И у вас получится понять о чем это я. Хотя я думаю, что вы и так все поняли.

Я не отрицаю, что QA успешно применяется при массовом производстве и обслучивании. Там даже слово "процесс" имеет смысл сходный с тем, который применяется в слупах. См. например здесь. Эти методы мне в целом ясны и я их, кстати, применяю профессионально, т.к. нагрузочные тестировщики по долгу службы часто работают с процессами массового обслуживания и (пусть иногда воображаемыми) control chart-ами.
А вот то, как SEI или кто там ещё этим делом занимается подтягивает его к денежным в настоящий момент областям, при этом ещё и осваивая федеральные фонды, действительно выглядит непонятно (и путаница в терминологии во многом из-за этого и возникла, как я могу судить). Ну а то, как это дело поняли и могут объяснить консультанты по тестированию и QA, вообще выглядит смехотворно.

Если консультант приходит в фирму с каким-нибудь дуболомным процессом, который этой фирме не нужен. И начинает навязывать этот процесс, ломая то что работало. - Тут не смеяться надо, а в шею гнать.
Но если приходит человек, который сначала находит проблемные области, затем начинает их постепенно устранять. То такого консультанта, надо беречь и потом рекомендовать знакомым.
Да и звать консультантов надо в случае, когда самим понятно, что что-то не работает. И что своими силами справиться не получается.
  • 0
Regards,
Alexey

#27 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 30 января 2008 - 10:58

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

Ну, собственно, это не новая точка зрения (я с ней не согласен, считаю её подменой понятий). Только хотелось бы, чтобы подтверждения были не на уровне оголтелого позитивизма. Конкретно вызывает сомнение, что именно обобщённые методики принесли успех успешным компаниям.
  • 0

#28 Green

Green

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 30 января 2008 - 12:24

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

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


аббат, сорри.

Я бы что-нибудь ответил, но ничего не понял из написанного.
:acute:
  • 0
Гринкевич Сергей

#29 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 30 января 2008 - 12:35

:acute:

Что неясно? Гражданин в статье утверждает что свойство повторяемости процесса (чтобы что-то было статистически измеримым и в связи с этим называлось процессом, оно должно повторяться, причём чем чаще и неизменнее, тем лучше), это на самом деле свойство повторённости за кем-то (то же самое что Вы, кажется, хотите утвердить) и дальше пытается разьяснить некоторые нестыковки этой теории с практикой. По-моему чистая игра слов.

P.S. А позитивизмом я назвал позицию: "Ну вот оно же где-то работает, приносит прибыль, значит вещь стоящая, разбираться подробно не будем".
  • 0

#30 Green

Green

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 30 января 2008 - 13:35

Честно говоря, статью я даже не читал. Как-то обломно.

Я имел ввиду, что ничего не понял из написанного Вами. :acute:
Но теперь Ваша позиция проясняется.

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

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

Мораль из написанного следующая.
Если у кого не получается правильно применить стандарт, то стоит проверить, откуда руки растут, а уж потом пенять на бумажку.
  • 0
Гринкевич Сергей

#31 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 30 января 2008 - 14:00

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

Да не применяю я стандарты, так, прицениваюсь просто. :) Но хочу посмотреть, стоит ли что-то реально за всякими заявлениями типа: "для внедрения автоматизированного тестирования нужен зафиксированный процесс тестирования" или это такая же игра слов и отмазка на случай неудачи по другим причинам.
  • 0

#32 Green

Green

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 30 января 2008 - 14:54

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

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


Совершенно правильный и разумный подход.

Следует только учитывать один момент. Когда речь идет о промышленном подходе (то есть когда нужно управлять не одним проектом, а несколькими, и не одним человеком, а несколькими группами), то сразу же встает вопрос об унификации типовых операций. (Зачем придумывать каждый раз новый велосипед, если все уже придумано до нас?)

Унификация операций - это типовое решение типовых задач. Методику решения задач можно придумать самому, либо взять за основу один (а может быть и не один) стандарт. Выбирайте то, что Вам больше нравится.
  • 0
Гринкевич Сергей

#33 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 30 января 2008 - 15:00

то сразу же встает вопрос об унификации типовых операций. (Зачем придумывать каждый раз новый велосипед, если все уже придумано до нас?)

Унификация операций - это типовое решение типовых задач. Методику решения задач можно придумать самому, либо взять за основу один (а может быть и не один) стандарт. Выбирайте то, что Вам больше нравится.

Это правда. Но правда ли что это процессный подход (я считаю, что QA всё-таки должно быть основано на процессном подходе, отходить от этого не надо)? Т.е. правда ли что такие операции, как бы часто они не выполнялись, полезно оформлять в полноценные процессы с документарными входами, выходами, унифицированными средствами мониторинга и воздействия.
  • 0

#34 Green

Green

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 31 января 2008 - 13:44

то сразу же встает вопрос об унификации типовых операций. (Зачем придумывать каждый раз новый велосипед, если все уже придумано до нас?)

Унификация операций - это типовое решение типовых задач. Методику решения задач можно придумать самому, либо взять за основу один (а может быть и не один) стандарт. Выбирайте то, что Вам больше нравится.

Это правда. Но правда ли что это процессный подход (я считаю, что QA всё-таки должно быть основано на процессном подходе, отходить от этого не надо)? Т.е. правда ли что такие операции, как бы часто они не выполнялись, полезно оформлять в полноценные процессы с документарными входами, выходами, унифицированными средствами мониторинга и воздействия.


Следует различать вопрос оформления и самого свершения.

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

Что касается оформления процесса, то это можете его описать, а можете передавать из уст в уста и открыть даже специальную должность - гусляр процесса, который будет ходить из проекта в проект и на своих гуслях петь о том, как хорош ваш процесс и горе тому, кто его не блюдет.
:biggrin:
  • 0
Гринкевич Сергей

#35 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 31 января 2008 - 15:26

процесс - это всего лишь набор последовательных действий.

Да с чего вы взяли-то, что процесс это просто некий алгоритм действий, оракул, который говорит, что надо делать в какой последовательности, который можно выразить достаточно абстрактным (одинаковым для разных выполнений процесса) текстом или заменить гусляром? Тогда давайте может объясните мне популярно, о чём речь идёт при обсуждении необходимых условий для внедрения автоматизированного тестирования. Там процесс и гусляр идут разными пунктами, т.е. автор, видимо, видел между ними какую-то разницу, жаль только не хочет раскрыть эту свою мысль.
  • 0

#36 Green

Green

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 31 января 2008 - 15:54

процесс - это всего лишь набор последовательных действий.

Да с чего вы взяли-то, что процесс это просто некий алгоритм действий, оракул, который говорит, что надо делать в какой последовательности, который можно выразить достаточно абстрактным (одинаковым для разных выполнений процесса) текстом или заменить гусляром? Тогда давайте может объясните мне популярно, о чём речь идёт при обсуждении необходимых условий для внедрения автоматизированного тестирования. Там процесс и гусляр идут разными пунктами, т.е. автор, видимо, видел между ними какую-то разницу, жаль только не хочет раскрыть эту свою мысль.


аббат,

а кто Вам сказал, что процесс - это только то, что записано на бумаге?

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

Так что гусляр - он тоже про процесс, только не формализованный.
:biggrin:


P.S.
Если вопрос про гусляра, то это в этой ветке.
Если вопрос по посту "Что необходимо для внедрения...", то это к автору топика.
  • 0
Гринкевич Сергей


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных