Что самое интересное, всё как раз с точностью до наоборот:
RoR превосходно подходит для создания сложных веб-приложений, а для создания простеньких сайтов подойдут скорее php-шные CMS'ки.
Необязательно, есть же такие слова, как «жюри», «каракули», «глясе», «пенсне» и др., которые прижились и без суффиксов.
Хотя всё равно, слова то не русские, а заимствованные.
И «юзабилити» и «эргономика» — оба заимствованные слова и в этом плане ничем кроме базового языка не отличаются.
Просто «грекофилы» теперь уже противостоят не «латинству», а «англицизму», не первый век уж буйствуют :-)
Доверить проектирование GUI тестеру — всё равно что доверить обезьяне управлять танком и не важно какой процент от кода приходится на долю UI, на его долю в любом случае приходится 100% взаимодействия с пользователем.
Научитесь уже проигрывать в споре достойно. Ваша точка зрения уже давно признана в корне ошибочной. Обратитесь уже наконец к мировому опыту IxDA, если ума хватит.
> у программиста, который зажат в рамках одного модуля
Это уж слишком проектнозависимо, мне не встречались проекты, в которых программисты работали только над одним модулем, как будто зашоренные.
Это просто плохой пример организации работы программистов.
> Я не согласен с тем, что программисты прекрасно знают все возможные фолтовые случаи
Ну не то чтобы «прекрасно знают», но как минимум догадываются при каких обстоятельствах посыпятся ошибки. Попробуй попроси у программиста, не занятого в проекте, прочитав спецификацию, назвать 20 мест, где могут возникнуть проблемы. Особого труда это для него составить не должно, при этом в 12-15 из 20 названных мест, ты потом реально найдёшь баги. А всё потому, что каких-то уникальных багов на практике встречается крайне мало и даже не в каждом проекте.
> бывают утечки памяти под нагрузкой, проблемы синхронизации в многопоточных приложениях
Так это как раз одни из самых очевидных случаев, в Топ-20 они будут одними из первых, конечно если спека предусматривает мультипоточность и немонопольный доступ к приложению :-)
> плох тот тестировщик, который не умеет программировать ;)
Оно может и так, но к сожаленью 80% тестировщиков даже базовых основ программирования не знают, куда уж там до умения…
> почему Вы считаете, что квалификация хорошего тестировщика ниже квалификации разработчика? Как же он тогда будет проверять результат?
Так дело в том, что результат работы программиста — это код, а тестировщики проверяют отнюдь не код, а реакцию программы на действия пользователя, поэтому им достаточно чтобы квалификация была выше чем у пользователя, а не выше чем у программиста.
Очень похоже, что Вы описываете должность, совмещающую обязанности инженера по качеству, больше известны как QA, и бизнес-аналитика (Business Analyst). Только это аж 2 другие профессии. Тестировщики (Software Test Engineer) не должны заниматься тем, что вы выше указали, это не входит в их должностные обязанности.
Кстати, мне довелось работать в компании, где были представители всех 3 вышеназванных профессий, вот там бюрократия то была… хотя сейчас не об этом. Они кстати все отличались и по уровню знаний и по уровню зарплат.
Поэтому мне в голову не приходило, что вы под тестировщиками имеете в виду людей, которые по вашему описанию аж на 3 ставки (SwT, QA, BA) работают. Я всё-таки считаю такое именование абсолютно некорректным.
работа программиста заключается в том, чтобы написать код который будет решать поставленную задачу (обычно четко понятную) и выполняться в рамках каких-то ограничений (тоже обычно оговоренных).
Далековато от истины, «чётко» известно что надо сделать, только сложность в том, что надо придумать как это сделать.
Т.е. для тестировщика единственной чётко поставленной задача будет «найти все несоответствия спецификации и здравому смыслу». А у программистов подобных «чётко» поставленных задач по несколько штук в день.
Задача тестировщика, мало того, что проверить, что код работает именно так как планировалось
ну это совсем тривиальная часть. согласны?
но и еще придумать случаи в которых программа может работать не правильно, и не только придумать а и заставить программу повести себя не правильно.
А вот тут у программистов преимущество, они прекрасно знают все эти случаи и уж тем более знают, что надо ввести чтобы получить ошибку, просто никогда не будут гонять по этим сценариям свою программу, т.к. это неосновной сценарий и т.к. для этого есть тестировщики.
Ничего нетривиального для программистов в этой части работы тестировщиков тоже нет.
В добаков не плохо еще и убедиться, что программа верно обрабатывает ошибки и исключительные ситуации.
Ну по найденному сценарию проверить реакцию программы — это совсем тривиально.
я никогда в жизни не видел идеальных спецификаций.
Идеальная, не идеальная, а формальную проверку на соответствие спецификации тестировщики обязаны делать для каждого минорного релиза.
Для примера, вот вам пара вакансий.
А ничего, что QA Engineer и Software Test Engineer (тестировщик) — это разные профессии?
Как обычно, вся дискуссия перестала иметь смысл, раз вы соединили эти 2 профессии в нечто единое и непонятное.
Вам понятие user experience testing ничего не говорит?
Говорит, это когда писали, писали программу, уже почти дописали и вдруг как вспомнили «А ей же люди будут пользоваться», «рюшечек» на самые уродливые места понавесили и поставили штамп «User Friendly».
Никто на этапе тестирования не даст менять концепцию UI, т.к. это будет стоить в 2 раза больше, чем то что уже есть.
А вот Вам понятие Interaction Design явно не знакомо. Советую ознакомиться.
часто GUI появляется намного позже, чем функциональность.
А кто спорит, именно из-за такого подхода большинство программ имеют уродский GUI. Всем известна гонка функциональных возможностей, которыми пользуются от силы 0.1% пользователей, зато остальных 99.9% эти излишние функции только в тоску вгоняют.
Только при таком херовом подходе к разработке, никакое тестирование уже не поможет.
А это ничего, что ГУЙ должен быть не только тыкабелен, но и юзабелен? А чтобы он был юзабельным и нужны тестеры
Для этого нужны проектировщики взаимодействия и специалисты по юзабилити, а не тестировщики. Причём их работа происходит до того как будет написана первая строчка кода, а когда программа уже написана о юзабилити думать уже поздно. Так что тестировщики тут ничем не помогут, разве что сделают запрос на косметические улучшения.
в нормальных компаниях нет кланов разработчиков и тестировщиков, а есть айтишники
Не знаю почему отделы стали называться кланами, но «айтишники» — это полный аут…
Если в компании работают люди без определённых должностных обязанностей, которые и принтер чинят, и баги ищут, да ещё и код ревьювят, то ничего нормального в такой компании нет.
А чего плохого в том, чтобы платить кодерам в 1.5 раза меньше чем архитекторам?
Ничего плохого. Скорее даже градация ещё более детальная: кодер получает в 1.5 раза меньше, чем программист, а программист — в 1.5 раза меньше, чем архитектор. Понятно, что все профессии нужны, все профессии важны, но это не значит, что у всех должна быть одинаковая зарплата.
У нас задачи, зачастую, намного более нетривиальны и сложны.
Можно примеры? Я работал с тестировщиками и даже читал, интереса ради, их учебник «Тестирование dot com», поэтому суть вашей работы понимаю, но ваше утверждение кажется мне довольно комичным.
Да, у вас муторная и даже, можно сказать, психологически трудная (пункт за пунктом десятки раз проходить по всей спецификации) работа, но чтобы в ней нашлось что-то нетривиальное для программиста… Мне реально интересны примеры таких уникальных случаев.
Меня вообще такой подход удивляет — давайте будем платить тестировщикам в полтора, в два, в три раза меньше чем разработчикам
А что плохого в том, чтобы платить тестировщикам в 1.5 раза меньше, чем программистам? Это всё-таки разные профессии, с разными требованиями по квалификации. Причём квалификация программиста включает квалификацию тестировщика как небольшое подмножество. Поэтому программисты и не любят выполнять функции тестировщиков, т.к. для них они слишком скучны и неинтересны, в силу своей тривиальности… Правда, ещё нужно учитывать, что программист может тестировать только те проекты или те части проекта, над которыми сам не работает.
К тому же экономическая сообразность QA отделов сводится как раз к тому, чтобы снять с программистов задачи интеграционного и функционального тестирования и поручить их людям с более низкой квалификацией и зарплатой. А если прибавить сюда проблемы с поиском тестировщиков, уровень знаний которых будет выше, чем просто «продвинутый юзер», то возможны варианты с зарплатами и в 2-3 раза меньше, чем у программистов. Но это уже скорее штатные бета-тестеры, чем тестировщики.
Моей задачей было познакомить Ruby сообщество с интересным GEM.
Да, бросьте. С этим гемом Ruby сообщество уже познакомил DHH в сообщении о выходе RoR 3 RC: weblog.rubyonrails.org/2010/7/26/rails-3-0-release-candidate
Обратите внимание на пункт «Support for the MySQL2 gem, which will take care of MySQL encoding issues on Ruby 1.9.2.»
Так что со знакомством припозднились недельки на три, а для обзорной статьи маловато.
RoR превосходно подходит для создания сложных веб-приложений, а для создания простеньких сайтов подойдут скорее php-шные CMS'ки.
Хотя всё равно, слова то не русские, а заимствованные.
И «юзабилити» и «эргономика» — оба заимствованные слова и в этом плане ничем кроме базового языка не отличаются.
Просто «грекофилы» теперь уже противостоят не «латинству», а «англицизму», не первый век уж буйствуют :-)
Вам кажется это мало? В городских розетках максимальный ток обычно ограничивают до 6 А, а на большем уже предохранители должны срабатывать.
Для ярых ненавистников магии существует Python и Django.
Научитесь уже проигрывать в споре достойно. Ваша точка зрения уже давно признана в корне ошибочной. Обратитесь уже наконец к мировому опыту IxDA, если ума хватит.
Это уж слишком проектнозависимо, мне не встречались проекты, в которых программисты работали только над одним модулем, как будто зашоренные.
Это просто плохой пример организации работы программистов.
> Я не согласен с тем, что программисты прекрасно знают все возможные фолтовые случаи
Ну не то чтобы «прекрасно знают», но как минимум догадываются при каких обстоятельствах посыпятся ошибки. Попробуй попроси у программиста, не занятого в проекте, прочитав спецификацию, назвать 20 мест, где могут возникнуть проблемы. Особого труда это для него составить не должно, при этом в 12-15 из 20 названных мест, ты потом реально найдёшь баги. А всё потому, что каких-то уникальных багов на практике встречается крайне мало и даже не в каждом проекте.
> бывают утечки памяти под нагрузкой, проблемы синхронизации в многопоточных приложениях
Так это как раз одни из самых очевидных случаев, в Топ-20 они будут одними из первых, конечно если спека предусматривает мультипоточность и немонопольный доступ к приложению :-)
> плох тот тестировщик, который не умеет программировать ;)
Оно может и так, но к сожаленью 80% тестировщиков даже базовых основ программирования не знают, куда уж там до умения…
> почему Вы считаете, что квалификация хорошего тестировщика ниже квалификации разработчика? Как же он тогда будет проверять результат?
Так дело в том, что результат работы программиста — это код, а тестировщики проверяют отнюдь не код, а реакцию программы на действия пользователя, поэтому им достаточно чтобы квалификация была выше чем у пользователя, а не выше чем у программиста.
Кстати, мне довелось работать в компании, где были представители всех 3 вышеназванных профессий, вот там бюрократия то была… хотя сейчас не об этом. Они кстати все отличались и по уровню знаний и по уровню зарплат.
Поэтому мне в голову не приходило, что вы под тестировщиками имеете в виду людей, которые по вашему описанию аж на 3 ставки (SwT, QA, BA) работают. Я всё-таки считаю такое именование абсолютно некорректным.
Далековато от истины, «чётко» известно что надо сделать, только сложность в том, что надо придумать как это сделать.
Т.е. для тестировщика единственной чётко поставленной задача будет «найти все несоответствия спецификации и здравому смыслу». А у программистов подобных «чётко» поставленных задач по несколько штук в день.
ну это совсем тривиальная часть. согласны?
А вот тут у программистов преимущество, они прекрасно знают все эти случаи и уж тем более знают, что надо ввести чтобы получить ошибку, просто никогда не будут гонять по этим сценариям свою программу, т.к. это неосновной сценарий и т.к. для этого есть тестировщики.
Ничего нетривиального для программистов в этой части работы тестировщиков тоже нет.
Ну по найденному сценарию проверить реакцию программы — это совсем тривиально.
Идеальная, не идеальная, а формальную проверку на соответствие спецификации тестировщики обязаны делать для каждого минорного релиза.
А ничего, что QA Engineer и Software Test Engineer (тестировщик) — это разные профессии?
Как обычно, вся дискуссия перестала иметь смысл, раз вы соединили эти 2 профессии в нечто единое и непонятное.
Говорит, это когда писали, писали программу, уже почти дописали и вдруг как вспомнили «А ей же люди будут пользоваться», «рюшечек» на самые уродливые места понавесили и поставили штамп «User Friendly».
Никто на этапе тестирования не даст менять концепцию UI, т.к. это будет стоить в 2 раза больше, чем то что уже есть.
А вот Вам понятие Interaction Design явно не знакомо. Советую ознакомиться.
А кто спорит, именно из-за такого подхода большинство программ имеют уродский GUI. Всем известна гонка функциональных возможностей, которыми пользуются от силы 0.1% пользователей, зато остальных 99.9% эти излишние функции только в тоску вгоняют.
Только при таком херовом подходе к разработке, никакое тестирование уже не поможет.
Для этого нужны проектировщики взаимодействия и специалисты по юзабилити, а не тестировщики. Причём их работа происходит до того как будет написана первая строчка кода, а когда программа уже написана о юзабилити думать уже поздно. Так что тестировщики тут ничем не помогут, разве что сделают запрос на косметические улучшения.
Не знаю почему отделы стали называться кланами, но «айтишники» — это полный аут…
Если в компании работают люди без определённых должностных обязанностей, которые и принтер чинят, и баги ищут, да ещё и код ревьювят, то ничего нормального в такой компании нет.
Ничего плохого. Скорее даже градация ещё более детальная: кодер получает в 1.5 раза меньше, чем программист, а программист — в 1.5 раза меньше, чем архитектор. Понятно, что все профессии нужны, все профессии важны, но это не значит, что у всех должна быть одинаковая зарплата.
Можно примеры? Я работал с тестировщиками и даже читал, интереса ради, их учебник «Тестирование dot com», поэтому суть вашей работы понимаю, но ваше утверждение кажется мне довольно комичным.
Да, у вас муторная и даже, можно сказать, психологически трудная (пункт за пунктом десятки раз проходить по всей спецификации) работа, но чтобы в ней нашлось что-то нетривиальное для программиста… Мне реально интересны примеры таких уникальных случаев.
А что плохого в том, чтобы платить тестировщикам в 1.5 раза меньше, чем программистам? Это всё-таки разные профессии, с разными требованиями по квалификации. Причём квалификация программиста включает квалификацию тестировщика как небольшое подмножество. Поэтому программисты и не любят выполнять функции тестировщиков, т.к. для них они слишком скучны и неинтересны, в силу своей тривиальности… Правда, ещё нужно учитывать, что программист может тестировать только те проекты или те части проекта, над которыми сам не работает.
К тому же экономическая сообразность QA отделов сводится как раз к тому, чтобы снять с программистов задачи интеграционного и функционального тестирования и поручить их людям с более низкой квалификацией и зарплатой. А если прибавить сюда проблемы с поиском тестировщиков, уровень знаний которых будет выше, чем просто «продвинутый юзер», то возможны варианты с зарплатами и в 2-3 раза меньше, чем у программистов. Но это уже скорее штатные бета-тестеры, чем тестировщики.
Да, бросьте. С этим гемом Ruby сообщество уже познакомил DHH в сообщении о выходе RoR 3 RC: weblog.rubyonrails.org/2010/7/26/rails-3-0-release-candidate
Обратите внимание на пункт «Support for the MySQL2 gem, which will take care of MySQL encoding issues on Ruby 1.9.2.»
Так что со знакомством припозднились недельки на три, а для обзорной статьи маловато.