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

[van]

Ситуация с документацией на этапе проектирования и разработки тестов достаточно прояснилась.

Теперь меня очень сильно мучает вопрос с документацией на этапах выполнения тестов, оценки результатов и т.п. Т.е. Речь идет об отчетности по результатам тестирования.

Поделитесь пожалуйста опытом в этой области.

[van]

Что - то тема не возимела успеха :)

[Case]

Даю совет :)
Вопрос поделитесь опытом не вызывает энтузиазма. ВОПРОСА нет.

М ведь сюда не просто рассказывать приходим?

Попробуйте переформулировать сам запрос - вопросы должны быть.

[Mike]

Если пользоваться инструментами управления процессом тестирования (такими, как Test Director (Mercury) или Rational Test Manager), документирование и снятие метрик происходит автоматически. Если у Вас нет этих или подобных инструментов, советую почитать Rational Unified Process (там всё это подробно описано).

Если же в двух словах, то документы по исполнению следующие:

1) Логи. Заполняются тестерами при выполнении тестов. Содержат ссылки на пройденные тесты, дефекты (с указанием, на каком шаге какого теста они найдены). Один лог обычно содержит либо один прогрон одного теста, либо один прогон всех тестов, назначенных на данного тестировщика (в рамках одного билда).

2) Отчёт о тестировании. Составляется QA Managerом из логов. Содержит ссылки на логи, статистику по каждому пройденному тесту, статистику по циклу тестирования в целом, метрики.

Подходы к организации этих документов зависят от организации workflow тестирования.

[van]

Спасибо за совет.

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

Короче говоря, что хотят, то и делаем :)

[Viktor]

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

Какие, например?
(Просто интересно, в моем случае просто спрашивают: "Ну что, готово?" :))

[van]

Например:
1. Количество ошибок различной классификации для задачи (иногда требуется количество итераций открытия - закрытия ошибки)
2. Количество ошибок в разрезе конкретных разработчиков
3. Количество ошибок, исправленных и нет на конкретный момент времени (например, накануне релиза)
и т.п.

[barancev]

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

Какие, например?
(Просто интересно, в моем случае просто спрашивают: "Ну что, готово?" :))

Хм. Не пристало так делать компании, которая свято блюдёт стандарты качества процессов :P

[barancev]

Я вам как менеджер (не топ, конечно, но всё таки :)) скажу -- плевать начальство хотело на то, сколько вы ошибок нашли! Лучше вообще не надо было их делать, не пришлось бы искать и исправлять. Что действительно важно -- сколько их осталось и как часто они будут встречаться, когда систему выпустят в поле. Докажите, что продукт качественный. Покажите, что ВЫ сделали для повышения качества.

А регистрировать ошибки нужно не для того, чтобы про них начальству сообщать, а для того, чтобы их анализировать и в следующий раз не делать!

[Viktor]

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

Какие, например?
(Просто интересно, в моем случае просто спрашивают: "Ну что, готово?" :))

Хм. Не пристало так делать компании, которая свято блюдёт стандарты качества процессов :P

Алексей, разверните мысль, расскажите, что пристало адептам стандартов качества процессов?

Я вам как менеджер (не топ, конечно, но всё таки ) скажу

Желаю Вам добраться и до топ.

[Green]

Что действительно важно -- сколько их осталось и как часто они будут встречаться, когда систему выпустят в поле.

Вообще то, данное утверждение очень спорно.
B)

Не возможно доподлинно определить количество оставшихся ошибок. Можно только предположить.

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

Так что, как ни крути, а показатель найденных ошибок играет важную роль.

:rolleyes:

[Green]

А регистрировать ошибки нужно не для того, чтобы про них начальству сообщать, а для того, чтобы их анализировать и в следующий раз не делать!

А вот с этого места можно поподробнее?

Полностью согласен, что данный вид коллекционирования багов очень полезен.

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

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

Существует ли у кого-нибудь на предприятии такой вид деятельности? Может кто-нибудь подскажет литературу на этот счет?

Спасибо.

[barancev]

Что действительно важно -- сколько их осталось и как часто они будут встречаться, когда систему выпустят в поле.

Вообще то, данное утверждение очень спорно.
B)

Не возможно доподлинно определить количество оставшихся ошибок. Можно только предположить.

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

