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

[barancev]

"If our goal is to show the absence of errors, we will find very few of them"
"If our goal is to show the presence of errors, we will discover a large number of them"
-- Bertran Mayer, 1979

Вопрос только в том, а надо ли искать ошибки, есть ли это основная цель?
Или это только побочный продукт деятельности по обеспечению качества?

[barancev]

"Дефекты. Основополагающие артефакты процесса тестирования".
-- цитата из статьи Автоматизация процесса тестирования при помощи методологии и инструментальных средств IBM Rational

Итересно, что получится, если дефекты положить в основу тестирования? :blink:

[Dmitry_NJ]

Итересно, что получится, если дефекты положить в основу тестирования? :blink:

"If our goal is to show the presence of errors, we will discover a large number of them" :D

[barancev]

What You Measure Is What You Get, said Harry Robinson

[Green]

Итересно, что получится, если дефекты положить в основу тестирования? :blink:

Получится тестирование с акцентом на поиск дефектов.

:)

[Case]

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

[Case]

Вопрос только в том, а надо ли искать ошибки, есть ли это основная цель?
Или это только побочный продукт деятельности по обеспечению качества?

Это основной продукт деятельности по тестированю.

Исканием ошибок обеспечение качества по-моему немного не занимается.

[Green]

В "радикальной" литературе я встречал мнение, что если тестировщик не находит баги, то он зря проедает свой хлеб.

Как вы думаете, правильно?
:P

[Viktor]

Программист, предположим, за две минуты найдет в чужом коде пару ошибок, которые никогда не приведут к дефектам и что, отбирать хлеб у тестеров? Он стал круче (выше сильнее умнее)? Может, всех тестеров повыгонять и набрать пару гуру программирования?
Если я правильно понял Алексея, он определяет цель тестирования как поиск дефектов в наиболее значимых функциях.
А дефект - это не ОШИБКА и даже не ее присутствие.

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

[barancev]

Вопрос только в том, а надо ли искать ошибки, есть ли это основная цель?
Или это только побочный продукт деятельности по обеспечению качества?

Это основной продукт деятельности по тестированю.

Исканием ошибок обеспечение качества по-моему немного не занимается.

Хорошо, сформулируем проблему по другому.

А нужна ли вообще деятельность по тестированию, если её цель -- ошибки искать? Кому они нужны?

Ведь если деятельность по обеспечению качества эффективно достигает своей цели без тестирования, то зачем его выполнять?

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

Исканием ошибок обеспечение качества по-моему немного не занимается.

В вышедшем недавно выпуске 2 рассылки "Тестирование ПО" автор приводит наименование "QA Engineer" в качестве синонима наименованию "тестировщик". Неувязочка получается :)

[Green]

Ведь если деятельность по обеспечению качества эффективно достигает своей цели без тестирования, то зачем его выполнять?

А кто сказал, что деятельность по обеспечению качества эффективно достигает своей цели без тестирования?

:P

[Green]

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

Совершенно верно!
Но как подсчитать, сколько ошибок осталось?

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

[Viktor]

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

Совершенно верно!
Но как подсчитать, сколько ошибок осталось?

Много нашли - мало осталось и наоборот
Мало нашли - много осталось

[Case]

А нужна ли вообще деятельность по тестированию, если её цель -- ошибки искать? Кому они нужны?

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

Ведь если деятельность по обеспечению качества эффективно достигает своей цели без тестирования, то зачем его выполнять?

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

В вышедшем недавно выпуске 2 рассылки "Тестирование ПО" автор приводит наименование "QA Engineer" в качестве синонима наименованию "тестировщик".

http://subscribe.ru/...9/14100442.html
"Кстати говоря, использование термина QA Engineer в данном контексте не совсем верно, так как оно исходит из ошибочного отождествление терминов тестирование и обеспечение качества (quality assurance). Тестирование является одним из проявлений обеспечения качества."
Синоним то синоним, однако не одно и тоже :)

Алексей, что-то вы такое задумали ;)

[Case]

Но как подсчитать, сколько ошибок осталось?

Есть статистика - на сколько строк кода сколько ошибок в среднем допускается.
Пусть приложение - 1000 строк. Пусть статистика говорит что в нём должно быть 10 ошибок. Нашли 4. Предположительно в коде их ещё 6. Грубо, конечно, но где-то так.


Если есть время на настолько глубокое тестирование - я вам завидую белой завистью.

[Guriy]

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

мои пять копеек:
именно так , как хотел пользователь

[Guriy]

Но как подсчитать, сколько ошибок осталось?

Есть статистика - на сколько строк кода сколько ошибок в среднем допускается.
Пусть приложение - 1000 строк. Пусть статистика говорит что в нём должно быть 10 ошибок. Нашли 4. Предположительно в коде их ещё 6. Грубо, конечно, но где-то так.


Если есть время на настолько глубокое тестирование - я вам завидую белой завистью.

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

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

[Green]

To Guriy

В принципе, подход понятен. Но он весьма спорен.

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

Из приведенного выше описания, я понял, что Вы предполагаете (допускаете) - какое количество ошибок МОЖЕТ быть на проекте.

Внимание вопрос!
Как Вы определяете СТЕПЕНЬ отличия (сильно или не сильно), если часть данных в формуле береться на основании предположения?
B)

[barancev]

Ведь если деятельность по обеспечению качества эффективно достигает своей цели без тестирования, то зачем его выполнять?

А кто сказал, что деятельность по обеспечению качества эффективно достигает своей цели без тестирования?

Не знаю кто сказал. Я такого не говорил :)

[barancev]

Но как подсчитать, сколько ошибок осталось?

Есть статистика - на сколько строк кода сколько ошибок в среднем допускается.
Пусть приложение - 1000 строк. Пусть статистика говорит что в нём должно быть 10 ошибок. Нашли 4. Предположительно в коде их ещё 6. Грубо, конечно, но где-то так.

Неправда, осталось всё равно 10! :)
Ведь количество строк кода не уменьшилось, а наука говорит, что... Ну, Вы сами знаете, что она говорит.