Сообщений в теме: 8

[Stena]

Всем, доброго времени суток,

столкнулась с следующей проблемой: проект идет уже несколько лет и вот наконец пришло понимание того, что нужен тестировщик. И приходит этот тестировщик и ему говорят: протестируй-ка нам подсистему. Естественный вопрос: на основании чего тестировать? Текущие требования в виде CRов фиксируются, а вот требований вообще (по реализованному или реализуемому) - нет и вести не предполагается. Команда разработчиков(они же аналитики - в одном лице) небольшая, итерации разработки - 2 недели на проект максимум, т.е. стремление к agile на лицо.
Но вот что делать тестировщику?
У меня есть пользовательская и админская документация, есть доступ к баг-трекеру и системе, в которой хранятся проекты и CRы (прямой связи между CRами и проектами нет).
За 2 месяца написала кейсы по одной из подсистем, а у меня их 51: Управление правами, Списки пользователей, Интеграционное взаимодействие(обмен данными с другими системами и синхронизации) и т.д.

Люди добрые, прошу совета: что делать? надо ли самостоятельно формализовать требования?
просто система-то развивается, пока я писала кейсы по одной из подсистем, в нее внесли изменения (частично по моим же ошибкам правда), я просто физически не успеваю.
может кто знает еще какие решения?

Всем заранее благодарна.

[Лелик32]

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

Вам просто нужно адаптироваться: вместо текст-кейсов составляйте чек-листы, это быстрее и занимает гораздо меньше времени + они хорошо поддаются изменениям; применяйте в своей работе exploratory testing там, где нет формализованных требований. Ну, и конечно же, если где-то что-то сомневаетесь, то нужно обязательно спрашивать и узнавать недостающую информацию.

[astenix]

Составьте список (или карту) функциональных возможностей системы.

Не список кнопок и ссылок на главной странице, а именно список функциональных возможностей.

Что там вообще, абстрактно говоря, можно сделать?

Это будет вам чек-листом, планом, отчетом и всем таким прочим.

На эксплоратори уповать не следует, если не умеете тестировать и сразу же записывать тесты. Без списка тестов регрессионное тестирование будет шаманством.

[SALar]

Естественный вопрос: на основании чего тестировать? Текущие требования в виде CRов фиксируются, а вот требований вообще (по реализованному или реализуемому) - нет и вести не предполагается.

Нормальная ситуация.

Команда разработчиков(они же аналитики - в одном лице) небольшая, итерации разработки - 2 недели на проект максимум, т.е. стремление к agile на лицо.

Не имеет никакого отношения к agile. Забудьте про это

Но вот что делать тестировщику?

Сейчас я вам скажу страшную вещь. За нее, кстати, можно с работы вылететь. Вполне реально.

Вашей команде нужно ставить "Управление требованиями" (в терминологии CMMI). Не "Разработку" - это следующий этап, а именно "Управление". Соответственно, вам нужен реестр требований. И судя по названиям подсистем начать вам стоит с инфологического описания предметной области. Можно ER диаграммы построить, можно другой вид описания сделать. Далее к каждой сущности привяжете пакет "Управление сущностью" ибудете детализировать по мере необходимости, если выйдете за CRUDL.

Внимание! Не перепутайте инфологическое описание с даталогическим. Это важно.

[Stena]

Большое спасибо за ответы!

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

Вам просто нужно адаптироваться: вместо текст-кейсов составляйте чек-листы, это быстрее и занимает гораздо меньше времени + они хорошо поддаются изменениям; применяйте в своей работе exploratory testing там, где нет формализованных требований. Ну, и конечно же, если где-то что-то сомневаетесь, то нужно обязательно спрашивать и узнавать недостающую информацию.