Так что, как ни крути, а показатель найденных ошибок играет важную роль.

:rolleyes:

Что ж тут такого спорного. Представьте себе, что Вы подаёте отчёт не начальнику, а непосредственно клиенту.
"За истекший период мы разработали 100000 строк кода и обнаружили в них 1000 ошибок, из них 900 исправлены, а ещё 100 пока нет".

Нужна клиенту такая информация? Нет, не нужна. Он в ответ на такое заявление спросит: ну хорошо, нашли, исправили, а работать-то будет?

Конечно, Сергей, Вы правы, сосчитать количество ошибок, которые остались невозможно. И столь же правы, что можно оценить. Для этого у Вас есть история прошлых проектов. Да, при оценке можно использовать количество найденных и исправленных ошибок как одну из метрик. Но эта метрика -- внутренняя. Она не пригодна для рапортов высокому начальству.

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

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

[van]

Так вот, меня давно мучает вопрос, как можно это организовать?

Об организации какого процесса идет речь?

[barancev]

А регистрировать ошибки нужно не для того, чтобы про них начальству сообщать, а для того, чтобы их анализировать и в следующий раз не делать!

А вот с этого места можно поподробнее?

Полностью согласен, что данный вид коллекционирования багов очень полезен.

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

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

Существует ли у кого-нибудь на предприятии такой вид деятельности? Может кто-нибудь подскажет литературу на этот счет?

Спасибо.

Сергей, кто из нас работает в организации, имеющей CMM level 5, я или Вы? :) Это я у Вас должен спрашивать совета и учиться, как организовать post mortem анализ проекта, в том числе анализ выявленных в процессе разработки дефектов, особенно в большой организации.

Мы умеем делать это в рамках проекта. Сергей, я думаю, тоже умеет. Как выйти на уровень организации -- к сожалению, у меня такого опыта нет.

[Case]

Покажите, что ВЫ сделали для повышения качества.

Алексей, я конечно зануда, но я всё-таки уточню :)

Какое отношение найденных или НЕ найденных ошибок имеет к качеству ПО? ;)

ХИНТ: мерседес - машина качественная? О каких ошибках идёт речь?

[barancev]

Покажите, что ВЫ сделали для повышения качества.

Алексей, я конечно зануда, но я всё-таки уточню :)

Какое отношение найденных или НЕ найденных ошибок имеет к качеству ПО? ;)

ХИНТ: мерседес - машина качественная? О каких ошибках идёт речь?

Количество найденных -- абсолютно никакого. А оценка количества оставшихся таки какое-никакое имеет.

Я говорю -- покажите, что ВЫ сделали для повышения качества. Тогда начальство поймёт, что ВЫ работали не зря. Что без ВАШЕЙ работы продукт был бы менее качественным.

Какие средства убеждения при этом удастся задействовать -- зависит и от начальника, и от многих других факторов. Некоторые скушают с удовольствием отчёт о количестве найденных ошибок и будут гордиться их обилием. Другой поймёт, что гордиться-то нечем и, подобно Станиславскому, скажет -- "не верю!", тогда придётся привлекать другие средства убеждения.

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

По поводу мерседеса -- если тестировщик скажет, что устранено 100 проблем с автоматическим центральным замком, это хорошо или плохо? А если он скажет, что, по его оценке, в выпускаемом замке 1 раз на 1000000 использований будет происходить сбой -- это совсем другое дело.

Буквально сегодня я увидел в блоге Джоанны Ротман замечательную мысль: нужно оценивать не то, что уже сделано, а то, что впереди. Потому что то, что уже сделано изменить уже нельзя, а то, что впереди, ещё можно улучшить. А оценки того, что сделано, можно и нужно использовать для этого прогнозирования, тогда они приобретают смысл.

[Viktor]

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

[barancev]

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

Вы что, в самом деле искренне верите, что выпущенные вами продукты не содержат ни одной проблемы?

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

Зачем прятать голову в песок? Если в прошлом проекте плотность оставленных ошибок была, скажем, xxx, а в этом проекте в процессе ничего не поменялось, можно предположить, что она тоже останется около xxx. Не надо сознательно оставлять ошибки в программе, они там и без того останутся. Зачем усугублять проблему?

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

[Undi]

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

Интересно, и как же Вы приходите к выводу, что такой вероятности уже нет?