Тест репорты что это
test report
Смотреть что такое «test report» в других словарях:
test report — gaminio juslinės analizės protokolas statusas Aprobuotas sritis žemės ūkio ir maisto produktų sauga ir kokybė apibrėžtis Dokumentas, kuriame registruojami kiekvienos juslinės savybės individualūs vertintojų rezultatai ir galutinis gaminio… … Lithuanian dictionary (lietuvių žodynas)
test report — bandymo ataskaita statusas T sritis Standartizacija ir metrologija apibrėžtis Dokumentas, kuriame pateikiami bandymo rezultatai bei kita su juo susijusi informacija. atitikmenys: angl. test report vok. Prüfbericht, m rus. отчет испытаний, m pranc … Penkiakalbis aiškinamasis metrologijos terminų žodynas
test report — bandymų protokolas statusas T sritis Standartizacija ir metrologija apibrėžtis Dokumentas, kuriuo gamintojas laiduoja, jog pristatyti gaminiai atitinka užsakymo reikalavimus, ir kuriame jis pateikia gaminių bandymo rezultatus. atitikmenys: angl.… … Penkiakalbis aiškinamasis metrologijos terminų žodynas
accredited laboratory test report — akredituotosios laboratorijos bandymo ataskaita statusas T sritis Standartizacija ir metrologija apibrėžtis Bandymo ataskaita, kurioje bandymų laboratorija nurodo, kad ji yra akredituota atlikti bandymą, kurio rezultatus pateikia protokole, ir… … Penkiakalbis aiškinamasis metrologijos terminų žodynas
Test data exclusivity — refers to protection of clinical test data required to be submitted to a regulatory agency to prove safety and efficacy of a new drug, and prevention of generic drug manufacturers from relying on this data in their own applications.… … Wikipedia
Test-driven development — (TDD ) is a software development technique consisting of short iterations where new test cases covering the desired improvement or new functionality are written first, then the production code necessary to pass the tests is implemented, and… … Wikipedia
Test Card W — is a test card, an image used to determine the quality of a broadcast television picture. It is an updated 16:9 (1.78:1) widescreen version of Test Card F, which was created by BBC engineer George Hersee. Test Card W is similar to Test Card J,… … Wikipedia
Test unit — Test unitaire Pour les articles homonymes, voir Test. En programmation informatique, le test unitaire est un procédé permettant de s assurer du fonctionnement correct d une partie déterminée d un logiciel ou d une portion d un programme (appelée… … Wikipédia en Français
Test Money — (or Test Notes, Test Bills, Funny Money, Monopoly Money) are a part of the test apparatus that are often used with currency handling equipment, such as Automatic teller machines. While it is often desirable to use actual banknotes or coins in the … Wikipedia
Test d’amobarbital sodique intracarotidien — Test de Wada En neurologie, le test de Wada consiste à injecter un anesthésique (en général de l amobarbital sodique) dans l une des artères carotides internes (droite ou gauche) de façon à déterminer quel est l hémisphère cérébral dominant pour… … Wikipédia en Français
Test de wada — En neurologie, le test de Wada consiste à injecter un anesthésique (en général de l amobarbital sodique) dans l une des artères carotides internes (droite ou gauche) de façon à déterminer quel est l hémisphère cérébral dominant pour une fonction… … Wikipédia en Français
test report
Смотреть что такое «test report» в других словарях:
test report — gaminio juslinės analizės protokolas statusas Aprobuotas sritis žemės ūkio ir maisto produktų sauga ir kokybė apibrėžtis Dokumentas, kuriame registruojami kiekvienos juslinės savybės individualūs vertintojų rezultatai ir galutinis gaminio… … Lithuanian dictionary (lietuvių žodynas)
test report — bandymo ataskaita statusas T sritis Standartizacija ir metrologija apibrėžtis Dokumentas, kuriame pateikiami bandymo rezultatai bei kita su juo susijusi informacija. atitikmenys: angl. test report vok. Prüfbericht, m rus. отчет испытаний, m pranc … Penkiakalbis aiškinamasis metrologijos terminų žodynas
test report — bandymų protokolas statusas T sritis Standartizacija ir metrologija apibrėžtis Dokumentas, kuriuo gamintojas laiduoja, jog pristatyti gaminiai atitinka užsakymo reikalavimus, ir kuriame jis pateikia gaminių bandymo rezultatus. atitikmenys: angl.… … Penkiakalbis aiškinamasis metrologijos terminų žodynas
accredited laboratory test report — akredituotosios laboratorijos bandymo ataskaita statusas T sritis Standartizacija ir metrologija apibrėžtis Bandymo ataskaita, kurioje bandymų laboratorija nurodo, kad ji yra akredituota atlikti bandymą, kurio rezultatus pateikia protokole, ir… … Penkiakalbis aiškinamasis metrologijos terminų žodynas
Test data exclusivity — refers to protection of clinical test data required to be submitted to a regulatory agency to prove safety and efficacy of a new drug, and prevention of generic drug manufacturers from relying on this data in their own applications.… … Wikipedia
Test-driven development — (TDD ) is a software development technique consisting of short iterations where new test cases covering the desired improvement or new functionality are written first, then the production code necessary to pass the tests is implemented, and… … Wikipedia
Test Card W — is a test card, an image used to determine the quality of a broadcast television picture. It is an updated 16:9 (1.78:1) widescreen version of Test Card F, which was created by BBC engineer George Hersee. Test Card W is similar to Test Card J,… … Wikipedia
Test unit — Test unitaire Pour les articles homonymes, voir Test. En programmation informatique, le test unitaire est un procédé permettant de s assurer du fonctionnement correct d une partie déterminée d un logiciel ou d une portion d un programme (appelée… … Wikipédia en Français
Test Money — (or Test Notes, Test Bills, Funny Money, Monopoly Money) are a part of the test apparatus that are often used with currency handling equipment, such as Automatic teller machines. While it is often desirable to use actual banknotes or coins in the … Wikipedia
Test d’amobarbital sodique intracarotidien — Test de Wada En neurologie, le test de Wada consiste à injecter un anesthésique (en général de l amobarbital sodique) dans l une des artères carotides internes (droite ou gauche) de façon à déterminer quel est l hémisphère cérébral dominant pour… … Wikipédia en Français
Test de wada — En neurologie, le test de Wada consiste à injecter un anesthésique (en général de l amobarbital sodique) dans l une des artères carotides internes (droite ou gauche) de façon à déterminer quel est l hémisphère cérébral dominant pour une fonction… … Wikipédia en Français
Отчётность в тестировании
Отчётность — сбор и распространение информации о результатах работы (включая текущий статус, оценку прогресса и прогноз развития ситуации).
К высокоуровневым задачам отчётности относятся:
Отчёт о результатах тестирования — документ, обобщающий результаты работ по тестированию и содержащий информацию, достаточную для соотнесения текущей ситуации с тест-планом и принятия необходимых управленческих решений.
К низкоуровневым задачам отчётности в тестировании относятся:
Качественный отчёт о результатах тестирования обладает многими свойствами качественных требований, а также расширяет их набор следующими пунктами:
Отчёт о результатах тестирования создаётся по заранее оговорённому расписанию (зависящему от модели управления проектом) при участии большинства представителей проектной команды, задействованных в обеспечении качества.
Большое количество фактических данных для отчёта может быть легко извлечено в удобной форме из системы управления проектом. Ответственным за создание отчёта, как правило, является ведущий тестировщик («тест-лид»). При необходимости, отчёт может обсуждаться на небольших собраниях.
Отчёт о результатах тестирования предоставляется:
Отчёт о результатах тестирования включает следующие разделы:
Логика построения отчёта о результатах тестирования
Для того, чтобы отчёт о результатах тестирования был действительно полезным, при его создании следует постоянно помнить об универсальной логике отчётности:
Выводы должны быть:
Рекомендации должны быть:
Definition of Done
Вы это уже сделали?
Что отвечать на такой вопрос рядовому сотруднику? Варианта два, но и два пути, которые данному работнику могут и не понравиться. Если он отвечает «да», то это означает, что он может взять еще работу на исполнение, а потом окажется, что ему нужно доделать старую. Также если он отвечает «нет», то его могут посчитать медлительным и он тормозит процесс.
Такой вопрос обычно задается бесчисленное количество раз при разработке какого-либо программного продукта, да и, в целом, во время рабочего процесса. В этих моментах, как и в любых других, должна быть оптимизация способная минимизировать или исключить полностью негативные стороны этого процесса. Вообще, понимание выражения «Definition of Done» в полной мере понятна людям, знакомыми с философией Scrum. Определенно сделанная задача – это та задача, которая не нуждается в доработках, но тут встает законный вопрос: «А как оценить, что задача действительно выполнена?»
Definition of Done на страже нашего спокойствия
На самом деле, на страже общего спокойствия. Мы действительно можем не понять до конца степень законченности нашей задачи, однако оповестить команду, что же мы все-таки сделали, обязаны. Definition of Done, как и всё в Scrum, должно быть лаконично, поэтому зачастую отводится для этого одно предложение, однако это не единственный вариант.
Для примера приведем несколько выполненных задач с использованием Definition of Done:
Как видно, любое описание начинается с “done=”, что дает понять, на что обращать внимание. Вообще, в листе принято писать такие результаты, которые можно проверить. Нет смысла описывать мысли, ведь, скажем, «done = придуман внешний вид интерфейса корзины» звучит странно и никак это проверить нельзя.
Желательно, изначально разработать список правил, которые будут описывать Definition of Done, чтобы все в команде писали в одном стиле. Это приведет к более быстрому пониманию того, что хотел передать коллега.
Еще одним из знаменитых способов записи Definition of Done — является простой список.
В заключении, хочется сказать, что не стоит пренебрегать Definition of Done, ведь это приводит не только к осознанию того, что было сделано, но и к тому, как это нужно сделать в будущем. Благодаря использованию Definition of Done все будут стараться делать задачи более четкими и конкретными, чтобы потом гордо сказать: «Точно сделано!». Помимо этого, набор рейтинга в Velocity будет гораздо выше.
В большинстве своем, мы привыкли к графикам идущими вверх, что означает положительную динамику, однако они могут идти и вниз и также показывать положительную динамику. Одним из таких ярких примеров является Диаграмма сгорания задач (Burndown chart). Само сочетание «Burn Down» дословно переводится как «гореть вниз» и это действительно так. Данный график является основным средством для отслеживания выполненных задач в спринте или во всем проекте. Хотя, по сути, он может использоваться как угодно, но мы его рассматриваем внутри методологии Scrum.
Пример Диаграммы сгорания задач:
Синим цветом на диаграмме сгорания отмечена идеальная линия выполнения задач, на которую и следует опираться.
Красным цветом отмечена реальная история выполнения задач.
По шкале Y отмечают количество запланированных баллов (в данном случае), идеальные часы, количество задач и так далее.
По шкале X отмечают количество дней до окончания Sprint.
Как может показаться на первый взгляд, данная диаграмма сгорания задач / Burndown chart служит всего лишь для самоконтроля и самоотчета, однако ее использование может рассказать об очень многом.
Читаем Диаграмму сгорания задач / Burndown chart
Начнем с примеров негативных результатов как ведения графика, так и самой работы команды и закончим более качественными.
1. Burndown Chart: Слишком рано
е
По диаграмме сгорания задач/Burndown chart отчетливо видно, что команда все задачи выполнила раньше срока. Такая ситуация тоже не является позитивной, так как это означает ряд совершенных проблем:
В случае такой проблемы, чаще всего Scrum Master спрашивает команду о возможности добавления дополнительных задач из Product Backlog.
2. Burndown Chart: Опоздали
Также один из видов негативных диаграмм сгорания задач.
Одной из возможных причин здесь может быть постоянное добавление новых задач во время спринта, что увеличило нагрузку.
Второй частой проблемой является недоделанность задач, когда задачи сделаны наполовину. Такие задачи, как выразился Джефф Сазерленд, являются хламом.
В такой ситуации, на Daily Scrum Meeting обязательно нужно говорить о проблемах, мешающих идти к цели ровной дорогой. Как только линия реальных задач пошла выше, сразу надо решать проблему – это также один из постулатов методологии Scrum.
3. Burndown Chart: Без оценок
Может быть даже команда и работала, только забыла или не захотела использовать диаграмму сжигания задач, что является прямо сказать дурным тоном и противоречит эффективной работе. Команда не может контролировать себя, не может совершенствоваться и так далее.
4. Burndown Chart: Конечная оценка
Собственно, ситуация равна предыдущей. Не смотря на законченный Sprint, все итоговые оценки были внесены в диаграмму сгорания в самый последний день после завершения работы. Это равносильно тому, когда вообще законченные задачи не вносятся. По данному графику невозможно сделать вывода о правильности работы команды и, даже более того, можно предположить, что команда не стремится к развитию.
5. Burndown Chart: Zero
Отсутствие показателя реальных задач в диаграмме не является поводом считать, что работа не производилась, ведь она могла быть просто не оценена. Как и в предыдущих пунктах, такая позиция не позволяет контролировать работу собственной команды и совершенствоваться.
6. Burndown Chart: Релаксирующая команда
Этот пример диаграммы сгорания задач уже значительно лучше, нежели другие, ведь в нем можно увидеть, как усовершенствовать команду. Возможные проблемы здесь такие же, как и в пункте «Слишком рано», но Scrum Team решили не заканчивать Sprint раньше, а более расслаблено продолжить работу, что также является ошибкой.
7. Burndown Chart: Совершенствование
Scrum Team на текущих показателях выглядит достаточно хорошо. По линиям видно, что в самом начале были трудности, но во время Daily Scrum Meeting все вопросы вскрывались и Scrum Master исправлял работу, ведя команду к цели.
Также, возможно, группа делала принципиальное ускорение для достижения цели.
Еще одной причиной, к примеру, может быть то, что команда брала дополнительные задачи.
8. Burndown Chart: Опыт
На лицо опытная группа, которая, после начала работы, сразу исправляет все возникающие трудности и совершенствуется так, что резко переходит к активному сжиганию.
9. Burndown Chart: A++
Бесконечно можно смотреть на три вещи: как горит огонь, как течет вода и как строится идеальный график =).
Матрица соответствия требований (Requirements Traceability Matrix)
Это двумерная таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. Матрица обычно хранится в виде электронной таблицы.
Матрица соответствия требований используется QA-инженерами для валидации покрытия требований по продукту тестами.
Цель «Traceability Matrix»:
Данный тестовый артефакт является неотъемлемой частью тестирования.
От тест-кейса до баг-репорта: что должен знать профессиональный тестировщик
На протяжении трех лет я работал на должности QA и считаю, что в IT-индустрии тестировщик, будучи частью scrum-команд, так же ценен, как и любой другой член команды.
Мне доводилось видеть различные аутсорсинговые компании, работающие в сфере тестирования, которые предоставляют полные интенсивные учебные курсы, чтобы превратить начинающих специалистов в экспертов QA. Большинство курсов QA больше связаны с тестированием ПО и ведут к тому, чтобы в перспективе стать разработчиком.
В этой статье я хотел бы изучить и представить свое видение того, как стать тестировщиком и как бы выглядело обучение в области выращивания инженеров обеспечения качества, если бы мы провели аналогию с университетским образованием: общие принципы и предметы, которые должны преподавать, а также какие пробелы в текущей ситуации нам нужно заполнить.
Основные навыки тестирования
В качестве базовых знаний студенты должны изучать тестовые артефакты (тестовую документацию) такие как: чек-лист, тест-кейс, тест-стратегия, тест-план, баг-репорт и тест-репорт.
Что это это такое? Давайте разберемся вкратце на примере курсов QA Manual.
Базовая теория тестирования
Рекомендуем курс по теме
Техники тест-дизайна
Существует несколько техник, помогающих создать эффективные проверки, которые рассматривают QA курсы онлайн. Техники тест-дизайна помогают создавать меньше тест-кейсов, руководствуясь логикой и предыдущим опытом, и одновременно найти наибольшее количество серьезных ошибок.
В качестве базовых знаний студенты должны изучать тестовые артефакты
Классификация тестирования
Тестовые активности можно классифицировать по разным параметрам, поделить на виды, разложить на классы, распределить по уровням, организовать в «семейства» и т.п.
Что нужно знать тестировщику: студентам также должны преподавать принципы тестирования, рассказывать о том, как соблюдать баланс между объемом работ и рисками, как создавать эффективные тестовые планы, а также обучать навыкам управления временем для повышения своей продуктивности.
Направления тестирования ПО
Существует несколько основных направлений тестирования (в зависимости от природы приложения): тестирование мобильных приложений, тестирование WEB-приложений, когда интерфейс программ отображается в браузере, тестирование desktop-приложений, которые необходимо устанавливать в ОС. Также, можно выделить еще достаточное количество более узких специалистов-инженеров, обеспечивающих качество: проверка игр, проверка безопасности, проверка нагрузки и т.п.
Так как я выполнял проверки игр, я считаю, что для того, чтобы QA был эффективным, необходимым является понимание основных игровых дисциплин. Это дает возможность разобраться в основах программирования или же понять принципы анимации на базовом уровне. Я заметил, что многие студенты заканчивают технические специальности в университетах, но в итоге проходят курсы QA и впоследствии двигаются в этом направлении.
Также должно быть уделено особое внимание тому, как предотвращать проблемы до их обнаружения и что является в данный момент самым эффективным решением — все компании к этому стремятся. Ведь если разобраться, то меньше ресурсов (времени всех членов команды, денег, вычислительных мощностей и т.п.) уйдет на предотвращение ошибки, чем на её нахождение, документирование, починку и проверку.
По завершении курса студенты должны находить эффективные решения проблем и общаться со всеми членами команды разработки на одном языке.
Рекомендуем публикацию по теме
Agile и Scrum для QA-специалиста
Agile и Scrum должны лежать в основе процессов разработки, которые преподаются в этом курсе. Студенты смогут понять, по каким процессам и руководствуясь какой логикой ведется общение в команде и принятие решений. Введение в специальность подготовит студентов к трудовой жизни в компаниях. Должно быть уделено особое внимание тому, как предотвращать проблемы до их обнаружения, а также важности QA и основных моментов, таких как непрерывная интеграция, TDD и т. д.
Также должен быть сделан акцент на лидерстве и управлении проектами, поскольку от студентов ожидается, что они будут руководить группами тестировщиков, обеспечивая выполнение стратегии QA.
Создание понятных отчетов о тестировании
Введение
Данная статья будет полезна для специалистов не только в тестировании, но и из других областей.
Я думаю, все понимают, что отчётность — это, зачастую, та часть, которая обязательна на проекте, но составлять ее всегда проблематично. Каждый, рано или поздно, сталкивается с проблемой «как это описать?», «что написать?» и главное «зачем и кто это будет читать?».
На самом деле, отчет — это важная и лаконичная форма передачи информации от исполнителя к заказчику. Это ответ на его технические требования и одновременно информация о проделанной работе.
Сегодня мы поговорим об отчетах в тестировании. В статье Вы найдет акценты на важные моменты при создании отчётов.
Понятный отчёт о тестировании
Создание понятного отчёта о тестировании (test-report) на практике.
Для начала, давайте вспомним определение:
Отчёт — это документ, содержащий информацию о выполненных действиях, результатах проведённой работы. Обычно он включает в себя таблицы, графики, списки, просто описывающую информацию в виде текста. Их пропорция и содержание определяют пользу и понятность отчета.
Нам важно понять, для кого, для чего и в каких условиях мы это делаем и на сколько это улучшит восприятие излагаемой нами информации. Надо помнить, что каждое действие преследует определенную цель. В случае отчета нам важно понять, для кого, для чего и в каких условиях мы это делаем.
Давайте посмотрим на схему:
Аналитические разрезы – это и есть наш отчет. В нем мы даем анализ нашей работе и оценку тестируемому продукту.
Вид компании, в идеальной ситуации, не должен влиять на качество и смысловую ёмкость отчетности. В реальном же мире, к сожалению, отчетность аутсорсинговых компаний является, как правило, более качественной и емкой, чем отчетность штатных отделов тестирования (бывают и приятные исключения).
Мы, как и любая другая аутсорсинговая компания, вынуждены уделять большое внимание качеству и прозрачности отчетности, потому что она является ключевой видимой заказчику метрикой оценки нашей работы.
Саму отчетность можно разделить на финальную и регулярную – дневную, недельную, месячную, версионную (для каждой версии продукта) и т.п. Различия заключаются в глубине временнОй выборки.
Итак, перед написанием отчета, сначала нам надо определиться для кого мы его пишем.
Для кого формируем отчет?
При создании отчета важно понимать, для кого он создаётся, и кто будет его читать.
Исходя из приоритетов целевой аудитории, мы должны определить, какую информацию должен содержать отчёт. Соответственно, в ходе проекта, информация должна консолидироваться по тому направлению, которое необходимо отразить.
Мы можем выделить три группы целевых аудиторий:
1. Технические пользователи — Test-manager. Для них приоритетно понимание хода тестирования, какие возникают проблемы, как они решаются, построение самого процесса тестирование, описание применяемых методов и технологий.
2. Product Manager, они же Менеджеры продукта. Их фокус сконцентрирован на сроках выполнения, выжимки из результатов тестирования без излишних технических подробностей и на общую статистику (цифровые и сравнительные метрики).
3. Бизнес-пользователи. Обычно это и есть те люди, которые принимают решения по завершению тестирования. Они же определяют качество проделанной работы. Для них, в первую очередь, важен конечный результат в максимально кратком и ясном формате (да\нет), наглядное представление информации (графики, диаграммы), экспертное мнение о возможности выпуска продукта в промышленную среду и т. п., без углубления в детали.
Вывод: Написать отчет, который устроит все группы, практически невозможно. Прежде чем писать отчет, обязательно определите целевую аудиторию. В зависимости от нее, содержание будет сильно отличаться своей структурой и содержать разные детали, необходимые конкретной группе.
Какова глубина временной выборки?
Отчёты могут делиться на два вида относительно времени:
1. (Недельный, дневной, месячный)/ промежуточный.
В общем, это практически тот же финальный отчет, но с измененными приоритетами фокуса и уменьшенной глубиной временной выборки. В нем обязательно должны содержаться две главных метрики:
— Оценка степени готовности продукта.
— Оценка проведённых работ по тестированию за время между отчетностями (прогресс).
Этот отчет должен показать какова динамика вашей работы.
Важно помнить, что прогресс – величина не постоянная, а динамическая, она определяется за счёт сравнения состояния проекта на прошлой неделе и настоящей. Соответственно прогресс – этот совокупность метрик, позволяющих понять в каком состоянии находится проект.
Они создаются для каждого проекта индивидуально, основываясь на целях, которые ставятся для успешного проведения тестирования. Метрики ставятся при создании ТК (тест-кейсов), прохождении ТК (провален\пройден), обнаружении дефектов (критичность). Они позволяют доступно и достаточно быстро составить общую сравнительную картину по проекту. Если вы, например, используете TestLink, то понимаете, что метрики позволяют делать быструю выборку по проблемам, составлять статистику проваленных ТК и т. п.
Данная информация полезна и необходима для Product Manager, её составляют и контролируют Test-manager, а также QE и SQE.
Есть еще один важный и часто используемые тип временного отчета – версионный (отчет по итерации).
Он схож с итоговым. В нём описываются те задачи, которые были выполнены командой тестирования для конкретной версии продукта.
2. Конечный /финальный.
В финальном отчете важно показать общий взгляд на проделанную работу (в контексте установленных метрик) и эволюцию продукта.
Так же, надо дать исчерпывающую информацию о статусе продукта в данный момент (количество оставшихся неисправленных ошибок, полностью ли протестирован продукт или требуется дополнительный цикл тестирования, оценка возможности выпуска продукта во «внешний мир» и т.д).
Вывод: Ведите статистику, используя метрики в течении всего проекта. Она поможет вам в нужный момент предоставить любую информацию заказчику и избавит от страха перед вопросами «А что конкретно вы сделали на четвертой неделе?» и «Что у нас со сроками?».
Какие приёмы представления информации и данных использовать в отчёте?
Когда технический специалист пишет для другого технического специалиста, вопрос о применении тех или иных приемов отражения информации возникает редко. Термины, формулы, профессиональный сленг – это привычно и понятно. Гораздо сложнее писать отчеты для людей, которые относительно далеки от специфики тестирования.
Для Бизнес-пользователей, зачастую, используют представление информации в виде графиков. Они наглядно показывают на сколько продукт готов к выпуску в промышленную среду, на сколько процентов проект выполнен.
Это может быть, к примеру, график пройденных ТК п о модулям. Он наглядно покажет, какой объем работы в каждом модуле уже проделан и поможет вычленить проблемы.
Так же, очень полезным может быть график отношения созданных тикетов (обнаруженных багов) и закрытых (исправленных багов). Не даром он является основным во многих таск-трекерах.
В случае продуктивной работы программистов над исправлением дефектов и написанием качественного кода кривая критических ошибок с выходом нового релиза стремиться к низу, при этом приоритет и важность ошибок тоже уменьшается.
Но, если разработчиками или тестировщиками уделяется мало внимания существующим дефектам, то кривая закрытых багов растет медленнее, чем не закрытых.
В идеальном случае кривая незакрытых багов (найденных, но не исправленных) должна сойтись с кривой исправленных. Другими словами, к финальному релизу необходимо, что бы все дефекты были устранены. Если это не так, то руководство может принять решение о продлении разработки и тестирования с целью устранения всех дефектов или выпустить продукт в «прод», беря на себя возможные риски.
В дополнение к графику необходимо оформлять сводную таблицу. График строится на основании этих данных.
Вот пример таблицы, на основании которой был построен график пройденных ТК по модулям:
Вывод: График для бизнес-пользователей — обязательная часть отчетности. Он информативен, доступен и понятен конечному пользователю, демонстрирует динамику активности на проекте или, в худшем случае — застой.
Так же, использование графиков в отчетах для любых пользователей и технических специалистов целесообразно тогда, когда надо быстро и наглядно сравнить цифры и показать динамику.
ЧТО НУЖНО УКАЗЫВАТЬ В ОТЧЕТЕ ВСЕГДА?
Может показаться, что отчеты разных типов сильно отличаются.
Тем не менее, в них есть схожие черты и данные, которые стоит указывать всегда.
Вот они:
1. Состав команды;
2. Сроки выполнения, за которые составляется отчет;
3. Описание процессов тестирования;
4. Изменения тестовой модели, дополнение ТК;
5. Процент пройденных ТК;
6. Критичные и блокирующие проблемы и принятые меры по их устранению;
7. Результаты регресса (плюс акцент на сохранившихся проблемах);
8. План на следующую итерацию\ неделю\ месяц;
Пункты 3, 4, 6 и 8 стоит писать с оглядкой на целевую аудиторию отчета.
Седьмой пункт стоит указывать тогда, когда проводилось «регресс-тестирование». Обычно этот пункт фигурирует в «версионных» отчетах.
Пункт 8 из итогового отчета исключается.
Заключение
Итак, мы поняли нашу целевую аудиторию, обозначили период, за который мы будем писать отчет, определили содержание и блоки. На самом деле — это практически все, что надо, чтобы сформировать понятный документ, который обязательно найдет отклик в головах тех, кому он адресован.
Пишите ваши отчеты детально, грамотно и с удовольствием, ведь хороший отчет – это как минимум треть работы и единственная ее часть, которая видна кому-то, кроме тестировщиков и программистов.