Отчётность по тестированию.
#1
Отправлено 24 сентября 2004 - 06:50
Теперь меня очень сильно мучает вопрос с документацией на этапах выполнения тестов, оценки результатов и т.п. Т.е. Речь идет об отчетности по результатам тестирования.
Поделитесь пожалуйста опытом в этой области.
#2
Отправлено 05 октября 2004 - 05:57
#3
Отправлено 05 октября 2004 - 06:51
Вопрос поделитесь опытом не вызывает энтузиазма. ВОПРОСА нет.
М ведь сюда не просто рассказывать приходим?
Попробуйте переформулировать сам запрос - вопросы должны быть.
Редактор портала www.it4business.ru
#4
Отправлено 05 октября 2004 - 07:35
Если же в двух словах, то документы по исполнению следующие:
1) Логи. Заполняются тестерами при выполнении тестов. Содержат ссылки на пройденные тесты, дефекты (с указанием, на каком шаге какого теста они найдены). Один лог обычно содержит либо один прогрон одного теста, либо один прогон всех тестов, назначенных на данного тестировщика (в рамках одного билда).
2) Отчёт о тестировании. Составляется QA Managerом из логов. Содержит ссылки на логи, статистику по каждому пройденному тесту, статистику по циклу тестирования в целом, метрики.
Подходы к организации этих документов зависят от организации workflow тестирования.
Майк.
#5
Отправлено 15 октября 2004 - 08:13
Пока решил ограничиться только отчетами, необходимыми топ - менеджменту.
Короче говоря, что хотят, то и делаем :)
#6
Отправлено 15 октября 2004 - 12:55
Какие, например?Пока решил ограничиться только отчетами, необходимыми топ - менеджменту.
(Просто интересно, в моем случае просто спрашивают: "Ну что, готово?" :))
Нельзя обсуждать здесь ересь, если только мы не размышляем, как ее уничтожить.
#7
Отправлено 15 октября 2004 - 13:00
1. Количество ошибок различной классификации для задачи (иногда требуется количество итераций открытия - закрытия ошибки)
2. Количество ошибок в разрезе конкретных разработчиков
3. Количество ошибок, исправленных и нет на конкретный момент времени (например, накануне релиза)
и т.п.
#8
Отправлено 15 октября 2004 - 13:13
Хм. Не пристало так делать компании, которая свято блюдёт стандарты качества процессов :PКакие, например?Пока решил ограничиться только отчетами, необходимыми топ - менеджменту.
(Просто интересно, в моем случае просто спрашивают: "Ну что, готово?" :))
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#9
Отправлено 15 октября 2004 - 13:18
А регистрировать ошибки нужно не для того, чтобы про них начальству сообщать, а для того, чтобы их анализировать и в следующий раз не делать!
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#10
Отправлено 18 октября 2004 - 04:35
Алексей, разверните мысль, расскажите, что пристало адептам стандартов качества процессов?Хм. Не пристало так делать компании, которая свято блюдёт стандарты качества процессов :P
Какие, например?Пока решил ограничиться только отчетами, необходимыми топ - менеджменту.
(Просто интересно, в моем случае просто спрашивают: "Ну что, готово?" :))
Я вам как менеджер (не топ, конечно, но всё таки ) скажу
Желаю Вам добраться и до топ.
Нельзя обсуждать здесь ересь, если только мы не размышляем, как ее уничтожить.
#11
Отправлено 18 октября 2004 - 06:07
Вообще то, данное утверждение очень спорно.Что действительно важно -- сколько их осталось и как часто они будут встречаться, когда систему выпустят в поле.
B)
Не возможно доподлинно определить количество оставшихся ошибок. Можно только предположить.
Но что бы это сделать, нужно знать, сколько реально ошибок уже найдено на сотню или тысячу строк написанного кода.
Так что, как ни крути, а показатель найденных ошибок играет важную роль.
:rolleyes:
#12
Отправлено 18 октября 2004 - 06:16
А вот с этого места можно поподробнее?А регистрировать ошибки нужно не для того, чтобы про них начальству сообщать, а для того, чтобы их анализировать и в следующий раз не делать!
Полностью согласен, что данный вид коллекционирования багов очень полезен.
Можно выделить следующую последовательность действий, с этим связанных:
- классификация программных дефектов по какой-то системе;
- выявление характерных или часто повторяющихся ошибок;
- проведение тренингов с целью обучения разработчиков стандартным решениям, позволяющим избегать данные ошибки в будущем.
Так вот, меня давно мучает вопрос, как можно это организовать?
Причем в масштабах не одной группы разработчиков (5 - 10 человек), а в масштабах компании (100 человек и больше - много различных проектов).
Существует ли у кого-нибудь на предприятии такой вид деятельности? Может кто-нибудь подскажет литературу на этот счет?
Спасибо.
#13
Отправлено 18 октября 2004 - 07:11
Что ж тут такого спорного. Представьте себе, что Вы подаёте отчёт не начальнику, а непосредственно клиенту.Вообще то, данное утверждение очень спорно.Что действительно важно -- сколько их осталось и как часто они будут встречаться, когда систему выпустят в поле.
B)
Не возможно доподлинно определить количество оставшихся ошибок. Можно только предположить.
Но что бы это сделать, нужно знать, сколько реально ошибок уже найдено на сотню или тысячу строк написанного кода.
Так что, как ни крути, а показатель найденных ошибок играет важную роль.
:rolleyes:
"За истекший период мы разработали 100000 строк кода и обнаружили в них 1000 ошибок, из них 900 исправлены, а ещё 100 пока нет".
Нужна клиенту такая информация? Нет, не нужна. Он в ответ на такое заявление спросит: ну хорошо, нашли, исправили, а работать-то будет?
Конечно, Сергей, Вы правы, сосчитать количество ошибок, которые остались невозможно. И столь же правы, что можно оценить. Для этого у Вас есть история прошлых проектов. Да, при оценке можно использовать количество найденных и исправленных ошибок как одну из метрик. Но эта метрика -- внутренняя. Она не пригодна для рапортов высокому начальству.
Что, предположительно, сделает начальник, узнав про количество найденных ошибок? Он придёт обратно и попросит посчитать, сколько ошибок осталось в поставленном продукте, в предположении, что работали так же хорошо (или плохо), как в прошлых проектах. При этом придётся взять статистику по нескольким проектам -- количество разработанного кода, количество найденных в процессе разработки и устранённых к моменту выпуска ошибок, количество ошибок, обнаруженных после выпуска, учесть сделанные улучшения в процессе (если были сделаны), и на основании этой статистики, произведя некоторые вычисления, можно будет получить оценку количества оставшихся ошибок в новом продукте.
Так почему не сделать это заранее и не принести начальству именно эту информацию, которая жизненно необходима для того, чтобы оценить, сколько придётся дополнительно потратить на этого клиента после того, как продукт поставлен, чтобы устранять возникающие ошибки.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#14
Отправлено 18 октября 2004 - 07:16
Об организации какого процесса идет речь?Так вот, меня давно мучает вопрос, как можно это организовать?
#15
Отправлено 18 октября 2004 - 07:21
Сергей, кто из нас работает в организации, имеющей CMM level 5, я или Вы? :) Это я у Вас должен спрашивать совета и учиться, как организовать post mortem анализ проекта, в том числе анализ выявленных в процессе разработки дефектов, особенно в большой организации.А вот с этого места можно поподробнее?А регистрировать ошибки нужно не для того, чтобы про них начальству сообщать, а для того, чтобы их анализировать и в следующий раз не делать!
Полностью согласен, что данный вид коллекционирования багов очень полезен.
Можно выделить следующую последовательность действий, с этим связанных:
- классификация программных дефектов по какой-то системе;
- выявление характерных или часто повторяющихся ошибок;
- проведение тренингов с целью обучения разработчиков стандартным решениям, позволяющим избегать данные ошибки в будущем.
Так вот, меня давно мучает вопрос, как можно это организовать?
Причем в масштабах не одной группы разработчиков (5 - 10 человек), а в масштабах компании (100 человек и больше - много различных проектов).
Существует ли у кого-нибудь на предприятии такой вид деятельности? Может кто-нибудь подскажет литературу на этот счет?
Спасибо.
Мы умеем делать это в рамках проекта. Сергей, я думаю, тоже умеет. Как выйти на уровень организации -- к сожалению, у меня такого опыта нет.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#16
Отправлено 18 октября 2004 - 10:11
Алексей, я конечно зануда, но я всё-таки уточню :)Покажите, что ВЫ сделали для повышения качества.
Какое отношение найденных или НЕ найденных ошибок имеет к качеству ПО? ;)
ХИНТ: мерседес - машина качественная? О каких ошибках идёт речь?
Редактор портала www.it4business.ru
#17
Отправлено 18 октября 2004 - 10:33
Количество найденных -- абсолютно никакого. А оценка количества оставшихся таки какое-никакое имеет.Алексей, я конечно зануда, но я всё-таки уточню :)Покажите, что ВЫ сделали для повышения качества.
Какое отношение найденных или НЕ найденных ошибок имеет к качеству ПО? ;)
ХИНТ: мерседес - машина качественная? О каких ошибках идёт речь?
Я говорю -- покажите, что ВЫ сделали для повышения качества. Тогда начальство поймёт, что ВЫ работали не зря. Что без ВАШЕЙ работы продукт был бы менее качественным.
Какие средства убеждения при этом удастся задействовать -- зависит и от начальника, и от многих других факторов. Некоторые скушают с удовольствием отчёт о количестве найденных ошибок и будут гордиться их обилием. Другой поймёт, что гордиться-то нечем и, подобно Станиславскому, скажет -- "не верю!", тогда придётся привлекать другие средства убеждения.
Прогноз количества оставшихся ошибок -- это ВАША предварительная оценка качества, измеренная в количестве проблем, которые возникнут у конечных пользователей. Совпадает ли она с реальным положением дел или нет -- это выяснится только спустя некоторое время после того, как продукт выпустят в поле. Но эта метрика более практична, она может быть использована для того, чтобы подготовиться к будущим проблемам. Предупреждён -- значит вообружён.
По поводу мерседеса -- если тестировщик скажет, что устранено 100 проблем с автоматическим центральным замком, это хорошо или плохо? А если он скажет, что, по его оценке, в выпускаемом замке 1 раз на 1000000 использований будет происходить сбой -- это совсем другое дело.
Буквально сегодня я увидел в блоге Джоанны Ротман замечательную мысль: нужно оценивать не то, что уже сделано, а то, что впереди. Потому что то, что уже сделано изменить уже нельзя, а то, что впереди, ещё можно улучшить. А оценки того, что сделано, можно и нужно использовать для этого прогнозирования, тогда они приобретают смысл.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#18
Отправлено 18 октября 2004 - 13:14
Или, лучше - я не заметил пары ошибок, но они скорее всего есть. И я об этом честно скажу. Последствия будут ужасны. Кошмар!!!
Пока существует хотя бы минимальная вероятность остаточной ошибки, продукт просто "не готов". Вот такие они - требования внутреннего ПО.
Нельзя обсуждать здесь ересь, если только мы не размышляем, как ее уничтожить.
#19
Отправлено 18 октября 2004 - 13:40
Вы что, в самом деле искренне верите, что выпущенные вами продукты не содержат ни одной проблемы?Я просто представил себе на минутку, что оставил пару ошибок в программе, и честно заявил об этом руководству. Оно мне памятник воздвигнет нерукотворный.
Или, лучше - я не заметил пары ошибок, но они скорее всего есть. И я об этом честно скажу. Последствия будут ужасны. Кошмар!!!
Пока существует хотя бы минимальная вероятность остаточной ошибки, продукт просто "не готов". Вот такие они - требования внутреннего ПО.
Речь не идёт только о функциональных проблемах (хотя я не верю даже в то, что и таких нет). Пользователи могут жаловаться на низкую производительность, неудобство использования, в конце концов, им может показаться ошибкой то, что согласно изначальным требованиям таковой не считалось и они захотят поменять требования.
Зачем прятать голову в песок? Если в прошлом проекте плотность оставленных ошибок была, скажем, xxx, а в этом проекте в процессе ничего не поменялось, можно предположить, что она тоже останется около xxx. Не надо сознательно оставлять ошибки в программе, они там и без того останутся. Зачем усугублять проблему?
Наконец, устранение некоторых проблем может быть признано экономически нецелесообразным, если ущерб от их наличия и периодического проявления ниже, чем затраты, необходимые для их устранения.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#20
Отправлено 18 октября 2004 - 14:59
Интересно, и как же Вы приходите к выводу, что такой вероятности уже нет?Пока существует хотя бы минимальная вероятность остаточной ошибки, продукт просто "не готов". Вот такие они - требования внутреннего ПО.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных