Вопрос про тестирование "зоопарков"

[Sheen]

Вопрос тестировщикам про программы для тестирования (хотя сдаётся мне, что вопрос к программистам).

Суть следующая, есть зоопарк программ и баз написанных на фиг знает каком старье (но под Win), всё это не плохо бы пропускать через regression testing время от времени, но не понятно как. Т.е. закупить что-то типа Rational Robot и не париться оно бы конечно здорово, только всё уже настолько неуправляемое, что разные приложения могут модифицировать тестовые данные для других программ (а также некоторые данные, например, котировки валют, могут изменяться во времени), хотя такого в test environment по уму быть не должно. Однако происходит. Как должно быть по уму я знаю/видел в реале, однако это не применимо к компаниям где вначале программят, а потом думают. (Ни чего не имею против классных программистов, за одним исключением, что они не думают, что будет с их софтиной лет эдак через 10-20, именно потому, потому что она классно и правильно написана.)

Как идею я предложил test-driven development, на что мне замахали руками и сказали, что девелоперы на это не пойдут.

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

[StS]

разные приложения могут модифицировать тестовые данные для других программ (а также некоторые данные, например, котировки валют, могут изменяться во времени), хотя такого в test environment по уму быть не должно. Однако происходит.

Не должно происходить. Создать для котировок mock objects которые не меняются.
Ну или найти code coverage tool.
For java http://emma.sourceforge.net/
http://www.eclemma.org/

[Sheen]

Это конечно здорово такую тулзу использовать, но в конце тестирования. Проблема с такими тулзами в том, что:

During product development, a large number of test cases are created and run to ferret out bugs in the system. Code coverage analysis monitors which parts of the product's code are exercised by the collection of test cases.

А если разработка типа agile не потому что такие умные, а потому что просто лениво (стандартно - "добавьте вот эту маленькую фичу и всё" ... после 10000 таких фич в течении 10 лет ), т.е. zero-based documentation, test cases отсутствует как класс, в коде ни чего нет поддерживающее тестирование, входы выходы "чёрных ящиков" ни где не описаны и тестеры могут только догадываться на основе собственного опыта. Если кто новый как тестер придёт, то как бы он крут не был (согласно прошлому опыту), его ценность в глазах остальных будет стремиться к нулю из-за незнания этого зоопарка. Знакомо звучит, не правда ли?

[StS]

Вроде можно данные code coverage tool-а не ресетить. Тогда тестерам даешь код, они кликают, смотришь чего они там накликали и какие куски кода не покрыты. Потом не ресетя данные просишь протестировать какую-нибудь фичу из непокрытого кода. Опять смотришь что они там накликали, и т.д.

[Sheen]

А вот я тут наткнулся на такую тулзу (точнее не понял ещё что это такое), WinFITRunnerLite называется. Есть версии для разных языков, Java и С# одни из них. Не много пока что понял, но звучит как заказчики сами пишут подобие test case и в тоже время близко к test-driven developmet.

Кто-нибудь это реально использует?

[Kiseta]

Вопрос тестировщикам про программы для тестирования (хотя сдаётся мне, что вопрос к программистам).

Суть следующая, есть зоопарк программ и баз написанных на фиг знает каком старье (но под Win), всё это не плохо бы пропускать через regression testing время от времени, но не понятно как. Т.е. закупить что-то типа Rational Robot и не париться оно бы конечно здорово, только всё уже настолько неуправляемое, что разные приложения могут модифицировать тестовые данные для других программ (а также некоторые данные, например, котировки валют, могут изменяться во времени), хотя такого в test environment по уму быть не должно. Однако происходит. Как должно быть по уму я знаю/видел в реале, однако это не применимо к компаниям где вначале программят, а потом думают. (Ни чего не имею против классных программистов, за одним исключением, что они не думают, что будет с их софтиной лет эдак через 10-20, именно потому, потому что она классно и правильно написана.)

Как идею я предложил test-driven development, на что мне замахали руками и сказали, что девелоперы на это не пойдут.

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

У нас ситуация такая:
Есть новые, в основном Web Based applications, которые взаимодействуют с legacy applications вплоть до mainframe + еще есть ряд всяких тулов написаных на Java, .NET. Все это еще взаимодействует с разными Seibel applications, SAP и тд. Вобщем тоже полный набор. Все это создавалось и создается только для собственных нужд.

Для всех этих систем написаны сотни и сотни test cases которые, мы автоматизируем сейчас в основном по принципу наиболее часто executed, smoke test and regression.

Весь development и testing у нас поделены на так называемые Streams, в каждом stream, test case может обращаться к разным системам - до 5 разных систем в одном test case.

Задача соответственно стояла в том, что test tool "узнавала" интерфейсные объекты всех систем. Мы используем QTP (QuickTest Professional) Раньше это был Mercury tool, сейчас это HP. Этот тул поддерживает практически все основные development platforms. Весь development and execution у нас происходит в нескольких test environments.

Test data, тоже у нас не совсем вещь надёжная, data refresh переодически происходит, тестеры, которые в ручную тестируют могут как то данные изменить, поэтому у нас так же автоматизирован процесс data creation. То есть если нужен customer с определёнными products, то сначала создаётся customer, потом ему "продаются" некие products. Все это бежит автоматом, создаются Account IDs, Customer IDs, Product IDs и прочее, все это на лету фиксируется и используется в дальнейших шагах тест кейса и мы уже не зависим ни от кого с точки зрения данных.

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