я понимаю разницу между формальными подходами и agile. У меня сейчас получается, что я почти все тестирую exploratory (или близко к тому потому что все равно сначала приходится прочесть все что удается найти по функционалу = требует времени) и достаточно успешно (ошибок нахожу достаточно, вплоть до архитектурных просчетов). Проблема именно в упрощении документирования тестов и сбора отчетности: мне надо объяснить начальству, что я целый день делала, почему нашла столько ошибок и как передать коллегам мой опыт.
Видимо стоило написать про инструментарий: наша команда - часть компании-разработчика ПО, которая для своих нужд разрабатывает внутреннее ПО. Поэтому у нас есть несколько своих систем:
- в одной из них ведутся ошибки, задачи и учет рабочего времени.
- в другой: CR, тех.проекты (и хотим туда же ошибки перевести, чтобы вязать их к проектам) и есть возможность вести функциональную модель, тесты. Я потихоньку начала заводить функциональную модель и заводить тесты в связи с функциями, но у меня постоянно встает вопрос: к какой функции писать тест, в котором задействован разный функционал? т.е. кейсы получатся достаточно объемные и сложные...
Я не очень понимаю, где брать основу для чек-листа? у меня есть пользовательская документация и можно покопаться в архивах проектов, но все это не отражает текущего состояния: получается надо или заводить ошибки, или спрашивать коллег(что в постоянном предверии выпуска несколько напрягает), верно?
В моем понимании чек-лист это короткие заметки для проверок - а не описание, что надо сделать 30 действий, чтобы проверить одну функциональную особенность, которой все пользуются. Что я не так понимаю? может мне просто не хватает знаний по организации тестирования в agile? что можно почитать в этой области? в какую сторону двигаться?

Составьте список (или карту) функциональных возможностей системы.
Не список кнопок и ссылок на главной странице, а именно список функциональных возможностей.
Что там вообще, абстрактно говоря, можно сделать?
Это будет вам чек-листом, планом, отчетом и всем таким прочим.
На эксплоратори уповать не следует, если не умеете тестировать и сразу же записывать тесты. Без списка тестов регрессионное тестирование будет шаманством.

как я писала - функциональную карту(модель) пытаюсь создавать, пока вроде не очень успешно. К тому же она получается очень общей и в нашей системе нет возможности взаимосвязи (к примеру, есть функция "Ведение списка пользователей" и есть отдельная функция "Управление ролями и доступом"), если только дублировать (Управление правами доступа и ролоями пользователей) = нагрузка очень большая. Разве что разработчки пропишут списки объектов метаданных по функциям? А можно про использование функциональной карты как планом и отчетом подробнее?

[Stena]

Не имеет никакого отношения к agile.

я не специалист по agile, просто в wiki написано:
Agile — семейство процессов разработки, а не единственный подход в разработке программного обеспечения, и определяется Agile Manifesto[1]. Agile не включает практик, а определяет ценности и принципы, которыми руководствуются успешные команды. ...
Основные идеи:
- Личности и их взаимодействия важнее, чем процессы и инструменты;
- Работающее программное обеспечение важнее, чем полная документация;
- Сотрудничество с заказчиком важнее, чем контрактные обязательства;
- Реакция на изменения важнее, чем следование плану.

заказчиками у нас являются коллеги, которые пишут свое ПО на основании нашего - взаимодействие постоянное, т.к. баг-трекер общий (не считая работы с форумом, куда пишут даже пользователи - по работе с которым достаточно жесткий регламент). Команда небольшая и находится в постоянном взаимодействии (обсуждение планов и текущего состяния, возможность обсуждения проектов, код общий, unit тестирование делаеют друг за другом, код общий, если кто-то в отпуске - функционал всегда поддержат, вплоть до передачи проекта при переходе в отпуск и т.д.), актуальная документация - только пользовательская. Чем мы не подходим под agile???

про управление требованиями - спасибо, я об этом тоже думала и задавала вопросы руковдству (с работы не выгонят, но и делать не будут). Пока никто не видит выгоды, от структурированного ведения требований (зато нагрузка - на лицо): чтобы они были взаимосвязаны, в по возможности привязаны к ошибкам и тестам (один из первых моих вопросов после приема на работу). Получила доступ к системе создания функциональной модели. Про CMMi я в курсе, и с удовольствием почитала бы более подробно. Если можете поделиться ссылками - буду крайне признательна.

