Я бы не сказала, что Грамотно организованный процесс разработки это обязательно процесс разработки, где в основу положен ВИ. Имхо, это еще надо доказать, для меня это не аксиома.ВИ отражает динамику системы, а у системы есть и статика, так что я не согласна с тем, что ВИ является законченной целостной функциональностью, достаточной для проведения тестирования.
В данном случае я имел в виду случай, когда юзкейсы рулят. У нас интерактивная система, построенная по сути на сценариях ее использования. И хотя в основе разработки совершенно не используются юзкейсы, более того они сознательно игнорируются и даже нет никакого стремления их использовать. Тем неменее предложенная мною форма описывания уже имеющейся функциональности через юзкейсы встретила понимание и одобрение. Более того такая форма оказалась понятной и быстро воспринимаемой теми людьми с которыми я начал работать.
Но стоит таки отметить, что я имел в виду некий идеальный процесс, управляемый вариантами, которого вовсе нет. А хотелось бы.
(ну все, сейчас меня побьют ногами юзкейсшаманы и прочие апологеты религии "юзкейсы это наше все")
Никто тебя не будет пинать. Просто в нашем случае нет ни того, ни другого. Нет не вариантов использования, нет и списка требований по задачам. Есть лишь знания предметки у аналитиков. Есть работающая система. Потому одной из первичной задач было описать функциональность системы, и я избрал форму ВИ.
В таком случае, если цель тестирования проверить некий механизм/функционал, то пойду от функций, и мне будет по фигу на юзкейсы. В общем, идти надо от цели тестирования (привет товарищу Boatman'у)
Я не противоречу тебе. Просто что значит я пойду от функции, а как ты о ней узнаешь? Потыкаешься в системе и поймешь - согласен. Но если у меня будет некий сценарий (ВИ или что-то иное, просто последовательность нажатия клавиш), то это уже дает мне много интересной информации.
1. анализируя каждый шаг - действия пользователя - отклик системы - я могу создать как минимум один тестовый случай, а если на шаге возможны вариации - уже больше
2. каждый ВИ я прошу описывать так - предусловие и возможные состояния в которые перейдет система - опять есть информация для анализа - проверить эти возможные состояния
3. анализа разных Ви позволяет выделить очень похожие шаги в них - аргумент в пользу скриптования таких похожих шагов в виде процедур и функций или скажем так библиотечных элементарных шагов. Это можно вторично использовать при разработке тестовых сценариев просто ссылаясть на эти процедуры или включать их как элементы сценария не вдаваясь в их структуру и анализируя их работу
4. при желании каждая такая процедура может быть сформирована как отдельный тестовый случай - стимул - ожидаемая или неожидаемая реакция
конечно большую часть шагов я не проверяю - полагаю их устойчивыми и простыми, но и они могут играть в пользу тестового покрытия скажем
5. как уже показал анализ написанных ВИ - проверка их работоспособности часто покрывается одинаковыми тестовыми скриптами. Скажем в случа оформления коммерческой поставки - через исполнение биллинга проверяется влияние схемы поставки.
Еще замечу - цель тестирования однозначна - обнаружить ошибки, чем больше, тем лучше. Другое дело какие ошибки, вот тут уже начинается по-моему стратегия. В моем случае как я понимаю в первую очередь нужно обнаружить функциональные.
Но что самое прикольное, особых ошибок мне вытащить пока не удается, поскольку так сложилось в проекте, что лучшие выявители ошибок сами пользователи - слава Богу их не мало.
А зато я пачками обнаруживаю ошибки юзабилити, например. Правда это следствие постоянной изменчивости системы и отсутствие стабилизированного релиза. Работа по стабилизации которого сейчас активно ведется.
Просмотр сообщений
Более того я в шутке скрываю свое сожаление по этому поводу.
