Сообщений в теме: 42

[Shander]

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

Конечно, не рождаются. Я спорю с принципом "смены шапок". От смены шапки проф. девелопер в проф. тестера не превратится.

Например, есть 2 варианта:
1. Профессиональный тестер, начитанный по теории тестирования и имеющий за плечами год опыта тестирования различных продуктов.
2. Профессиональный девелопер, знающий наизусть (это гипербола) Кнута-Страуструпа?.

У кого, по-Вашему, больше шансов найти действительно сложный баг (при прочих равных)?
Первый, как минимум на интуиции уже выигрывает.

[SALar]

Ну дык, юнит тестами тестирование не ограничивается. Если бы разработчики еще и регрессионкой занимались, нагрузочное тестирование проводили, то на саму разработку времени не осталось бы.

Короче говоря, твой знакомый скорее всего не был задействован в крупных "долгоирающих" проектах и не имеет должного представления о данном вопросе

А что регрисионные тесты нельзя реализовать через юнит тесты? Собственно, одна из главных задач юнит тестов - регрессионное тестирование. Да и нагрузочное тестирование часто проводится при помощи юнит тестов.

И действительно часто созданием этих тестов занимаются люди, в трудовом договоре которых написано "программист". Только вот во время создания тестов (не кодирования, а создания) они выполняют роль тестировщиков. Или, как образно выразился Алексей, "надевают шляпу тестировщика" . Верно и обратное. Человек, в трудовом договоре которого записано тестировщик, при кодировании тестов "надевает шляпу кодера (программиста)". Совершенно неважно в чем он кодирует, в QTP или nUnit.

PS. IMHO кодирование тестов одна из простых задач в тестировании.

Это конечно было прикольно насчет того, что тестировщики вымрут 
Может они начнут называться по другому, например, Senior Developer-QA, но работу придется делать ту же. Я думаю, что начальству понятно, что незачем платить программеру за работу, которую может сделать тестер за меньшие деньги.

Кто сказал что за меньшие? По моей статистике тестировщик получает больше чем программист, при равной с ним квалификации. Другой вопрос, что у программиста потолок зарплаты повыше.

[SALar]

Есть проекты, где нет тестеров.
Есть проекты, где нет программистов.
Есть проекты, где нет аналитиков.
Есть проекты, где нет ПМ.
Есть проекты, где нет конечного пользователя.
Есть проекты, где нет заказчика.

Это тоже вымирающие виды?

[SALar]

1. Профессиональный тестер, начитанный по теории тестирования и имеющий за плечами год опыта тестирования различных продуктов.

Это не профессионал. Это начинающий.

2. Профессиональный девелопер, знающий наизусть (это гипербола) Кнута-Страуструпа?.

Тоже начинающий.

Конечно, не рождаются. Я спорю с принципом "смены шапок". От смены шапки проф. девелопер в проф. тестера не превратится.

У кого, по-Вашему, больше шансов найти действительно сложный баг (при прочих равных)?
Первый, как минимум на интуиции уже выигрывает.

Когда они будут искать ошибку, то оба будут "тестировать", или "выполнять роль тестировщика".

Шансы найти ошибку зависят от типа ошибки.

[SALar]

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

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

Как бы это помягче сказать, чтобы никого не обидеть...
Эти инструменты и библиотеки немного отстают, от того, что сейчас имеют программисты. Примерно как гужевая повозка от автомобиля. Нет конечно и там и там есть четыре колеса. Но на этом, собственно, сходство и заканчивается.
Если хотите возразить, то скажите:
1) Где я могу приобрести библиотеку для тестирования стандартных операций (например файловых операций)?
2) В каком средстве я могу рисовать диаграммы тестовых классов, с наследованием от классов программы? И еще мне нужна возможность генерации кода и реинжиниринга.
3) В каком средстве я могу рисовать диаграммы тестовых сценариев с наследованием от прецендентов?

Для тех, кто занимается ручным тестированием, такой возможности, естественно, нет.

Не совсем так. И там и там есть возможность переиспользования тесткейсов. На этом возможности переиспользования заканчиваются.

[Shander]

Когда они будут искать ошибку, то оба будут "тестировать", или "выполнять роль тестировщика".

Шансы найти ошибку зависят от типа ошибки.

Безусловно. Потому я и написал - при прочих равных.

[KaNoN]

Как бы это помягче сказать, чтобы никого не обидеть...
Эти инструменты и библиотеки немного отстают, от того, что сейчас имеют программисты. Примерно как гужевая повозка от автомобиля. Нет конечно и там и там есть четыре колеса. Но на этом, собственно, сходство и заканчивается.
Если хотите возразить, то скажите:
1) Где я могу приобрести библиотеку для тестирования стандартных операций (например файловых операций)?

