Сообщений в теме: 12

[Case]

Качественный успех
Автор: Артём Ваулин

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

Существует множество различных способов для достижения этих целей. В рамках же данного монолога хотелось бы немного поговорить о КАЧЕСТВЕ. Не о каком-то абстрактном качестве из Большой Советской Энциклопедии (или из Модных Западных Стандартов), а о том реальном КАЧЕСТВЕ производимых, разрабатываемых и внедряемых нами продуктов и услуг, которое позволяет сделать эти самые продукты и услуги лучшими и, как следствие, приближает нас к заветным целям.

-----------------------------
Другие статьи раздела "Качество ПО"

[barancev]

"Хлебные крошки" (над заголовком) неправильный путь указывают -- "Методология построения тестовых случаев на основе ортогональной классификации дефектов".

[Case]

Исправил - спасибо.

[SALar]

Артем, статья понравилась. Несколько замечаний.

Внедрение на проектах тестирование требований.

Предложение не согласованно. Правильно: «тестированиЯ».
И еще. Словосочетание «Тестирование требований» - устоявшийся оксюморон. Можно оставить, можно заменить.

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

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

Он не панацея. «Серебряной пули нет» (с) Брукс «Мифический человеко-месяц». Я не против фразы, я против категоричности. На мой взгляд будет лучше убрать «Только» и заменить «позволит» на «поможет».

тестирование должно осуществляться штатными тестировщиками, а не постоянными членами команды;

• тестирование обязательно должно быть выделено в отдельный этап, в отдельный вид деятельности;
• обязательно должно быть организовано специальное тестовое окружение (тестовая лаборатория).

Аналогичное замечание. Я против категоричности.
Можно обойтись без тестирования «штатными тестировщиками». Если в фирме один проект, то более выгодна проектная организация (как правило).
XP с успехом демонстрирует, что тестирование может не выделяться в отдельный этап, а быть частью процесса разработки.
Иногда выделенную тестовую лабораторию создать невозможно, иногда очень дорого.

3. Функциональное (ручное) тестирование
4. Регрессионное (автоматизированное) тестирование

Некорректное использование различных способов группировки. А что не может быть функционального регрессионного тестирования? Или ручного не функционального?

Основной вид тестирования, направленный на проверку всех требований Заказчика.

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

Цель плана тестирования — обеспечить полноту процесса тестирования.

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

Общее количество тестов / общее количество требований. Измерение тестового покрытия показывает плановое тестовое покрытие.

Видимо должно быть «Количество требований, на которые есть тесты/ общее количество требований». Но и в этом случае метрика будет не совсем корректной. Как быть с требованиями, полноту тестирования, которых можно обеспечить только группой тестов? Впрочем, это очень сложный вопрос.

[barancev]

И еще. Словосочетание «Тестирование требований» - устоявшийся оксюморон.

Это почему оксюморон, если не секрет?

[SALar]

Это почему оксюморон, если не секрет?

Я так понимаю, что по первому вопросу возражений нет.

.

Из определения тестирования:
Теситрование - выполнение программы с ...

Хотя действительно можно ничего не менять.

[Guriy]

Что-то никак понять не могу

повторно появляются новые ошибки

[Kaluga]

Такие затраты бывают внутренними и внешними: ..., внешние — уже отправленный продукт (простои, затраты на восстановление, сопровождение и поддержку)

Что это Вы забыли чуть ли не самое главное - возмещение ущерба заказчика? Если, например, Боинг с вашим ПО рухнет [по Вашей вине], затраты на сопровождение и поддержку Вам покажутся копеечными.
Или банк переведет кучу денег не туда?

[dlg99]

Это почему оксюморон, если не секрет?

Из определения тестирования:
Теситрование - выполнение программы с ...

white box testing - тоже оксюморон?

[barancev]

Это почему оксюморон, если не секрет?

Из определения тестирования:
Теситрование - выполнение программы с ...

Да, пожалуй. При таком определении тестирования получается оксюморон. Более честно, действительно, говорить про анализ требований.

А с white box testing все в порядке, не путать его со статическим анализом кода!

[NewTester]

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

Работать без выходных??? Это уж слишком... Я бы такого руководителя рекомендовать друзьям не стала - живодер он.

[Nadezhda]

Наверняка имелось в виду работать так, чтобы не было необходимости работать в выходные... Хотя формулировка, может быть, и не самая удачная

[van]

Коллеги, спасибо большое за ваши замечания и комментарии!

Отдельное спасибо Сергею за его развернутую критику!

Обязательно учту при доработке статьи.

Правда, от категоричности и ряда формулировок относительно видов тестирования не откажусь

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

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

Начиналось все здесь: http://forums.softwa...?showtopic=4304

Что касается работы в выходные, то, естественно, речь идет именно о том, как эту самую работу в выходные избежать, а потрать их на что - то более приятное