Отчет по качеству Flashcards
Виды отчёта по качеству:
1) Промежуточный
2) Итоговый
Промежуточный:
Промежуточный отчет составляется и отправляется на всех заинтересованных лиц после каждого вида тестов. Данный тип отчета составляет каждый тестировщик, проверивший заданную часть функциональности. В свою очередь такой отчет можно разделить по разновидностям теста, т.к. для каждого вида теста при написании отчета нужно учитывать те или иные параметры: Smoke, DV, AT, NFT, MAT, Regression.
Итоговый:
В конце предопределенного промежутка времени (обычно за неделю либо перед выходом очередной сборки) составляется итоговый отчет о всей проделанной работе за этот промежуток времени. В отчет включена информация о качестве всех проделанных видов тестов, которые проводились за указанный период. Как правило, такой отчет составляет ведущий тестировщик (QA Lead), который может проанализировать всю информацию и сложить ее воедино.
Перед составлением отчёта убедиться что:
1) Вся запланированная на текущую сборку функциональность проверена (какая-то часть функциональности), обработаны все CRs
2) Все дефекты, пришедшие на проверку, обработаны в баг-трекинговой системе (закрыты, завалидированы, внесены комментарии к заблокированным дефектам…)
3) Все новые найденные дефекты внесены в баг-трекинговую систему (не осталось необработанных пометок на листике…)
4) Заполнены тест-планы на интранете (любая другая отчетная тестовая документация)
5) Обновлены все данные в feature matrix
6) Обновлен документ со статистикой (если имеется)
Содержимое отчёта:
1) Приветствие
2) Общая информация
3) Тестовое окружение
4) Рекомендации QA
5) Детализированная информация
6) Окончание содержимого
Общая информация вкл:
В данной части отчета описывается какие виды тестов проводились. Зачастую указываются модули, которые тестировались или функциональность. Тестовое окружение: 1) Название проекта 2) Номер сборки 3) Ссылка на проект (сборку)
Рекомендации вкл:
Здесь показывается аналитическая работа тестировщика, его рекомендации по улучшению функциональности, наиболее слабые места и наиболее критичные дефекты, динамика изменения качества проекта.
Детализированная информация вкл:
В данной части отчета описывается более подробная информация о проверенных частях функциональности, устанавливается качество каждой проверенной части функциональности (модуля) в отдельности.
Окончание содержимого вкл:
1) Ссылка на тест-план, который находится на интранет
2) Ссылка на документ feature matrix (если таковой имеется)
3) Ссылка на документ со статистикой (если таковой имеется)
4) Общее количество всех новых дефектов
5) Подпись высылающего отчет
Smoke приемлемое:
1) Отсутствие блокирующих или критических дефектов, можно приступать к более подробным тестам (NFT, DV, Regression, etc.).
2) Для сборки Release Candidate: все проверки из Smoke Test имеют статус Passed.
Smoke неприемлемое:
1) Наличие блокирующих или критических дефектов, дальнейшее тестирование не может быть продолжено/не имеет смысла (заблокирован доступ к необходимой функциональности; имеется критический дефект в основной функциональности, после исправления которого придется проводить все тесты заново, и т.п.).
2) Для сборки Release Candidate: наличие проверок из Smoke Test в статусе Failed.
DV:
Высокое менее 1% Выше среднего 1-10% Среднее 10-20% Ниже среднего 20-30% Низкое более 30%
NFT высокое:
1) Новая функциональность реализована в соответствии с требованиями и дизайном.
2) Отсутствуют какие-либо дефекты.
3) Допускается наличие рекомендаций по улучшению
NFT выше среднего:
1) Все требования реализованы корректно.
2) Наличие небольшого количества тривиальных функциональных проблем, незначительных GUI/Usability дефектов, улучшений.
NFT среднее:
Наличие проблем по основным сценариям новой функциональности.
NFT низкое:
1) Наличие серьезных проблем по основым сценариям новой функциональности.
2) Не реализованы (либо реализованы неверно) ключевые требования к новой функциональности.
Regression Tests высокое:
1) Отсутствуют какие-либо дефекты.
2) Допускается наличие рекомендаций по улучшению.
Regression Tests выше среднего:
Наличие небольшого количества дефектов уровня Minor, незначительных GUI/Usability дефектов, улучшений.
Regression Tests среднее:
1) Наличие проблем в основых функциональностях приложения.
2) Наличие дефектов уровня Major/Average, либо значительного количества дефектов уровня Minor.
Regression Tests низкое:
1) Наличие серьезных проблем в основных функциональностях приложения.
2) Наличие дефектов уровня Critical, либо значительного количества дефектов уровня Major.
Субъективная оценка
тип оценки, при котором она выставляется на основании субъективного мнения QA инженеров, основываясь на количестве дефектов, их важности, удобстве пользования продуктом и т.д.
Объективная оценка
тип оценки, при котором используется математическая формула, основанная на количестве дефектов, их важности и размере проекта.
Формула объективной оценки
Показатель качества (Q) равен е в степени -1 делённое на размер проекта(р) E( над 5, под i=1) умноженное на вес дефекта (w) с индексом i умноженное на количество дефектов (с) с индексом i
Показатель качества (Q)
1) Принимает значения от 0 до 1.
2) Если Q=1, то в приложении нет дефектов.
3) Чем ниже значение Q, тем больше дефектов в приложении, соответственно ниже качество.
