В нескольких статья меня пнули ногой (и правильно), что я путаю QA и QC. Ну, слава богу, уже разобрался.
Хотя как показала практика, не один я такой. В Google ищем «QA engineer» — получаем 1M результатов, «QC engineer» — 200k. Судя по всему, большинство таки людей хотя сказать QC используют QA.
Но, я собственного говоря не об этом. Я совсем о другом.
Почему-то в последнее время повеяла такая мода программистам побольше QC задач подкидывать и пытаться размыть границу между программистами и QC engineer (я дальше буду писать тестировщиком, хотя это и не идеально выражает то, что делают QC engineer’ы).
Проще говоря, когда менеджер говорит, ты код напиши и оттестируй полностью, чтобы после тебя тестировщам не надо было тратить много времени.
Или например, в Scrum, есть попытка ввести понятие Team member, без разделения на программиста и тестировщика. И типа, что нужно то и делай для окончания задачи.
Честно говоря, я не в восторге от обоих инициатив. Разобью по пунктам, собственно в чем состоит мое недовольство.
а) Разделение труда
Достаточно странно, что везде идет разделение труда для повышения эффективности, тут же наоборот начинают смешивать труд.
б) Квалификация
Квалификация среднего тестировщика может быть (и обычно бывает) гораздо ниже чем у программиста.
Само по себе это ничего не значит, но влияет на следующий пункт.
в) Стоимость работы
Спрос на программистов и более высокие требования к квалификации удерживают зарплаты программистов выше чем зарплаты тестировщиков.
Можете бросаться в спор. Мне уже пытались доказывать обратное. Однако, цены на сайтах по предложений работы подтверждают именно мою теорию.
г) Односторонняя взаимозаменяемость
Да, программист может выполнять тестирование и достаточно легко может научиться писать планы тестирования и придумывать стресс тесты.
В обратную сторону, тестировщик чаще всего либо не может программировать вообще, либо является очень слабым программистом.
Опять же из этой асимметрии следует, что программисты должны таки работать над той задачей, которую тестировщики не могут решить.
В личных спорах мне говорили, что я типа зараза пытаюсь программистов выделить в высшую касту и что типа это ужас как плохо. На самом деле никакой высшей/нижшей касты нету — есть работа, которую делают и программисты и тестировщики и программисты просто (как по мне) являются более дорогим ресурсом.
Никаких супер привелегий у них нету, просто они делают работу которую тестировщик не умеет делать.
Как пример, нейрохирург вполне может вполне знать педиатрию. Но это же не значит, что он должен работать по этому поводу педиатром.
Суммируя. В целом, я не против некоторого количество тестирования на стороне программистов, которые уменьшает суммарное бюджет необходимый для доведения до ума. Но я категорически против того, когда из разряда «некоторое количество» это пытаются перевести в раздел — программист обязан делать полное регрессионное тестирование.
Дописал большой P.S.
Дисскусия в нескольких ветках упала в сторону, кто быстрее выучиться программист — тестировщиком или тестировщик программистом.
Откинем вопрос, хотят ли они учиться и примем за данность, что у обоих есть голова на плечах.
Плюс, сразу выкинем из рассуждения фразы типа «я вот знал тестировщика, который стал хорошим программистом, а наоборот не знаю ни одного».
Мы будем говорить о статистической сложности переучивания, а не разбирать конкретный пример Васи или Пети.
Возьмем двух человек
а) Хорошего программиста
б) Хорошего тестировщика
Начнем с того, что хороший тестировщик вполне может не уметь программировать вообще (оставим на секунду автоматизированное тестирование за бортом). Он может заниматься написание планов тестирования, стресс тестированием, обучение молодежи как тестировать,тестировать безопасность, тестировать usability и т.п.
То есть, тестировщик знает как тестировать, но при этом легком может не иметь даже базовых знаний программирования.
В обратную же сторону -хороший программист НЕ может работать без базовых знаний тестирования. Он в общих чертах понимает, что такое план тестирования (просто за X лет работы он уже с ним не раз сталкивался), он делает минимальное тестирование сам перед отдачей тестерам. Я не говорю, что программист отлично понимает, но базовые понятие у него уже есть.
Таким образом, когда программиста нужно обучить тестированию, то по большему счету ему нужно углубить свои знания в
а) Стресс тестировании
б) Почитать несколько книг по планированию тестирования
в) Поменять мышление, для того, мыслить не с точки зрения «вот, что надо сделать, чтобы оно работало» а на «вот, что надо сделать, чтобы оно НЕ работало».
г) Изучить некоторое количество инструментов для тестирования
д) Потестировать, чтобы разобраться что правильно, а что неправильно
То есть, как по мне, база знаний необходимая тестировщику не слишком большая, частично программист ей владеет. Ему нужно ее углубить и получить опыт.
Теперь тестировщику нужно обучиться программированию.
И вот тут база оказывается достаточно большой
а) Изучить основы программирования
б) Изучить язык программирования
в) Изучить API операционной системы/browser/базы данных
г) Изучить инструменты для программирования
д) Изучить такие вещи как ООП
е) Пописать программы, чтобы понять, что правильно, а что неправильно
То есть база знаний больше. А знание основ этой базы у тестировщика меньше.
Проблема в сложности изучения программирования (по сравнению с тестирование в двух вещах)
— В программировании гораздо больше информации нужно просто запомнить, которая не поддается логическому объяснению (на начальных этапах учебы). В тестировании же больше вещей логичны с самого начала
— В программировании результат работы гораздо медленней становится видим (например можно неделю работать над кусочком программы) и поэтому ошибки и опыт накапливаются медленнее.
Уже через неделю программист может выполнять простые элементы тестирования на __РЕАЛЬНЫХ__ (это ключевое слово) проектах.
В обратную же сторону, тестировщик сможет в этот момент только учиться на маленьких программках, которые не являются настоящими проектами. И только через долгое время сможет делать даже простые задачи на реальном проекте.
И возвращаясь к автоматизированному тестированию. Да, безусловно у тестировщика занимающегося автоматизацией, очень хорошая фора перед тестировщиком. Тем не менее скрипты по автоматизации на порядок проще, чем реальный код.
Таким образом тестировщик, который занимался автоматизацией имеет уже некий задел в основах программирования и может быть языке. Тем не менее все остальные пункты все еще остаются той базой, которую ему придется выучить до того, как стать программистом, приносящим пользу.
Странно, что по этому вопросу вообще возникают какие-то споры. Тут по-моему все очевидно. Мнение автора полностью разделяет Джоел Спольски. Смотрим, к примеру тест Джоела, комментарий к п.10.
Цитата для тех, кому лень читать многобукв:
Безотносительно обсуждаемой темы: Спольски — персонаж неоднозначный. И уж тем более я бы не стал ссылаться на него как на авторитет.
На него ссылаются не как на авторитет, а как на человека, который руководит успешной софтверной компанией.
Как там было Фрица Моргена…
Если я захочу заработать миллион, то мнение одного миллионера для меня будет весомей, чем мнение миллиона людей с одним долларом. 😉
Вы ниже очень красноречиво аппелировали к логике. Что ж, давайте везде рассуждать логически. :+Р
1. Успешность софтверной компании совершенно не говорит о том, что все процессы там поставлены идеально, и уж тем более о том, что рассматриваемый в данный момент процесс работает в компании на должном уровне.
2. Если человек заработал миллион, это ещё не значит, что он может дать правильные советы желающим. Вспомните «ван мильон доллар хомпэйдж». Чистое везение. Вы действительно верите, что владелец может дать ценный совет желающему заработать мильён? :+)
ЗЫ Фриц-то вообще ничем не примечателен, чтобы его здесь упоминать.
Логическая задача:
При прочих равных условиях, к чьим советам «как заработать миллион» вы прислушаетесь, в большей степени? К тем людям, которые заработали миллион или к тем, кто его не заработал?
P.S. >> ЗЫ Фриц-то вообще ничем не примечателен, чтобы его здесь упоминать.
Это ваше мнение (не примечательность Фрица), вряд ли стоит его кому-то навязывать.
> К тем людям, которые заработали миллион или к тем, кто его не заработал?
Мне Ваш вопрос напомнил анекдот про трёх девушек: «Одна мороженое лижет, другая кусает, третья — сосёт. Которая замужем?»
Я прислушаюсь ко всем советам, которые покажутся мне логически обоснованными. Несомненно, я буду принимать во внимание биографию и опыт советчика. А также причины, которые привели или не привели его к владению миллионом, буде такие окажутся мне известны.
> Это ваше мнение (не примечательность Фрица), вряд ли стоит его кому-то
> навязывать.
Вам померещилось. Я лишь высказал своё отношение к названному Вами персонажу в ответ на Вашу попытку подкрепить своё высказывание «авторитетным» мнением.
Не вдаваясь в ваш спор о Фрице и о том, насколько Спольски может дать советы.
Но, вот правила Спольски мне кажутся логичными и правильными.
>Экономия на тестерах — это оскорбительно ложная экономия.
Да, собственно это одна из целей этого смещения задач — экономия на тестировании.
Сама по себе экономия не плохая вещь, но до тех пор пока она не начинает приносить отрицательные результаты.
Есть один важный момент. Когда пишешь код, знаешь, что в некоторых местах мало подумал, и там может быть баг. Тестировщик этого не знает. Так что, определённую часть тестирования должны делать программисты.
ЗЫ Так и не понял, где здесь опенид ввести.
А то, что программист склонен доверять собственному коду, вы об этом слышали? 😉
P.S. Справа в самом верху меню, есть ссылка login. Проходите по ней и вводите свой OpenID.
Разверните мысль.
Это была скорее качественная оценка, нежели количественная. Из опыта своего получена. Но развернуть мысль всё-таки попробую.
Программист получает задачу и продумывает алгоритм решения, иерархию классов, последовательность вызовов и т.д. Всё нацелено на то, чтобы решить задачу и предусмотреть как можно больше нестандартных ситуаций (которые приводят к дефектам).
Вот сидит он день придумывает и в итоге строит «красивое», «правильное», «гибкое» и «универсальное» решение. Придумал. Ура! Дальше — начинаем воплощать решение в жизнь, по сути — переносить в код то, что было придумано. На этом этапе уже анализ задачи и возможных условий работы отходит на второй план — день уже потрачен на раздумья, всё предусмотрено — сиди, пиши код.
И тут выходит тот самый фактор доверия своему коду — если время на продумывание решения было и было потрачено не зря, считается, что и код будет правильным.
А что на самом деле? На самом деле все люди ошибаются (да-да, и QA с QC в том числе). Так вот, у программиста есть два места, где он может допустить ошибку — при продумывании решения и при его реализации в коде. Ошибки в коде — выявляются легче, зачастую ещё в процессе написания кода. А ошибки в алгоритме (иерархии классов и т.д.) — пропускаются. И не потому, что программист плохой и не думает о дефектах. Просто он верит, что всё в порядке.
Надеюсь теперь стало яснее, что имелось в виду под «программист склонен доверять собственному коду».
Мысль понятна. Очевидно, что в любой работе сторонний, «незамыленный», взгляд всегда полезен.
Естественно. Поэтому стараюсь всячески содействовать внедрению процесса ревизии кода. 😉 Очень даже помогает.
Вот с этого места, пожалуйста, поподробнее. Как это выглядит? Одни люди читают код других?
Угу, для начала на соответствие хотя бы общему стилю кодирования.
Согласитесь, что если все стараются писать в едином стиле, внесение изменений будет занимать меньше времени, поскольку чтение и понимание кода будет проходить быстрее.
Дальше, помимо стиля кодирования, во время ревизии начинают проверять алгоритмы.
Ну, а если совсем всё нравится в таком подходе, то переходят к его высшей ипостаси — XP, где один из основных моментов — парное программирование. Один пишет, второй думает. 😉
P.S. Там где я работал, чтобы не изобретать велосипед, все начинают со RSDN Code Style Standard — http://www.rsdn.ru/article/mag/200401/codestyle.XML естественно с вариациями, отвечающими реалиям компании (отдела).
Скажем так, с чем я согласен у Woland, что конечно программисту проще искать ошибки в «слабых» местах. Но он легко может эти места и тестерам рассказать и сказать в каком направление тестировать.
Ну и безусловно согласен с dm-cat. У программистов не просто взгляд замыливается, но и они переконцентрируются на реализации, постепенно теряя из виду реальную задачу.
кстати, я до сих пор путаю…. пытался и заучивать уже — бесполезно!!!!!
QA — Quality Assurance — обеспечение качества. Понятие более общее, нежели QC — Quality Control — контроль качества.
Скажем так, чтобы ОБЕСПЕЧИТЬ качество, кьюэйщики суют свой нос везде. В процессы написания кода, организации билдов, форматов документации и т.д. Каждый раз, когда они видят проблему, они начинают разворачивать всю цепочку действий, которая привела к проблеме, разбираются в начальной причине и придумывают что-то такое (тут стоит матное слово), что позволит в дальнейшем избежать её возникновения.
А люди, которые контролируют качество — используют то, что получили от «светлых» голов кьюэйщиков и проверяют, чтобы не было расхождений реальности и того, что придумали QA.
Как-то так.
>> а) Разделение труда
>> Достаточно странно, что везде идет разделение труда для повышения эффективности, тут же наоборот начинают смешивать труд.
Тут не смешивают труд, а переводят его на качественно другой уровень.
Пример: Одна бригада копает траншею, вторая — прокладывает в этой траншее трубу. Чистое разделение труда. Тут появляется автотрубоукладчик, который сам умеет копать и прокладывать — переводим всех бывших траншеекопателей и трубоукладчиков в операторы автотрубоукладчика. Это что, смешение труда? Нет, это переход на новый уровень.
>> б) Квалификация
>> Квалификация среднего тестировщика может быть (и обычно бывает) гораздо ниже чем у программиста.
Квалификация в чём? В программировании — да, ниже. В тестировании — наоборот выше.
>> в) Стоимость работы
>> Спрос на программистов и более высокие требования к квалификации удерживают зарплаты программистов выше чем зарплаты тестировщиков.
Тут не поспоришь. Только разницу в зарплатах не стоит сводить к одной причине (квалификации непонятно в чём). Мне видится, что их несколько больше. Например, недооценка роли тестирования, количественное соотношение тестировщики — программисты (программистов больше), более низкий входной порог (руководители компаний, подразделений и т.п. готовы брать кого угодно, хоть немного знакомого с компьютером на роль тестировщика).
>> г) Односторонняя взаимозаменяемость
>> Да, программист может выполнять тестирование и достаточно легко может научиться писать планы тестирования и придумывать стресс тесты.
А также в разумные сроки овладеть багажом знаний по тестированию (не поверите, но это очень даже серьёзная дисциплина, почитайте на досуге http://www.ozon.ru/context/detail/id/1903552/), выработать в себе навыки тестирования и изучить инструменты тестирования. 😉
Согласен, что хороший программист быстрее станет хорошим тестировщиком (вопрос захочет ли — не рассматриваем), чем хороший тестировщик станет хорошим программистом. Но вот то, что это не произойдёт в один момент, типа сел и начала тестировать — это 100%.
>переводим всех бывших траншеекопателей и трубоукладчиков в операторы >автотрубоукладчика.
Согласен с вами, в случае когда появляются автотрубоукладчик (то есть новый инструмент).
Плюс, и траншеекопателей и трубоукладчиков в конечном счете становятся взаимозаменяемыми.
В нашей ситуации с программистами и тестировщиками, никаких дополнительных супермощных инструментов не добавилось. Плюс тестировщики не могут исполнять работу программистов.
>Квалификация в чём? В программировании — да, ниже. В тестировании — наоборот выше.
Некоторое абстрактное общее количество обучения, практики и знаний требуемое для качественного исполнения своих задач.
Кстати более низкий входной порог, как раз одна из сторон более низкой квалификации.
>Только разницу в зарплатах не стоит сводить к одной причине
Бесспорно. Например я упомянул — больший спрос на программистов. Так, что согласен — причин много.
>Согласен, что хороший программист быстрее станет хорошим тестировщиком (вопрос >захочет ли — не рассматриваем), чем хороший тестировщик станет хорошим программистом. >Но вот то, что это не произойдёт в один момент, типа сел и начала тестировать — это 100%.
Собственно, я об этом и говорил. Согласен, что переход не мгновенный, но переход в сторону тестирования проще, чем переход в сторону программирования.
>очень даже серьёзная дисциплина
Не спорю. Но в основном, я пытаюсь сказать, что она менее серьезная, чем программирование.
>> В нашей ситуации с программистами и тестировщиками, никаких дополнительных супермощных инструментов не добавилось. Плюс тестировщики не могут исполнять работу программистов.
В нашей ситуации появился инструмент в виде методологии разработки ПО — Scrum. Вот он и диктует, что теперь не нужны «траншеекопатели» и «трубоукладчики». Теперь нужны операторы «автотрубоукладчиков».
То есть, с использованием Scrum нужны не программисты и тестировщики, а нечто другое — их слияние в одном человеке. 😉
>То есть, с использованием Scrum нужны не программисты и тестировщики, а нечто >другое — их слияние в одном человеке. 😉
Отлично. В таком случае, программисты, которые начинают больше тестировать исполняют свою роль внутри Scrum более качественно, так как тестировщики программировать не начинают обучаться.
Scrum не дает того выигрыша, который дает автотрубоукладчик. С автотрубоукладчиком эффективность возрастает в 10 раз и поэтому исчезают профессии, которые были до этого, а теперь не эффективные.
Точно также электричество убило профессию зажигателя фонарей.
У Scrum’а есть свои плюсы и на определенного типа проектах он увеличивает эффективность. Но не в 10 раз и профессии программиста и тестировщика он не делает устаревшими. Поэтому, да возможно Scrum предлагает слияние в одном человеке этого, но это не значит, что
а) слияние возможно
б) слияние эффективно
Ну и термины у вас. А по-русски говорить никто не пробовал?
Во первых че то не работает тут авторизация по OpenID. Я под своимм ЖЖ аккаунтом зайти не смог.
Предыдущему комментарию +1.
Если встречались QA которые ставят перед собой малую часть ответственности и задач, то это именно их проблемы. Похожую тему писал на http://the-sapiens.livejournal.com/1040.html .
По поводу взаимозаменяемости слышал раз 100, но знаете ли хороший QA тоже может написать фиговый код, также как и программист фигово протестирует задачу 🙂 Думаю здесь не стоит гонятся за 2-мя зайцами и развиваться в своей среде
Капча ужасная кстати. И под предыдущим комментарием имел в виду http://dm-cat.blogspot.com/ 🙂
За капчу извиняюсь, нужно что-то делать, а руки не доходят.
>По поводу взаимозаменяемости слышал раз 100, но знаете ли хороший QA тоже может >написать фиговый код, также как и программист фигово протестирует задачу 🙂
ok. В основном я утверждаю, что хороший программист гораздо быстрее станет хорошим QA, чем хороший QA — хорошим программистом.
>ok. В основном я утверждаю, что хороший программист гораздо
>быстрее станет хорошим QA, чем хороший QA — хорошим программистом.
Вот это тоже не факт. Честно говорю, что наверное у вас плохой опыт работы с QA 🙂 Все как всегда будет зависить от самого человека и его понимания профессионализма… Хотя я тоже редко встречаю хорошего QA спецаилиста, но они поверьте — есть.
Постоянно падаем мы в ситуацию «как всегда будет зависить от самого человека и его понимания профессионализма». Так оно и есть. Но я говорю, скорее о статистических величинах.
То же самое, есть тестировщики с зарплатами больше программитских, но в среднем по индустрии все же зарплаты меньше.
Естественно у меня нету данных, так что это чистая игра ума.
Тем не менее, давайте возьмем двух человек
а) Хорошего программиста
б) Хорошего тестировщика
Начнем с того, что хороший тестировщик вполне может не уметь программировать вообще (оставим на секунду автоматизированное тестирование за бортом). Он может заниматься написание планов тестирования, стресс тестированием, обучение молодежи как тестировать,
тестировать безопасность, тестировать usability и т.п.
То есть, тестировщик знает как тестировать, но может не иметь базовых знаний программирования.
В обратную же сторону -хороший программист НЕ может работать без базовых знаний тестирования. Он в общих чертах понимает, что такое план тестирования (просто за X лет работы он уже с ним не раз сталкивался), он делает минимальное тестирование сам и т.п.
Таким образом, когда программиста нужно обучить тестированию, то все по большему счету ему нужно углубить свои знания в
а) Стресс тестировании
б) Почитать несколько книг по планированию тестирования
в) Поменять мышление, для того, мыслить не с точки зрения «вот, что надо сделать, чтобы оно работало» а на «вот, что надо сделать, чтобы оно НЕ работало».
г) Изучить некоторое количество инструментов для тестирования
д) Потестировать, чтобы разобраться что правильно, а что неправильно
То есть, как по мне, база знаний необходимая тестировщику не слишком большая.
Теперь тестировщику нужно обучиться программированию.
И вот тут база оказывается достаточно большой
а) Изучить основы программирования
б) Изучить язык программирования
в) Изучить API операционной системы/browser/базы данных
г) Изучить инструменты для программирования
д) Изучить такие вещи как ООП
е) Пописать программы, чтобы понять, что правильно, а что неправильно
Проблема в сложности изучения программирования (по сравнению с тестирование в двух вещах)
— В программировании гораздо больше информации нужно просто запомнить, которая не поддается логическому объяснению (на начальных этапах учебы).
В тестировании больше вещей логичны с самого начала
— В программировании результат работы гораздо медленее становится видим и поэтому ошибки и опыт накапливаются медленее.
Уже через неделю программист может выполнять простые тестировочные задачи на __РЕАЛЬНЫХ__ (это ключевое слово) проектах.
В обратную же сторону, тестировщик сможет в этот момент только учиться на маленьких программках, которые не являются настоящими проектами.
Занесу-ка я это в P.S. к статье.
Ура отличный коммент, но есть загвоздки.
>Он может заниматься написание планов тестирования, стресс
>тестированием, обучение молодежи как тестировать,
>тестировать безопасность, тестировать usability и т.п.
Тестировать безопасность и заниматься стресс тестированием QA не сможет, если не знает
>а) Изучить основы программирования
>б) Изучить язык программирования
>в) Изучить API операционной системы/browser/базы данных
>г) Изучить инструменты для программирования
>д) Изучить такие вещи как ООП
>е) Пописать программы, чтобы понять, что правильно, а что неправильно
Вот к чему я и клоню. Вот вам другая моя статья http://the-sapiens.livejournal.com/4373.html . Не сочтите за рекламу блога, просто нашу дискуссию я в какой то мере уже описывал. Теперь думаю я немного открыл смысл предыдущего своего поста.
Кстати по поводу того, что
>скорее о статистических величинах.
То я полностью согласен. Но это можно объяснить и тем, что в сфере тестирования нет фундаментальных документов (стандартов) как же надо тестировать и что делать 🙂 Но шаги в этом направлении уже есть.
И еще по поводу
>Уже через неделю программист может выполнять
>простые тестировочные задачи на __РЕАЛЬНЫХ__
>(это ключевое слово) проектах.
А вы можете после этого заказчику асболютно уверенно сказать, что все работает как часики и можно проводить внедрение в реальную эксплуатацию? Думаю, что нет 🙂
>Вот к чему я и клоню. Вот вам другая моя статья http://the-sapiens.livejournal.com/4373.html . Не сочтите за рекламу блога, просто >нашу дискуссию я в какой то мере уже описывал. Теперь думаю я >немного открыл смысл предыдущего своего поста.
Можете спокойно рекламировать блог 🙂 Он же тематический, а не про продажу виагры 🙂
Насчет поста в вашем блоге. С одной стороны — я согласен, что в хорошей ситуации QA должен разбираться в программирование, причем в идеале достаточно неплохо.
Но, идеал сталкивается с реальностью. Большинство тестировщиков разбирающихся в программировании уходят в программистов, из-за более высоких зарплат. Остаются буквально единицы, которым нравиться именно тестирование. И эти единицы разбавляются толпами тестировщиков, который в программировании таки не понимают.
>А вы можете после этого заказчику абсолютно уверенно сказать, >что все работает как часики и можно проводить внедрение в >реальную эксплуатацию? Думаю, что нет
Если посадить человека за регрессионное тестирование по достаточно хорошо описанным тестам, то еще через пару недель, поглядев, что результаты у человека выходят нормальные (да пару этих недель с ним прийдется возиться) — можно будет уже отдавать и заказчику.
Еще раз подчеркну. В тестировании есть больше задач, которые требует малого количества опыта для их исполнения.
В программировании меньше таких задач, поэтому выход на ступеньку, когда можно что-то уже делать на реальном проекте занимает дольше.
Хмм… Я наверное тогда везучий, у меня ЗП такая же как и у TeamLead-а у программистов и я не один такой. Мои хорошие знакомые QA получают также. Ну опять же в большинстве случаев все так и есть наверное:)
Ну, это просто говорит о том, что вы действительно толковый и друзья у вас тоже толковые. 🙂
Ну спасибо конечно 🙂
Кстати о том, что
>Экономия на тестерах — это оскорбительно
> ложная экономия.
полностью согласен.
Я чуть выше делал комментарий по поводу этой фразы.
Я бы сказал, слово «оскорбительная», здесь не уместно, так как это бизнес.
А вот «ложная экономия» достаточно точное описание проблемы.
Чесно говоря, я бы не стала писать так много о том, о чем не разбираюсь. Чтобы не быть голословной — я управляю командами тестирования, пройдя путь от младшего тестировщика. Так вот, весь пост говорит именно о том, что вы сами, считаете тестировщиков «второй сорт — не брак». Это обидно :(.
Хороший (!) тестировщик может стоит больше программиста и знать намного более, чем программисты. Ваш пост говорит о некотором непрофисианализме. Професионал понимает, что тестировщик делает работу не меньшую, и не худшую, чем программист. При сегоднешнем уровне языков программирования, не смочь программировать — это надо быть тупым. Поэтому я бы не стала приувеличивать серьезность программирования.
По пунктам:
>>а) Разделение труда
>>Достаточно странно, что везде идет разделение труда для повышения эффективности, тут же наоборот начинают смешивать труд.
Хочу заметить, что често программисты пытаються рассказать тестировщикам что и как тестировать. Согласно QMS и другим системам качества у тестировщика есть свой руководитель и только он говорит ЧТО делать тестировщику и как. Мнение программиста нас волнует, но не сильно. Программисты имеют свое виденье продукта, наше же виденье ближе к тому что хочет заказчик. НАм все равно как легче или круче, нам важно как должно быть и чего хочет заказчик.
>>б) Квалификация
>>Квалификация среднего тестировщика может быть (и обычно бывает) гораздо ниже чем у программиста.
Это квалификация постредственного тестировщика. Квалификация хорошего тестировщика (и даже просто нормального) такая же, а то и выше. Тестировщик должен мыслить системно, а большинство программистов 1) не программисты, а кодеры, 2) дальше своего куска кода вообще ничего не знают. Тестировщик — это образ мысли, способ мышления. Тестировщик видит всю систему и анализирует как одна функциональность влияет на другую, а программист — написал, запустил — и что на что влияет его не интересует.
Кстати, на счет квалификации. Как показывает практика, программистам тяжело дается английский, зато все тестировщики его осваивают 😉
>>в) Стоимость работы
>>Спрос на программистов и более высокие требования к квалификации удерживают зарплаты программистов выше чем зарплаты тестировщиков.
>>Можете бросаться в спор. Мне уже пытались доказывать обратное. Однако, цены на сайтах по предложений работы подтверждают именно мою теорию.
Это ситуация в бывших странах СССР, именно потому что программисты решили, что тестировщики — это второй сорт. В странах запада тестировщик ценится выше, чем кодер, как человек, отвечающий за качество передзаказчиком.
>>г) Односторонняя взаимозаменяемость
>>Да, программист может выполнять тестирование и достаточно легко может научиться писать планы тестирования и придумывать стресс тесты.
>>В обратную сторону, тестировщик чаще всего либо не может программировать вообще, либо является очень слабым программистом.
Желательно чтобы вы четко себе запомнили, что из любого программиста тестировщик скорее всего не получится, так как виденье программы совсем другое. Причем я это пишу не по наслышке. Почему-то думаю, что если челвоек не смог кодить, то сможет тестировать. На самом деле он тестировать тоже не сможет — проверено на людях.
Советую почитать про автоматизированное тестирование. Этих людей в тестировании немало и все они программируют, причем их задача усложняется, если спрограммированое кое как — тогда оно просто не автоматизируется.
Отвечу на все ваши вопросы по тестированию как профильный специалист :).
PS таки опен-айди не работает 🙁
> При сегоднешнем уровне языков программирования, не смочь программировать —
> это надо быть тупым.
Так и надо было сказать: «Я никогда не пыталась программировать, но считаю это дело занятием примитивным».
Пыталась, и чуть не стала программистом :), но во-время предложили попробовать силы в тестировании. Поэтому что такое программист знаю не по наслышке, имею профильное образование :р
> не стала программистом 🙂
Это заметно. :+)
В каком смысле заметно?
Я очень хорошо отношусь к программистам, но не люблю когда гнобят тестировщиков. Не я первая начала.
Высказанные очевидные вещи Вы восприняли чуть ли ни как личное оскорбление и начали кидаться на мельницы.
А факты просты: без программистов тестировщики не нужны. Потому что им нечего будет тестировать. Без тестировщиков программисты вполне способны справиться с тестированием своего продукта. И в ряде случаев сделают это лучше, потому что знают особенности внутреннего устройства (которое сами же и создали). Из выше означенного и следует бо́льшая ценность программистов в сравнении с тестировщиками. И, как верно было сказано, тестировщики нужны именно для того, чтобы не расходовать понапрасну дорогое время программистов.
>>Без тестировщиков программисты вполне способны справиться с тестированием своего продукта. И в ряде случаев сделают это лучше, потому что знают особенности внутреннего устройства (которое сами же и создали).
Программист оттестирует программу ХУЖЕ чем тестировщик. Знание кода тут не при чем. Заказчику все равно какое там стройство — важно как работает — именно это и высняет тестировщик.
>>И, как верно было сказано, тестировщики нужны именно для того, чтобы не расходовать понапрасну дорогое время программистов.
То есть вы подписываетесь, что тестировщик — это второй сорт. Вы в принципе не понимаете в чем задача тестировщика, к сожалению.
Жаль что вы не встречали нормальных тестировщиков.
1. Сознаюсь, что тестировщиков я не встречал вообще, но смысл их работы себе представляю.
2. Вы смешиваете в одну кучу тестирование на ошибки и на соответствие ожиданиям заказчика.
3. Да. Я бы сказал, что тестировщик — работа, требующая меньшей квалификации, нежели программист.
>> 1. Сознаюсь, что тестировщиков я не встречал вообще, но смысл их работы себе представляю.
Смешно. «Автора не читал, но осуждаю.»
>> 2. Вы смешиваете в одну кучу тестирование на ошибки и на соответствие ожиданиям заказчика.
Соответствие ожиданиям заказчика — это ответственность QA. Тестирование на ошибки — QC. QC — это лишь часть QA.
>> 3. Да. Я бы сказал, что тестировщик — работа, требующая меньшей квалификации, нежели программист.
А ну, пример в студию? Какая нужна квалификация тестировщику, а какая — программисту?
> Смешно. “Автора не читал, но осуждаю.”
Мимо.
Тестирование продукта — работа программиста там, где нет тестировщиков.
И я никого не осуждаю.
> Соответствие ожиданиям заказчика — это ответственность
> QA. Тестирование на ошибки — QC. QC — это лишь часть QA.
А при чём здесь QA? Сам пост и весь тред — про QC.
> А ну, пример в студию? Какая нужна квалификация
> тестировщику, а какая — программисту?
Вам в каких единицах?
Если по-простому, то для тестирования программы на ошибки вообще никакой квалификации не нужно. Достаточно знать, как должна работать программа и как не должна. Чтобы эти ошибки искать, нужен некоторый багаж знаний. Но я могу предположить (именно предположить, см. п. 1), что QC может быть обучен на рабочем месте за два месяца из выпускника ВУЗа без опыта работы, а потолка в развитии достигнет (если достаточно умён) через полгода-год.
Движку: нет, блядь, это не дупликейт коммент.
По пунктам:
2. Я смешиваю потому, что и то и то — это работа тестировщика. И как раз первостепенная задача — проверка программы на соотвествие спецификации.
3. Изначально — да, но если квалификация опытного тестировщика уступает квалификации программиста (в относительном, а не буквальном сравнении) — он/она плохой тестировщик. Квалификация атоматизатора соотносима полностью с квалификацией программиста.
>> И как раз первостепенная задача — проверка программы на соотвествие спецификации.
А как же тестирование требований? Или вы им сразу верите? 😉
Я брала только эти два направления, указаных в посте:
>> 2. Вы смешиваете в одну кучу тестирование на ошибки и на соответствие ожиданиям заказчика.<<
Под словом «первостепенный» — я имела ввиду «первой важности» для рядового тестиовщика. Для тестирвощика выше уровня, руководителя группой тестирования — да, сначала тестируем требования ;).
Мы закапываемся черезчур глубоко 😉
> 2. Я смешиваю потому, что и то и то — это работа
> тестировщика. И как раз первостепенная задача — проверка
> программы на соотвествие спецификации.
Но если мы говорим не об отдельно взятых тестировщиках, а сравниваем их с программистами, надо бы отделять мух от котлет: тестирование на ошибки программист выполнит, в общем случае, лучше. Потому что знает систему изнутри.
Тестирование на соответствие требованиям заказчика — вообще работа механическая. Есть требования, есть продукт — сиди и проверяй.
Вы некомпетентны в том о чем тут ведете полемику, поэтому я считаю бесполезным ее продолжение, так как не собираюсь тут излагать основы тестирования для тех, кто не в теме.
Ваша проблема в том, что вы преувеличиваете роль и тестирования, и тестировщиков в процессе разработки. Я бы посоветовал Вам развиваться дальше и перестать испытывать комплексы на тему своей профессии.
Спасибо, я и так себя неплохо чувствую. Как раз вам советую расширить горизонты …
Чуть просуммирую.
2Woland, я НЕ согласен с вами насчет роли тестирования.
Роль тестирования крайне важна и чаще всего тестировщик протестирует таки программу гораздо лучше чем программист ее написавший.
Собственно говоря — это одна из причин, почему это выделилось в отдельную специальность.
2Screenshoter: Мне кажется нельзя сравнивать хорошего тестировщика с плохим программистом.
Нужно сравнивать хорошего тестировщика с хорошим программистом.
Вполне согласна. Но если тут сравнивать «хорошего тестировщика с хорошим программистом» то мы зайдем в ненужную полемику.
> Изначально — да, но если квалификация опытного
> тестировщика уступает квалификации программиста (в
> относительном, а не буквальном сравнении) — он/она плохой
> тестировщик. Квалификация атоматизатора соотносима
> полностью с квалификацией программиста.
А этот опус я вообще не понял? Он означает «если тестировщик со временем не повысил свою квалификацию, то он дебил»? По-моему, это и так очевидно.
Из огня, да в полымя. То хаили тестировщиков. Теперь хаим программистов.
>> Так вот, весь пост говорит именно о том, что вы сами, считаете тестировщиков “второй сорт — не брак”. Это обидно :(.
Тут согласен. Многие знакомые программисты считают тестировщиков неполноценными техническими специалистами.
>> Хороший (!) тестировщик может стоит больше программиста и знать намного более, чем программисты.
Смотря чем мерить знания. Как можно сравнить, например, навыки грамотного использования ООП и навыки построения тестирования с максимальным покрытием функционала? Это разные области, критерии — разные. Сравнивать их — некорректно. Разве что качественно, но ни в коем случае не количественно.
>> Ваш пост говорит о некотором непрофисианализме. Професионал понимает, что тестировщик делает работу не меньшую, и не худшую, чем программист.
Тестировщик делает работу, которая занимает столько же времени, сколько и у программиста — 1 рабочий день. 😉 Меньше — не получится. Естественно он делает не худшую работу. Он делает «другую работу». При чём тут профессионализм автора — не понятно.
>> Хочу заметить, что често программисты пытаються рассказать тестировщикам что и как тестировать. Согласно QMS и другим системам качества у тестировщика есть свой руководитель и только он говорит ЧТО делать тестировщику и как.
Насчёт попыток рассказать, что и как тестировать, то рассказ о том «что» тестировать — идёт на пользу всем. А вот «как» тестировть — надо пресекать. Только не стоит аппелировать QMS и т.п. QMS волнует тестировщиков и, не поверите, абсолютно не волнует программистов (зачастую). Поэтому, уж вы, как руководитель, должны знать — общение с другими подразделениями необходимо вести на языке понятном всем участвующим и аргументы приводить, которые имеют значение для всех участников. Я в своей практике, использую универсальный набор параметров, к которым свожу все свои аргументы (стараюсь сводить) — Time, Budget, Client Satisfaction. Это понимают все.
>> Тестировщик должен мыслить системно, а большинство программистов 1) не программисты, а кодеры, 2) дальше своего куска кода вообще ничего не знают.
Зря вы так. Я был свидетелем, как такой ситуации, так и диаметрально противоположной. Так что факты в студию. 😉
>> Кстати, на счет квалификации. Как показывает практика, программистам тяжело дается английский, зато все тестировщики его осваивают
Какой из вас тестировщик, точнее руководитель тестировщиков, если вы не можете грамотно составить логическое выражение. Сделаем разбор:
«Как показывает практика» — опускаем, как несущественное в разборе.
«программистам тяжело дается английский» — то есть, программисты испытывают сложности при изучении английского.
«зато все тестировщики его осваивают» — то есть, тестировщики выучивают английский.
Где здесь противопоставление?
Что, программисты не выучивают английский? — не верю, передо мной целый отдел программистов, знающих английский.
Что, тестировщики не испытывают сложностей при изучении английского? — не верю, передо мной тестировщик (хороший тестирвщик), который с трудом пытается выучить английский.
>> В странах запада тестировщик ценится выше, чем кодер, как человек, отвечающий за качество передзаказчиком.
Невнимательно Виктора читаете. 😉 Вот ссылка, которую он давал:
http://www.payscale.com/research/US/Employer=Google,_Inc./Salary
И что мы видим?
Google
— Software Engineer / Developer / Programmer — 82 746$ в год
— Test / Quality Assurance Engineer — 74 147$ в год
Очень неприятно слышать от человека, отвечающего за качество перед заказчиками, такое необоснованное утверждение.
>> Желательно чтобы вы четко себе запомнили, что из любого программиста тестировщик скорее всего не получится, так как виденье программы совсем другое. Причем я это пишу не по наслышке.
А я не по-наслышке знаю, что это зависит от людей, в обязанности которых станет обучение/руководство бывшим разработчиком, а ныне тестировщиком.
>> Почему-то думаю, что если челвоек не смог кодить, то сможет тестировать. На самом деле он тестировать тоже не сможет — проверено на людях.
Вы читать умеете? Текст написан в контексте того, что людей «умеющих кодить» заставляют тестировать. Понятно, что дибила ни там, ни там ничему не смогут научить.
P.S. Может вы что-то не так делаете с OpenID? Я ведь с него пишу.
P.P.S. >> Отвечу на все ваши вопросы по тестированию как профильный специалист :).
А вы специалист именно по тестированию или по обеспечению качества в целом?
Автор написал усредненное мнение про тестировщиков (которых, как тут выше выяснилось, он никогда не видел), я написала что-то среднее в ответ. Конечно, на все можно найти обратные примеры.
На счет оплаты — я писала что стоимость тестировщика может быть выше стоимости кодера (!), а не программиста.
Из программиста можно перейти в тестирование, но я писала что «из ЛЮБОГО программиста тестировщик скорее всего не получится». Считается, что если ты программист, то ты с легкостью станешь тестировщиков — может и станешь, а может и нет.
Повторюсь из ответа автору выше:»Я очень хорошо отношусь к программистам, но не люблю когда гнобят тестировщиков. »
Я занимаюсь тестирование, а не QA. Я не занимаюсь качеством процесов, на это есть другие люди.
>> Автор написал усредненное мнение про тестировщиков (которых, как тут выше выяснилось, он никогда не видел), я написала что-то среднее в ответ. Конечно, на все можно найти обратные примеры.
Вообще-то, автор — Виктор Ронин, а тестировщиков в глаза не видел Woland. 😉
>> На счет оплаты — я писала что стоимость тестировщика может быть выше стоимости кодера (!), а не программиста.
Тогда нужно добавить, что в западных компаниях нет вакансии «кодер». Как минимум в приведённом мной примере у Google нет должностей с названием coder, так что опять не ясно, выше чем кто ценятся тестировщики в странах запада?
>> Повторюсь из ответа автору выше:”Я очень хорошо отношусь к программистам, но не люблю когда гнобят тестировщиков. ”
Согласен, сам не люблю, но это ещё не повод гнобить в ответ программистов. Есть и другие способы ведения беседы.
Ииии, жуть какая, извинения в первую очеред автору, напутала :(.
Ой, а где гнобили программистов???
Обьясните, по вашему кто такой кодер, а кто такой программист ?
Кодер — тот кто пишет поготовым алгоритмам. Проргаммист — разрабатывает в перую очредь концепцию написания и алгоритмы.
Хуясе. Ни разу не видел, чтобы отдельный человек «писал код по готовым алгоритмам». Это обычно для директорво секретарши под диктовку текст набивают. А программисты пишут код сами.
Попрошу следить за речью!
Просите, кто ж вам запретит.
По готовым алгоритмам это как ? Например, существуют разные алгоритмы сортировки, если человек использует один из них и реализует в коде программы, то он кодер или программист по вашему ? 🙂
Под QA я понимаю обеспечения качества процессов, их соотвествие стандартам качества.
Но если «QC — это лишь часть QA», тогда я занимаюсь и QA.
Спасибо 🙂 Все таки приятно, когда читатели аккуратно по пунктам все раскладывают, как сделал бы я сам :))
> считаете тестировщиков “второй сорт — не брак”
>Професионал понимает, что тестировщик делает работу не меньшую, и не худшую, чем >программист.
Я считаю тестировщиков людьми, которые умеют делать свою работу. Так сложилась ситуация, что их работа стоит меньше и она более проста чем у программистов.
Я не утверждаю, что она «раз плюнуть» или «меньше», я только говорю — более проста.
Скажем если вы будете сравнивать работу тестировщика с работой уборщицы. Вероятнее всего вы скажете, что работа тестировщика стоит больше, и более сложна. И я буду согласен. Это вполне нормальная житейская ситуация.
Насчет квалификации писал чуть раньше. Квалификация — это количество времени требуемого которые люди учаться, работают, для достижения нормального уровня. Входный порог у тестировщиков — ниже.
>cоветую почитать про автоматизированное тестирование. Этих людей в тестировании >немало и все они программируют, причем их задача усложняется, если спрограммированое >кое как — тогда оно просто не автоматизируется.
Я знал, что об этом вспомнят.
Я знаю, что такое автоматизированное тестирование. Замечу большинство (90%) тестов на порядок проще чем проекты средней сложности.
Таким образом 20% тестировщиков умеют писать код, который в 90% случаев будет проще среднего.
P.S. Мне кажется в свою очередь вы недооцениваете сложности программирования.
>Тестировщик должен мыслить системно, а большинство программистов 1) не программисты, >а кодеры, 2) дальше своего куска кода вообще ничего не знают.
Ведь эту же фразу можно и наоборот повернуть (указав, что большинство тестеров просто тыкатели в кнопочки для проверки).
Тут мы пытаемся сравнить программистов и тестировщиков примерно одного уровня.
В Украние нумерации не принято, а в штатах вполне есть
Software developer engineer I, II, II и аналогично для тестировщиков.
Специально для Виктора Ронина — вечно у вас темы, приводящие к долгим и жарким дискуссиям. Пол года сдерживал себя, просто читал. Пришёл терпению конец. 😉
Я случайно (шаркая ножкой) 🙂
Просто пытаюсь поднять больные темы, на которые сам несколько раз наступал. Ну и видно, ни один я на этих граблях побывал.
Чуть выше уже писал спасибо. ЕЩе раз напишу. Очень нравиться мне, когда люди пишут аргументировано и взвешенно (как вы) 🙂
> Смешно. “Автора не читал, но осуждаю.”
Мимо.
Тестирование продукта — работа программиста там, где нет тестировщиков.
И я никого не осуждаю.
> Соответствие ожиданиям заказчика — это ответственность
> QA. Тестирование на ошибки — QC. QC — это лишь часть QA.
А при чём здесь QA? Сам пост и весь тред — про QC.
> А ну, пример в студию? Какая нужна квалификация
> тестировщику, а какая — программисту?
Вам в каких единицах?
Если по-простому, то для тестирования программы на ошибки вообще никакой квалификации не нужно. Достаточно знать, как должна работать программа и как не должна. Чтобы эти ошибки искать, нужен некоторый багаж знаний. Но я могу предположить (именно предположить, см. п. 1), что QC может быть обучен на рабочем месте за два месяца из выпускника ВУЗа без опыта работы, а потолка в развитии достигнет (если достаточно умён) через полгода-год.
Промахнулся. Удалите, пожалуйста.
ЗЫ И каптча эта уже заебала, простите мой французский. Если промахнуться в капче, текст улетает в космос.
Да, уж у моей капчи действительно проблемы, но что-то ее и openid до ума руки не доходят довести.
вы сейчас на каком языке разговаривали???
ИНФОРМАЦИЯ ПОНРАВИЛАСЬ. ОТ КОМЕНТАРИЕВ ВОЗДЕРЖУСЬ
Виктор, хотелось бы отметить вот это место в Вашем тексте:
——
Почему-то в последнее время повеяла такая мода программистам побольше QC задач подкидывать и пытаться размыть границу между программистами и QC engineer (я дальше буду писать тестировщиком, хотя это и не идеально выражает то, что делают QC engineer’ы).
——
Замечание справедливое, такая тенденция действительно есть. В связи с чем вопрос — почему она есть? Не означает ли это, что задачи тестирования настолько усложнились, что теперь они требуют не меньшей квалификации, чем разработка? Ведь те, кто отправляют разработчиков тестировать тоже не дураки, и понимают про более высокую зарплату, но всё равно посылают. Почему?
Вы рассматриваете некоего «идеального» работодателя. В реальной же ситуации всегда не хватает денег, хочется сэкономить. Причём, сэкономить самым простым и очевидным способом — нагрузить уже имеющихся сотрудников максимумом задач.
Вдобавок очень часто можно увидеть желание работодателя заставить сотрудников работать сверхурочно и бесплатно. Несмотря на то, что это практически лучший способ демотивировать сотрудника и получить в результате вместо работы 4-6 часов в день (будем брать реальные цифры) 10-12 часов просиживания штанов.
Загадочный вордпресс сначала обругал меня кучей сообщений об ошибках MySQL, а потом вставил комментарий не сюда, а на верхний уровень. Впрочем, предыдущий комментарий был немного в сторону.
По существу вопроса: как я понял, Вы считаете, что эта тенденция объясняется тем, что работодатели стали почему-то на низкоквалифицированную работу назначать высококвалифицированных специалистов в стремлении сэкономить. Верно я уловил Вашу мысль?
Не так. Я не знаю, чем в такие моменты думают работодатели, но часто наблюдается картина, когда вновь появившиеся задачи сваливаются на уже имеющихся сотрудников вне зависимости от соответствия задач квалификации и загруженности сотрудников на тот момент. Как Вы понимаете, необходимость тестирования возникает гораздо позже начала разработки.
Могу предположить, что дело не просто в том, что эта работа возникает позже. Мне кажется, что Вы считаете менеджеров неспособными планировать и предвидеть, что эта работа возникнет, поэтому они не планируют выделение ресурсов для неё, в результате чего и приходится назначать на того, кто под руку попадётся. Я думаю, Виктор в своей статье имел в виду несколько другую ситуацию. И вообще, двигаясь в этом направлении мы сейчас оставим в покое тестировщиков и разработчиков и начнём гнобить их начальников 🙂
> Мне кажется, что Вы считаете менеджеров неспособными планировать и
> предвидеть
Я делаю выводы из того, что вижу :+)
А вы сами пытались выполнять работу менеджера?
Нет.
Вставлю свои 5 копеек в ваше дискуссию.
Woland>Вы рассматриваете некоего «идеального» работодателя. В реальной же ситуации всегда не хватает денег, хочется сэкономить. Причём, сэкономить самым простым и очевидным способом — нагрузить уже имеющихся сотрудников максимумом
задач.
В целом согласен. Особенно для не сильно опытных, или имеющих свои личные цели (не совпадающие с целями компании) менеджеров такой подход вполне част.
Screenshoter >Я думаю, Виктор в своей статье имел в виду несколько другую ситуацию. И вообще, двигаясь в этом Screenshoter >направлении мы сейчас оставим в покое тестировщиков и разработчиков и начнём гнобить >их начальников 🙂
Действительно я рассматривал ситуацию, когда менеджеры действую осмысленно и с благими намерениями. Хотя, я утверждал, что они заблуждаются.
В этом смысле Woland прав. Еще одна из ситуаций, которая может описывать, то что происходят, когда они действуют либо неосмысленно, либо с плохими намерениями.
Кстати, в обсуждении промелькнуло два слова «работодатель» и «менеджер». Замечу, у них могут быть абсолютно разные цели.
Работодатель (в случае, если он владелец фирмы) беспокоиться о долгосрочной перспективе (ну например 5 лет) гораздо больше, чем менеджер (который через 5 лет с 90% вероятностью будет работать в другом месте).
>Я делаю выводы из того, что вижу :+)
Извиняюсь, за легкое ерничество 🙂
Думаю желательно к этому добавить некоторое количество аналитики.
А то выйдет что-то в таком стиле «Я вижу, что деревья сбрасывают листья». Из этого делаем вывод, что деревья плохие и не заботятся о листьях 🙂
Если менеджер плохо выполняет свою работу, тому могут быть несколько объяснений:
— работа плохопредсказуема (из-за общего подхода в фирме)
— менеджер малоопытен
— менеджер злонамеренен
— менеджер выполняет работу хорошо, но со стороны этого не видно
и т.п.
Не стоит все их сыпать в одну корзину.
Я бы не сказал, что каждая тенденция выявляет какие-то внутренние правильные закономерности.
Из недавнего. Весь этот кризис с домами базировался на тенденции, что стоимость домов шла вверх. Как показала практика — в основном она шла вверх из-за спикуляций на разных уровнях.
Согласен, что тестирование усложняется. Но скорее это говорит, о том, что требования к тестировщикам должны расти, а не о том, что надо передвигать работу.
Victor Ronin> Согласен, что тестирование усложняется. Но скорее это говорит, о том, что требования к тестировщикам должны расти, а не о том, что надо передвигать работу.
А мне кажется, что всё совершенно логично, наблюдаемое «передвижение работы» является отражением этого повышения требований к уровню квалификации. Давайте разделим людей и выполняемую работу (ну или роли, или позиции).
Пусть у нас есть А.Белый, уровень квалификации 10, занимается разработкой, потому что эта работа требует квалификации 8. И пусть у нас есть А.Чёрный, уровень квалификации 4, занимается тестированием, потому что эта работа требует квалификации 3. И вот прошло время, требования к квалификации тестировщика возросли до 6, и теперь А.Чёрный не может заниматься этой работой. Что делает начальник? Предлагает А.Белому заняться тестированием, логично? Вот вам и «передвижение работы» Да, оверквалификейшен налицо, а что делать?
Кстати, именно это на мой взгляд является одной из причин того, что как уже упоминалось выше в комментариях, в некоторых компаниях квалифицированные тестировщики оплачиваются выше, чем ещё более квалифицированные разработчики. Дело в том, что А.Белому, с его уровнем квалификации 10 и благородным происхождением не хочется заниматься «чёрной работой». Да даже если бы у него было всего 7, а не 10, всё равно бы не хотелось, потому что при таком уровне квалификации он уже мог бы претендовать на должность разработчика! Ну вот и приходится работодателю перешибать эту породистость рублём.
Согласен. Только небольшое дополнение.
С точки зрения менеджера, то что вы описали, идеально описывает ситуацию.
Есть работа X и А.Белый и А.Черный, и самое важное с помощью их двоих выполнить работу X.
С точки зрения же предпринимателя, есть А.Белый и А.Черный и с их помощью нужно сделать как можно больше. И в таком случае, А.Белый должен заниматься работой с сложностью 10 или близкой, а А.Черный работой с сложностью 4. Если появилась работа с сложностью 6, то вероятнее всего, нужен еще один человек, чтобы не терять денег, на том, что А.Белый будет заниматься простой для него задачей вместо того, чтобы решать сложные (и вероятное более важные).
Да, действительно, кажется, что лучше всего назначать на работы исполнителей, наиболее соответствующих по уровню квалификации. Но тут есть целая куча подводных камней. С одной стороны, реальная действительность не всегда позволяет принимать идеальные решения. Но это мы даже обсуждать не будем, потому что есть и теоретические ограничения у этого подхода, именно на них я хочу обратить Ваше внимание.
Предположим, что мы таки решили, что для выполнения работы сложности 6 нерационально использовать А.Белого, у которого квалификация 10. Использовать А.Чёрного мы тоже не можем. Что делать? Давайте посмотрим, можем ли мы нанять для решения этой задачи Г.Серого с уровнем квалификации 7.
1. Нанятый работник не сразу выходит на «расчётную мощность», ему для этого понадобится месяц-два, поэтому если работа относительно краткосрочная, этот вариант не прокатывает.
2. Если работа долгосрочная, мы всё же можем нанять Г.Серого вместо А.Чёрного. Но через какое-то время эта работа заканчивается и снова появляется работа по тестированию сложности 3. Опа! Опять те же грабли — Чёрного мы уже уволили, поэтому приходится назначать на эту работу Серого.
Конечно, если у нас есть идеальный пул ресурсов, откуда мы можем людей с нужной квалификацией мгновенно брать и так же мгновенно возвращать туда, когда они больше не нужны — это здорово. При этом, чур, когда они «хранятся» в этом пуле, зарплату им платить не надо и есть они не просят. У кого-то есть такой пул?
3. Но и это ещё не самое страшное. Предположим, что у нас все работы длинные и сложность их постоянная. Оказывается, что даже в этой ситуации невозможно построить идеально сбалансированную команду! Для того, чтобы она эффективно работала требуется запас мощности. Причина этого явления кроется в статистических отклонениях от идеальной ситуации, которые есть всегда (подробно причины разбалансировки описаны в замечательной книжке Гольдрата «Цель», поэтому подробно писать про это не буду). И чем ближе по уровню квалификации будут задачи разработки и тестирования, тем чаще будут возникать перекосы. Математика, чёрт бы её побрал!
Полностью согласен 🙂
В целом — это и есть проблема, нанимать или не нанимать Г.Серого, в зависимости от предполагаемой будущей загрузки. И естественно эта величина хотя предсказуема, но не является гарантированной.
Единсвенную дополнительную вещь замечу. Чаще всего спихивают на программиста не задачу с сложностью 7, а задачи с сложностью 3.
Возможно это из моего опыта ситуации, но достаточно часто
а) Зачастую дается тривиальное ручное тестирование продукта ДО отдачи продукта QC.
Ручное тестирование по уже написанным тест case’ам это как раз задача даже не 3, а 2.
Обычно это делается с фразой «Для повышения качества и меньшего количество итераций между проргаммистом и QC)
б) Разобраться с плохо разобранным багом
Когда есть баг, но который плохо воспроизводиться.
Согласен, тут сложность уже пожалуй 5-6. Тем не менее, частенько баг могли бы и в QC раскрутить.
Опять же агрументируется «сбережение времени».
В целом, все пытаються сберегать абстрактное «время», а не вполне конкретные «деньги» или хотя бы «время до выпуска программы».
Тут уже подымался это вопрос: как свести к одной квалификации программиста и тестировщика? Или это какая-то стартовая квалификация?
Мне идея кажется где-то такой: есть учитель математики и учитель физкультуры (он как правило не такой умный как математик), кого надо напрячь вести урок труда?
Если же квалификация не начальная, то судя по примеру давайте уволим А.Чёрного и возмем А. НеТакогоЧерного с квалификаций 5 и походу работ дотянем до 6. Либо же сэкономим и выгоним А.Белого как человека с надмерной квалификаций и возмем А.НеТакогоБелого с квалификацией 8 — тогда 6 вполне войдет в его квалификацию.
Почитайте чуть выше мой комментарий про Г.Серого, я постарался в нём достаточно подробно описать, что будет, если последовать предложенному Вами решению.
Весьма странный способ сэкономить, Вы не находите? 🙂 Мне например он совершенно не кажется очевидным. Конечно, если разработчики простаивают, а работа по тестированию есть, тогда нужно отправить их тестировать, пусть хоть чем-то занимаются, это будет всё таки дешевле, чем оплачивать их простои в ожидании, пока тестировщики закончат свою часть работы. Но если программисты работают сверхурочно, да ещё может быть и премию придётся за это им дать или оплатить сверхурочные (по ещё более высокой ставке) — почему бы не нанять дешёвого тестировщика? Что, на такое умозаключение способны только идеальные работодатели? Лично я гораздо лучшего мнения о наших руководителях и бизнесменах 🙂
> Лично я гораздо лучшего мнения о наших руководителях и бизнесменах
*посмеиваясь* Это Вы зря. :+)