Все зависит от средства, которым пользуешься (например библиотека, реализованная для WinRunner не подойдет для SilkTest, например). Но разве невозможно реализовать такую библиотеку? Более того, некоторые наработки выкладываются в Интернете, но на данный момент автоматизированное тестирование еще является экзотикой и поэтому такие библиотеки не получают широкого распространения ( у них небольшой круг потребления).

2) В каком средстве я могу рисовать диаграммы тестовых классов, с наследованием от классов программы? И еще мне нужна возможность генерации кода и реинжиниринга.
3) В каком средстве я могу рисовать диаграммы тестовых сценариев с наследованием от прецендентов?

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

[Mila]

Но разве невозможно реализовать такую библиотеку? Более того, некоторые наработки выкладываются в Интернете, но на данный момент автоматизированное тестирование еще является экзотикой и поэтому такие библиотеки не получают широкого распространения ( у них небольшой круг потребления).

Мне кажется, что экзотика автоматизации - это не основная причина.... иначе бы никто не стал заморачиваться и создавать тулы для автоматизации в таком количестве.
Опять же ИМХО, при создании подобной библиотеки есть сложность в элементарной формулировке задачи: что должна уметь библиотека - тут будет море пожеланий. А выделить из этого моря какие-то более менее универсальные вещи - еще та задача...

Как пример, можно обсудить предложенные "стандартные файловые операции". Кто и что под ними подразумевает? Что именно будем реализовывать?

PS: если сможем сформулировать, то можно и создать эту библиотеку тут на портале... для каждого тула.

[KaNoN]

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

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

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

[Mila]

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

Ню... программеры в аналогичной ситуации просто создавали библиотеки для каждого языка программирования, потом придумали COM, потом .Net, а так же ввели стандарты (типа, xml и иже с ними). Так что готовые решения уже есть.

[KaNoN]

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

А вообще библиотеки в принципе встречаются и для последних, но не часто

[SALar]

Но разве невозможно реализовать такую библиотеку? Более того, некоторые наработки выкладываются в Интернете, но на данный момент автоматизированное тестирование еще является экзотикой и поэтому такие библиотеки не получают широкого распространения ( у них небольшой круг потребления).

Мне кажется, что экзотика автоматизации - это не основная причина....

Экзотика? Ну,ну.
Я не знаю сколько лет существуют автоматические тесты. Может быть 20 лет, может быть 30, может быть 40.
Одни из них дают больший ROI, другие меньший. На мой скромный взгляд, наибольшая отдача у такого вида автоматизированного тестирования как "ежедневная сборка". Этому тесту точно больше 10 лет.

PS. Под автоматизированным тестированием я понимаю не только тесты закодированные с помощью QTP, RR, TC, WR и прочее, но и любые другие тесты, выполняющиеся в автоматическом режиме.

[SALar]

2) В каком средстве я могу рисовать диаграммы тестовых классов, с наследованием от классов программы? И еще мне нужна возможность генерации кода и реинжиниринга.
3) В каком средстве я могу рисовать диаграммы тестовых сценариев с наследованием от прецендентов?

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

Лет 20-30 назад программисты тоже не знали, есть ли в этом необходимость. Теперь знают.

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

[KaNoN]

Лет 20-30 назад программисты тоже не знали, есть ли в этом необходимость. Теперь знают.

Я имел ввиду то, что не все средства автоматизированного тестирования работают с данными сущностями. Соответственно и диаграмм на них особо не порисуешь

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

Странно, в SilkTest версии 6.5 уже был компонент поддерживающий С (я так предполагаю, что это то, о чем ты говоришь). Я его в действии не испытывал (в той поставке, что мы получили, этот компонент не включался), но такая поддержка вроде как уже имеет место.

[KaNoN]

Но разве невозможно реализовать такую библиотеку? Более того, некоторые наработки выкладываются в Интернете, но на данный момент автоматизированное тестирование еще является экзотикой и поэтому такие библиотеки не получают широкого распространения ( у них небольшой круг потребления).

Мне кажется, что экзотика автоматизации - это не основная причина....

Экзотика? Ну,ну.
Я не знаю сколько лет существуют автоматические тесты. Может быть 20 лет, может быть 30, может быть 40.
Одни из них дают больший ROI, другие меньший. На мой скромный взгляд, наибольшая отдача у такого вида автоматизированного тестирования как "ежедневная сборка". Этому тесту точно больше 10 лет.

Сравни количество людей, занимающихся автотестингом с количеством людей,
пишущих на том же С++, C# и прочее. Затем сопоставь вероятность найти более-менее знающего специалиста в этих областях. То, что автоматизированное тестирование придумано не вчера, это понятно. Но далеко не каждый человек, работающий в IT-сфере имеет четкое представление о том, что это такое и "с чем его едят". На данный момент не каждая компания может себе позволить такое удовольствие. Это я подразумевал под "экзотикой".

PS. Под автоматизированным тестированием я понимаю не только тесты закодированные с помощью QTP, RR, TC, WR и прочее, но и любые другие тесты, выполняющиеся в автоматическом режиме.

