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

Очень хотелось бы понять, чем руководствуется начальство, когда поручает решение стратегических вопросов не совсем компетентным людям?

Это жадность/не дальновидность - сэкономим побольше?
Некомпетентность - сами не знают что это такое, пусть мальчик почитает и нам расскажет?
Неверие в нужность тестирования - пусть займется чем-нибудь, авось и пригодиться в будущем?

:ph34r:

Я еще бы добавил, что человек может прикидываться ..., а быть вполне приличным человеком (или наоборот?). Кто знает какие у него интересы? Не факт, что он некомпетентен, но не факт, что и наоборот. По паре, десятку постов ничего не понятно.
Тенденции, описанные Вами конечно же есть, но это скорее исключение, а не правило.
Сейчас (в России) все чаще встречаются проектные подходы в решении задач. А иметь своих "проектных менеджеров" для организаций очень заманчиво.
Вообще в моей практике был анекдотичный случай, когда целые организации создавались для "хорошего человека".

Я боюсь, что мы (я) не сможем (смогу) бороться с таким источником компетенции как ГОССТАНДАРТ России (правда, некоторые смогут :))
А он четко определил:
verification - верификация
validation - аттестация
хотя их определения вам (мне) не понравятся :)

О валидации
В переводе уже упомянутой книги Rapid Testing термин Validation рассматривается как "аттестация", а аттестация это есть "определение качества продукции" (по www.km.ru) , о чем, кстати, далее в книге и говорится
И, на мой взгляд, это правильно, так как этот термин не подразумевает только техническую оценку, или технические действия по оценке.

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

Подытожу, если непонятно :), в двух этих терминах я согласен с переводом книги "Rapid Testing" (Зав. ред. С.Н. Тригуб)

Можно и так, почему бы и не пропустить некоторые действия, если это не приведёт к печальным последствиям. Это вопрос организации процесса. Иногда такая оптимизация прокатит, а иногда и нет.

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

Можно и так, почему бы и не пропустить некоторые действия, если это не приведёт к печальным последствиям. Это вопрос организации процесса. Иногда такая оптимизация прокатит, а иногда и нет.

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

С удовольствием расскажу.

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

Предположим также, что перед началом каждой деятельности выполняется только контроль входа так, как это понимают люди, осуществляющую эту самую деятельность.

Что проверит архитектор? Он проверит, что требования полны, замкнуты и непротиворечивы. Это критерий "правильных входных данных" для его работы. Что он не проверит? То, что модель адекватно отражает реалии предметной области. Это -- критерий "правильных выходных данных" анализа и моделирования.

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

Что получится в итоге такого процесса? Трудно сказать что именно, но вряд ли то, что ожидает заказчик.

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

Алексей, я Вас (себя?) здесь и подловил, за что Вам спасибо :)
В этой ситуации вообще выпал процесс верификации :) (по ГОСТ 12207)

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

Если я правильно понял уважаемого Victor, то единственное противоречие между моей позицией и позицией Госстандарта России, это перевод термина Validation.

Я их приведу, а то вдруг у меня устаревший вариант (ГОСТ Р ИСО/МЭК 12207-1999)

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

Что-то очень похожее на технический контроль

Косвенно с этим соглашается и Victor

Да

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

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

А готовы ли Вы (Госстандарт) согласится с тем, что технический контроль- это частный случай аттестации/сертификации? Другими слова, аттестация - это технический контроль с последующим(в случае удачного его завершения) оформлением соответствующего документа- Сертификата?

ГОСТ на Вашей стороне, Анатолий, за исключением перевода :), и он не требует сертификата

PS. Международная организация по стандартизации (ИСО) запросто добавила в русский язык слово "валидация",например, ИСО 9001:2000. Узнать бы кто это так перевел, ... И как после этого верить людям?

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

А вот такой подход гораздно более интересный, целесообразный, правильный, качественный, оптимальный (не нужное зачеркнуть!):
Некий артефакт появляется на выходе ящичка хоть белого, хоть черного - делаем ему верификацию (потому как этого вполне достаточно!) и суем в следующий и т.д., пока не вываливается артефакт в виде готового продукта, тогда аттестируем (конкретно!), представляем объективные доказательства (не подкопаться!) - и кладем баксы в карманы - все счастливы, заказчик, разработчик, я, ГОСТ, Анатолий, Алексей и Сергей?

Viktor,

Вы полностью соответствуете выбранному Вами псевдониму!

Спасибо

Какова основная мысль в Вашем предыдущем сообщении?

B)

Нельзя бросать дело, не доделав его до конца. Особенно, когда за этот конец заплатили и его ждут :).
И если что-то от этого дела долетело, нельзя говорить что это именно тот конец.
(Скоро начну себя в рамки вставлять :))

