Ну вот еще одна тема пришла на ум...
Хотелось бы выслушать кто и как организовывает тестирование у себя? И как правильно?!
Мы пишем тест сценарии, но их трудно поддерживать в актуальном сосотянии, да и в ручную трудно протетсить все приложение. Поэтому смотрим в сторону правильного применения тестирования в разработке ПО.

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

Это очень похоже на юнит тестирование.
А как на счет поддержания в актуальном состоянии?

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

Ну вот еще одна тема пришла на ум...
Хотелось бы выслушать кто и как организовывает тестирование у себя? И как правильно?!
Мы пишем тест сценарии, но их трудно поддерживать в актуальном сосотянии, да и в ручную трудно протетсить все приложение. Поэтому смотрим в сторону правильного применения тестирования в разработке ПО.

На работе, где я проработала около 3 лет, тестировщики занимались автоматизированным тестированием. IBM Rational Robot - довольно прикольная штука, я сама смотрела как они это делают и простые скрипты делала сама. Естественно, было несколько тестовых баз. Одна из которых была конкретно для Robot.
Соответственно, тестировщики "прогоняли" свои тесты в Rational Robot. Если там не выдавалось ошибки, то аналитики уже свои локальные замечания по системе проверяли сами, или написав, как это делать, давали тестерам.
Если ошибка выдавалась, то тестировщик сам ставил задачу программисту на доработку.

На последнем месте работы, где я проработала всего 2 месяца, говорили на моё возмущение, что ИМ ВООБЩЕ НЕ НУЖНЫ ТЕСТЕРЫ, что пользоватеь (РЖД) сам протестирует!!!! При том, что программы валились на ошибках по 200 раз за день. Это одна из причин моего ухода из этого гиблого места.

Место тестирования в процессе разработки ПО - центральное. Мы должны быть ответственны за качество поставляемого продукта.

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

Может поговорим тогда о Test Driven Development?

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

Нет, только до тех пор, пока они не найдут другого поставщика.

Может поговорим тогда о Test Driven Development?

Далеко не везде применимо. AgileRussia проводили в прошлом году семинар по TDD. Я после него поразмышлял немного и обнаружил (!), что мы-то, оказывается, такой метод уже применяли!

Расскажу чуть подробнее. Чтобы банк получил право обслуживать чиповые карты MasterCard, он должен пройти несколько сертификационных процедур, и одна из них - сертификация софта терминала на специальном тестовом наборе карт. Набор этот в настоящее время включает несколько десятков карт, и в общей сложности проводится несколько сотен тестов. Каждый тест проверяет достаточно узкую функциональность. Набор тестов, как мне представляется, формируется на основе огромного опыта MasterCard по каким-то прецедентам (не путать в вариантами использования ), и постоянно расширяется. То есть, если мы прошли сертификацию в одном банке на определённом наборе тестов, в следующем банке этот набор будет уже немного другим - появятся новые карты, новые тесты, содержимое некоторых старых тестов изменится.

Приведу пример, чтобы было понятнее, о чём речь. В стандарте EMV есть специальный тэг - PAN sequence number, который записывается на карту и не изменяется до конца её жизни. Обычно, когда вы открываете карточный счёт в банке и получаете карточку, значение этого тэга выставляется в 1. Когда срок действия карты заканчивается, вам выпускают новую карту с тем же номером, а значение этого тэга увеличивают на 1. Так в теории. На практике же возможны ещё такие варианты: номер тэга всегда выставлен в 0, либо этот тэг вообще отсутствует (не записан на карту). На самом деле, в реальной жизни вариантов ещё больше (например, значение тэга выставлено в FFFF, что вообще не соответствует спецификации EMV).

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


Так вот, о TDD. Проходя очередную сертификацию, мы "подгоняли" поведение терминала под критерии прохождения всех тестов MasterCard. То есть занимались практически чистым Test-Driven Development - вместо глубокого и детального изучения спецификаций (а на это в области смарт-карт реально полжизни можно угробить, к тому же они непрерывно изменяются) извлекали "требования" непосредственно из тестов. Отличие только в том, что тесты разрабатывали не мы сами, а получали их от авторитетного источника.

