Профит? Питоновская надстройка, хорошо интегрированная с nose. Впрочем, рекламировать не буду - сам не использовал.

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

Ну, мы nose не используем, так что пока не актуально.
Вот и у нас практика то же показывает. Кроме того регрешен тестирование разбухло по времени настолько, что срочно надо что-то с этим делать. Вот и пытаемся наших QA пересадить на рельсы автоматизированного тестирования. И желательно поменьше привлекая в это дело разработчиков.

Я думаю что проблема с javascript решится самими javascript-юнит тестами.

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

Мне кажется, что юниттесты для javascript - замечательная вещь. Только, как и с такими же тестами для Питона, одним модульным тестированием не отделаться.

Очень интересно.

Ты знаешь, я вот пообщался на эту тему с Pawel Lipinski, так вот товарищ говорит что у них QA нету в принципе, и обходятся они только юнит-тестированием, и только совсем недавно начали писать тесты на GUI. По мне, так это blade running, но вот, бывает и такое.

Нуу. Это - очень круто, если только юниттесты. Проект под названием Питон так и поступает.

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

Они реально сокращают мои усилия по созданию тестового окружения - покрываю модульными только “библиотечную” часть.

Для “большой” работы отличие гораздо значительней. Команда QA необходима, если имеем конечное приложение, а не либу. И ребята из QA должны тестировать именно приложение. Они знают предметную область - но не всегда владеют Питоном. И уж точно они не настолько осведомленные программисты, чтобы читать код и модульные тесты, выявляя несоответствия.

С регрессинонками поступали так: часть QA объявлялась regression и переносилась в отдельную папку. Разработчик *обязан* выполнить regression и те QA, которые непосредственно относятся к теме. Это - долго и напрягает. Порядка получаса. После чего шел commit в trunk. При использовании DVCS немного проще - делать только перед push/merge.

Полная картинка была сложнее, конечно. Много мелких вопросов между тестерами и разработчиками, ежедневный и еженедельный внутренние релизы, отдельная головная боль с официальными релизами… Регулярная сборка… Уххх!

Он вообще о продукте для корп. сектора говорил. А питон практически и есть сплошная бибилиотека :)
У меня проблема так не стоит - я в TDD стиле программирую.
По поводу QA - так и есть. Но у них тоже есть regression тестирование и оно у нас очень много забирает (вручную) так что будут переезжать на автоматизированное тестирование. Вот я и думаю на них большую часть acceptance перекинуть (пусть seleniumom и тестируют), оно им ближе. У себя высокий уровень только по необходимости делать. (что-то я повторяюсь)

Я вот по поводу “объявлялось regression” не понял — это как? И зачем тесты отдельно переносить? Или имелись в виду функциональные, типа как c selenium?
Мы перед отправкой изменений запускаем все тесты, и собственно push делаем только если все отработают. Долго, конечно, но спасает то, что обычно такое происходит только когда готова реализация User Story.

QA - только автоматический. Тесты с ручным выполнением просто отсутствовали.

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

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

Тестеры запускают QA потом опять, как часть процесса автосборки - чтобы все QA успели провериться до утра.
И тестеры пишут свои тесты, правят уже готовые, принимают участие в составлении/проверки story, делают первичную диагностику по сломавшимся на ночном прогоне.

Так и работали.

А что за проект был, если не секрет? Десктоп/веб?

Распределенный десктоп. Веба - чуть. Финансы. Точнее, биржевые спекуляции для довольно серьезных контор.

Я это к чему спрашиваю — интересно чем тестировали и как.