Отчет по качеству

Question 1

Виды отчёта по качеству:

Answer 1

1) Промежуточный

2) Итоговый

Question 2

Промежуточный:

Answer 2

Промежуточный отчет составляется и отправляется на всех заинтересованных лиц после каждого вида тестов. Данный тип отчета составляет каждый тестировщик, проверивший заданную часть функциональности. В свою очередь такой отчет можно разделить по разновидностям теста, т.к. для каждого вида теста при написании отчета нужно учитывать те или иные параметры: Smoke, DV, AT, NFT, MAT, Regression.

Question 3

Итоговый:

Answer 3

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

Question 4

Перед составлением отчёта убедиться что:

Answer 4

1) Вся запланированная на текущую сборку функциональность проверена (какая-то часть функциональности), обработаны все CRs
2) Все дефекты, пришедшие на проверку, обработаны в баг-трекинговой системе (закрыты, завалидированы, внесены комментарии к заблокированным дефектам…)
3) Все новые найденные дефекты внесены в баг-трекинговую систему (не осталось необработанных пометок на листике…)
4) Заполнены тест-планы на интранете (любая другая отчетная тестовая документация)
5) Обновлены все данные в feature matrix
6) Обновлен документ со статистикой (если имеется)

Question 5

Содержимое отчёта:

Answer 5

1) Приветствие
2) Общая информация
3) Тестовое окружение
4) Рекомендации QA
5) Детализированная информация
6) Окончание содержимого

Question 6

Общая информация вкл:

Answer 6

В данной части отчета описывается какие виды тестов проводились. Зачастую указываются модули, которые тестировались или функциональность.
Тестовое окружение: 
1) Название проекта
2) Номер сборки
3) Ссылка на проект (сборку)

Question 7

Рекомендации вкл:

Answer 7

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

Question 8

Детализированная информация вкл:

Answer 8

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

Question 9

Окончание содержимого вкл:

Answer 9

1) Ссылка на тест-план, который находится на интранет
2) Ссылка на документ feature matrix (если таковой имеется)
3) Ссылка на документ со статистикой (если таковой имеется)
4) Общее количество всех новых дефектов
5) Подпись высылающего отчет

Question 10

Smoke приемлемое:

Answer 10

1) Отсутствие блокирующих или критических дефектов, можно приступать к более подробным тестам (NFT, DV, Regression, etc.).
2) Для сборки Release Candidate: все проверки из Smoke Test имеют статус Passed.

Question 11

Smoke неприемлемое:

Answer 11

1) Наличие блокирующих или критических дефектов, дальнейшее тестирование не может быть продолжено/не имеет смысла (заблокирован доступ к необходимой функциональности; имеется критический дефект в основной функциональности, после исправления которого придется проводить все тесты заново, и т.п.).
2) Для сборки Release Candidate: наличие проверок из Smoke Test в статусе Failed.

Question 12

DV:

Answer 12

Высокое менее 1%
Выше среднего 1-10%
Среднее 10-20%
Ниже среднего 20-30%
Низкое более 30%

Question 13

NFT высокое:

Answer 13

1) Новая функциональность реализована в соответствии с требованиями и дизайном.
2) Отсутствуют какие-либо дефекты.
3) Допускается наличие рекомендаций по улучшению

Question 14

NFT выше среднего:

Answer 14

1) Все требования реализованы корректно.

2) Наличие небольшого количества тривиальных функциональных проблем, незначительных GUI/Usability дефектов, улучшений.

Question 15

NFT среднее:

Answer 15

Наличие проблем по основным сценариям новой функциональности.

Question 16

NFT низкое:

Answer 16

1) Наличие серьезных проблем по основым сценариям новой функциональности.
2) Не реализованы (либо реализованы неверно) ключевые требования к новой функциональности.

Question 17

Regression Tests высокое:

Answer 17

1) Отсутствуют какие-либо дефекты.

2) Допускается наличие рекомендаций по улучшению.

Question 18

Regression Tests выше среднего:

Answer 18

Наличие небольшого количества дефектов уровня Minor, незначительных GUI/Usability дефектов, улучшений.

Question 19

Regression Tests среднее:

Answer 19

1) Наличие проблем в основых функциональностях приложения.

2) Наличие дефектов уровня Major/Average, либо значительного количества дефектов уровня Minor.

Question 20

Regression Tests низкое:

Answer 20

1) Наличие серьезных проблем в основных функциональностях приложения.
2) Наличие дефектов уровня Critical, либо значительного количества дефектов уровня Major.

Question 21

Субъективная оценка

Answer 21

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

Question 22

Объективная оценка

Answer 22

тип оценки, при котором используется математическая формула, основанная на количестве дефектов, их важности и размере проекта.

Question 23

Формула объективной оценки

Answer 23

Показатель качества (Q) равен е в степени -1 делённое на размер проекта(р) E( над 5, под i=1) умноженное на вес дефекта (w) с индексом i умноженное на количество дефектов (с) с индексом i

Question 24

Показатель качества (Q)

Answer 24

1) Принимает значения от 0 до 1.
2) Если Q=1, то в приложении нет дефектов.
3) Чем ниже значение Q, тем больше дефектов в приложении, соответственно ниже качество.

Question 25

Размер проекта (р)

Answer 25

1) Размер проекта зависит от длительности проекта и от количества функциональных модулей.
2) Переменная. Определяется при введении объективной оценки на проекте и пересматривается с течением времени при изменении размера проекта (увеличение/сокращение тестируемой функциональности).
3) За единицу программного продукта принимается модуль, единица имеет размер.

1-12 человек-месяц- 50/200 единиц
1-3 человека-год-200/500 единиц
Более 3 человек-год-500/1000 единиц

Question 26

Вес дефекта (w)

Answer 26

1) Вес дефекта, он зависит от критичности дефекта.
2) Значение определяется для каждого уровня критичности, определенного на проекте.
3) Константы. Определяются один раз при введении объективной оценки на проекте и согласовываются с Заказчиком.

Question 27

Количество дефектов (с)

Answer 27

1) Количество дефектов для каждого уровня критичности, определенного на проекте.
2) Подсчитывается для каждой итерации тестирования.