Сертификацию прошли успешно, но выявились следующие проблемы:
- сертификация, пройденная в одном банке, совершенно не гарантирует успешного прохождения сертификации в другом банке - набор тестов будет несколько другим, и опять придётся править приложение "на лету", что, вообще говоря, противоречит сертификационной процедуре;
- кое в чём требования MasterCard не совпадают с требованиями, например, VISA - и приложение, "заточенное" под тесты Master Card, может не пройти визовские тесты (что будет очень неприятным сюрпризом для банка, и ещё более неприятным для нас, особенно если десятки или сотни терминалов уже установлены в точках);
- ну и, как предсказывает TDD, появляется тот самый "вонючий" код, который очень трудно сопровождать. А рефакторинг сертифицированного приложения - это очень и очень муторное занятие (а сертификатами оно обкладывается по полной программе, и при этом каждый сертифицирующий орган свято уверен, что любое изменение в приложении требует его повторной сертификации).

Место тестирования в процессе разработки ПО - центральное. Мы должны быть ответственны за качество поставляемого продукта.

Странно, "Му-му" Тургенев написал, а мы анализ и проектирование обсуждаем.

Ну посты не совсем о месте тестирования, но все же. Добавлю свои пять копеек.
Начальные данные: маленькая компания, распределенная команда в 20 человек, группа тестирования - 3 человека, бизнес-аналитики удаленные и недостаточно квалифицированные.. мгм)

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

неоттестированная функциональность пользователям не идет ни при каких условиях.

как-то так.

p.s. ваял пост, но он умер, так что кто набрел на его ошметки - просьба игнорировать, и считать текст выше окончательной версией.

Расскажу чуть подробнее....

В вашем случае вы поимели больше проблем от TDD, чем +? Т.е. если есть тесты и приложение заточено только на них, то TDD подходит как никогда. Если же придется потом изменять приложение, то проблем будет больше?! Так?

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

Кто правит требования?? Согласуются ли правки с Аналитиками?

В вашем случае вы поимели больше проблем от TDD, чем +? Т.е. если есть тесты и приложение заточено только на них, то TDD подходит как никогда. Если же придется потом изменять приложение, то проблем будет больше?! Так?

Я бы только не стал сразу обобщать наш опыт на другие проекты. Все проекты разные, и везде разные риски.

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

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

Так что в данном конкретном проекте - TDD не панацея и не может быть принято в качестве базового метода, но иногда вполне оправдывает себя в тактических целях.

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

Кто правит требования?? Согласуются ли правки с Аналитиками?

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

Уважаемый atermath, на первый взгляд, у вас вполне хорошая, продуманная технология тестирования. И довольно продвинутая. По части поддержки тестов в актуальном состоянии, тут все очень зависит от степени детализации тестов. Имхо, наиболее эффективна следующая схема: тест-сценарии детализируются только до определенного уровня (т.е. как бы описаны все кирпичики, которые надо тестировать), а тому, как тестировать сами кирпичики (или их виды), тестеры должны знать (т.е. их специально этому надо научить, чтоб набор тестов для проверки поля ввода, проведенный Машей, означал тот же набор, проведенный Петей).
Ну и обновление тестовых сценариев должно проводиться при тестировании требований либо параллельно с разработкой, чтоб к началу тестирования уже были как найдены ошибки в требованиях, так и готовы тесты, что тоже часто возможно только до определенного уровня детализации сценариев.
А вопрос "Как правильно" имеет свой ответ в каждом случае. Очень многое зависит как от приложения, так и от степени детализации постановок задач/ТЗ, так и от численности проектной группы. Мы стараемся включить тестеров в работу как можно раньше, ТЗ не идет в работу, если по нему есть вопросы/замечания от тест-аналитиков и разработчиков (разумеется, одно ТЗ смотрит по одному представителю от тестеров и разработчиков).