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

[Jazzyekim]

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

[Green]

Никто никогда не тестит AutoCAD за один раз. Это процесс итеративный. За первую итерацию кусочек, потом второй и так далее.

Но тестировать можно бесконечно. Сколько есть времени, столько можем тестировать и то, до конца так и не прогоним все возможные варианты тестов.

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

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


Выписали все функции, определили вес (критичность) каждой из них, выстроили очередь - что и когда тестировать первым, что вторым и т.д. Посмотрели на график работ и определили, что у нас есть время что бы тщательно протестировать функции с 1-й по 20-ю. Остается время что бы не очень тщательно, но протестировать функции с 21-й по 50-ю. После этого есть еще время что бы просмотреть функции с 51-й по 100-ю. А вот на функции с 101-й и по 10.000-ю времени уже нет. Но так как они менее важны чем все выше перечисленные, то и хрен с ними.


Ну... или примерно так.
Могут быть вариации.

[Nadya Kochetova]

Смотря , что включаете в "прогон одного цикла тестирования программного продукта". Планирование? Разработку тестов? Развертываение и поддержку тест окружения (простите, не знаю какой термин употребляется environment)? стресс тестинг включаете? объем тестинг включаете?

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

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

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

если юз-кейсов нет, используем разбивку функциональности на тест-объекты. уровень глубины определяем сами. мы не пользуемся Functional Point Analysis о котором писал Green как мне кажется.

Ошибаемся ли мы? да, но стараемся.

[Green]

если юз-кейсов нет, используем разбивку функциональности на тест-объекты. уровень глубины определяем сами. мы не пользуемся Functional Point Analysis о котором писал Green как мне кажется.

Я привел всего лишь пример. Важно понять, что объем работ ВСЕГДА больше имеющихся ресурсов. Поэтому нужно выработать принцип, по которому происходит планирование работ. В дальнейшем его можно корректировать или менять на новый, но в этом случае действия будут разумными и обоснованными.

[GoldenBoy]

Хочу напомнить про одно золотое правило в планировании временных ресурсов в целом. Время, которое у Вас получилось при расчётах необходимо умножить на Pi (3,14) - вот это и будет приблизительно то время, которое реально будет затрачено с учётом внештатных ситуаций, которые обязательно возникают.

[Alfa]

Хочу напомнить про одно золотое правило в планировании временных ресурсов в целом. Время, которое у Вас получилось при расчётах необходимо умножить на Pi (3,14) - вот это и будет приблизительно то время, которое реально будет затрачено с учётом внештатных ситуаций, которые обязательно возникают.

Тут вы не правы, домножать конечно надо, но на e (2.718281828..) .

[GoldenBoy]

Хочу напомнить про одно золотое правило в планировании временных ресурсов в целом. Время, которое у Вас получилось при расчётах необходимо умножить на Pi (3,14) - вот это и будет приблизительно то время, которое реально будет затрачено с учётом внештатных ситуаций, которые обязательно возникают.

Тут вы не правы, домножать конечно надо, но на e (2.718281828..) .

Вероятно, это всего лишь различие в источниках информации и разных подходах к планированию. Эти числа можно и округлить до 3, разница не настолько существенна, особенно в рамках небольших по продорлжительности проектов :)

[Green]

Хочу напомнить про одно золотое правило в планировании временных ресурсов в целом. Время, которое у Вас получилось при расчётах необходимо умножить на Pi (3,14) - вот это и будет приблизительно то время, которое реально будет затрачено с учётом внештатных ситуаций, которые обязательно возникают.

Тут вы не правы, домножать конечно надо, но на e (2.718281828..) .

Вероятно, это всего лишь различие в источниках информации и разных подходах к планированию. Эти числа можно и округлить до 3, разница не настолько существенна, особенно в рамках небольших по продорлжительности проектов :)

Один из руководителей проектов жаловался мне, что он взял эстимации, сделанные разработчиками по своим кускам работ, умножил их на два, потом еще накинул сверху 30% и они все равно не уложились.



Подозреваю, что не в коэффициентах дело.

[GoldenBoy]

Один из руководителей проектов жаловался мне, что он взял эстимации, сделанные разработчиками по своим кускам работ, умножил их на два, потом еще накинул сверху 30% и они все равно не уложились.
:crazy:


Подозреваю, что не в коэффициентах дело.
:acute:

Мы говорили лишь о методах планирования и расчёта времени. Если интересно, то могу порекомендовать книжку "Мифический человеко-месяц" Фредерика П. Брукса - здесь можете найти много интересного и полезного по планированию и оценке проектного времени. Но даже если расчёты верны, то это не гарантирует, что вы уложитесь в эти рамки. Дело ещё и в других проблемах - распределение нагрузки на персонал, наличие кадров и ресурсов на проекте, активность самого персонала в работе и многое другое, что является ещё одной серьёзной головной болью менеджеров.
Из своего личного опыта могу сказать, что лишь малая часть проектов укладывается в запланиированные сроки (и не потому, что были неправильные расчёты!). Насколько я знаю, всего 9-10% проектов укладывается в запланированные сроки.
Так что вопрос о том, почему проект не укладывается в запланированные сроки - это уже несколько иная тема, чем планирование этих сроков.

[Oldman]

...
Насколько я знаю, всего 9-10% проектов укладывается в запланированные сроки.
...

... это потому что большинство проектов начинают люди, которые ничего в этом не понимают

[Case]

...
Насколько я знаю, всего 9-10% проектов укладывается в запланированные сроки.
...

... это потому что большинство проектов начинают люди, которые ничего в этом не понимают

