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

[galogenIt]

Коллеги,
не могу назать себя очень опытным тестировщиком. Поскольку имел дело только с системами, заявленными в заголовке темы. Да и уж если совсем откровенно, то и система то была всего одна. Ни тебе веб-приложений, ни какого-то там встроенного ПО, ни наукоемких приложений, ни просто узкофункциональных продуктовых разработок от разных производителей в разной архитектуре, технологии и т.п. Да и методы и способы тестирования главным образом фокусируются на черном ящике и по сути проверке исполнения требований.

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

С другой стороны долго изучая подобную систему, постепенно сродняешься с ней что ли, понимаешь все ее проблемные места и сложности (кстати создает эффект, что начинешь аккурантно их обходить). Но все равно уровень тестирования недостаточен. Об этом говорим ПМ, сетуют аналитики, видно по пользовательским инцидентам.

Вопрос: существуют ли какие-то особенности, правила, методики и способы, ориентированные на такие долгоиграющие тяжелые системы? С длинными цепочками бизнес-процессов, со сложной зависимостью между операциями, со значительной долей автоматизации их?

[Wolonter]

Вопрос: существуют ли какие-то особенности, правила, методики и способы, ориентированные на такие долгоиграющие тяжелые системы? С длинными цепочками бизнес-процессов, со сложной зависимостью между операциями, со значительной долей автоматизации их?

Ситуация аналогичная, долгий проект с огромной/большой бизнес-логикой.

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

Автоматизаторы готовы продать душу и принести кофе за годный сценарий.
Ручные тестировщики радуются скриптам наполнения/конфигурирования системы для каких-то кейсов.

Но не думаю, что существуют какие-то особые, уличные, методики.

Может лучше спросить о конкретной проблеме?

[galogenIt]

Не могу выделять явную проблему, хотя ...

Скажем так. Мое представление классического тестирования. Есть бааальшая система. Типично, что она поделена на системы по-меньше, те в свою очередь и т.д. Декомпозиция, ведь.

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

Другая ситуация, протестировать все возможные аспекты практически нереально. Например влияние финансовых условий на конечные результаты, (суммы) выставляемые в автоматическом биллинге значений. Или как протестировать GUI? Если в нем контролов как грязи? И нужно ли это делать?

Да еще проблема, в том, что тестирование началось системно не так давно. Так что покрытие довольно слабоватое. главным образом генеральное направление и новый функционал
...

Я конечно понимаю, что никаких уличных методик нет, но есть некая практика, которая может быть весьма полезной ...

[George.Ivanov]

Вопрос: существуют ли какие-то особенности, правила, методики и способы, ориентированные на такие долгоиграющие тяжелые системы? С длинными цепочками бизнес-процессов, со сложной зависимостью между операциями, со значительной долей автоматизации их?

RUP?

Маловато данных для анализа ситуации.
Как организован процесс разработки и конкретно тестирования? Есть ли требования и специальные люди которые ими занимаются? Какие ресурсы имеются у тестирования: люди, навыки? Какая цель ставится перед командой?

[Vasiliy]

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

Из опыта работы с большими (но не бааальшими) системами. А вы потом проверяете общую работоспособность системы? Регресс полностью пускаете по системе?
К примеру, у нас модули связаны так, что даже когда разработчики уверяют, что вот это не трогали, то с вероятностью раз в год там что-то громко сломается :( И самое обидное, что может уже и у заказчика((

[galogenIt]

Вопрос: существуют ли какие-то особенности, правила, методики и способы, ориентированные на такие долгоиграющие тяжелые системы? С длинными цепочками бизнес-процессов, со сложной зависимостью между операциями, со значительной долей автоматизации их?

RUP?Маловато данных для анализа ситуации. Как организован процесс разработки и конкретно тестирования? Есть ли требования и специальные люди которые ими занимаются? Какие ресурсы имеются у тестирования: люди, навыки? Какая цель ставится перед командой?

Не, никакой не RUP. Водопад скорее, но такой неклассический, что-то от agile, что-то от других.
Процесс организован примерно так:
есть некоторые длинные работы-проекты, многорелизные.
Релиз типично занимает 2 месяца. Накануне планируется список работ к исполнению: исправление сложных ошибок, доработка, новый некрпный функционал или достаточно быстро разрабатываемый, работы на проектирование и подготовку длинных задач.
В конце периода дней за 10 - бранч. Тестирование происходит практически с момента начала нового релиза в фоновом режиме - (регрессия) + проверка релизных работ вручную с проектированием и реализацией новых автотестов.
Затем ставят на учебную базу скажем так для бета-тестирования, а потом на живую на бета-тестирование но уже в таком жестком режиме.

Группа тестирования: 6 человек. 1 системный программист, 3 прикладных тест-программиста, 1 тест-дизайнер-аналитик, 1 руководитель
2 сотрудника с годичным опытом, 1 с трехлетним, 3 в 2-2,5 годичным. Ранее нигде тестированием не занимались
Задачи: анализ логов прогонов автоматизированных тестов, прием работ над ошибками, прием релизных работ.
Цель по-моему одна - находить ошибки :) Ранее ставилась цель обеспечения устойчивости системы, отслеживание и перехват регрессии. Сейчас на раннее обнаружение ошибок, разгрузка аналитиков по приему релизных работ

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

Из опыта работы с большими (но не бааальшими) системами. А вы потом проверяете общую работоспособность системы? Регресс полностью пускаете по системе?К примеру, у нас модули связаны так, что даже когда разработчики уверяют, что вот это не трогали, то с вероятностью раз в год там что-то громко сломается :( И самое обидное, что может уже и у заказчика((

Постоянно проверяем это. Регресс крутится в автоматическом режиме без нашего участия по ночам.
У нас это легко может происходить ежедневно. Раз в год - это просто чудо :)
Проблема в том, что регресс на все не поставишь. Ясно, что там где идет интенсивное изменение и рефакторинг применяется и усиленное внимание. Однако бывает и так, что где-то тронули. Наш регресс прошел, поскольку он же не всемогущ, и проявляется у клиента :(