?

Log in

November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

Миф о документации, продолжение

Posted on 2011.06.18 at 23:06

Comments:


миххон
mihhon at 2011-06-19 17:13 (UTC) (Link)
а теперт правильный ответ на вопрос а зачем нам тогда тестировщики/QA? В чем их роль?

1. любая программа содержит ошибки
2. закон распределения времени до выявления ошибки должен напоминать закон Пуассона http://swsys.ru/index.php?page=article&id=958 , http://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D1%81%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%9F%D1%83%D0%B0%D1%81%D1%81%D0%BE%D0%BD%D0%B0
3. так что даже полусознательно тыкая по кнопкам, тестеры выявляют некую долю дефектов (и чем лучше план тестов, тем больше они их выявят)

так что правильный ответ: они снижают персональные инвестиции манагеров в вазелин посредством увеличения корпоративных инвестиций в QA
Lost In Paradox
localstorm at 2011-06-19 17:19 (UTC) (Link)
Не факт, что игра стоит свеч, но даже если все действительно так, что чтобы натренировать их нужно аллоцировать разработчиков, потому что у них сосредоточено знание. А это значит пролонгация сроков деливери. А это значит увеличение персональных инвестиций в вазелин :)
Gaperton
gaperton at 2011-06-19 17:32 (UTC) (Link)
Пункт 2, к сожалению, ошибочен.

У ошибок разных классов сильно разное респределение времени их обнаружения, зависящее от процесса разработки.

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

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

Статья датирована 99 годом, и не ссылается на исследования Carnegie-Mellon SEI, в результате которых были экспериментально установлены упомянутые мной закономерности. Ключевые слова - PSP/TSP, Watts Humphrey.
миххон
mihhon at 2011-06-19 17:47 (UTC) (Link)
хорошо

и на что похожа кривая плотности вероятности суммарного количества выявленных ошибок от времени согласно PSP/TSP, Watts Humphrey ?

программа, как и, скажем, телевизор, представляет из себя сложную систему

количество отказов (всех типов) в партии телевизоров на единицу времени подчиняется закону Пуассона

чем должен отличаться принципиально закон распределения количества найденных ошибок в программе на единицу времени?
Gaperton
gaperton at 2011-06-19 17:53 (UTC) (Link)
> и на что похожа кривая плотности вероятности суммарного количества выявленных ошибок от времени согласно PSP/TSP, Watts Humphrey ?

Понятия не имею. Так как ответ на этот вопрос не несет практической пользы, и из него полезных выводов не делается, PSP/TSP его не рассматривает. Там вместо этого корреляции ищутся между объемом кода, количеством ошибок, и потраченным на работу временем. На основе этого строится система мониторинга и предсказания качества ПО и сроков разработки. И она работает.
миххон
mihhon at 2011-06-19 18:06 (UTC) (Link)
почему же не несёт? как раз несёт

всё тестирование внутри контор, публичное бета-тестрирование как раз является выявлением дефектов, количество которых подчиняется закону Пуассона : наибольшее количество дефектов выявляется в начале
Gaperton
gaperton at 2011-06-19 18:11 (UTC) (Link)
Ок, допустим. Тока есть нюанс - дефекты имеют неодинаковую цену исправления. Нас что на самом деле интересует - их количество, или распределение совокупных затраты на их исправление?
миххон
mihhon at 2011-06-19 18:19 (UTC) (Link)
изначально это было ответом на вопрос, заданный здесь http://gaperton.livejournal.com/60632.html?thread=1621720#t1621720 : каково обоснование существования низкоквалифицированного низкооплачиваемого QA/тестировщика?

в том, что даже полусознательно тыкая по кнопкам, он выявит большое количество дефектов

так как он "низкоквалифицированный низкооплачиваемый" , то это уже хорошо

выявление более затратных в выявлении (и исправлении) дефектов переносится на пользователя :)

либо, если есть здравый смысл у руководства, наймом более квалифицированных разработчиков и т.д.
Gaperton
gaperton at 2011-06-19 18:22 (UTC) (Link)
Да вот не факт. Случайно тыкать по кнопкам и программа может. Причем, такие программы есть. Нанять одного нормального QA и задействовать такую программу будет дешевле.
hedgeov
hedgeov at 2011-06-19 18:40 (UTC) (Link)
Очевидно природой ошибок. Отказ какого-то компонента телевизора сильно отличается от ошибки в программе хотя бы тем, что на другом телевизоре этот компонент не откажет, а программа сто пудов в этом же месте упадет.
миххон
mihhon at 2011-06-19 18:43 (UTC) (Link)
сто пудов в этом же месте упадет

неправда: вы писали многопоточный код с ошибками ? он падает в разных местах :)
hedgeov
hedgeov at 2011-06-19 18:44 (UTC) (Link)
Каюсь -- не писал. :)
Previous Entry  Next Entry