Да ну прям-таки. Многомиллионная отрасль безмозглых бизнесменов, которые нанимают безмозглых ПМ-ов и те валят проекты налево и направо за всё более растущую зарплату. Ага. Разработчики и тестеры, которые ни в грош свои слова про сроки не ставят, тут абсолютно не при чём. Главная беда это дураки, дороги и тупые ПМ-ы. Угу.

[Oldman]

...
Насколько я знаю, всего 9-10% проектов укладывается в запланированные сроки.
...

... это потому что большинство проектов начинают люди, которые ничего в этом не понимают

Да ну прям-таки. Многомиллионная отрасль безмозглых бизнесменов, которые нанимают безмозглых ПМ-ов и те валят проекты налево и направо за всё более растущую зарплату. Ага. Разработчики и тестеры, которые ни в грош свои слова про сроки не ставят, тут абсолютно не при чём. Главная беда это дураки, дороги и тупые ПМ-ы. Угу.

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

На самом деле интересная тема для дискуссии, но думаю здесь (в данном топике) это будет офтоп

[greesha]

На самом деле интересная тема для дискуссии, но думаю здесь (в данном топике) это будет офтоп

Тема архиважная и архинужная! А где это будет не оффтоп?

[Oldman]

На самом деле интересная тема для дискуссии, но думаю здесь (в данном топике) это будет офтоп

Тема архиважная и архинужная! А где это будет не оффтоп?

Просто нужно создать новую тему: Причины несвоевременного завершения проектов (ну или как-то так)

[greesha]

Тема архиважная и архинужная! А где это будет не оффтоп?

Просто нужно создать новую тему: Причины несвоевременного завершения проектов (ну или как-то так)

Это понятно, но в каком из разделе?

Форум тестировщиков ПО и QA? На самом деле, тема выходит за рамки тестирования и QA.
Business Service Management? Само это название отпугивает...
Инструментальные средства разработки, Работа, Образование - всё не то

[Case]

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

На самом деле интересная тема для дискуссии, но думаю здесь (в данном топике) это будет офтоп

Нормальная тема :)

Планирование это часть дисциплины управления проектами, верно? Есть ещё ресурсы - то есть люди.

Возьмём тебя, дадим тебе 5-6 солдат и задачу штурмовать здание: терористы, к примеру захватили булочную со стратегическим запасом булочек. План ты составил отличный. Расставил людей, снайперов посадил, спец.технику заказал, которая дверь высадит в нужный момент, по секундам всё расписал, сам встал для поддержания боевого духа рядом с людьми в строй, но так чтобы видеть всю картинку. И чудо - до тех пор пока ты закончил планировать обстоятельства не изменились, булочки не сьели, никто не рванул сдуру чеку и бронник с груди не сорвал. И терористы у нас загляденье просто - сидят как мышки, ждут, значит.

Ты по рации скомандовал "вперёд" и началось.

Машина высадила не ту дверь, ну ошиблись просто, потому что водителя взяли недавно, он до этого карьерным Белазом рулил.

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

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

Рванули вы строить пирамиду из тел, по которой должен кто-то самый первый в окно ввалиться. Ему конечно наваляют, но надо. Тут как-то все застеснялись, никому геройская слава нафиг не надо. Хорошо лестница нашлась у кого-то (со старой работы, то есть из десанта, прихватил). Словом ты влез, тебе первому прикладом и приложили, остальные кое как терористов отогнали хаотической стрельбой, тебя за шиворот отволокли и со словами «командир, да мы тут счас всех!..»... начали обсуждать каким бы это им порядком лучше из комнаты на врага вывалить, колонной или по модному как в кино и западных журналах – гибкими командами по двое-трое? Пока спорили нас огнём неприятельским с самому окну оттеснили.

Ввалились терористы в комнату. Шум, гам – стратегическими булочками забросали. Того и гляди выбросят из окна, а отступать некуда, последний из твоих бойцов лестницу возьми да откинь от стены. Ты на него смотришь как на врага народа, а он руками разводит: у нас так всегда делали, когда в окна лазили – бывший командир говорил что это психилогически верно и команду сближает. Правда мы там внизу одного оставляли – он её если что обратно приставлял...

Вы бы сейчас слезли, а снайперы всех терористов через окна того... А так вы только своим же мешаете работать, прикрываете терористов. Бардак.

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

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

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

Заменим терористов на клиентов, а своих бойцов и снайперов на девелоперов и тестеров. Да, дядька в спец.машине это DBA, ну а ты ПМ.

Что с тобой как с ПМ-ом делать-то будем?

[Oldman]

Стоп, Слав, почему сразу что делать.

если сначала:

Водитель не в ту дверь въехал, а точно ли он знал в какую ехать, убедился ли командир в правильном понимании задачи?

Лом не захватили - а почему не предусмотрели запасной вариант, не ПМ ли должен был подумать?

А чего это ПМ первым полез, а как же: но так чтобы видеть всю картинку?

дальше сложно описывать - уже это бы изменило картинку боя.

...План ты составил отличный...

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

Что с тобой как с ПМ-ом делать-то будем?

Ну это вопрос уже к менеджеру ПМов.

Я бы поставил вопрос по другому: Что я теперь как ПМ делать буду?

[Case]

Формально виноват ПМ?

[Oldman]

Формально виноват ПМ?

на какое слово логическое ударение?

и смысл искать виноватых? лучше подумать о том что сделать чтобы такое не повторилось

[Case]

И я про тоже. Виноваты не те кто берётся делать проекты не понимая как надо, систем не работает практически6 нет взаимной отвественности перед менеджментом, владельцами бизнеса и специалистами. Кабы такой трёхстронний комитмент что "всё будет офигенно" был, тут же встал бы вопрос "а как?".