Каморка

Вот подумалось, если есть Agile development, то должен быть какой-то способ этот zero-documentation project тестировать, какой-то Agile Testing (и что самое интересное Google даёт кучу всяких ссылок на эту тему ... ключевое слово "всяких").

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

Use Case нет, и стало быть Test Case не по чему писать. Пользователь может протестировать только своё типичное поведение в своём отдельно взятом environment. Шаг в сторону и система падает. В то же время тестер же не может просто так сидеть и пытаться уронить систему из всех положений, достаточно чтобы версия работала в 99% вариантах работы разных пользователей.

Собственно subj, так как тестировать то при agile'ности? У кого какой опыт?

Sheen писал(а):Вот подумалось, если есть Agile development, то должен быть какой-то способ этот zero-documentation project тестировать, какой-то Agile Testing (и что самое интересное Google даёт кучу всяких ссылок на эту тему ... ключевое слово "всяких").

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

Use Case нет, и стало быть Test Case не по чему писать. Пользователь может протестировать только своё типичное поведение в своём отдельно взятом environment. Шаг в сторону и система падает. В то же время тестер же не может просто так сидеть и пытаться уронить систему из всех положений, достаточно чтобы версия работала в 99% вариантах работы разных пользователей.

Собственно subj, так как тестировать то при agile'ности? У кого какой опыт?

есть user stories, которые и описывают как аппликуха должна работать, даже еще лучше: что есть подверждение, что аппликуха работает... а там, уж девелопер пишет унит тест, по которому ваяет код, или тестер потом прогоняет тест, сути не меняет.

в общем agile: установка приоритета: "Working software over comprehensive documentation", а не отсутствие документации. user stories могут быть весьма детальными при желании

Пока что я вижу две реальные проблемы: девелоперы не будут писать unit test по той же самой причине, по которой UC обычно отстают на шаг от реального приложения по валидности. Второе, User Stories по сути buzzword для тех же самых UC и стало быть смотри пункт 1.

За то время пока спрашивал нашёл одну статью в Dr.Dobb, думаю кому-нибудь будет также интересно прочитать. Но не увидел ни чего такого, чего нет в waterfall. Практически всё тоже самое. Складывается впечатление (сугубо субъективное мнение, очень хочется чтобы это было не так), что вся agile'ность придумана девелоперами (ну состарились дядечки, не вечно же код ваять) и для девелоперов. Всё что вне этого круга как бы первоначально не рассматривалось и теперь притягивается за уши (и напоминает историю с кошкой в храме).

ps. Интересно, почему те же дядечки первоначально не искали аналогии в остальном мире. Взять работу того же портного, чем она отличается от программизма, и ведь ни кто там не спорит про waterfall и agile, просто делают своё дело и всё, приглашают раз по несколько на примерку и клиент уходит именно с тем костюмом, который хотел получить.

Если все еще актуально и больше практический акцент интересует, вчера по рассылкам проскочил AgileTrack. Попробуй запустить через webstart demo c http://www.agiletrack.org . Я правда его глубже чем просто побаловаться не смотрел - у нас RUP пользуют, а там подход совсем другой.

Спасибо за ссылку. Интересная штука, имхо для стартапа как раз самое то, а вот для компании со сложившимся видинием (пусть даже не правильным) вряд ли ... нет интеграции с существующим зоопарком, а слезать с него бизнес оунеры не позволят.

Однако ... однако ... Однако это ещё одна тулза для тракинга требований. Вопрос как же тестировать, кроме как классического подхода (прописанного в том же RUP например) пока так и остался для меня не совсем понятным ...

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

Вова (или Володя) ... похоже ты не совсем внимательно прочитал мой первоначальный постинг. Собственно вопрос был - если нет документации как таковой, а есть только примитивные users stories, то как строить процесс тестирования в agile. Будем считать, что бабла у заказчика не меренно и они готов на всё, даже из окна офиса прыгнуть. Пока что у меня в голове "пятнашки" не складываются в логическую последовательность. Т.е. понятно, что как-то да протестируем (а что не протестируем, то в вернётся в виде work/change request из production), но это не то, что я хотел бы знать. Я знаю как это должно быть в "тяжелых" методологиях, хотелось бы знать, что делать в упрощённых (правильнее сказать - отсутствующих) методологиях.

Sheen писал(а):Вова (или Володя) ... похоже ты не совсем внимательно прочитал мой первоначальный постинг. Собственно вопрос был - если нет документации как таковой, а есть только примитивные users stories, то как строить процесс тестирования в agile. Будем считать, что бабла у заказчика не меренно и они готов на всё, даже из окна офиса прыгнуть. Пока что у меня в голове "пятнашки" не складываются в логическую последовательность. Т.е. понятно, что как-то да протестируем (а что не протестируем, то в вернётся в виде work/change request из production), но это не то, что я хотел бы знать. Я знаю как это должно быть в "тяжелых" методологиях, хотелось бы знать, что делать в упрощённых (правильнее сказать - отсутствующих) методологиях.

Это ты невнимательно прочитал. Ежели у заказчика бабла полно - то вместо складывание этого бабла в карман - потратьте это бабло на написание документации как таковой и внедрение правильных методологий. Как ты их называешь тяжелых.

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

Use Case нет, и стало быть Test Case не по чему писать. Пользователь может протестировать только своё типичное поведение в своём отдельно взятом environment.

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

Шаг в сторону и система падает.

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

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

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

исключительно ИМХО:

одна из неприятных проблем с обычным процессом разработки, это слишком тяжелая нагрузка на документацию, и даже не на документацию, а собственно на ее поддержание, наверное это хорошо для больших комманд и для некоторых задач. К сожалению очень часто это завершается спецификациями которые были написаны N лет/месяцев назад и с тех пор не обновлялись. Собственно тест кейсы если они лежат как документ подподают под ту же категорию. Собственно agile это не требование не писать документацию, а всего-ли установка актента, что документация неплохо, даже хорошо, но главное работающая и значит тестируемая вещь.
В качестве тестов ставятся унит тесты как один из краеугольных камней, что на самом деле накладывает большой отпечаток на то, как собственно пишется software. из методик functional/integration testing выплывают средства типа фитнессе (http://www.fitnesse.org/). А вообше чем ближе тест лежит к исходному коду, тем легче его поддерживать. а что нет детальных спек... за-то business user сидит каждый день на митинге (ну или должен сидеть ). Да, не для всех приложений подходит, наверное софт для boing 747 по agile подходам создать сложно... но для обычных бузинес аппликух вплоне работает.