[SALar]

К тому же она получается очень общей и в нашей системе нет возможности взаимосвязи (к примеру, есть функция "Ведение списка пользователей" и есть отдельная функция "Управление ролями и доступом"), если только дублировать (Управление правами доступа и ролоями пользователей) = нагрузка очень большая. Разве что разработчки пропишут списки объектов метаданных по функциям? А можно про использование функциональной карты как планом и отчетом подробнее?

* Пользователь
* Роль
* Связь пользователя и роли
* Связь роли и группы функций
Это отдельные объекты. С линками друг на друга. ER-диаграмма ваш друг.

PS. Я занимаюсьпохожей задачей, что и вы, просто у меня система побольше. Я вынужден печатать ER-ки и работать с распечатками, т.к. пока это самый эффективный способ.
PSS. Если что Visual Paradigm - вполне приличная программа для рисования (и не только). Visio - даже не пробуйте - не пойдет.

[Stena]

* Пользователь
* Роль
* Связь пользователя и роли
* Связь роли и группы функций
Это отдельные объекты. С линками друг на друга. ER-диаграмма ваш друг.

PS. Я занимаюсьпохожей задачей, что и вы, просто у меня система побольше. Я вынужден печатать ER-ки и работать с распечатками, т.к. пока это самый эффективный способ.
PSS. Если что Visual Paradigm - вполне приличная программа для рисования (и не только). Visio - даже не пробуйте - не пойдет.

Большое спасибо.
Вот с перекрестными ссылками-то у меня и проблема. В моем инструменте есть 2 понятия: Процессы и Функции. Функции ведутся в древовидной структуре, с возможностью прикреплять к ним ER-ки (а еще операции и тесты - что для меня особо привлекательно), кроме как древовидностью структуры функции у меня никак не взаимосвязаны. У Процессов нет возможности визуализации, зато есть возможность указать Предшествующие процессы и просмотреть список процессов, использующих данный (т.е. последующих). В компании разные команды пользуются разной частью интрумента: кто ведет процессы, кому удобнее функции. Мне не удобно ни то, ни другое. Правильно ли я оцениваю ситуацию?
просто предложенное вами решение у меня никак не ложится на мои инструменты...

[SALar]

Большое спасибо.
Вот с перекрестными ссылками-то у меня и проблема. В моем инструменте есть 2 понятия: Процессы и Функции. Функции ведутся в древовидной структуре, с возможностью прикреплять к ним ER-ки (а еще операции и тесты - что для меня особо привлекательно), кроме как древовидностью структуры функции у меня никак не взаимосвязаны. У Процессов нет возможности визуализации, зато есть возможность указать Предшествующие процессы и просмотреть список процессов, использующих данный (т.е. последующих). В компании разные команды пользуются разной частью интрумента: кто ведет процессы, кому удобнее функции. Мне не удобно ни то, ни другое. Правильно ли я оцениваю ситуацию?
просто предложенное вами решение у меня никак не ложится на мои инструменты...

Есть разные виды атомарных элементов требований.

Для всяких КИС и АСУ удобно пользовать набор:
* [не]действующее лицо
* юзкейс
* объект
* печатная форма
* алгоритм
* нефункциональные требования в разрезе ГОСТ ИСО/МЭК 9126
* Диаграммы анализа - термин Вигерса, все виды диаграмм

Дополнительно можно в качестве требований приводить:
* ссылки на стандарты и законодательные акты
* протоколы сторонних систем (это требования, а не элемент проектирования)
* ...

Уровень детализации хорошо выбирать такой, чтобы программировани занимало от получаса до двух дней. Тогда элементы хорошо ложатся под управление. Пакеты большего размерв ведут как группирующую сущность.

Но поскольку, в РФ аналитиков исчезающе мало, думать на таком уровне декомпозиции в фирмах, как правило, даже не пробуют. И используют усеченные варианты.

Вы правильно понимаете. Те типы элементов, которые у вас ведут - не слишком удобны.

PS. Вам на конфу аналитиков сходить надо. На ЛАФ-2013 идите.