Новая статья: Три ступени развития службы контроля качества ПО

В библиотеку добавлена статья Сергея Гринкевича "Три ступени развития службы контроля качества ПO". Статья написана по мотивам доклада, который был сделан Сергеем на конференции “Российские Интернет технологии 2007″ (РИТ2007) в апреле 2007 года в Москве.

Вам нужно создать отдел контроля качества "с нуля"? Прочитайте статью, пройдите описанный в ней "тест Гринкевича", запомните три шага, которые вам предстоят -- и в бой!

Читать статью...

Я прекрасно понимаю, что Сергей знает разницу между тестированием и обеспечением качества, но почему-то эти понятия часто смешивает (и не только в этой статье).

С моей точки зрения, тестирование - это неотъемлемая часть процесса разработки и написания кода, поэтому говорить, что "тестирование не создает прибавочной стоимости" неверно. Вопрос лишь в том, кто тестирует, как и с какой целью - но кто-то делает это обязательно. Без этого оно просто не заработает :-)

А вот обеспечение качества - это вещь опциональная и в некоторых случаях даже излишняя.
Code&fix - это вполне себе модель разработки, иногда даже коммерчески успешная (чаще для небольших проектов).

С моей точки зрения, тестирование - это неотъемлемая часть процесса разработки и написания кода, поэтому говорить, что "тестирование не создает прибавочной стоимости" неверно. Вопрос лишь в том, кто тестирует, как и с какой целью - но кто-то делает это обязательно.

Если кто-то что-то делает, это ещё не значит, что от этого создаётся прибавочная стоимость
Лично мне тоже не нравится эта экономическая модель, основанная на прибавочной стоимости, но если говорить в рамках неё -- таки да, не создаётся. Вот после того, как, скажем, дефект исправлен -- тогда создаётся. А чисто после тестирования -- ноль.

А вот обеспечение качества - это вещь опциональная и в некоторых случаях даже излишняя.

Верно также и обратное -- если вы можете обеспечить нужный уровень качества без тестирования, значит обеспечение качества у вас есть, а тестирование оказалось не нужно.

В том-то и подвох, что quality assurance направле на обеспечение гарантированного уровня качества при предсказуемых сроках и расходах.

А вот необходимый уровнь качества для конкретного ПО можно достичь любым способом :-)

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

По поводу прибавочной стоимости тестирования дискутировать не буду :-)
IMHO это неотъемлемая часть процесса разработки, навязывать его не буду.

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

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

Верно также и обратное -- если вы можете обеспечить нужный уровень качества без тестирования, значит обеспечение качества у вас есть, а тестирование оказалось не нужно.

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

Последние два абзаца :)

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

Последние два абзаца :)

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

Хотя, возможно будет продолжение

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

Последние два абзаца :)

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

Хотя, возможно будет продолжение

Коллеги,

прошу учесть то обстоятельство, что я не собирался включать разбор метрик в доклад. На все про все у меня было 45 минут. Я и так превысил этот лимит.

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

Кстати, я выложил запись доклада на веб-ресурс. Его (доклад), можно посмотреть на странице моего блога:
http://www.drquality.ru/?p=22