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

[Darkus]

Умение программировать и знание какого-то языка программирования или методологии - это разные вещи. Человек который "умеет пару строк кода для авто-тестов наваять" и который не самосовершенствуется - не может называться *хорошим* тестером. А речь о таких людях. Если он хороший тестер, но еще неопытный, то через какое-то время он будет с легкостью писать авто-тесты. А еще через какое-то время сможет и свой фрэймворк сделать.

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

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

Здесь я с вами не совсем согласен. Если вы для тестирования такого ПО наберете людей, которые до этого не написали не строки кода - провал обеспечен, согласен. Если в группу тестирования приходит новый человек, хороший опытный тестер - он научится всему чему надо.

А попробуйте объяснить тёте за 50 - что такое кодить?
Она прекрасно умеет делать своё дело - читать спецификацию и повторять эту работу. Она вполне способна найти ошибки и она отрабатывает свои деньги. Но когда начинается думки - как этой тёте написать код... то тут приходите вы и она

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

А потом ещё и фреймворк напишет

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

А если

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

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

[LeshaL]

Хочу подрезюмировать, чтобы кучу цитат убрать. Не так уж у нас с вами взгляды и различаются.
1) Название топика "Нужно ли тестировщику знать языки программирования". Поэтому я и веду речь об этом. Если тестер хорош, в организации и планировании работ, в управлении людьми - то пусть совершенствуется в сторону мэнеджмента. Не надо тратить время на изучение ненужных языков программирования.

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

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

4) По поводу стремления к новому и распыления. Тут очевидно, что вы правы. Естесственно, если я сейчас работаю с Java и SQL, то и навыки надо преобретать соответственные (например различные БД и диалекты SQL, подходы к тестированию и тулы). Если я вдруг при этом заинтересуюсь C# и Web-программированием - то это будет несколько странно. Да еще и по шапке получу от начальника.

5) Идеально, я бы хотел, чтобы со мной в команде работали только "хорошие" тестеры. Такие, которым я могу доверить любую работу, в лубое время. Пусть один подольше делает, другой побыстрее. Но я буду спокоен за результат - мне не надо будет перепроверять их работу. Исходя из этого я и говорю, что умение программировать для тестера - это плюс. В настоящий момент в нашей команде все умеют автоматизировать тестирование, настраивать необходимый environment, анализировать результаты, писать тест-кейзы, гонять manual тесты итд. Кто-то в чем-то лучше других, но всегда может заменить или помочь любому.

6) Повторю сам себя - неумение программировать это не препятствие для того чтобы стать "хорошим" тестером. Но количество видов работ по тестированию, которые может работник выполнить - сокращается.

[Akeem]

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

[LeshaL]

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

Примеры в студию, пожалуйста!
Мне такое тяжело представить. Единственно, что приходит в голову, это когда при взгляде на код возникает вопрос "как, это еще и работь может?" :)

[Akeem]

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

Примеры в студию, пожалуйста!
Мне такое тяжело представить. Единственно, что приходит в голову, это когда при взгляде на код возникает вопрос "как, это еще и работь может?" :)

Самый яркий пример:
Мой знакомый тестировал одно приложение и нашел ошибку. Ну после исследования этой ошибки получилось так что она возникала из-за того что неправильно был указан адрес в памяти куда писались данные. Он об этом сказал девелам. Ну им не понравилось то что он такое нашел. Ну и как следствие нагрубили и сказали что ему нужно только искать ошибки, а не говорить в чем эти ошибки состоять и как их исправить.

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

[LeshaL]

Самый яркий пример:
Мой знакомый тестировал одно приложение и нашел ошибку. Ну после исследования этой ошибки получилось так что она возникала из-за того что неправильно был указан адрес в памяти куда писались данные. Он об этом сказал девелам. Ну им не понравилось то что он такое нашел. Ну и как следствие нагрубили и сказали что ему нужно только искать ошибки, а не говорить в чем эти ошибки состоять и как их исправить.

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

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

[Akeem]

Самый яркий пример:
Мой знакомый тестировал одно приложение и нашел ошибку. Ну после исследования этой ошибки получилось так что она возникала из-за того что неправильно был указан адрес в памяти куда писались данные. Он об этом сказал девелам. Ну им не понравилось то что он такое нашел. Ну и как следствие нагрубили и сказали что ему нужно только искать ошибки, а не говорить в чем эти ошибки состоять и как их исправить.

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

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

ну в некоторых компаниях как видите такое не приветствуется. Я не говорил тк именно такая политика была избрана компанией. Тестировщики искали только баги и репортили о них. А саму суть бага они не вникали.

[barancev]

Товарищи, а давайте расширим постановку вопроса. Нужно ли тестировщику знать SQL, если он тестирует приложение над базами данных? И не будет ли знание SQL ему мешать? Нужно ли тестировщику веб-приложений уметь читать исходники HTML? И не будет ли это знание ему мешать? Сейчас, в XXI веке, когда мало мальски программировать учат уже в школе, а в вузах и подавно, иногда даже в гуманитарных, почему именно знание или незнание языков программирования вызывает столь яростные споры? Я понимаю, спорили бы на форуме секретарш, нужно ли уметь писать макросы в экселе, или это мешает работе, но тестировщики же всё таки считают себя айти-специалистами :)

[SMITA]

Товарисчи!
Напомню, что вопрос не ставился как "Нужно ли знать...", он звучал "Чем конкретно это знание может помочь " и насколько оно должно быть глубоким. Я сейчас работаю с C#, и решила, что мне его знать надо. Правда не представляю пока, какие тесты я смогла бы на нем написать.

[Darkus]

