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

[melan]

Нет, конечно же нет. По моему личному убеждению, не бывает софта свободного от багов. Если кто-то утверждает, что данный софт не содержит багов, то скорее всего их просто плохо искали.

Я предполагаю, что мы вносим 10 дефектов в систему и определяем, сколько из них нашли тестеры, не обращаяя при этом вниманеие на остальные дефекты.

[DrVal]

IMHO это и есть баловство.

Отдаем продукт с 10 внесенными багами пользователям.

90% продуктом довольны, 10% прислали по нескольку фиче-реквестов и объявили их критичными багами. 10 внесенных багов не волнуют никого.
Какая разница сколько из них не нашли тестировщики?

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

[Yury]

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

1) Правильно ли я понял, что для вас главное это определить "эффективность" работы тестеров, а качество продукта совсем не важно?

2) Я надеюсь, что Вы понимаете, что тестеры не создают дефекты.
Все дефекты создаются программистами.
Если Вы начнёте противопостовлять тестеров программистам - то это самый надёжный способ разрушить вашу команду и загнать ваш продукт в тупик, из которого не так то просто будет и выбраться.

3) А какого гения вы наймёте, чтобы 10 посеяных дефектов соответствовали вашим настоящим ошибкам (включая и ещё не найденные)?

[Darkus]

Есть мнение, что любые коэффициенты критичности - это баловство.

Есть мнение, что если эти коэффиценты имеют место быть, значит взяты они не с пустого места и кому то они действительно нужны :)

По поводу данного коэффицента... смотрите сценарий.
Менеджер по тестированию (скажем так для простоты) составил план тестирования.
Ведущий тестировщик написал по этому плану test-case- ы и вместе с тестировщиками прогнал их. Ошибок не обнаружено. Сдали, выпили, закусили.

Теперь к нам приходят ошибки от заказчика. Приходят и приходят, заказчик недоволен. Мы вначале раз правим, два правим, а потом думаем... а не пора ли прекращать это безобразие. Садимся, берём карандаш и бутылку, считаем количество ошибок после релиза.
Смотрим и приходим к выводу (посовещались, покурили), что всё же много ошибок от заказчика(ов) приходит на наш взгляд (х%- зачот, у% - в топку продукт со всей командой)
Начинаем выяснять - а почему наш заказчик недоволен, откуда "растут ноги".
Выписываем ошибки, открываем план тестирования и смотрим туда... ага...

Ошибка 1. Вот этой ошибки можно было избежать, просто неподумали, что нужен вот такой и такой test-case. Делаем выводы, учитываем на будущее...
Ошибка 2. Тестер Вася не прогнал почему то test-case, который обязательно бы выявил эту ошибку. Судебные разбирательства откладываем на первый раз, потому что Вася хороший тестировщик и тоже имеет право на ошибку (проводим разъяснительные беседы).
Ошибка 3. Ну не судьба... Заказчик "маньяк", но!!! тем не менее, вносим эту ошибку в баг трекер, правим и возможно пишем отдельный Test-case.
Ошибка 4. Заказчик не прав, это не ошибка, это фича его придуманная. А в принципе, он просто сам не знает чего хочет. Ведь этого в требованиях не было оговорено. Значит правим требования, берём планы правим(или ваще!!! пусть он катится со своими проблемами в Бабруйск жывотное!!! - так и запишем - пофиксено в мозгах заказчика :) ).
Ошибка 5. Похоже, что наконец-то!!! выловлена довольно трудновоспроизводимаДурацка ошибка!!! УРА заказчику, фуршет.

Вопрос. А если не считать эту метрику, то жить можно? Да можно. Приходят ошибки, ну и пусть приходят. Только вот вопросы...
1. А будет ли видно - улучшается ли наш процесс в целом? Нужно ли как то реагировать?
2. А на каких основаниях нужно будет расследования устраивать по ошибкам? На плохом\хорошем настроении менеждера\руководства или по циферкам?
3. А премии отделу тестирования за малый процент ошибок найденный заказчиком с каких мотиваций давать? (ошибки ведь были таки, но и их мало, а сколько мало? А я не помню, заказчик всегда жаловался на что-то, останемся без премии)
4. Кто-нибудь вообще будет этим всем процессом заниматься, если процесс не поставлен и сравнивать не с чем?

Ну список можно продолжить :) Всё зависит от того - нужно это вам или нет.
Если заказчик и так доволен жизнью, и не портит её вам, то усё будет хорошо.

[Netrat]

Например, на этапе разработки обнаружено 4000 багов на 1000000 строк кода.

Постойте, а при чём тут количество строк кода? Оценивать кол-во ошибок на строк кода может руководитель разработчиков, но не тестирование.

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

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

Вышел релиз, не важно Альфа или Бета, или даже final - заявленная фунциональность по идее должна работать без ошибок.

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

За время тестирования заказчиками (приемочные испытания) обнаружено еще 200 багов. Собственно вот эти 200 багов - это катастрофа или допустимо?

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

Но положим, все найденные заказчиком баги оказались важными или даже критичными. В таком случае процент серёжных дефектов, обнаруженных после сдачи проекта будет равен (200/4000) * 100% = 5%.

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