1. Протокол результатов

2.  Помогает разработчикам определить и
исправить ошибку;
 Предлагает пути решения проблемы /
улучшения качества продукта;
 Обеспечивает информацию о качестве /
готовности объекта тестирования;
 Должен быть объективным, избегать
обвинений и критики.
Ошибки не должны уйти в небытие!

3. Название атрибута Предназначение
Идент.номер Уникальный номер для отчета
Объект тестирования Идентификатор или название объекта
тестирования
Источник Этап разработки, во время которой была
допущена ошибка
Версия Идентивикатор версии объекта тестирования,
в которой найдена ошибка
Автор отчета об Имя (тестировщика), создавшего отчет об
ошибке ошибке
Ответственный Имя программиста, ответственного за
разработчик отладку
Дата Дата создания отчета об ошибке

5. Название атрибута Предназначение
Тест-кейс Описание теста, во время выполнения которого
была обнаружена ошибка (шаги, необходимые
для воспроизведения)
Описание Описание возникшей проблемы: несоответствие
проблемы полученного результата ожидаемому
Требование Указание на требование (клиента), которое не
выполняется из-за обнаруженной ошибки
Комментарии Комментарии задействованных сторон,
обсуждение ошибки
Исправления Описание внесенных изменений (patch notes)
Ссылки Ссылки на другие связанные отчеты об ошибках

6. ... we have introduces matching to handle the confirmation of transactions. An error,
which occurs when matching without incoming is the following:
1) a transaction is saved and awaiting match. having reached status FinCalc
2) the transaction is loaded in the match window
3) the transaction is opened from the match window (Show Conf./Trans.)
4) the transaction is modified (regardless if anything changes).
5) a new instance of the transaction is saved (again status FinCalc).
6) the new transaction is now waiting for match.
The problem is, that the "old" transaction, now with status cancelled is still shown in
the match window. It seems it can be proccessed from there, however nothing really
happens. Ie. as long as the match window is not refreshed, the transaction still
appears. Pressing "Match without incoming" seamingly executed the match and the
transaction disappears - however nothing has happened. The "new" transaction is
still waiting for match, and will appear when refreshing.
At least a Warning "Another user has updated the transaction" should appear when
trying to manually match a transaction which is no longer up to date.
Example exists in 5.1 Public - you might use match screen with id "AAKTEST" and
transaction # 20121003000002

7. When transactions have been
changed in the background and
a changed transaction is
matched without incoming, the
user will now presented an error
message
Setups for netting rules using settlement
information free-codes as grouping fields did
not show transactions without settlement
information at all. This has been corrected

8. Название атрибута Предназначение
Статус Текущее состояние процесса обработки отчета
об ошибке
Важность Класс важности отчета об ошибке
Срочность Класс срочности отчета об ошибке
Категория Классификация по «содержанию»

10. Severity vs. Priority
Важность – уровень влияния ошибки на
деятельность пользователя (impact):
◦ Критичная ошибка
◦ Важная
◦ Средняя
◦ Низкая

11. Severity vs. Priority
Срочность – указывает на временные рамки
ожидания исправлений:
◦ Срочно
◦ В следующем релизе
◦ При случае
◦ С открытой датой

12. • Ошибка
• Запрос на доработку
• Предложение
• ...

14. Новый отчет об
ошибках
КОНТРОЛЬ ОТКРЫТ ОТКЛОНЕН
АНАЛИЗ
ИСПРАВЛЕНИЯ
ТЕСТ ПРОВАЛЕН ТЕСТ ЗАКРЫТ

15. Закрывать отчеты об ошибках должны
только тестировщики и никто кроме
тестировщиков!