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

[Mimicry]

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

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

[Case]

Чем аргументировал то? :)

[KaNoN]

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

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

Один мой знакомый тестер, когда глянул на работу скриптов автоматизированного тестирования сказал: "Я понял, что мне здесь скоро делать будет нечего".

Но даже если использовать средства автоматизированного тестирования, то возникнут случаи, когда:
1) Некоторые действия и проверки нецелесообразно автоматизировать ( например проверка корректности печати )
2) Любые изменения продукта могут дестабилизировать работу скриптов автоматического тестирования - соответственно нужен человек, который это все должен фиксировать

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

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

[Mimicry]

Чем аргументировал то? :)

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

[Mimicry]

to KaNoN
спасибо, вы полностью подтверждаете мое мнение по этому вопросу..
видимо просто был приступ легкой паники

[KaNoN]

у них, мол 90% покрытия кода скриптами(которые пишут все те-же разработчики) и необходимости в тестировщиках просто нет..
(пишут они на Java..)

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

вот и делает вывод, что вскорости разработчик, который может написать автоматизированные скрипты, может заменить тестировщика

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

спасибо, вы полностью подтверждаете мое мнение по этому вопросу..
видимо просто был приступ легкой паники

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

[Mila]

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

Это они про юнит-тесты?

[Mimicry]

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

Это они про юнит-тесты?

ага.

[KaNoN]

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

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

[barancev]

Чем аргументировал то? :)

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

Да, он совершенно прав!!! Всё именно так и обстоит. Фокус в том, что количество работы, которую нужно сделать, при этом сохраняется прежним -- тестировать всё равно кому-то придётся. Вашему товарищу кажется, что если это делает человек, который условно называется "разработчик", это как-то меняет существо дела. Не меняет. Пусть нет должности тестировщика, но есть работа по созданию тестов, и её нужно выполнять. "Тестировщик" и "разработчик" -- это не должности, это роли, "шляпы". Когда человек пишет программу, он надевает шляпу с надписью "разработчик", а когда он тестирует эту программу, он надевает шляпу "тестировщик". Какая разница -- будут ли люди постоянно ходить в одних и тех же шляпах или будут их переодевать по мере надобности?

[Romich]

Это конечно было прикольно насчет того, что тестировщики вымрут
Может они начнут называться по другому, например, Senior Developer-QA, но работу придется делать ту же. Я думаю, что начальству понятно, что незачем платить программеру за работу, которую может сделать тестер за меньшие деньги.
И вообще, программеры всегда были в шоке, когда приложение, работавшее без сбоев год, сыпалось после 10 мин краш-тестинга протым незаурядным тестировщиком.
И еще история. Захотело как-то наше начальство выпустить свой TMS (программа учета рабочего времени). На тестирование решили ресурсы не тратить и потому все время разработки (0,5-1 месяц, не помню) это приложение не тестировалось. Предполагалось, что в процессе эксплуатации будут выявлены и пофикшены все баги. Пришел долгожданный день и нам в обязательном порядке дали еги на использование. Первое, что нам пришло в голову - всей командой тестировщиков (8) на счет три залогиниться. Короче вышло только у двоих, а для остальных сервер упал... доработали. Только запустили, я сразу вспомнил, что у меня есть средства по автоматизированному тестированию. Короче через несколько дней доработки опять нам сказали им пользоваться. Оказалось, что это приложение не проходит позитивного тестирования, т.е. не все функции можно выполнить, которые нужно делать... за неделю исправили. После этого мы начали его тестировать и начальство решило, что этот проэкт вести нецелесообразно...

Так что, товарищи, как вы видите, тестировщики действительно НЕ НУЖНЫ, без них все работает, а как только что-то попадает к ним в руки, то сразу ломается. Это самые настоящие вредители, которые действительно обречены на вымирание

[Shander]

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

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

[barancev]

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

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

Но я, конечно, не спорю с последним тезисом

[Bishop_]

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

[barancev]

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

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

[KaNoN]

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

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

[Green]

Коллеги!

Очень интересная тема, только немного в другом аспекте.

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

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

Очень интересный вариан предлагает компания UniTesK. Думаю, что это самое перспективное направление в автоматизированном тестировании. Фактически строятся два описания системы: в операторах кода и в описателях логических элементов системы. При наложении их друг на друга, происходит сравнение поведения двух интерпритаций системы. Расхождение в поведении - повод для разбирательств.

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

Есть ли другие ветви развития? Алексей, ты у нас на самом "острие" науки. Может быть выскажешься по этому поводу?
;-)

[barancev]

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

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

[barancev]

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

Очень интересный вариан предлагает компания UniTesK. Думаю, что это самое перспективное направление в автоматизированном тестировании. Фактически строятся два описания системы: в операторах кода и в описателях логических элементов системы. При наложении их друг на друга, происходит сравнение поведения двух интерпритаций системы. Расхождение в поведении - повод для разбирательств.

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

Есть ли другие ветви развития? Алексей, ты у нас на самом "острие" науки. Может быть выскажешься по этому поводу?

К сожалению, мы не на другой ветви развития. Мы на той же, просто немного впереди

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

Но если посмотреть на то, что сейчас предлагает большинство производителей инструментов тестирования, можно видеть, что основной маркетинговый удар наносится именно по простым задачам. Записал скрипт -- воспроизвел его. Быстро, эффектно.

Но отрезвление наступает достаточно быстро. После того, как записана сотня-другая скриптов, которые нужно поддерживать, вся мишура отпадает и начинается нормальная работа -- программирование в среде QTP или RFT или TC. Создаются библиотеки поддержки, нарабатываются шаблоны и приемы, всё как в нормальном программировании.

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

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

Эта проблема носит вообще не технический характер. Ни UniTESK, ни какое бы то ни было иное техническое решение не позволят её решить. Вот это и есть, на мой взгляд, иная ветвь развития, которая могла бы дать качественный скачок, прорыв. Но как это сделать???

[KaNoN]

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

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

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

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

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