Архив рубрики 'Аналитика'

TrainingLabs с разных точек зрения.

Четверг, Июль 10th, 2008

Взгляд посетителей
Проблема с информацией. Невинный вопрос на секции тестирования: «Кто был на SQADays?» выявил грустную картину. Там был один человек. Но еще хуже то, что сказала одна из участниц: «Я узнала об этом событии на следующий день после того, как конференция прошла». И что делать? Как донести до потребителей информацию, которую они жаждут получить? Кстати, тем, кто ищет идею для проекта: «В Росси нет нормального, не забитого рекламой канала информации о событиях».

Столько всего вкусного! Выбор первого тренинга многих поставил перед неразрешимой проблемой. Хотелось и туда и туда и туда.

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

Через некоторое время появятся интервью с конференции и можно будет ознакомиться с мнениям участников подробнее.

Взгляд тренера
Я выбрал в качестве темы «базовые методы создания тестовых сценариев». Никаких высоких теорий о преимуществах и недостатках классических или гибких подходов или о регламентах работы. Вот такой вот примитив. Тема, которая мало обсуждается и, насколько мне известно, слабо освещена в литературе на русском языке. С другой стороны это базовые знания тест-аналитика. Очень приятно, что поднятые на тренинге вопросы вызвали живой интерес. По просьбе участников я выкладываю одно из заданий с тренинга [1].

Взгляд организатора
Как это ни грустно, но приходится признать, что сейчас в Москве проблема найти полноценный центр подготовки персонала по программной инженерии. Несмотря на внешне внушительный список в 50 учебных центров, при ближайшем рассмотрении выяснилось, что в массе своей они дают курсы по инструментам вендоров. Есть несколько УЦ, состоящих из объединившихся тренеров, которые дают интересные тренинги, но, как правило, они ограничены одной - двумя областями программной инженерии. Это могут быть модные сейчас методологии, тренинги по управлению проектами,… Но полного спектра нет. Текама предлагает достаточно много тренингов по различной тематике, но не так много готовит внутри. УЦ Люксофт разрабатывает тренинги и закрывает все или почти все области программной инженерии. Сейчас УЦ Люксофт – уникальное явление, и, думаю, в ближайшее время он станет лидером рынка не только по полноте охвата, но и по количеству отчитанных часов (если еще не стал). Никто не хочет составить конкуренцию?

[1] Напомню, о чем идет речь. Есть задание на расчетный модуль. По этому заданию написано несколько (6) алгоритмов. Один правильный, остальные с теми или иными ошибками. Требуется составить тестовый набор, проверяющий эти алгоритмы.

Порядок работы. Тестовые набор поместить в голубую область. Фреймворк покажет достаточен ли этот тестовый набор.
Файл: calc_days.zip

Пример требований к системе. Часть 5.

Четверг, Апрель 10th, 2008

(more…)

Пример требований к системе. Часть 4.

Четверг, Апрель 10th, 2008

Объекты системы

(more…)

Пример требований к системе. Часть 3.

Четверг, Апрель 10th, 2008

4 Требования

(more…)

Пример требований к системе. Часть 2.

Четверг, Апрель 10th, 2008

3 Спецификация вариантов использования

(more…)

Пример требований к системе. Часть 1.

Четверг, Апрель 10th, 2008

В связи с огромным количеством вопросов: «А где можно найти образец написания требований к системе?» - и стандартным ответом: «В рунете - маловероятно», - выкладываю вариант описания требований к системе.

В целом эта документация базируется на руповском шаблоне SRS. Это не плохо и не хорошо. Для некоторых команд было бы удобней видеть не варианты использования, а пользовательские истории. И совсем не видеть функциональных требований в виде «Система должна» ;-) . А описание объектов можно делать и более удобным способом. Но так писать тоже можно. В конце концов, если бы на проектах была такая документация, жить как программисту, так и тестировщику было бы значительно проще.

Документация «рабочая», т.е. перед выкладкой не прилизывалась. Часть информации не заполнена. Сделано это умышленно, чтобы показать работу с документом. Набор частей также не полон.

Дисклаймер. Авторские права да данный материал полностью принадлежат мне. При публикации не пострадали интересы ни одной фирмы.

(more…)

Вопросы аналитику

Понедельник, Июль 2nd, 2007

Буквально недавно меня попросили провести собеседование с претендентом на позицию аналитика. Хорошо, что вопросы были сформулированы давно. Эта заметка в помощь остальным, проводящим подобные собеседования. Важно, почему и зачем мы задаем именно эти вопросы. Как только это станет понятно, можно будет придумать другие вопросы. А главное, понять, что должен отвечать кандидат.

Основные виды деятельности аналитика:

  • Выявление требований
  • Формализация требований для передачи остальным членам команды

Это основные виды деятельности. Гипертрофируем в утверждение: “Эти виды деятельности есть смысл существования проектной роли аналитик”. Дополнительно, в зависимости от проекта, аналитик может заниматься внедрением, подготовкой рабочей и конечной документации, тестированием, подготовкой документов, в соответствии с ГОСТами. Оставим пока эти вещи в стороне и сосредоточимся на первостепенных.

(more…)

Немного критики в адрес RUP

Суббота, Март 31st, 2007

- В чем разница между методологом и террористом?
- С террористом можно вести переговоры.

Тема родилась отсюда: Зачем нужен тест-план?, происки подлых бюрократов?

В одном из своих постов я покусился на святое:

RUP чудовищно устарел. Это прекрасно разработанная система. Без дураков. Одна из самых, а, скорее, самая подробная. Но как раз ввиду этого - застывшая, неповоротливая и во многом ошибочная.
Так, например, их модель прецедентов “действующие лица и цели” устарела на дюжину лет. Взаимосвязь артефактов также нуждается в “капитальном ремонте”.

(more…)