Прыгун в высоту. Хороший прыгун. Гарантированно прыгает 2 метра, даже выше может, но 2 метра -- гаратированно. Имеет сертификат "Прыгун на 2 метра". Как он его получил? Сертификационная организация проверила, что 1000 последних прыжков была не ниже 2 метров и на основании этого выдала сертификат.

Но вот кто-то бросил шкурку от банана как раз в тот момент, когда он собирался сделать 1286-й прыжок, и она упала ему под ноги, и он поскользнулся и сшиб планку. Кошмар! Да нет, ничего страшного, ногу-то не сломал, в следующий раз он снова прыгнет выше двух метров. Не надо отбирать у него сертификат. Он всё ещё хороший прыгун. Но прыгнуть не смог.

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

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

Если это качественный прыгун и он следует требованиям, он не остановится пока не прыгнет на два метра, даже если первый раз ему это не удалось.
Именно для того, чтобы не было таких "брошенных" прыжков и существуют требования стандартов по обеспечению качества. Прыгун должен прыгать до тех пор, пока не перепрыгнет. И заказчик знает, прыгун будет прыгать, а не плюнет и скажет, что "в следующий раз". И вот это я называю гарантия качества и этого требует стандарт. Прыгать не до обеда (или один раз), а прыгнуть на определенную высоту, и не важно сколько раз придется прыгнуть для этого. Хотя в другой ситуации, возможно, потребуется прыгать до обеда. Значит качественный будет тот прыгун, который будет прыгать до обеда.
Заказчик не любит случайностей. Все должно быть определено и измерено. ГОСТ нужен заказчику, а не производителю изначально. Здесь палка о двух концах, на одном конце один поставщик, у которого, возможно, "толковые ребята", на другом - поставщик с гарантированным качеством услуги. Где заказчик? Особенность системы менеджмента качества как раз и заключается в том, что стоимость услуги не увеличивается(даже сокращается). Заказчику должно гарантироваться качественное исполнение заказа. А сколько это стоит (сколько раз нужно прыгнуть), это не проблема качества (хотя, возможно, проблема заказчика). Возьмите такой пример: без ТЗ сложно оказывать качественные услуги, с этим все согласны (кроме бабушки :)). Сколько будет стоить разработка продукта без ТЗ, или по ТЗ? Заказчику? Разработчику? (Я уже не говорю о рисках вообще не получить продукта). Но получение продукта - лишь доля работ по получению прибыли. Его нужно качественно подать, качественно поддержать и т.д. Вот у разработчика есть продуктный стандарт. Продукт удовлетворяет требованиям заказчика сегодня. А завтра? Заказчику, необходимо чтобы и завтра он удовлетворял его требованиям. А где это требование прописано? В процессном стандарте :). Вот и понятие возникло - жизненный цикл. Требования стандарта - обеспечение качества на протяжении всего жизненного цикла. Хочешь мертвую программу - пожалуйста, говорят, есть нетленные тела. Лично мне нужна программа без запаха. "Программа умирает", если не поддерживается и не обслуживается. Прыгун дряхлеет и чахнет, банан гниет. Но появится новый прыгун, вырастет новый банан. Появится другая программа и другой разработчик на нашем месте, если мы не будем качественно исполнять заказ.

Нельзя бросать дело, не доделав его до конца. Особенно, когда за этот конец заплатили и его ждут :).

А разве, кто-то с этим спорит?

B)

Никто, наверное, просто размышляем :)
Вот, например, если все с этим согласны, то как это гарантировать?
Мой тезис такой - Качество процесса - гарантия доведения проекта до качественного конца.
Чем меньше качество процесса - тем меньше гарантии.
Алексей требует ответа "Да или Нет". Я сказал "Да"
Человек 8, мне кажется, вот здесь уже возразят.

Стандарт не гарантирует, что разработчик будет за свои деньги исправлять ошибки, а договор -- гарантирует.

За чьи деньги - это к качеству продукта не относится. Гарантия стандарта, что ошибки (если возникнут) будут исправляться (если это необходимо).

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

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

Хороший договор - тоже требование процессного ГОСТа

Возьмите такой пример: без ТЗ нельзя оказывать качественных услуг, с этим все согласны (кроме бабушки :)).

Не только бабушка, я тоже с этим не согласен :)

Хорошо, заменяю "нельзя" на "сложно". Хотя для меня это одно и тоже.

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

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

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

Не думал, что эти Имена нужно озвучивать :)
По стандартам и моделям: начиная с ИСО 9000 и далее, 12207, 12119, 9126, рекомендации по стандартизации 50.1.*, ГОСТ 19.*,34.*, 28195 и т.д (далеко не полный список, мне достаточно только этих).
Возможно, СММ ( а уж CMMI - просто песня) даже лучше, но, увы, сначала хотим достигнуть "показателей, позволяющих летать на самолете, а уж потом на космическом корабле".

Кто-нибудь может ответить на любой из этих трёх вопросов?

