Так вроде и статья отчасти об этом — что есть определённый тип людей, которым свобода/мощь консольных команд намного больше по душе, чем окошки и галочки.
Проблема оконных систем в том, что как только что-то там меняется (убирается галочка, радио-батончики становятся менюшкой и прочие изменения-переезды) — так сразу надо учиться(привыкать) заново, каждый раз матерясь, зачем они перевезли эту опцию из одного диалога в другой.
Да, на юниксе тоже бывает и конфиги по-разному называются и новые версии сервисов работают по-другому итд итп. Но есть уверенность, что (а) практически всегда можно вернуться к предыдущей знакомой версии и (б) с помощью хелпа и манула найти как это делается по-новому и слегка перенастроить какой-нибудь свой скриптик. И как запускал скрипт conf_service_xxx, так и запускаешь дальше.
Что делать если какая-то опция из гуя была убрана _совсем_ для меня загадка. Реестр разве что.
Если честно, я в штатах год назад поледний раз был. А в mountain view моё любимое место это Tied House (кстати, в первый раз неправильно написал, б-р-р-р). С удовольствием бы там посидел, но я сейчас в России, а на JavaOne в этом году не посылают :(.
Не думаю, что данный топик — место для рассуждений на эту тему. Здесь люди поздравляют друг друга с праздником, желают чего-нибудь.
Если хотите, можете поднять тему на тут или на software-testing.ru (в форуме или сообществе).
Лично я не понимаю, что мне делать с двумя _огромными_ белыми пятнами слева и справа от выдачи. Это, между прочим, почти 2/3 моего широкоформатника. И мне нравится когда там есть какая-то полезная информация!
Я понимаю, когда такой layout имеют ресурсы на которых надо много читать (взглядом, говорят, лучше захватывается) и которые идут на печать. Ну а тут-то зачем? Кол-во полезной информации на экране уменьшилось, количество прокручиваний увеличилось. Юзабильнее не придумать.
Полностью присоединяюсь к предыдущему высказыванию — по мне, так чем меньше багов — тем лучше.
А чтобы программисты были «вменяемые» призываю всех тестеров больше работать над собой: научиться правильно и аргументированно преподносить проблемы, изучать больше технических аспектов, чтобы говорить с программистами на одном языке и стараться помогать программистам, делая то, что им наиболее необходимо в данный момент. И вообще чувствовать себя полноценными разработчиками ПО. И будет вам и респект и уважуха.
Чтобы что-то найти надо знать, что искать ;)
Теперь, благодоря вашей наводке я знаю что и скать (уже нашёл). За что вам спасибо.
Под «беспарольным» входом я, в данном случае, говорил про вход по rsa ключу, пардон, если непонятно выразился. Как это все дело настроить я тоже знаю и давно пользуюсь. А вот на виндовой машине возникло в свое время препятствие в виде невозможности правильно выставить права под cygwin-ом. Проще было тогда забить и один раз на сессию вводить пароль. Вот собственно и всё, теперь, обладая новым знаниям, можно попробовать победить старую проблему.
О как интересно. Подскажите, пожалуйста, какие настройки SSH надо крутить (и на какой стороне) или киньте ссылкой. Хочу поэксперементировать и сделать «беспарольный» вход и с винды(cygwin-a) так же. А то там ничего не выходит — как раз из-за того, что права правильные не настроить.
Да, согласен, там несколько первых глав (штук 5) нужно читать и делать упражнялки. Этого вполне достаточно чтобы жить дружно с командной строкой и для написания несложных скриптов. Ведь куда ж на юниксе без знания grep и sed?
Говорю по собственному опыту. Мне для начала хватило, а за 6 лет вроде стандартные утилиты не поменялись (смайл).
Во! Как раз именно это-то и есть тестировщики.
Я вам и пытаюсь показать, что в мире уже давно начали происходить изменения. «Мир сдвинулся» (с) С. Кинг.
Просто, к сожалению, многие считают, что тестировщики сидят в отдельной комнате, ничего не знают, ничего не умеют, делают что-то странное (монотонно раз за разом прокликивают ГУЙ по спекам), но иногда пишут баги. И этом, отчасти, есть и вина тестировщиков.
Вы, судя по вашим словам, работали не с тестировщиками, а с кликерами. А книга, которую вы приводите в пример написана для тестировщиков, которые только начали работать. Книга для базового уровня знаний — весьма хорошая.
Еще для примера — работа программиста заключается в том, чтобы написать код который будет решать поставленную задачу (обычно четко понятную) и выполняться в рамках каких-то ограничений (тоже обычно оговоренных). Задача тестировщика, мало того, что проверить, что код работает именно так как планировалось, но и еще придумать случаи в которых программа может работать не правильно, и не только придумать а и заставить программу повести себя не правильно. В добаков не плохо еще и убедиться, что программа верно обрабатывает ошибки и исключительные ситуации.
И да, как ликбез — нормальный тестировщик, находясь в здравом умен не будет работать по принципу: пункт за пунктом десятки раз проходить по всей спецификации. Я вот никогда так не делал. Во-первых я никогда в жизни не видел идеальных спецификаций. Во-вторых — описанный вами алгоритм действий не эффективен.
Где написано, что нет должностных обязанностей?
Возможно вы не поверите, но бывают тестировщики которые понимают код программы или которые вместе с программистами и руководителями проекта совместно разрабатывают программу или находят место в коде где сломано или предлагают варианты решения проблемы или пишут небольшие программы позволяющие локализовать ошибки. Нет, они не пишут код продукта — это задача программистов, но участвуют в обсуждении архитектуры или функциональной наполнености продукта. Поэтому я и говорю, что и те и другие — разработчики.
Если вам не повезло встретиться с такими — не отчаивайтесь, как только попадёте в компанию, где тестировщикам платят достойную зп — сразу поймёте.
А чего плохого в том, чтобы платить кодерам в 1.5 раза меньше чем архитекторам? Далее по вашему тесту первого параграфа, заменяя слово «программист» на слово «архитектор», а слово «тестировщик» на слово «кодер».
А в словах "… для них они слишком скучны и неинтересны, в силу своей тривиальности" я вижу просто Ваше непонимание профессии тестировщик. У нас задачи, зачастую, намного более нетривиальны и сложны. В этом, кстати, и есть более глобальная проблема — большинство тестеров прекрасно понимают сложность работы программистов, а вот программисты (не все, к счастью) не понимают сложности работ по тестированию.
Вы, наверное, здесь сравниваете программистов с инженерами, а тестеров с фрезеровщиками, правильно?
На мой же взгляд (у меня был небольшой опыт работы программистом — ушёл так как скучно было) — работа тестера более интересная и творческая, чем работа программиста. Причём, я слышал подобные высказывания от других людей, работающих в тестировании, способных писать код и попробовавших и то и другое.
Но думаю, что дело даже не в самой работе, а в предласположенности людей к той или иной профессии. И поэтому в нормальных компаниях нет кланов разработчиков и тестировщиков, а есть айтишники, одни из которых специализируются на написании кода (программисты) и которые понимают, что тестирование вовсе не «прокликать GUI», а другие специализируются на поиске багов (тестеры), но если надо могут и код поревьювить. И те и другие — разработчики называются.
Поэтому и тестировщики у вас такие, которые в полтора-два раза хуже хороших :)
Меня вообще такой подход удивляет — давайте будем платить тестировщикам в полтора, в два, в три раза меньше чем разработчикам, а потом говорить: «тестировщики чего-то у нас не тянут, а те кто получше почему-то уходят (в другие компании, в разработчики, вообще из ИТ)».
Проблема оконных систем в том, что как только что-то там меняется (убирается галочка, радио-батончики становятся менюшкой и прочие изменения-переезды) — так сразу надо учиться(привыкать) заново, каждый раз матерясь, зачем они перевезли эту опцию из одного диалога в другой.
Да, на юниксе тоже бывает и конфиги по-разному называются и новые версии сервисов работают по-другому итд итп. Но есть уверенность, что (а) практически всегда можно вернуться к предыдущей знакомой версии и (б) с помощью хелпа и манула найти как это делается по-новому и слегка перенастроить какой-нибудь свой скриптик. И как запускал скрипт conf_service_xxx, так и запускаешь дальше.
Что делать если какая-то опция из гуя была убрана _совсем_ для меня загадка. Реестр разве что.
Если хотите, можете поднять тему на тут или на software-testing.ru (в форуме или сообществе).
Я понимаю, когда такой layout имеют ресурсы на которых надо много читать (взглядом, говорят, лучше захватывается) и которые идут на печать. Ну а тут-то зачем? Кол-во полезной информации на экране уменьшилось, количество прокручиваний увеличилось. Юзабильнее не придумать.
А чтобы программисты были «вменяемые» призываю всех тестеров больше работать над собой: научиться правильно и аргументированно преподносить проблемы, изучать больше технических аспектов, чтобы говорить с программистами на одном языке и стараться помогать программистам, делая то, что им наиболее необходимо в данный момент. И вообще чувствовать себя полноценными разработчиками ПО. И будет вам и респект и уважуха.
За поздравление, спасибо!
Теперь, благодоря вашей наводке я знаю что и скать (уже нашёл). За что вам спасибо.
Под «беспарольным» входом я, в данном случае, говорил про вход по rsa ключу, пардон, если непонятно выразился. Как это все дело настроить я тоже знаю и давно пользуюсь. А вот на виндовой машине возникло в свое время препятствие в виде невозможности правильно выставить права под cygwin-ом. Проще было тогда забить и один раз на сессию вводить пароль. Вот собственно и всё, теперь, обладая новым знаниям, можно попробовать победить старую проблему.
И спасибо, давно хотел настроить авторизацию, напомнили.
Говорю по собственному опыту. Мне для начала хватило, а за 6 лет вроде стандартные утилиты не поменялись (смайл).
www.books.ru/shop/books/82361
Я вам и пытаюсь показать, что в мире уже давно начали происходить изменения. «Мир сдвинулся» (с) С. Кинг.
Просто, к сожалению, многие считают, что тестировщики сидят в отдельной комнате, ничего не знают, ничего не умеют, делают что-то странное (монотонно раз за разом прокликивают ГУЙ по спекам), но иногда пишут баги. И этом, отчасти, есть и вина тестировщиков.
Для примера, вот вам пара вакансий.
spb.hh.ru/vacancy/3064218
spb.hh.ru/vacancy/3064231
Еще для примера — работа программиста заключается в том, чтобы написать код который будет решать поставленную задачу (обычно четко понятную) и выполняться в рамках каких-то ограничений (тоже обычно оговоренных). Задача тестировщика, мало того, что проверить, что код работает именно так как планировалось, но и еще придумать случаи в которых программа может работать не правильно, и не только придумать а и заставить программу повести себя не правильно. В добаков не плохо еще и убедиться, что программа верно обрабатывает ошибки и исключительные ситуации.
И да, как ликбез — нормальный тестировщик, находясь в здравом умен не будет работать по принципу: пункт за пунктом десятки раз проходить по всей спецификации. Я вот никогда так не делал. Во-первых я никогда в жизни не видел идеальных спецификаций. Во-вторых — описанный вами алгоритм действий не эффективен.
Возможно вы не поверите, но бывают тестировщики которые понимают код программы или которые вместе с программистами и руководителями проекта совместно разрабатывают программу или находят место в коде где сломано или предлагают варианты решения проблемы или пишут небольшие программы позволяющие локализовать ошибки. Нет, они не пишут код продукта — это задача программистов, но участвуют в обсуждении архитектуры или функциональной наполнености продукта. Поэтому я и говорю, что и те и другие — разработчики.
Если вам не повезло встретиться с такими — не отчаивайтесь, как только попадёте в компанию, где тестировщикам платят достойную зп — сразу поймёте.
А в словах "… для них они слишком скучны и неинтересны, в силу своей тривиальности" я вижу просто Ваше непонимание профессии тестировщик. У нас задачи, зачастую, намного более нетривиальны и сложны. В этом, кстати, и есть более глобальная проблема — большинство тестеров прекрасно понимают сложность работы программистов, а вот программисты (не все, к счастью) не понимают сложности работ по тестированию.
На мой же взгляд (у меня был небольшой опыт работы программистом — ушёл так как скучно было) — работа тестера более интересная и творческая, чем работа программиста. Причём, я слышал подобные высказывания от других людей, работающих в тестировании, способных писать код и попробовавших и то и другое.
Но думаю, что дело даже не в самой работе, а в предласположенности людей к той или иной профессии. И поэтому в нормальных компаниях нет кланов разработчиков и тестировщиков, а есть айтишники, одни из которых специализируются на написании кода (программисты) и которые понимают, что тестирование вовсе не «прокликать GUI», а другие специализируются на поиске багов (тестеры), но если надо могут и код поревьювить. И те и другие — разработчики называются.
Меня вообще такой подход удивляет — давайте будем платить тестировщикам в полтора, в два, в три раза меньше чем разработчикам, а потом говорить: «тестировщики чего-то у нас не тянут, а те кто получше почему-то уходят (в другие компании, в разработчики, вообще из ИТ)».