Доверить проектирование 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.»
Так что со знакомством припозднились недельки на три, а для обзорной статьи маловато.
гуру могут подсказать, когда связка rails 3 + ruby 1.9.x (2?) будет к продакшену готова?
Смотря, что под этим подразумевать… Для активных гуру она и сейчас уже готова, а тем, у кого нет желания самостоятельно ринуться в бой с возможными проблемами, возможно имеет смысл подождать пока выйдет Ruby EE на основе 1.9.x, как признание окончательной готовности для продакшена.
Какие могут быть истории успеха, если релиз вышел только вчера вечером? Подожди хоть месяц с подобными вопросами, пока первые проапдейтившиеся убедятся в отсутствии или наличии подводных камней…
Ты смысл цитаты не понял, она как раз про то, что на любом языке можно программировать как надо(аля совершенный код), а не как диктуют ограничения языка.
Вам кажется это мало? В городских розетках максимальный ток обычно ограничивают до 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.»
Так что со знакомством припозднились недельки на три, а для обзорной статьи маловато.
Смотря, что под этим подразумевать… Для активных гуру она и сейчас уже готова, а тем, у кого нет желания самостоятельно ринуться в бой с возможными проблемами, возможно имеет смысл подождать пока выйдет Ruby EE на основе 1.9.x, как признание окончательной готовности для продакшена.