[Meadie]

Вопрос тестировщикам про программы для тестирования (хотя сдаётся мне, что вопрос к программистам).

Суть следующая, есть зоопарк программ и баз написанных на фиг знает каком старье (но под Win), всё это не плохо бы пропускать через regression testing время от времени, но не понятно как. Т.е. закупить что-то типа Rational Robot и не париться оно бы конечно здорово, только всё уже настолько неуправляемое, что разные приложения могут модифицировать тестовые данные для других программ (а также некоторые данные, например, котировки валют, могут изменяться во времени), хотя такого в test environment по уму быть не должно. Однако происходит. Как должно быть по уму я знаю/видел в реале, однако это не применимо к компаниям где вначале программят, а потом думают. (Ни чего не имею против классных программистов, за одним исключением, что они не думают, что будет с их софтиной лет эдак через 10-20, именно потому, потому что она классно и правильно написана.)

Как идею я предложил test-driven development, на что мне замахали руками и сказали, что девелоперы на это не пойдут.

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

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

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

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

[Sheen]

Похоже тесты PISA подтверждаются. Извини, но я в своём постинге уже писал - "... Как должно быть по уму я знаю/видел в реале, однако это не применимо к компаниям где вначале программят, а потом думают. ... Поделитесь опытом, чего в других компаниях делается на эту тему."

Ответ на свой вопрос я частично нашёл на последней конференции, где было сказано, что в Канаде только 5% компаний уровня CMM3 (это о чём ты пишешь). Остальные 95% - это бардак на коленках. Наша входит в эти 95.

[Meadie]

Похоже тесты PISA подтверждаются. Извини, но я в своём постинге уже писал - "... Как должно быть по уму я знаю/видел в реале, однако это не применимо к компаниям где вначале программят, а потом думают. ... Поделитесь опытом, чего в других компаниях делается на эту тему."

Ответ на свой вопрос я частично нашёл на последней конференции, где было сказано, что в Канаде только 5% компаний уровня CMM3 (это о чём ты пишешь). Остальные 95% - это бардак на коленках. Наша входит в эти 95.

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

А что можно делать в компании с СММ2 или тем более СММ1 (бардак на коленках) - ясно как божий день. Когда нет процесса - все начинает зависеть исключительно от личностей. Если у вас умные, талантливые и квалифицированные менеджеры, программисты и тестировщики, то они могут быстро добиться очень хороших результатов, особенно, в условиях когда не давит процесс. И их работа будет заметно более эффективна, чем в условиях СММ3. Конечно, когда команда состоит из троечников, то в условиях бардака у них ничего хорошего не получится.

[Sheen]

Как я выше писал, своему начальству я предложил использовать WinFITRunnerLite, которое, на мой взгляд, хорошо подходит под концепцию "а нам лениво создавать документацию потому что у нас классные программисты". Эта тулза, как я понял, с одной стороны заставляет customer'ов формализовать свои требования, а не просто высказать эмоции, а девелоперам использовать test-driven и сверять результаты с пожеланиями. При минимуме документации.

А программисты то может быть и классные, но ни кто из них, если он конечно в здравом уме и памяти, не будет работать 20-30-40 лет на одну компанию, а рано или поздно уйдёт. И вот тогда в компании наступит полный "ой", потому что кроме этого отдельно взятого программера ни кто ни чего про систему не знает. Ситуация будет (есть!) очень похожа на слепых мудрецов и слона. А уж если на каждого слепого мудреца приходится по одному "животному" разного вида, которого они все называют "слоном", тогда вообще уже вешалка.

Вот так и работаем.

[Meadie]

Как я выше писал, своему начальству я предложил использовать WinFITRunnerLite, которое, на мой взгляд, хорошо подходит под концепцию "а нам лениво создавать документацию потому что у нас классные программисты". Эта тулза, как я понял, с одной стороны заставляет customer'ов формализовать свои требования, а не просто высказать эмоции, а девелоперам использовать test-driven и сверять результаты с пожеланиями. При минимуме документации.

А программисты то может быть и классные, но ни кто из них, если он конечно в здравом уме и памяти, не будет работать 20-30-40 лет на одну компанию, а рано или поздно уйдёт. И вот тогда в компании наступит полный "ой", потому что кроме этого отдельно взятого программера ни кто ни чего про систему не знает. Ситуация будет (есть!) очень похожа на слепых мудрецов и слона. А уж если на каждого слепого мудреца приходится по одному "животному" разного вида, которого они все называют "слоном", тогда вообще уже вешалка.

Вот так и работаем.

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

Что делать в подобной ситуации, понятно - работать:) В ситуации подобной вашей, куэи вместе с менеджерами и аналитиками, как раз и должны компенсировать отсутствие или несовершенство процесса. Ну а что делать с программистами, тоже ясно - кормить, чтобы не улетели.

[Sheen]

Кстати, во многих компаниях работающих по СММ3 и выше, есть специальные люди, которые отвечают за стыковку процессов - например у кастомера бардак, а у производителя софта СММ5:) - эти люди как раз и занимаются выявлением и формализацией требований кастомера.

Ну да, аналитики они называются, знаем про такое, "склеивали" уже.

Ладно, мы уже ударились в философию, это всё классно, но надо работать.