По ходу, замечу, что бывают такие случаи, когда знания мешают.
Достаточно часто тестировщик делает поспешные выводы о природе бага.
И так прямиком в CR и пишет, мол сделал то-то, функция такая-то не работает, т.к. явно видно, что переполнение произошло.
Разработчик смотрит, вроде прав тестировщик и начинает копать вообще не в том направлении.
...
А неискушёныый тестировщик пишет просто - нажал кн."1", приложение исчезло.
...
Это палка о 2-х концах - знание сила, знания головная боль. :)

[rlabs]

Совершенно правильное утверждение о том, что тестировщику не стоит самостоятельно искать в коде и тем более описывать причину проблемы. Ибо без знания архитектуры это сделать очень проблематично. И дело даже не в том, что разработчик пойдет по неправильному пути (этого, скорее всего, не произойдет - программисты не такие дураки), а в том, что отношение к такому тестировщику будет описываться одной фразой: "Надо же, еще и указывает нам, что делать". Это совершенно не нужно ни тем, ни другим.

Лично мне представляется, что самое полезное, что может изучить тестировщик, работающий в основном с черным и серым ящиками - это любой удобный скриптовой язык. Perl, Python, Ruby - на выбор. В идеале это должен быть тот же язык, которым пользуется остальная команда для автоматизации своих задач. Скриптовой язык позволяет без особенных заморочек автоматизировать многие скучные задачи (вроде генерации тестовых данных) без привлечения дорогих инструментов или недешевого труда разработчиков. С языками высокого уровня имеет смысл разбираться только при тестировании белого ящика.

[barancev]

Достаточно часто тестировщик делает поспешные выводы о природе бага.
И так прямиком в CR и пишет, мол сделал то-то, функция такая-то не работает, т.к. явно видно, что переполнение произошло.

Это ему не знания мешают, а склонность к деланию поспешных выводов :)

[barancev]

Напомню, что вопрос не ставился как "Нужно ли знать...", он звучал "Чем конкретно это знание может помочь " и насколько оно должно быть глубоким. Я сейчас работаю с C#, и решила, что мне его знать надо. Правда не представляю пока, какие тесты я смогла бы на нем написать.

Знания должны быть настолько глубокими, насколько это необходимо, а необходимость определяется контекстом. Предположим, нужно тестировать MS Word, но не "кнопочки-менюшечки", а COM-интерфейс -- ну как тут обойтись без умения программировать?

[Darkus]

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

Полностью разделяю вашу точку зрения, Алексей.
Вспомнил, что как то уже размышлял над этим вопросом в блоге http://software-test...p;showentry=370

[VLana]

Считаю что знание SQL или языка программирования надо знать тестеру по мере необходимости. Я тестирую клиент-серверное приложение и для этого мне не надо знать ни SQL ни язык программирования, на котором написан клиент. При работе с приложением ведется лог действий, я копирую ошибку из лога и программисты сами определяют характер ошибки. Даже если я начну вникать в какой-нибудь Delphi скрипт, то он с легкостью уйдет из памяти за ненадобностью или при смене работы мне понадобятся знания другойго языка.

Во всяком случае я не понимаю наличие таких знаний при ручном тестировании GUI.

[Boltick]

Самый яркий пример:
Мой знакомый тестировал одно приложение и нашел ошибку. Ну после исследования этой ошибки получилось так что она возникала из-за того что неправильно был указан адрес в памяти куда писались данные. Он об этом сказал девелам. Ну им не понравилось то что он такое нашел. Ну и как следствие нагрубили и сказали что ему нужно только искать ошибки, а не говорить в чем эти ошибки состоять и как их исправить.

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

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

[Boltick]

Считаю что знание SQL или языка программирования надо знать тестеру по мере необходимости. Я тестирую клиент-серверное приложение и для этого мне не надо знать ни SQL ни язык программирования, на котором написан клиент. При работе с приложением ведется лог действий, я копирую ошибку из лога и программисты сами определяют характер ошибки. Даже если я начну вникать в какой-нибудь Delphi скрипт, то он с легкостью уйдет из памяти за ненадобностью или при смене работы мне понадобятся знания другойго языка.

Во всяком случае я не понимаю наличие таких знаний при ручном тестировании GUI.

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


Меня тут подмыло привести простой пример:

Есть форма 1 на ней заполняются поля А и В.
По нажатию кнопки ОК, значения полей записываются в БД
И есть форма 2, на которой показывается значение полей А и Б
Как определить на каком этапе произошла ошибка, если после нажатия кнопки на форме2 не показалось значение поля А?

Можно написать багу, что форма 2 не отображает значение поля А,
а можно пойти дальше, сделать SQL запрос с базу, посмотреть есть ли данные для полей А и Б в таблице, и если их нет, значит бага относится к функционалу Сохранения данных.

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

И все это нам дало совершенно поверхностное знание SQL.

Вот и думайте нужны ли вам дополнительные знания или нет.

[VLana]

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

[LeshaL]

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

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

[Boltick]

И все таки, у меня есть сомнения,должен ли это делать тестер.

Это вопрос квалификации тестера. Есть тестеры, которые просто семафорят, увидев проблему. Есть которые ее изучают и в результате дают полное описание проблемы. И это экономит время разработчику на фикс.

Простой экономический расчет:
Разработчик получает больше чем тестер. я думаю - это ФАКТ!!!
- если ему надо дополнительно исследовать баг, он потратит час времени на фикс.
- если все написано достаточно понятно и проблема видна сразу, то он потратит пол часа.
В итоге, за 8 часов, при нечетком описании бага разработчик пофиксит только 8 багов, а при четком и полном - вдвое больше.

Если компании необходимо делегировать это тестерам- пусть учат.

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

Вот и пришли к тому , что если нужны- учим, если нет- то нет.

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


ИМХО