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

[barancev]

На тестирование может расходоваться в зависимости от типа системы от 10 до 90% общего времени проекта,это зависит от множества факторов. Но среднестатистический показатель -- 40%, можно на него ориентироваться.

А если для тестирования идёт просто параллельная разработка второй аналогичной системы (DoD) то и все 100%

?????
Я имею в виду проценты от общего бюджета проекта, а не проценты по отношению к затратам на разработку. Мы реально встречались с ситуациями в авионике, когда на тестирование тратилось около 90% всех денег проекта, то есть на разработку -- менее 10%, тестирование было в 10 раз дороже. (Правда, по времени там соотношение было не такое страшное, как по деньгам, но тоже весьма впечатляющее).

По моему мнению, классическое среднее распределение примерно такое: 40% -- проектирование, 20% -- разработка, 40% -- тестирование (включая модульное тестирование, выполняемое разработчиками).

[Case]

Ну вопрос то звучал:

сколько времени умные люди тратят на тестирование

Приведённый пример: по времени бывает что и 100% - то есть столько же как и на разработку. Наверное и больше бывает, если вариантность большая.

[EL_GE]

Вопрос еще следующего содержания:
Если я в процессе тестирования выявляю несоответствие или баг, то какие должны быть мои действия
1. Бежать к разработчику и трубить ему об этом.
2. Или же провести все тесты до конца, написать отчет по ним (описать несоответствия) и с этим отчетом к начальству.

Что эффективнее и правильнее?

p.s. Прошу сильно не обижаться на мои вопросы, кому-то они просто покажутся нелепыми и ответ на которые очевиден, ...но тем не менее тема форума ведь так и называется "Для начинающих".

[Case]

Слава, не нагнетайте обстановку и не провоцируйте панику.

Я вполне себе спокойно рекомендую что делать :)

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

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

Реально научится работать в такой ситуации нельзя. Свернуть себе набекрень представление о том, что такое тестирование да и сам процесс software development - запросто. Можно попробовать что-то менять, но я привёл физические требования к такому человеку: повторюсь - задача интересная, но толку от неё не будет. Продвинуть что-то по процессам "снизу" нельзя - это для меня стало аксиомой (чем больше смотрю, тем больше убеждаюсь).

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

Коллега EL_GE, прошу отнестись к высказанному с пониманием: проще рассказать всё такими словами (что называется "как есть"), чем весело подшучивать. Вы и сами прекрасно понимаете что проблем выше крыши и с удовольствием присоединитесь с веселящимся, будь это не ваш конкретный пример.

[barancev]

Что эффективнее и правильнее?

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

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

Накатывать на разработчика проблемы по одной или пачками -- как договоритесь, "правильнее" по одной, но на начальных этапах иногда удобно пачками, чтобы не захлестнуло.

[Case]

Рабочая схема, Алексей! Если Руководсвто идёт навстречу и не гнёт свою непонятную политику.

[barancev]

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

Да, я согласен. Это проблемы роста. Лечатся путем реорганизации. Требуют сильной поддержки со стороны руководства.

Единственное, я не согласен с тем, что лечить можно только с привлечением внешних консультантов. Я бы сказал несколько иначе -- реорганизацию может выполнить тот, кто имеет четкое представление о том, что должно получиться в результате, тот, кто имеет правильное видение будущего. Это может быть внешний консультант, может быть новый руководитель, может быть тот самый "пробивной" человек, про которого Вы упоминали.

Но если руководство сопротивляется -- шансов никаких.

[EL_GE]

Что эффективнее и правильнее?

Лучше использовать некоторую систему обмена информацией, то бишь BTS, и привязать процедуру к ней. Устно сообщать бесполезно -- забудут.

BTS...? Это что такое?

[Mad Cat]

BTS...? Это что такое?

Bug
Tracking
System

[barancev]

BTS...? Это что такое?

Bug Tracking System, это та самая БД багов, которую Вы написали. Осталось обучить всех остальных сотрудников пользоваться ею.

[EL_GE]

Понял, понял.

[Clauster]

Bug Tracking System...
http://forums.softwa...php?act=SF&f=61

[Case]

Вопрос еще следующего содержания:
Если я в процессе тестирования выявляю несоответствие или баг, то какие должны быть мои действия
1. Бежать к разработчику и трубить ему об этом.
2. Или же провести все тесты до конца, написать отчет по ним (описать несоответствия) и с этим отчетом к начальству.

Мы так делаем:
Если баг не держит дальнейшее тестирование - то просто заносим его в багтрекер и идём дальше. Если дальше идти не можем - то приоритет ставим БЛОКЕР и тут уже разработчики сами прибегают, потому ч то наш ведущий разработчик ставит всех на уши. БЛОКЕР приоритет я стараюсь с ведущим согласовывать, благо мы в пределах досягаемости голоса сидим.

[Cyclone]

Ребята, подскажите, что такое Defect life cycle. Это что-то из теории тестирования.

[Scorp-13]

А Google зачем придумали?

http://www.google.co.....ta=lr=lang_ru

http://www.osp.ru/os/1998/06/39.htm

[Cyclone]

Дякую.

[EL_GE]

Можно ли тестировать не большие программы только с помощью ручного тестирования?
Будет ли это достоверно?
Обязательно ли использовать нагрузочное тестирование или автоматическое?
Как делать правильно? В каких случаях какое тестирование нужно использовать? Испотльзовать несколько методов тестирования или пользоваться одним?

[Clauster]

Ну и вопросы... Вы бы, что ли, книжку какую-нибудь по тестированию прочитали. Или, думаете, вам тут всю теорию в форуме будут расписывать?

[barancev]

Можно ли тестировать не большие программы только с помощью ручного тестирования?

Можно.

Будет ли это достоверно?

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

Обязательно ли использовать нагрузочное тестирование или автоматическое?

Необязательно.

Как делать правильно? В каких случаях какое тестирование нужно использовать? Испотльзовать несколько методов тестирования или пользоваться одним?

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

[Case]

Ну и вопросы... Вы бы, что ли, книжку какую-нибудь по тестированию прочитали. Или, думаете, вам тут всю теорию в форуме будут расписывать?

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