Естественно, что все начиналось с каких-то самодельных программ, которые как-то тестировали некоторое приложение. QTP, RR, TC, WR и прочие просто предоставляют более универсальный механизм такого тестирования.

[Yury]

А если вспомнить историю?

-----------------------------------------------

Лет 15 назад все говорили о "CASE tools".
Некоторые даже утверждали, что скоро эти самые "CASE tools" разовьются до того, что
1) ими будут орудовать простые бизнес аналитики
2) "CASE tools" сами будут выдавать работающий код, а программисты будут совсем не нужны.

Как оказалось, слухи о вымирании программистов были несколько преувеличены.

-----------------------------------------------

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

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

-----------------------------------------------

Сейчас много говорят о "Service Oriented Architecture" - по сути, это реинкарнация компонентов, реализованная через интерфейс веб сервисов.

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

-----------------------------------------------

Предсатвители школ "Экстрим программирования" и "Test Driven Development" говорят, что так как сами программисты будут готовить автоматизированные "Acceptance Test Cases", то тестировщики теперь будут не нужны.

-----------------------------------------------

Могут ли современные прогнозы о вымирании программистов и тестировщиков сбыться?

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

Хотя, как мне кажется, лет через десять - двадцать положение и начнёт постепенно меняться.


Юрий

[KaNoN]

Ага, еще вспомним, что 640 Кб хватит для каждого
Естественно, средства программирования со временем позволяют выполнять некоторые задачи проще, чем раньше. Но при этом и сами приложения усложняются. Поэтому программистам вымирание пока не грозит. Что до тестеров, то им работа найдется все-равно. В своё время они выделились как отдельная штатная должность - соответственно необходимость в этом была. Я не думаю, что в ближайшее время необходимость в них отпадет. Из "заменитель", программы автоматического тестирования, постоянно нуждаются в поддержке, а также, зачастую, забирают слишком много времени, чтобы ими занимался кто-то из основных разработчиков

[SALar]

Я имел ввиду то, что не все средства автоматизированного тестирования работают с данными сущностями. Соответственно и диаграмм на них особо не порисуешь

Именно. Не работают.

Странно, в SilkTest версии 6.5 уже был компонент поддерживающий С (я так предполагаю, что это то, о чем ты говоришь). Я его в действии не испытывал (в той поставке, что мы получили, этот компонент не включался), но такая поддержка вроде как уже имеет место.

* Базовый язык написания тестовых скриптов был С?
* И можно было напрямую обращаться к классам исходного кода? Хотя о чем я, это же С. Какие там классы... ?

А если это просто было распознавание контролов С, то спрашивается и что? Это еще в первой версии надо было делать.

[SALar]

Сравни количество людей, занимающихся автотестингом с количеством людей,
пишущих на том же С++, C# и прочее. Затем сопоставь вероятность найти более-менее знающего специалиста в этих областях. То, что автоматизированное тестирование придумано не вчера, это понятно. Но далеко не каждый человек, работающий в IT-сфере имеет четкое представление о том, что это такое и "с чем его едят". На данный момент не каждая компания может себе позволить такое удовольствие. Это я подразумевал под "экзотикой".

Согласен, профессиональные тестеры в нашей стране большая редкость.
Но и хорошие программисты тоже редкость. И далеко не каждая компания может себе позволить ПМа, умеющего планировать, аналитика, умеющего писать требования, и архитектора, знающего, ну например, плюсы и минусы GUID и автоинкрементных идентификаторов. А уж проекты, на которых есть все эти люди вообще редки, как животные занесенные в красную книгу.

Естественно, что все начиналось с каких-то самодельных программ, которые как-то тестировали некоторое приложение. QTP, RR, TC, WR и прочие просто предоставляют более универсальный механизм такого тестирования.

Visual Studio попала в разряд самописок? Или она не предоставляет фрейморка для создания автоматизированных тестов?
На мой взгляд, VS2005 сейчас лучшее средство для автоматизации тестирования. В частности потому, что она предоставляет "более универсальный механизм".
Плохо с записью действий пользователя? Что да, то да. Будем ждать очередного релиза.
IMHO Микрософт идет по правильному пути в деле автоматизации процессов обеспечения качества ПО.

[SALar]

Согласен, что ни программистам, ни тестерам вымирание пока не грозит.

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

Да не в программе,нуждающейся в поддержке дело!
Тестер - это не тот, кто кодит тесты. И не тот, кто кликает мышкой. И то и другое тривиально (если не сражаться с инструментом). Тестер сценарии тестирования пишет. Вот это сложно. И это то, что нет смысла перекладывать на программиста. Слишком долго учить.
Вы что всерьез думаете, что для программера проблема закодить тестовые скрипты? Не смешите меня. Здесь они тестеров уделывают как бог черепаху. А вот с разработкой тестовых сценариев ситуация обратная.