Могу ответить на первый и третий
Во-первых, давайте говорить не "ГОСТ гарантирует", а "выполнение требований ГОСТ гарантирует", так проще, понятней и правильней, ГОСТ сам по себе ничего не гарантирует :).
Во-вторых, основной принцип системы менеджмента качества ИСО - ориентация на потребителя. Поэтому ГОСТ требует, чтобы значения характеристик качества должны быть приемлемы для потребителя. Это значит, что если потребитель требует количественных метрик, они должны быть посчитаны, если ему достаточно простых оценок типа "круто/не круто", продукт должен быть оценен с учетом этого представления. ИСО 9001 не поможет в измерении качества продукта, а вот ИСО 9126 очень даже поможет.
Что же касается третьего вопроса, то это частный случай первого, но довольно интересный.
Была такая хорошая статья в ОС

При применении на предприятии устоявшихся процессов качество разработок будет выше (при условии соблюдении стандартов на эти процессы).

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

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

Да, без него сложно. Вопрос в другом: а с ним -- гарантируется, что продукт будет качественным?

Конечно одного ТЗ недостаточно.
Но здесь появляется следующий вопрос: Что нужно, чтобы создать качественный продукт? Естественно,
следовать требованиям ГОСТ (и/или какой-нибудь авторитетной модели), в том числе и требованиям к процессам.
Но это все проблема тех или иных артефактов, скажет сомневающийся :).
А вот еще одно предложение
"Процессный" ГОСТ требует выполнения в ходе проекта постоянных действий по оценке продукта и процесса разработки с привлечением заказчика. Попробуйте без V&V создать качественный продукт или оказать качественную услугу!

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

Случайно - вполне запросто :)
Ну я могу качественно перевести бабушку через дорогу. Но имея стандарт перевода бабушек, я могу организовать отряд скаутов для качественного перевода всех бабушек улицы.

Не можете :(.
Вполне может оказаться, что бабушка даже останется живой :), но это будет в любом случае некачественная услуга. Скажите честно, будете ли Вы достаточно "удобным" для использования Вас в качестве средства для перевода бабушки через улицу? :) Наверняка Вы выше ростом, Ваш шаг шире, у Вас крепкая рука (будете давить на бабушку :)), Вы будете спешить по своим делам, бабушка начнет нервничать, Вы будете ее успокаивать, от этого она будет еще больше нервничать :) и т.д., а?

Я смогу перевести бабушку, вполне случайно, так что полностью удовлетворю все её требования по переводу: скорость движения, давление на руку, конечній пункт (другая сторона).

То есть у неё будут невысокие требования - я окажу услуги согласно её требованиям, то есть окажу качественную услугу, соответсвующую требованиям + в нужное время, в нужном месте.

Я потому и усомнился в качестве, так как требования бабушки Вы ведь не узнали? Просто повели ее в неизвестном (удача - если совпало :)) направлении. Ваше качество будет очень субъективное. Бабушка может думать совсем по-другому. Услуга только тогда будет считаться качественной, если представлены объективные доказательства. Предположем, что Вы получили вознаграждение от бабушки в сумме $50, это уже объективное доказательство ее удовлетворенности. Но ведь случайно такого не бывает?

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

Ну вот есть станарт, его адаптировать надо - и от этого будет зависеть как применять.

Это, кстати, одно из первых требований стандарта 12207

видимо, мы опять говорим на разных языках

Я все еще во власти данного Вам обещания. Хотя сомнения уже закрадываются в мою голову :).

Ну что же, интерес вполне обоснованный и сомнения тоже.
Экспертная оценка, нормальный метод. Мы работаем в команде. Команда профессиональна. Если у кого-то есть сомнения в качестве, продукт не поставляется. Время не имеет значение, ресурсы - тоже. Качество - имеет значение. Работаем, пока все сомнения не устранены.
К Алексею: верю (хотя, я привык сомневаться во всем, как-то я уже это писал, видно к работе это не относится). Вопрос в другом, верит ли мне менеджмент? Не знаю, но если я (или другой ответственный специалист) сказал, что продукт готов, ему этого достаточно (Значит верит?).

Виктор, вопрос именно в том КАК Вы определяете, что ошибок НЕТ? Никакая оценка не даст такой гарантии на 100%.
Что именно устраняет все Ваши сомнения?

К сожалению, наш процесс разработки очень завязан на конкретные условия.
Т.е. он работает в наших условиях рассказать о нем в двух словах не могу, на большее пока не готов.
Но я запомню Ваш интерес и по мере возможности расскажу.
Главный принцип - верификация любого продукта в любой стадии, будь то проектная модель, ТЗ или код программы. Что это значит? Например, если при тестировании, выявилось какое-либо непонимание исходных требований, значит возвращаемся к стадии анализа. Ресурсоемко, затратно по времени, но зато качественно.

Вы упомянули верификацию. Что Вы имели в виду -- динамическую верификацию (в просторечии называемую тестированием) или формальную проверку правильности программы?

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