[Scrum. : Check Meeting.]

{09:46}
Сегодня должны узнать промежуточные результаты по заданиям текущего спринта.

1. [Фиксирование скорости спринта для проектов.]
Вроде бы все уже сделали замеры, кроме Common Agenda, у нас спринт ещё не кончился.

2. [Использовать демо-митинги для того, чтобы показать скорость команды.]
Непонятно. Какая взаимосвязь между демо и скоростью?

3. [Владелец Продукта желает иметь Список Заданий Проекта с приоритетами.]
Кто ему мешает? Список Заданий составляет Владелец и он же расставляет приоритеты.

4. [Владелец Продукта желает иметь Список Заданий Спринта для того, чтобы видеть, какие задания охватывает данный спринт.]
Интересно, в каком виде сделали этот СЗ остальные команды. В наших с Лёнькой проектах СЗС - отдельная часть в Списках Заданий Проекта и Команды.

---

[Common Agenda. : Architecture Meeting.]
{10:07}

Базы данных.
"Валидация данных должна происходить на уровне базы данных."
"Бизнес-логика - на уровне сервисов."
"Хранимые процедуры (storage procedures, sprocs) используются для: 1) существенного сокращения трафика между уровнями приложения; 2) обеспечения дополнительной секретности; можно установить ограничения на уровне базы, например, закрыть таблицу для прямого доступа и создать процедуру, которая будет играть роль посредника; 3) осуществления разделения таблиц по каким-либо логическим условиям, например, на текущие и архивные, для разных организаций и др.
Однако следует иметь ввиду, что поддержка хранимых процедур - сложная задача, поэтому использовать их нужно только при возникновении явной необходимости."
"Общение между различными частями системы должно быть максимально ограниченным. В частности, для этого можно организовать кеширование для каждого отдельного уровня системы."
"Функция кеширования характеризуется различными параметрами, которые можно настраивать в зависимости от потребностей."
"Кешировать нужно только те данные, которые необходимы именно в этой части приложения. Это называется оптимизация данных кеширования."
"Один из возможных вариантов кеширования - подключение к какому-либо уровню приложения специализированной базы данных (небольшой, рассчитанной в основном на чтение). Отдельное хранилище данных может быть и у браузера."
-----
{10:31} Довольно интересная тема.
[Базы данных. : Хранимые процедуры. : Инфо.]
[Базы данных. : Секретность. : Прокси-процедуры.]
[Базы данных. : Условное разделение таблиц.]
[Веб-приложение. : Кеширование. : Инфо.]
[Веб-приложение. : Кеширование. : Специализированные базы данных.]
[Веб-приложение. : Кеширование. : Браузеры.]

---

[Testing System. : Тест. : Спецификация.]

{12:17}
Что же следует понимать под тестом в Системе Тестирования? Нужно использовать именно этот взгляд - с точки зрения Системы Тестирования, для которой Тест - это не её составная часть, а нечто внешнее. Система Тестирования взаимодействует с объектом Тест, поэтому некоторые соглашения можно принять. А может, и требования выдвинуть.
Тесты могут быть созданы кем угодно. Системе Тестирования, по большому счёту, всё равно, как они выглядят внутри, но внешний интерфейс должен быть оговорен чётко.
Уровни, которые можно выделить.
Менеджер Тестирования. Это ядро Системы Тестирования. К нему можно подключить модуль, специфический для конкретного приложения. Этот модуль содержит менеджеры и тесты.
Запуск тестов производится Менеджером Тестирования. В ответ ему возвращается результат выполнения. Процессом выполнения Менеджер Тестирования не управляет. А состояние системы? Состояние системы - это глобальное понятие, Менеджер Тестирования должен знать состояние системы.
Получается, что Менеджер Тестирования взаимодействует с менеджерами модуля тестируемой системы.
Менеджеры модуля тестируемой системы взаимодействуют также с Менеджером Логирования и Менеджером Обработки Исключений, которые являются составной частью Системы Тестирования.
Так какие же требования можно определить для Теста?..
Менеджер Тестирования каким-то образом должен знать о существовании конкретного теста. Вряд ли сам тест должен сообщать ему о своём существовании. Наверное, нужно создать что-то вроде каталога, в котором и будут перечислены все доступные для выполнения тесты.
Получается, что я одновременно работаю над двумя системами: 1) непосредственно Системой Тестирования, управляющей сессией тестирования; 2) модулем, специфическим для проекта Common Agenda.
Менеджеру Тестирования вовсе необязательно знакомиться с каждым Тестом лично. Вместо этого можно создать Менеджер Тестов, который и будет знать обо всех тестах. Подробно знать обо всех тестах. Что им нужно для выполнения, как исправлять ошибки и т.д.
-----
Итоги.
["Тест не является составной частью Системы Тестирования."]
["Взаимодействие Системы Тестирования и [Тестируемой Системой] осуществляется посредством взаимодействия Менеджера Тестирования Системы Тестирования и Менеджера Тестов Тестируемой Системы."]
["Состояние Системы - это одна из характеристик Тестового Окружения."]
["Тестовое Окружение - это один из параметров Тестируемой Системы."]
-----
Диаграмма по теме:
http://www.dabbleboard.com/draw?b=Guest356555&i=3&c=6574cd4a36527e3d8ce8d83fab32b462f120d43a

---

[Mantis. : Testing and analysis.]

{15:20}
Resolved: [28] - [27]{15:28} - [26]{15:44} - [25]{16:01} - [24]{16:11} - [23]{16:21}.
New: [1]{15:56}.
[0007560: Questionaire prompt] Closed. {15:28}
[0009722: Action for "input fields"-question.] Closed. {15:44}
[0010259: Questionnaire. "Collapse answers" button.] New. {15:56}
[0009854: if 3 times entered wrong login details then only show prompt below] Closed. {16:01}
[0010031: I see double SMS in alert message] Closed. {16:11}
[0009995: chose another answer type feedback: improve usability more] Closed. {16:21}

---