Почему тестировщики получают меньше?

«Ещё один узнал про TDD»
И у меня вопрос:
Я думаю, что человек, который пишет тесты, по умолчанию, должен знать больше того кто пишет код, который должен не валить эти тесты. Более того, он должен быть ещё и бизнес-аналитиком, поскольку в тестах зашита бизнес-логика. Кроме того, если тесты для MVC он ещё и пользовательский интерфейс должен понимать. Добавьте сюда интеграционные тесты и моки(?) из базы и мы получим архитектора.
Вместе с тем, мне кажется, что тестировщики ценятся ниже кодеров, во всяком случае по зарплате и по расхожему мнению, что тестировщиком может быть кто-угодно. Почему тестировщики получают меньше?

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Лучшие комментарии пропустить

Я думаю, что человек, который пишет тесты, по умолчанию, должен знать больше того кто пишет код

Дану? Он должен знать другое, просто другое, а не больше/меньше.

Кроме того, если тесты для MVC он ещё и пользовательский интерфейс должен понимать. Добавьте сюда интеграционные тесты и моки(?) из базы и мы получим архитектора.

Смешались в кучу кони, люди. ©

Вместе с тем, мне кажется, что тестировщики ценятся ниже кодеров

А вы сравнивайте КуА инженеров и Софтвар инженеров, а не абезянок которые набирают код и абезянок которые кликают мышкой.

А теперь заключительный аккорд:

«Ещё один узнал про TDD»

ТДД — это совсем про другое, а не про тестировщиков. Вы бы хоть определение прочитали, а не только расшифровку сокращения.

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

Весь вопрос в том, что те тестировщики, которые способны реально выполнять весь спектр SQA-обязанностей, включая автоматизацию и аналитику для создания адекватного тест-плана по требованиям, ценятся ничуть не ниже. А test monkeys, вся задача которых сводится к прохождению готовых тест-сценариев/написанию простых тест-скриптов, суть которых выплывает из UI, действительно стоят ощутимо дешевле, т.к. готовятся из кого угодно за пару недель.

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Это заблуждение, мне кажется. Простые «тыкальщики по кнопкам» ценятся меньше, а всякие автотестеры — на уровне разработчиков. Просто их чаще называют разработчиками с навыками разработки *-тестов.

Просто их чаще называют разработчиками с навыками разработки *-тестов.

Никто их так не называет.
И да, тестировщики автоматизаторы могут дотянуться до планки жава синьора, только знать нужно больше, и на вещи смотреть ширше.

А хто сказав що професіонали в тестуванні заробляють менше?

Може рівень зарплати залежить швидше від працівника, а саме від рівня наступних параметрів, які впливають на продуктивність, швидкість та якість виконання завдань:
— знання,
— досвід,
— аналітичні здібності,
— технічні здібності,
— вміння документувати,
— комунікабельні здібності,
— вміння працювати самостійно і в команді,
— організаційні здібності,
— рівень знань англійської мови,
— етика спілкування,
— уважність,

— вміння нести відповідальність за себе і за інших.

Якщо справді добре проаналізувати рівень заплат тест інженера і програміста то можна здивуватися, на користь тестера.

Скільки часу і зусиль треба прикласти програмісту, щоб заробити 1 і 5 к?

А скільки часу і зусиль треба прикласти тестеру, щоб заробляти стільки?

Зарплата також залежить від рівня компанії, та її рівня заробітних плат, від особистісного рівня працівника. В галузі ІТ часто рівень зарплати визначається коефіцієнтом корисної діі для компанії.

Для одної, Петро може бути працівником «номер один», а для іншої «одним з багатьох», то й зарплати будуть сильно відрізнятися.

Важливо осісти в «Своєму гнізді» :). А для цього треба працювати, бо найчастіше «Найкраще Своє Гніздо» можна створити лиш своїми руками.

А хто сказав що професіонали в тестуванні заробляють менше?

dou.ua/...-december-2011

Город:
Киев
Должность:
Senior Software Engineer
Язык программирования:
Опыт: 5 — 10+ лет
25th percentile
2500 $
Median
3000 $
75th percentile
3300 $
Город:
Киев
Должность:
Senior QA Engineer
Язык программирования:
Опыт: 5 — 10+ лет
25th percentile
1750 $
Median
2000 $
75th percentile
2400 $

исче вапросы?

исче вапросы?
Вы кол-во анкет (hint: 32 против 239) в выборке укажите, товарищ гений! У меня в подчинении не многим меньше QA-ев чем эта выборка.
Если нравится писать бред, вот вам еще один на «подумать»:
Город: Киев
Должность: Senior QA Engineer
Опыт: меньше года — 2 года
25th percentile
1000 $
Median
2300 $
75th percentile
2500 $
Город: Киев
Должность: Senior Software Engineer
Опыт: меньше года — 2 года
25th percentile
1750 $
Median
2000 $
75th percentile
3000 $

По медиане QA выше и что?

В общем — не пишите глупости, хорошо? Человек все верно описал!

Речь шла о специалистах, а не «senior-ах» с опытом работы в год. Очевидно что люди из твоей выборки никакие не специалисты и не сеньёры. Ну и колучество анкет в твоем примере(3) говорит о том что чья бы корова мычала.

3 пров 15 и 32 против 239 сильно отличаются в %-ом соотношении? (hint: проведенное выше еще хуже!)

Если вы не поняли мою иронию и суть сказанного и в этом, и в прошлом посте, извините.

Я понял твою иронию, но помоему вместо иронии у тебя получился маразм.
Я привел единственный доступный мне индикатор который описывает картину, если у тебя есть индикатор лучше, you are welcome.

Твои проценты вообще здесь побоку, подучи статистику.

подучи статистику.

Полностью взаимно, сэр!

А снизойти до обьяснения почему ты прицепился к процентам ты видимо не соизволишь?

Я привел куда менее «глупый» и куда меня лишенный смысла момент из «статистики» ДОУ в опозицию твоего примера, чтобы объяснить что это вообще не показатель.

В этой теме все изначально согласились что «среднее по больнице» у программистов выше.

Но попытались объяснить, что так далеко не всегда, и что есть исключения и их немало, и что зависят они от многих факторов. Вы же почему все равно продолжаете спорить отвергая очевидное, а некоторые люди просто откровенную чушь пишут, — по сути издеяваясь над профессией и постами.

Я не лечу проблемы самоутверждения, но вести дискуссию в «вашем тоне» мне попросту стало противно.

Понятно, слив засчитан господин балабол.

Процентное отношение тут ни о чем вообще. При чем тут ЦПТ и прочие доверительные интервалы, которые кагбе намекают нам, что выборки 3 и 15 можно сразу выбрасывать в мусорку, потому что точность у них ±полкилометра, на выборку 32 можно смотреть с некоторым интересом, но не слишком большим, а выборка 239 уже вполне адекватного размера. Как-то так.

Должность: Senior QA Engineer

Должность: Senior Software Engineer

Опыт: меньше года — 2 года

...баный стыд!

Опыт: 5 — 10+ лет 1750- 2000-2400 $
Опыт:
меньше года — 2 года 1750-2300-2500 $
И отсюда вывод — опыт работы куэю вредит!

Чота ржу. Статистика такая статистика :)))

Статистика такая статистика :)))

Статистика не ошибается, ошибаются люди которые ее не верно используют.

Так что проблема в «Cross-location QA Manager, CSC — Project Office в Ciklum», которые считают что можно использовать 3 испытания для того чтобы что-то обосновывать, это при том что всего результатов 62.

— Почему тестировщики получают меньше?
— по «щам»!

:)

Потому что на начальном этапе у кодеров больше знаний чем у тестеров. С профессиональным ростом до уровня Senior и выше — эта разница в з/п сглажевается и выходид на равные значения. (Как и все практические задачи, задача определения уровня з/п многофакторная и по сему здесь есть много «но» и «если»)

Неверно говорить: «арбуз стоит дешевле персика». Зависит от размера персика и арбуза, а также от страны и сезона.

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

Весь вопрос в том, что те тестировщики, которые способны реально выполнять весь спектр SQA-обязанностей, включая автоматизацию и аналитику для создания адекватного тест-плана по требованиям, ценятся ничуть не ниже. А test monkeys, вся задача которых сводится к прохождению готовых тест-сценариев/написанию простых тест-скриптов, суть которых выплывает из UI, действительно стоят ощутимо дешевле, т.к. готовятся из кого угодно за пару недель.

готовятся из кого угодно за пару недель.

Я все такие сказал бы что за пару месяцев, нюансов таки достаточно, но суть абсолютно верна!

Кстати вот, реальные программеры, реальные куа кто все находит, а вот почему то до сих пор не нашли и не исправили простой баг, который доводит до бешенства тех, кто пытается сделать онлайн заказ из Украины. Половина если не больше уважающих себя онлайн магазинов, да и такие сайты как аналог девайса, техас инструментса при оформлении онлайн заказа, не важно за деньги или так пару чипов нашару в выпадающем комбоксе списка стран не имеют такую страну как Украину, есть Гондурас, Уганда, ЮСА, а вот Украины нет... и уже много много лет этому багу и все ок. Так за шо тестерам деньги то платить :). Вот недавно теще лептоп покупали — опять попали на такой онлайн магаз, ну что стандартный вариант — вбили Россию-Одессу. А что делать млин.

Мне, конечно, не платят за тестирование зрения у посетителей ДОУ, но вот, к примеру, картинка с выпадающим списком с сайта техас инструментс — s403934162.onlinehome.us/ti.jpg

А вообще баги на тему того, что онлайн-магазы не хотят слать товары в Украину, хотя согласны на Уганду — это в верховну раду.

Вы так думаете, да ну вы что, это тупой баг который ваши братья по разуму не нашли, вот последняя попытка с нахождением такого бага из вот этого магаза
www.laptopauthority.com. И верховная рада тут вообще не причем, вам лишь бы на кого то спихнуть тупо, типа аут оф скоп.
С техасом и аналогом значит спутал еще с какой нить такой же конторой, где с семпелсами надо было через опу заказ делать.

последняя попытка с нахождением такого бага из вот этого магаза

www.laptopauthority.com.

Да-да, конечно. Этот комбик означает именно «мы случайно пропустили 125 стран при составлении списка и не заметили», а вовсе не «да в гробу мы видели что-то продавать во всякие туземные республики, в которых вообще электричества, наверное, нет». Очень убедительно.

Раскрой глаза: Уругвай, Венесуелла, Монголия, и т.п. реально думаешь то что пишешь. Еще раз повторюсь, это последняя попытка, что свежа в памяти, были в прошлом варианты, когда рядом стояла Уганда, Узбекистан и не было Украины, просто облом искать щас эти магазины, все равно ведь, тому кто не хочет чего то видеть, навряд ли расскроешь глаза.
Этот комбик может означать: девелопер взял комбик из проекта какого то студента, который туда вбил что нашел на своем глобусе, ему то пофиг, он учился на проекте, а программер поставил чтобы самому не писать такое. Я вот честно скажу, да да и я беру иногда либы у студентов, гуглю и беру. Вот пользовался парсером НМЕА недавно, работало. Правда пришлось переписать, когда на эмбеддед таргет поставил. Когда на писюке работало, не обращал внимания на 1% поедания проца, а на арме стало кушать 20%, переписал и щас кушает почти 0% на таргете.
Есть более профессиональные комбики, если конечно хочешь искать. Там есть например все страны бывшего союза, кроме Украины, есть все африканские страны (ну почти все). Странно что отрицаешь, наверное никогда в онлайне не заказывала.

Так что досвидос амигос, Джейн, Вы явно относитесь к той категории, о которой я вообщем то и написал. Если ткнуть носом, найдет 1001 блаблабла «почему не баг». Так что подумайте об этом, если хотите дальше профессионально развиваться. Лептоп то мы купили, читай «вставил место украины россию и город Одесса», никого ничего не смутило что оплатили из Украины вообщем то. Так что все таки баг.

Да можешь верить во Всемирный Тестеромасонский Заговор, который мы заключили, чтобы не продавать тебе лэптоп. Так даже прикольнее.

Вы мыслите стереотипами — «должен... не должен».
Уровень зарплаты как правило не всегда линейно зависит от уровня знаний.
Больше получает тот, кто смог себя дороже «продать», и в данном случае специальность тут не причем (тестировщик, программист или ПМ и тд).
Я знаю UX дизайнеров, которые получают на уровне матерых программистов.
Просто рынок диктует свои условия

Уровень зарплаты как правило не всегда линейно зависит от уровня знаний.

Уточнение: не зависит вообще!

не зависит вообще!
Не верное уточнение.
Ок. Опишите зависимость.
...

И все же вы правы, утверждение очень жесткое, корректнее: влияние данного параметра столь не значительно что им можно пренебречь.

Зависимость существует, больше знаний — больше ЗП.

Да, не всегда, да, есть исключения, да, иногда человек сам «виноват» что у него меньше чем он «стоит», но да — чаще всего именно «больше знаний — больше ЗП.»

влияние данного параметра столь не значительно что им можно пренебречь.

Нельзя. Тут объяснять не буду, даже не просите.

Хоть прошлое описание тоже априорно, но объяснять уж на столько очевидное, извините, напрягитесь сами.

чаще всего именно «больше знаний — больше ЗП.»

1) Какая ЗП у работника НИИ? Какая ЗП у среднего формошлепа в аутсорсе? Вот целый пласт людей которые опровергают ваше утверждение.
2) Есть еще один массовый пример ИТшники города Киева и того же Львова или Донецка.

3) Что уже говорить о социальных моментах (это отложим на потом)

но объяснять уж на столько очевидное, извините, напрягитесь сами.

Напрягся (хотя и не особо) и привел 2 контр примера, то есть квантор общности снят. Где же тогда общая зависимость?

Так же вы не показали что данная зависимость, если она существует, является хоть сколько значимой.

1. При чем тут знания в других сферах вообще? Или когда заканчиваются аргументы мы добавляем в суп все что угодно?
2.

Есть еще один массовый пример ИТшники города Киева и того же Львова или Донецка.

Аналогично первому, давайте еще ЗП Индии и США примешаем, а еще лучше вспомним что было 10 лет назат...

привел 2 контр примера,

Приведите еще кризис доллара в США начала ХХ века как пример дабы оправдаться.

Так же вы не показали что данная зависимость, если она существует, является хоть сколько значимой.

От того что я показал Вам или нет, поняли Вы или нет, существование этой зависимости никак не изменилось.

1. При чем тут знания в других сферах вообще?

Каких других. НИИ и аутсорс — это одна сфера. Разработка ПО.

давайте еще ЗП Индии и США примешаем

О то есть вы признаете что локация влияет довольно сильно. А если сравнивать еще и с США, то доля знаний вообще мала.

существование этой зависимости никак не изменилось.

Или НЕсуществование.

Yeah, sure, whatever!

Кстати, так же классный аргумент :)

Вроде никого и не оскорбил, и суть передал ©

А что еще Вам сказать?
Наши мнения кардинально расходятся.
Мои слова для Вас — не аргументы и не слышны Вами вовсе.

Ваши слова для меня — «салат» в который бросается все что угодно, и, по большей части, нон-сенс.

Что еще обсуждать тут?

Мои слова для Вас — не аргументы и не слышны Вами вовсе.

Слова я ваши слышу, а вот аргументов нет и на сколько я понял вы считаете что ваши утверждения и есть аргументы.

Что еще обсуждать тут?

Мммм... Сейчас в теме 256 комментариев, предлагаю добить до 1024 ;)

По этому я и не хочу продолжать дискуссию...

По этому я и не хочу продолжать дискуссию...

И снова не правда. Если бы не хотели, то не отвечали бы на коммент :)

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

Конечно в аутсорсе есть перекосы, когда аутсорс контора разводит крупного кастомера на новые вакансии или кастомер обещал аусторс конторе нанять людей, тогда может быть что угодно. И даже матерые сениор мануальные тестеры с зп 2800.

чушъ.

Для хорошего тестирования требуется несколько иной склад мышления, нежели у девелоперов.

если девелопер не может взять в штат толкового человека

Взять в штат может. Найти, заинтересовать и привести в компанию — далеко не всегда.

если девелопер не может нормально протестировать свое приложение

Если бы мог — не было бы такой профессии как QA :)

Вот скажите, вы занимались вообще «нормальным» трудоемким изнурительным мануальным тестированием с анализом спек, написанием тест планов, тест кейсов, и прогонами после каждого чиха ? Да большенство мозговитых программистов, которые привыкли задачи решать любых программистов, тупо помрут от скуки и убегут

торговать котятами

Девелопер не может нормально протестировать свое приложение. Это данность. Чужое может, свое нет.

Ясен пень, в MSF методологии разрабов вообще к тестированию и не подпускают. Чтоб не смухлевали :)

Девелопер не может нормально протестировать свое приложение.

Что значит «протестировать»? Написать условия проверки или выполнить эти условия?
Второе точно может — хЮниты всякие и тд.
Осталось написать правила — а это, де-факто, задача БА (в смысле роли).

Тестировщики, де-факто, закрывают недоделки БА и нехотелки ДЕВов.

1. Всякие *Unit-ы почти бесполезны при тестировании. Просто потому, что ими нельзя охватить ненаписанный код. По определению. Юнит тесты вообще пригодны только для двух вещей: для заказчика (показать, что сложные алгоритмы считаются согласно ТЗ) и для разработчика (точнее для удобства рефакторинга). Тестирование намного более общий процесс.

2. Бизнес-аналитики тут вообще ни при чем. Они пишут юзкейсы «как оно должно быть», юзкейсы «как моча пользователю в голову стукнет» они не прорабатывают. Это скорее задача архитектора, чтобы такие сценарии были исключены (по возможности). Ну и тестировщиков, естественно.

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

Просто потому, что ими нельзя охватить ненаписанный код.

А тестировщик может охватить НЕНАПИСАННЫЙ код? Если вы говорите о ЕЩЕ не написанном коде, то вы ошибаетесь, ибо возможно: Вы пишете тесты они валятся до тех пор пока код напишут.

юзкейсы «как моча пользователю в голову стукнет» они не прорабатывают.

Это скорее задача архитектора

Дану?

Задача анализа возможного поведения системы — это задача всяких БА и СА (коих ваапшэ мало).

«Протестировать» это значит пройти все логические пути в программе

Если цель только «пройти», то привет хЮнит и Селеним (с его наследниками).
КуА гордятсо тем шо они А, а не КуЦ, в основном потому что они не просто «проходят» они еще и «находят» всякие неточности/неопределенности.

А вот тут основная проблема: наличие этих самых «неточности/неопределенности». Что свидетельствует о не полной постановке задачи. И ваш же пример:

Причем ошибка приложения при ошибочных данных или ошибочных действиях пользователя также может являться ожидаемым результатом.

Это должно быть описано человеком который ставит задачу: должна выдаваться 500 ошибка пользователю или красивое сообщение о том что что-то случилось.

В общем задача:

Приведите реальный случай, когда КуА не заменимы. А не просто закрывают лень и/или некомпетентность разработчика и/или аналитика (человека который ставит задачу).

Приведите реальный случай, когда КуА не заменимы

А вы когда допишите какую-то шнягу, делаете глубокий интеграционный тест на последней версии системы? А если сосед еще не вчекинил свой овнокод? А регрессионное тестирование тоже делаете сами чтобы проверить, а не повылазили ли зафикшенные годичной давности баги? :)

? :)

Я просил случай, а не 100500 вопросов:

реальный случай

Добрый день Богдан,
1 Очень реальный случай: Веб приложение, которое через сторонний сервис передает банку логин\пароль\много_чего_еще\банку для авторизации пользователя.
Большинство банков используют набор полей по принципу «И».
Некоторые по «ИЛИ»

Один крупный международный банк сделал комбинированную — «И»+"ИЛИ"

2 Случился большой fuckup и не по нашей вине.

3 Благодаря регулярному и тщательному тестированию проблема была обнаружена быстро, когда заказчик и пользователи ее обнаружили, уже был готов фикс.
.....................

PROFIT!!

Один крупный международный банк сделал комбинированную

Бабах!
А как об этом узнали?
1) Инфа пришла от банка (или аналитика или шота в этом роде)? Тогда что мешало написать тест на эту ситуацию? Ведь это изменение спецификации.

2) Инфы от поставщика услуги, аналитика или кого-то в этом роде не было и тестер тыкаясь попал на эту ситуацию. Тогда поздравляю: вы сидите на бомбе которая может взорваться в любой момент, ведь следующую комбинацию, тестер может и не найти. :)

Тогда поздравляю: вы сидите на бомбе

Да, бомбу нашли и обезвредили. Написали специальный тест, который позволял находить такие ситуации автоматически — т.е. найти все похожие бомбы.

Результат: теперь подобное художество любого банка в мире будет иметь ограниченные последствия (пострадают только его пользователи, а все остальное будет работать)

Вывод: главное качество QC#QA — умение задавать глупыеправильные вопросы и понимать ответы на них.

главное качество QC#QA — умение задавать глупыеправильные вопросы и понимать ответы на них.

Основная мысль которую я пытаюсь донести:
Эти свойства должны быть у БА/СА/какого-тоА. И проблема часто в том что задачи ставят не достаточно продумано.

Фактически в вашем случае, КуА закрыли одну дырку в работе того кто ставил задачу, а может еще несколько не закрыли (от поэтому я не уверен что вы нашли все бомбы)

Если же вернуться к той фразе, на которую вы отвечали, то в оригинале она звучала так:

реальный случай, когда КуА не заменимы.

В вашем случае, КуА можно было заменить? ... Например, четкой постановкой задачи? (На мой взгляд ДА)

А на мой взгляд, то, что программист и пр. могут заменить тестировщика — это тот случай, когда правильное рассуждение приводит к явно нелепому результату, как в задаче про Ахиллеса и черепаху :) Ответ — можно или нет, зависит от каждой конкретной ситуации, как и ответ на вопрос — «Вы бросили пить»?

да не надо заменять, конечно нужны кюей инженеры, просто зп у них меньше.

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

Потому тут требуется

Нет. Ибо нет факта (с квантором общности) который необходимо опровергнуть. А ваше утверждение даже не противоречит моему утверждению.

Но все же:

реальный проэкт где наличие куа не дает бенефита.

Дальнейшие рассуждения делаются с оговоркой: не дает ощутимого или оправданного бенефита.
На данный момент я знаю несколько проектов которые утверждают что работают без КуА. В конце концов я сам работал на проекте где не было КуА, правда был довольно прямой контакт с конечными пользователями.

В принципе есть целый клас задач для которых КуА не принесут ощутимой выгоды — хорошо структурированные задачи, ибо проверка таких задач, как правило, хорошо автоматизируется, а корректность моделей, как правило, доказана.

QA\QC обеспечивают обратную связь. Насколько бы dev/ba/spec не были бы идеальными — обратная связь все равно будет нужна.

Ведь более мощный двигатель и более надежное рулевое управление в авто не делают тормоза ненужными?

Я могу своё тестировать, но мне не разрешают.

похоже, мои менеджеры этого не знают. Более 7 месяцев сами (разработчики) всё тестируем.

Я считаю, что єто все миф — что девелоперы обладают особым складом ума, который не дает им возможности, работать в определенных областях. Какой нужно склад мышления что — бы сотавить тест план и протестировать свой кусок фичи? Девелоперы всегда лучше кюея знаю и фичу и как она должна работать и принципи юзабилити и всего остального, просто иногда некоторые леняться, зная что тестировщик должен все протетсить.

Девелоперы всегда лучше кюея знаю и фичу и как она должна работать и принципи юзабилити и всего остального

Я выпал в осадок! :D

Странно что вы еще лучше PM-а не знаете как руководить проектом, и лучше Sales-а как его продать! :D

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

Нет. ПМ лучше знает как руководить, а сейлз — как продать.

Но при этом девелопер:

всегда лучше кюея знаю и фичу и как она должна работать и принципи юзабилити и всего остального

Ок :D

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

Странно почему... Ладно, ваше право, я осознал ваш случай, размеры ЧСВ и «любовь» к тестировщикам :)

Нет. ПМ лучше знает как руководить, а сейлз — как продать.
Но при этом девелопер:

всегда лучше кюея знаю и фичу и как она должна работать и принципи юзабилити и всего остального

А в чем тут противоречие ?ПМ лучше девалопера знает как руководить, а сейлз лучше знает, как продавать.
Но при этом девелопер, который разрабатывет фичу, знает ее лучше чем кюей.

Покажите, в чем тут противоречие?

Удивительно то, что вам все понятно с Сейзами и ПМ-ами, а с тестировщиками — нет.

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

И уж тем более не знает как это все полноценно и эффективно надо сделать.

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

Вы для начала попробуйте мануально потестировать некоторую фичу блекбоксом (без знания кода вообще).

Потом сравните свой результат с результатом нормального куея. А потом будете здесь расказывать :-)

Вы знаете, я имел опыт тестирования с знанием кода, и без знания кода.

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

я это делал и не раз). Тестировал сам, когда было время, и не хуже кьюея. Правда не все кейсы покрывал (просто было лень с окружением возиться)

Предложите уволить QA-я и делайте его работу сами, — получив +++ к ЗП, почему нет?

Очень хочу посмотреть, что будет дальше с продуктом и его качеством! ;)

в некоторых продвинутых конторах типа фейсбука и гугла именно так и делают.

Почему не делают у нас тогда? :)

Я же предлагаю — попробуйте!

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

Ну и подход когда программист занимается автоматическим тестированием предполагает некоторую инженерную культуру слабосочетающуюся с потогонной системой большинства аутсорсеров.

То есть — не делают потому что сейчас это по сути не возможно и/или не выгодно, и/или не получается :)

Я, кстати, не только Аутсорсинг имел ввиду.

Еще интересный момент, — почему на odesk и других ресурсах тонны QA и запросов на них? Клиенты и компании по всему миру тоже делают «не верно» вешая эти задачи не на своих программистов, а нанимая QA? — или как?

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

Ну тогда почему весь мир не рационален до сих пор, раз все так просто, а? :)

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

И весь на столько глуп, что все на это ведутся и не понимают «обмана» или как? :)

А может таки есть другие причины этому? ;)

Есть, я их даже уже перечислил.

То есть помимо перечисленных вами, — нет других причин?

Помойму рациональней держать одного человека, чем постоянно переписывать, и дописывать автоматические тесты.

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

В любом случае скидывать «ношу» по поддержанию автоматезированных тестов на программистов реализующих собственно функционал, имхо, не рационально. Тут, если нет политики прогнать юнит-тесты перед коммитом, то поддержание даже юнит тестов — становится проблемой :-)

Ну я ж и говорю, это все зависит от уровня инженерной культуры в компании.

QA на которых — в первую очередь,

а пишущий и поддерживающий пачки автоматизированных тестов.

В классической классификации таких людей называют engineer in test. Ну и это все не отменяет того что 95% QA занимаются обезьяньей работой по вбиванию данных в формы согласно тест плану.

Предложите уволить QA-я и делайте его работу сами, — получив +++ к ЗП, почему нет?
Если я буду делать работу QA, то кастомер и аустосрс контора будет терять часы работы девелопера, что не вариант.

Увольнять конечно же не надо. Кюей — инженеры конечно же нужны, просто получают меньшую зп, чем девелоперы.

Очень хочу посмотреть, что будет дальше с продуктом и его качеством! ;)

Естественно качество упадет, но если уволить девелоперов, то продукта не будет вообще. Продукта не может быть без девелоперов. Пока еще роботы не научились кодить, вот когда научаться, тогда может и тестеры будт получать больше.

Что значит — качество упадет? Ладно еще, если продукт- игрушка, но если продукт нужен для жизни и работы — считайте, что его и нету. Вот вы, к примеру, будете жить в шатающемся домике? Хирург будет делать операцию тупым лезвием? Поэтому девелоперы обязательно выделят из своей среды человека, который будет тестировать их продукт. И, скорее всего над проектом он работать не будет — у тестирующих свои проекты глаза зашорены. Так что, как не крути, а от тестера вам избавиться не удастся :) Если б пользовались продуктами роботы, то тестировать можно было б поручать полностью роботам. Но пока еще есть «особо одаренные» юзеры с извращенной логикой, надежнее, если тесты проводит человек.

я ни разу не сказал что кюей инженеров надо избавляться. Так же считаю что никакая автоматизация не может заменить ручное тестирование.

Увольнять конечно же не надо. Кюей — инженеры конечно же нужны, просто получают меньшую зп, чем девелоперы.

Основное, что я имел ввиду- это то, что экономически обоснованая зп кюа и тестера ниже чем зп девелопера.

Я поняла про зарплату. Просто, скажем так, в некоторых случаях некачественный продукт — аналогично отсутствию продукта. Что как бы уравнивает в правах тестера и девелопера :). Если серьезно, зарплата тестера — забота конторы и лучше регулируется рынком, чем какими то логическо-моральными рассуждениями — оставьте их социалистам. Если девелоперы допускают много ошибок, зарплата тестера вырастает и наоборот...Если сейчас зарплата тестера увеличивается быстрее, чем зарплата программиста, значит или мы глупеем, или растет сложность программных продуктов. Какие могут быть претензии к НТР?)

чушь. надо чтобы было не безразлично, а не иной склад ума.

Опят таки — у вас есть опыт нормального ручного тестирования, в сравнении с парнями которые «умеют это делать» ?

Работала и Куа, и девелопером. Все — успешно. Вопрос — у меня два ума?

Нет.

Я работал гитаристом и водителем. И что?

Алексей, если вы не поняли, мой ответ на слова Grez’а

<quote>
чушъ.
Для хорошего тестирования требуется несколько иной склад мышления, нежели у девелоперов.

</quote>

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

п.с. иногда лучше промолчать, чем оставлять комментарии типа «я настолько нелогичен, что стол, конь, двадцать восемь».

Так, к чертям все эти ПыСы в контексте открытого обсуждения.

Уж прекрасно я видел, кому был адресован комментарий, а вот вы мой комментарий зачем-то снизвели до пресловутого «я настолько нелогичен»...

Вы как пример — совершенно не пример. Это алогичность из разряда «Я живу в Киеве, и ни разу не был обкраден ворами в общественном транспорте, следовательно, в Киеве карманников не следует опасаться».

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

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

Что вы подразумеваете под успешностью? Факт получения зарплаты, и не быть быстро уволенным?

Какой страшный мир, вокруг одна

чушъ

и

чущь

Когда вменяемые аргументы закончились, пошол бессмысленый флуд. Мы же всетаки разумные прогроммисты :-D

пошол бессмысленый флуд

А я думал тут вся тема «бессмысленый флуд». Или вы тут серьезно говорите? :)

Ну я хоть и тролю, но местами выражаю свою точку зрения... Видимо это всетаки бессмысленно :-(

Но, подобный спор будет иметь смысл когда манагер скажет «Нафиг вам куа? пишет юнит-тесты сами!»

«Нафиг вам куа? пишет юнит-тесты сами!»

Опа :)

Вопрос: Какое отношение КуА имеют к юнит-тестам?

Но вы же сами сетуете за то чтобы заменить КуА юнит тестами, иль я чегото непонимаю ?

за то чтобы заменить КуА юнит тестами

Кто сказал?

Кроме юнит-тестов есть еще много других тестов.

да да да. Какие из них вы предлагаете возложить на плечи программистов ?

Какие из них вы предлагаете возложить на плечи программистов ?

Все. Точнее на плечи программистов и аналитиков. Типа любое требование или пункт в спеке — это тест.

Мануальное тестирование тоже ?

Нет.

А зачем оно надо если спецификации полные, при этом они переведены в спеки (тесты)?

А затем, что, например, баги, связанные с некорректным отображением веб-интерфейса крайне паскудно автоматизируются, в итоге дешевле держать человека, который руками проклацает и просмотрит кучу страниц в разных браузерах и скажет «тут чего-то не так», нежели городить огород по автоматизации оного процесса.

И затем, что некоторые вещи практически невозможно автоматизировать малой кровью (классический пример задачи — получение информации с акселерометра/гироскопа на Android).

И затем, что, например, в системах, связанных с безопасностью, было бы неплохо делать penetration testing.

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

баги, связанные с некорректным отображением веб-интерфейса крайне паскудно автоматизируются

Да. Вывод: Вставляем мозг дизайнеру, шоб не придумывал всякой хны и делал простые («чистые») интерфейсы. И пользователь выиграет и тестить проще.

получение информации с акселерометра/гироскопа на Android

Пишем код, покрываем его тестами и тогда единственная проблема остается в «поломанном оборудовании или прошивке» (по телехвончикам не спец, так что уточните где проблема)

penetration testing

А вот это уже совсем другая история и спецов которые этим занимаются я бы не назвал тестерами.

привлечения для этого же «поклацывания» штатных разработчиков.

Это, БЛ...!, их (то есть наша) прямая обязанность! Снова привет ТДД, БДД.

дешевле

А тут смотря как считать :) Сильно большой человеческий фактор. И говорить «я шас наговняю, а они найдут» — не эффективно. При этом если разработка хорошо настроена, то тестеры — это «лишние» затраты, а если плохо — то даже с тестерами можно классно попасть.

P.S. Приятно видеть новые лица в этом уютненьком сраче :)

Да. Вывод: Вставляем мозг дизайнеру, шоб не придумывал всякой хны и делал простые («чистые») интерфейсы. И пользователь выиграет и тестить проще.

Слишком много случаев, когда так сделать не получится: например, если используются сторонние библиотеки элементов управления: проверка их функционала на корректность отображения во всех средах, предусмотренных спецификацией — задача ОЧЕНЬ плохо автоматизируемая и времязатратная.

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

(по телехвончикам не спец, так что уточните где проблема

Проблема в том, что единственный способ получения изменяющейся информации от акселерометра/гироскопа — физически крутить телефон, эмулятор не позволяет подать ему команду «а ну-ка поверни девайс на 40 градусов по оси y». Строить манипулятор о шести степенях свободы на сервомоторах с программным управлением — идея, бесспорно, крутая, но не слишком дешево- и быстрореализуемая.

Это, БЛ...!, их (то есть наша) прямая обязанность! Снова привет ТДД, БДД.

Это может быть хорошим подходом в том случае, если целевая платформа одна (либо адаптации под каждую из целевых платформ значительны). Вернемся к тем же веб-приложениям: положим, у нас в требованиях корректное отображение в ФФ, Хроме и Сафари на 3 последних мажорных версии назад. Опять же — положим, что время, затрачиваемое на тестирование одной из комбинаций занимает N часов. Что эффективнее — провести developer test на основных направлениях силами разработчика (положим, по одной из комбинаций «браузер-версия»), а остальное — отдать тестировщику, если зарплата оного в полтора раза ниже разработчицкой?

говорить «я шас наговняю, а они найдут» — не эффективно.

Сложно переоценить влияние умолчаний в требованиях. Одним из источников возникновения таких умолчаний является то, что не так часто разработка представляет собой реализацию некоего ISO или RFC в абстрактной среде, а разработчики не ознакомлены со всеми особенностями всех возможных окружений. Приведу прекрасный пример из жизни: жила была АРМ-система, которая представляла из себя веб-сайт. Одной из её функций была скромная кнопочка «напечатать страницу», каких-то дополнительных требований к этой функции не предъявляли — она должна была работать на тех Windows-системах, где принтер в системе установлен стандартным образом. И вот внезапно начинают поступать жалобы от пользователей — печатает, дескать, в искаженном виде, все сжато по вертикали. Фокус оказался в следующем: веселые разработчики IE8 решили, что у всех существующих на планете принтеров DPI по вертикали и горизонтали — одинаковый, например, 300×300. При этом нигде (в релиз-нотах или на мсдн-ах) об этом не уведомили. А принтера у пользователей отличались крайней матричностью и имели три установки DPI, из которых «квадратного» не было ни единого. Предупредить такую ситуацию можно было бы исключительно имея огромную базу тестовых конфигураций, на которых нужно было бы провести (и проанализировать результаты выполнения) приличного количества тестов, при этом эта работа совершенно не требовала бы квалификации разработчика.

сторонние библиотеки элементов управления: проверка их функционала

ЧАВО?!! Мо и ОС надо протестировать, мо там баги есть ;)

единственный способ получения изменяющейся информации от акселерометра/гироскопа

Почему не подходят моки/стабы?

положим, у нас в требованиях корректное отображение в ФФ, Хроме и Сафари на 3 последних мажорных версии назад.

Берем компы на которых сидели (должны сидеть) тестеры и запускаем Силениум и Ко.

веселые разработчики IE8 решили, что у всех существующих на планете принтеров DPI по вертикали и горизонтали — одинаковый, например, 300×300.

И сколько человеко-часов вы в результате потратили на то чтобы исправить баг ИЕ?

И вот внезапно начинают поступать жалобы от пользователей

Оказывается никакой тестер не гарантирует что 100% багов будут найдены, «так зачем платить больше?»

ЧАВО?!! Мо и ОС надо протестировать, мо там баги есть ;)

Желание иронизировать на эту тему резко пропадает, когда одной из составляющих проекта становится какая-нибудь community-driven компонента. Под GPLv2, например, и поставляющаяся with no warranties. :) Более того, есть такой интересный этап в жизни проекта — «тестирование и уточнение требований», очень важный для тех случаев, когда заранее неизвестно, возможна ли реализация задуманного на выбранной платформе и возможно ли её сделать «прямым» методом или же придется ставить приличное количество костылей. Вот на нем зачастую приходится в каком-то смысле тестировать и ОС — точнее, те её части, с которыми придется соприкасаться.

Почему не подходят моки/стабы?

Потому что по сути все, что мы знаем об акселерометре/гироскопе — в каком формате он отдает данные, какой диапазон данных он в принципе способен отдавать и дискретность, с которой сенсор в принципе может эти данные получать. В итоге у нас получаются следующая проблема: Android как бы далеко не RTOS и если производитель чипа заявляет, что сенсор передает показания раз в 10 мс, это вовсе не значит, что раз в 10 мс мы гарантированно получим эти самые показания. Более того, 10 мс легко превращаются в 100-200 мс. Вдобавок к этому, нужно ещё и собрать кучу данных о реальной кинематике поворота, которые нужно предварительно намерить. Плюс проверить все терминальные случаи (самое простое — переходы через условные нули сенсора). И только собрав вот такую пачку данных для каждого из целевых устройств, уже можно говорить о каких-то моках.

Берем компы на которых сидели (должны сидеть) тестеры и запускаем Силениум и Ко

И что нам покажет Селениум и Ко? Это как бы средство для функционального тестирования, поплывший интерфейс он не оттестирует никоим образом.

И сколько человеко-часов вы в результате потратили на то чтобы исправить баг ИЕ?

Пару дней переписки, чтобы локализовать конфигурацию, на которой случается проблема, и три часа на «гугл по вопросу».

Оказывается никакой тестер не гарантирует что 100% багов будут найдены, «так зачем платить больше?»

Особой прелести ситуации придает то, что именно на этом проекте выделенных тестировщиков не было.

Под GPLv2, например, и поставляющаяся with no warranties. :)

Да, конечно. Ведь это так правильно тянуть в проект какую-то хну с не понятным поведением.

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

Разве мок должен моделировать обект? Он вроде как должен моделировать ситуацию. Если есть информация что время отклика будет 100500 мс моделируем это на моке. А вариант написать код в расчете на 10 мс, и после закрытия задачи получить баг шо не работает на 100 — это не метод. Тут проблема в том что не был проведен анализ.

поплывший интерфейс он не оттестирует никоим образом.

Не относитсо. Я отвечал на это:

привлечения для этого же «поклацывания» штатных разработчиков.

---

Пару дней переписки, чтобы локализовать конфигурацию, на которой случается проблема, и три часа на «гугл по вопросу».

Вместо того чтобы сказать «пшолты»? Кстати, а время на фикс бага?

Особой прелести ситуации придает то, что именно на этом проекте выделенных тестировщиков не было.

А он бы однозначно спас ситуацию. Ведь он не «тупой» аналитик который не смог учесть, что:

А принтера у пользователей отличались крайней матричностью и имели три установки DPI, из которых «квадратного» не было ни единого.

Суть в том что всех багов не пофиксишш.

Те примеры что вы привели лишь подтверждают, что часто тестеров используют, чтобы заткнуть дыры в анализе. Так не будет ли правильнее провести нормальный анализ, за шо же платят деньги всяким БА и СА?

Да, конечно. Ведь это так правильно тянуть в проект какую-то хну с не понятным поведением.

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

Разве мок должен моделировать обект? Он вроде как должен моделировать ситуацию.

Правильно. Только «ситуация» в данном случае — не «отклик через 100500 мс», а «девайсом трясут пять секунд». И сбор данных с сенсоров в подобных сценариях для дальнейшего анализа этой информации — задача, как я уже говорил, достаточно плохо автоматизируемая, т.к. трясти девайс надо руками.

Не относитсо. Я отвечал на это

Да как же не относится, когда относится. «Проклацывание» в данном случае — это не манки-тест разной степени осознанности, нажали на ссылку — получи ошибку, но и просмотр того, что, собственно, рисуется. Не сличать же, в самом деле, скриншоты с эталоном.

Вот как бы ещё один пример плохоавтоматизируемой задачи (точнее — частичноавтоматизируемой): есть CAD-система. У неё, в частности, есть функционал экспорта-импорта в кучу форматов. Причем тестировать надо не только «файл сохранился без ошибок», но и то, что мы, собственно, экспортировали. Документация по форматам может быть неполной или реализация конкретного формата может различаться в тех системах, куда идет экспорт.

Ведь он не «тупой» аналитик

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

куда более разумно взять тот же openssl и проверить его работоспособность в необходимых условиях.

И это делает разработчик, ДО начала кодинга.

а «девайсом трясут пять секунд».

А 6? А 7? А 777? А теперь другой рукой? А если Марс в 9 доме Юпитера?

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

Да. И это часть анализа. Это должно быть в требованиях. Если вы говорите о закрытом формате, то никакой тестировщик вас не спасет от того что завтра его поменяют и исправить это будет не возможно. Смысл в баге который нельзя пофиксить?

что под аналитиком вы подразумеваете того человека, которого часто называют Test lead

Под аналитиком, я подразумеваю того кто пишет спецификацию, и это явно не тест-лид.

А 6? А 7? А 777? А теперь другой рукой? А если Марс в 9 доме Юпитера?

Открою, наверное, страшную тайну: одним из важных моментов в процессе тестирования является поиск момента, когда мы можем остановиться. Для очень большого числа задач 100%-е покрытие возникающих ситуаций не просто не нужно, но и невозможно, поэтому важно определить тот набор тестов, который будет достаточным для обеспечения работоспособности на таком уровне, что дальнейшее тестирование и багфикс будут стоить дороже потенциальных убытков из-за получаемых багов. И определением этих границ зачастую заняты совсем не разработчики, а различного рода аналитики, которых вполне оправданно относят к SQA.

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

Смысл в том, что здесь и сейчас бага не будет. Пример все о той же CAD-системе. Есть такой формат DWG, который поддерживается компанией Autodesk. Совершенно любой производитель CAD-систем может экспортить/импортить в него, не приобретая у Autodesk их официальных библиотек для работы с этими файлами: можно использовать спецификации Open Design Alliance, можно реверс-инжинирить файлы, сохраняемые AutoCAD (единственное, чего «нельзя» — пытаться обмануть систему валидности, которая разделяет файлы от кого угодно и от Autodesk/официальных лицензиатов. Периодически Autodesk меняет некоторые составляющие этого формата, но делает это не часто (раз в год-два), т.к. изменение форматов потребует раздачи новых версий библиотеки всем лицензиатам, а от лицензиатов — выпуска патчей/новых версий своих продуктов. Соответственно, протестировав экспорт-импорт один раз, риск потери совместимости сильно уменьшается на значительный промежуток времени.

Под аналитиком, я подразумеваю того кто пишет спецификацию, и это явно не тест-лид.

Спецификацию (если имеется в виду Software Requirements Specification) по-хорошему пишет очень не один человек — к ней так или иначе прикасаются и бизнес-аналитики, и разработчики, и SQA.

Кстати, особенная прелесть работы «без SQA» начинается на многомодульных проектах. Есть полдесятка тимов, каждый из которых пишет свой, условно независимый модуль. Когда же это все собирается в кучу, возникают очень и очень интересные вопросы: пара модулей динамически связывается с разными версиями одной библиотеки, которые не очень хорошо уживаются в системе, общая конструкция не влазит в память: для обнаружения таких проблем не нужен ещё один тим разработчиков — нужен в лучшем случае один разработчик, который может донести информацию до других тимов и разработать адекватную интеграционную стратегию (причем её лучше бы разработать ДО кодирования) и энное число людей, которые просто проведут интеграцию на всех целевых платформах и смогут оценить то, что там происходит.

а различного рода аналитики, которых вполне оправданно относят к SQA.

Не понимать. Человек который ставит задачу, какое он отношение имеет к КуА?

к ней так или иначе прикасаются и бизнес-аналитики, и разработчики, и SQA.

А еще админы, продавцы и чертизнакто. Это все не важно. Есть спецификация. Бывает что спецификация гуано, но это уже проблема процесса в целом, и КуА здесь скорее костыль чем лекарство.

И вот ваш пример:

Пример все о той же CAD-системе...

Проблему того что не отслеживаются (не существуют) изменения сторонней системы с которой интегрирован продукт, заменена костылем в виде КуА который запустит новую версию и скажет работает/нет. И это вместо того чтобы узнать у официального поставщика когда и что меняется.

Не понимать. Человек который ставит задачу, какое он отношение имеет к КуА?

Человек не ставит задачу. Человек определяет, насколько задача выполнена. Вполне себе QA.

Есть спецификация.

И есть пределы детализации спецификации. Т.е. спецификация обычно включает в себя:
— функциональные и смежные (производительность, время наработки на отказ) требования
— требования к интерфейсам

— требования к окружению

Вопрос в том, что делать полное покрытие тестами для всех возможных комбинаций входных данных и окружения — в большинстве случаев, ересь, т.к. временные и человеческие ресурсы ограничены. Соответственно, нужно определить, что в данном случае более важно, что менее, чем вообще на данном этапе можно пренебречь. Использовать для этих целей разработчика, конечно можно, да вот только есть нюанс — разработчик, который способен выполнять такой анализ, будет стоить ощутимо дороже Test Analyst’a, а встречаться — ощутимо реже.

И это вместо того чтобы узнать у официального поставщика когда и что меняется.

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

Человек определяет, насколько задача выполнена. Вполне себе QA.

Еще раз: процесс проверки возможно автоматизировать, при том большую его честь. Поэтому саму проверку выполняет компутер, а описывают эту проверку аналитик и разработчик.

покрытие тестами для всех возможных комбинаций входных данных и окружения

А разница в покрытии? Оно одинаково, просто в моем случае это делает машина, а в вашем человек.

да вот только есть нюанс — разработчик, который способен выполнять такой анализ, будет стоить ощутимо дороже Test Analyst’a,

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

Нятно. Экономим на качестве.

процесс проверки возможно автоматизировать, при том большую его честь.

А меньшую — нельзя. Забьем?

А разница в покрытии? Оно одинаково, просто в моем случае это делает машина, а в вашем человек.

В обеих случаях это делает человек. Просто в вашем случае автотесты пишут те же люди, которые непосредственно создают новый функционал/устраняют дефекты, а в моем случае — выделенные.

Нятно. Экономим на качестве.

Максимизируем прибыль за счет снижения себестоимости конечного решения.

А меньшую — нельзя. Забьем?

А она всегда есть. И на нее всегда забивают.

а в моем случае — выделенные.

Есть еще одна разница:
В вашем случае, ошибку находят через некоторое время *после* закрытия задачи.

В моем случае, это всплывает на этапе разработки (а то и раньше).

А она всегда есть. И на нее всегда забивают.

Всегда забивают на меньшую часть. Не всегда забивают на ту часть, которую не автоматизируют.

Есть еще одна разница...

Внедрить непрерывное тестирование совсем никогда не получится?

Юрий, забейте, это не имеет смысла.

Даже если вместо гороха в «стену» вы будете кидать кирпичи — это не поможет.

Пусть уважаемый Богдан убеждает свое руководство в своих «гениальных взлядах». А еще лучше, — на практике пусть все свое мышление применит, тогда может изменится «замыленное теоритическим бредом» отношение к такой профессии как QA.

Юрий, забейте, это не имеет смысла.

Alexander Kuznyak, это трололо-тред, он не может иметь смысла «по-умолчанию»!

Пусть уважаемый Богдан убеждает свое руководство в своих «гениальных взлядах».

Нахнадо?! Это ж тогда работать прийдетсо. А так я могу чегота наговнять и дальше «общаться на ДОУ» :)

Смысл есть :) В первую очередь — расширение кругозора, я совершенно не исключаю случаев, к которым не применимы практики, полученные на собственном опыте.

Тестировщики начинают получать гораздо больше кодеров, когда становятся PM-ами, etc. А становятся тестировщики разнообразными PM-ами чаще кодеров. Потому что:

по умолчанию, должен знать больше того кто пишет код

Возможно, не больше,а немного другое

он должен быть ещё и бизнес-аналитиком

пользовательский интерфейс должен понимать

и пр.

А где, извините, корреляция между тестер — бизнес-анализ и тестер — UX-эксперт? Нет! Точно так же и с программистом.

Корреляция, имхо, в различии задач. Задача девелопера — написать, чтобы работало хорошо. А задача тестировщика — сравнить ожидаемый и фактический результат. То есть , в идеале, сравнить то,что ожидает пользователь с тем, что получилось. Вот если то, что получилось, хорошо работает и отвечает ожиданиям — продукт получился.

Обладание знаниями об ожиданиях — корреляция, если проще.

То есть таки нет, или чего хотели сказать?

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

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

Заказчику легче общаться с таким же как он, да :)

Человек который лучше знает продукт — это человек, который дольше проработал на проэкте (если не штаны конечно протирал). Хотя за весь оутсорс, конечно, не скажу...

мидл автоматизатор и синьор .нет девелопер

Lead automation QA, который получает ЗП больше чем Team Lead девелоперов

Вывод: в конторе .net-чики — л...хи? ;)

Этот пост не троллинг, а реальная возможность заработать

;)
А нечего улыбаться и подмигивать, тут БЛ....!!!! плакать хочетсо.
Lead automation QA, который получает ЗП больше чем Team Lead девелоперов
Team Lead — это должен быть человек который направляет разработку продукта и в некотором плане и авто-тестирование.
Lead QA — это должен быть человек который управляет качеством (да, да именно УПРАВЛЯЕТ и именно КАЧЕСТВОМ).

Кто БЛ.. такой «Lead automation QA»? Человек который руководит группой людей, основная задача которых даже не создание стратегических моментов тестирования, а просто реализация некоторого тактического направления.

Сержант получает больше полковника! БЛ.. не рынок, а писец БЛ...

Тут, ИМХО, зависит от меры ответственности. Навряд-ли тестировщики тестируют программный продукт по ночам, и в праздники :) И как насчет овертаймов?

Тут, ИМХО, зависит от меры ответственности.

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

Но это все в моем идеальном мире, а на практике кто наглее у тому и бабла больше дают.

Навряд-ли тестировщики тестируют программный продукт по ночам, и в праздники

Это уже совсем другая история. Если ПМ и соответствующий лид налажали, то и такое может быть.

Почему бы и нет? Отвецтвенность за пропущенный в продакшн баг в первую очередь должны нести тестировщики :-)

Отвецтвенность за пропущенный в продакшн баг в первую очередь должны нести тестировщики

Смотря что за баг конечно, но в большинстве случает — да.

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

по аналогии из реального мира — именно поэтому и медсестра получает меньше хирурга, так как она это вспомагаетльное звено, без которого можно обойтись.

Времена меняются. Тестирование, становится сложнее. Иногда явно сложнее программы. Написать форму с двадцатью чекбоксами просто, а проверить какой вариант вызовет падение — уже сложнее. Написать отправку писем — два пальца об асфальт, написать тест который не позволит посылать невалидные письма — гораздо сложнее.

Аналогия не такая примитивная. Скорее, надо сравнивать больницу и страховую компанию и их доходы.

который не позволит посылать невалидные письма — гораздо сложнее
Невалидное — если емыл получателя не подходит под регулярное выражение емыла? Или в сабже и в письме матюки, а самого ресипиента не существует? Как два пальца, еще на этапе разработки
Если ваш модуль занимается не только отправкой но и валидацией то вы нарушаете принцип единственности ответственности.
Совершенно нет никакой уверенности что кто-то попытается отправлять письма не через ваш модуль PochtalyonPechkin. Либо кто то напишет «лучшую» сортировку, которая будет резать всё после собаки. Уже после вашего шикарного модуля который всё знает и всё умеет.

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

Я так понимаю, что исторически идея тестов так и сформировалась.

то вы нарушаете принцип единственности ответственности

Вы ж .net используете? SmtpClient прост как полено, и под него какую-то иерархию городить типа один проверяет, другой сортирует, третий все это херит и т.п. смысла ИМХО нет. Сортировка емыл адресов получателей вообще бессмысленна — быстрее получателю не прийдет :) Любой паттерн тут можно вхерячить бессмысленно, даже цепочку ответственности :) Ну может вы извращенец и предпочтете реализовать smtp протокол на сокете, аттачи вручную конвертить в base64, я ж не знаю :)

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

Вы не любите кошек? Может, вы просто не умеете их готовить?

Написать форму с двадцатью чекбоксами просто, а проверить какой вариант вызовет падение — уже сложнее.
А написать так, чтобы падения не было, — это нет, никак не получается? Ну, тогда да — тестировщик достоин большего , чем девелопер.

Ни у кого не получается. Если конечно голова бизнес-аналитика не весит больше тонны и не использует водяное охлаждение.

Не понял, к чему тут голова бизнес аналитика, головы то будут пухнуть у девелоперов и тестировщиков. А вот у бизнес-аналитиков, когда они рожают идеи таких форм, ничего не болит. Нечему просто болеть.

А почему HR (точнее рекрутеры) зарабатывают меньше программистов? Ведь без них не было бы и программистов в компаниях!

нужно сравнивать только программиста и тестировщика

я отталкиваюсь от темы и содержания поста:

Почему тестировщики получают меньше

Я полагаю, что сравнивается именно тестировщик и программист.

Косвенно сравниваются...

В топике об том только:

мне кажется, что тестировщики ценятся ниже кодеров

А «ценится» не равно «платят меньше» :)

В общем — суть в том, — что поднятая тема — странна.
Я написал аналогичный пост про рекрутеров где провел туже «параллель в аргументах», что и постеры ниже — что якобы без программистов нет продукта, а без QA-я есть.

Я же сказал что без Рекрутеров не было бы Программистов в компаниях, тогда почему в этом случае они получают меньше программистов? :)

были бы, рекрутеры не нужны

едь без них не было бы и программистов в компаниях!

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

А почему HR (точнее рекрутеры) зарабатывают меньше программистов?

То же, кстати, не факт.

Да я вообще с вашей колькольни все путаю постоянно.

То же, кстати, не факт.
Разница в ЗП HR-Developer как минимум в 2-3 (а иногда и в 5-10) раз больше чем QA-Developer. Конечно есть исключения, скорее всего, но их на порядок меньше, или даже на два порядка.

Так что мой «не факт» куда более «факт», чем то, что описано автором. Скорее даже — «больше чем факт, так это было на самом деле!» ©

Да я вообще с вашей колькольни все путаю постоянно.

Я 5 минут читал это предложение, так до конца и не понял.

Это утверждение о том, что я утверждаю, что вы что-то путаете? Если да то где я такое говорил?

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

Сообщение выше. Остальные мне просто искать лень.

TDD

А причем сдесь TDD к тестировщику?

TDD — это же методология разработки, и исходя из неё человек сперва пишет тест, а потом пишет код. Есть разные виды тестирования, вы о каких тестерах говорите? О мануальщиках или автоматизаторах?

Честно, не видел людей, которые имеют должность тестеров и при этом сидят и клепают юнит тесты для существующего кода... Не могу понять, от куда вы сюда TDD прилепили... Есть один, но он джуниор девелопер, но не тестер...

Оно в кавычках. Это эпиграф.

Я получил представление из комментариев о тестерах, их видах, ореолах обитания, и примерном круге обязанностей, а также о положении вещей в наших широтах.

А что, обязательно было ради этого создавать холиварную тему? Почитать «Принципы, паттерны и методики гибкой разработки на С#» Мартин/Мартин, в которой TDD и тестированию вообще посвященно несколько глав не судьба?

Там не о том тестировании рассказывается.

Таковое тестирование достаточным не является, если софтом будут пользоваться живе юзеры.

Ареалах, а не ореолах :)

тагда не паймёт втарая, бесграматная палавина пасититилей. стотистека утвирждаит что они важнейе.

А я видел. Кажется бредом, но такое бывает — отдельные тестировщики покрывают юнит-тестами существующий код. Так сам Заказчик захотел...

Тогда это уже разговор о «лычках».
Переиначу пословицу: хоть лохом назови, только зарплату плати.

По той же причине почему Java и .NET в среднем получают больше, чем PHP. Всему виной — спрос, предложение и количество времени, необходимое для достижения определённого уровня.

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

Кстат актуальная тема: что должно стоить дороже рыба или мясо :)

Альберт, у Вас талант поднимать трафик на сайте.

Вы бы могли на этом делать деньги.

Ви б оперували якимись цифрами. Ато все якось сухо получається.

С цифрами я бы сразу ответ знал и было бы неинтересно.

Почему тестировщики получают меньше?

Наверное потому что работу разную делают. ^_^

Почему водитель и пилот получают разную ЗП?

Кстати, тестер, тестеру — рознь.
Пообщайтесь с HRами and хэдхантерами как они за синьорами охотятся.
А еще попробуйте найти тестера автоматизатора. Например QTPшника с хорошим опытом.

Ну или performance/load/stress тестировщика.

Найти специалиста! Вот ключевая фраза. Все хотят найти готовое. А самим подготовить специалиста и удержать? А?

Ну это уже повод для следующей темы :-)

А самому подготовиться и на плаву удержаться?

Да не вопрос -так и делаем. Только я не про внутренние курсы и что-то там такое, что происходит в некоторых больших компаниях.
Я конкретно про опыт в работе. Его нигде не получишь, если не возьмут ПЕРВЫЙ раз без опыта. Кто-то то берёт.
А товарищи, хотят уже готовенькое.
А тот же QTP в отличие от Селениума стоит денег. (ну можно раздобыть нечестную версию наверное). Но реально , не поработав в нём над кусочком проекта, все красивые видео уроки и мануалы только и останутся базовыми знаниями.
Много ли в Киеве юзают QTP? Может быть юзают, но по просмотренным многочисленным вакансиям практически только один Эпам и юзает .

И потом они хотят взять готового специалиста с хорошим опытом.

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

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

Я конкретно про опыт в работе. Его нигде не получишь, если не возьмут ПЕРВЫЙ раз без опыта. Кто-то то берёт. А товарищи, хотят уже готовенькое.

Вы появляете очень «студенческое» видение и понимание обсуждаемого процесса.

Вот, ОС Windows тоже стоит денег. И что?! :)

Выходит, что теститровщиков сейчас будет побольше к количеству рабочих мест и вновь открываемых вакансий, поэтому и зп меньше

по моему из-за ЗП квалифицированных тестировщиков не найдешь

Феномен как раз обратный — квалифицированных тестировщиков сложно найти.

Неквалифицированных — хоть каждый день набирай/увольняй...

Альберт Толоконников, имейте совесть!

Набросайте хоть немного, а то все свалили на плечи общественности. Нехорошо однако.

Почему тестировщики не находят все баги??? Им же за это и платят!!! Каждый должен заниматься своим делом!!!

Невыгодно :) Найдут все баги — останутся без работы :)

ага фигли разработчик должен проверять свою работу, для этого тестировщики есть.

тсс.... А то услышит ПМ и заставит программистов документацию писать

Ну например программист Java EE это Core Java, Servlet API, EJB, Spring, Hibernate (все с тысячестраничными мануалами )ну и SQL зачастую еще и CDI, JSF, GWT, JAXRS + паттерны, алгоритмы, computer science и рабочий опыт(а это и AS’ы и svn’ы всякие), тестер же это пара книжек по теории + опыт. То есть стать разработчиком сложнее и дольше чем куэейем, при этом надо обладать не только складом ума но и специфическим характером, а стать квалифицированным разработчиком еще тяжелее, из этого вытекает дефицит кадров и дороговизна рабочей силы.

Раз уж Вы в топике снизу выступили grammar nazi, то я тоже себе позволю :)

тысячастраничными

а тестировщики нужны чтобы находить вот такие ошибки в программерском коде :)
Правильно писать «тысячЕстраничными».

Сейчас начнётся холивар, что тестировщика заменит любая проверка орфографии, но всё-равно я не соглашусь :)

Java EE это Core Java, Servlet API, EJB, Spring, Hibernate (все с тысячестраничными мануалами )ну и SQL зачастую еще и CDI, JSF, GWT, JAXRS + паттерны, алгоритмы, computer science и рабочий опыт(а это и AS’ы и svn’ы всякие

Вау, сколько ты баззвордов знаешь. :)

Я и другие знаю — катаморфизм, хиломорфизм, квазицитирование, эндофунктор, монадный трансформатор, карринг, бета-редукция. Я вообще Senior Buzzword Engineer.

Было бы странно, если б Сталин не был-бы марксистом.

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

«Ещё один узнал про TDD»

нет, похоже не узнал.

А что бывают спец выделенные тестировщики, которые чиста юнит тесты пишут? Ну это тогда программист-тестировщик.

Логика подсказывает, что написать код который по спеке тупо вход-выход сверяет (пусть и с моками) всяко легче чем собственно решать алгоримико-архитектурные задачи (на должном уровне).

По поводу цен могу скзать по поводу «кнопочкотыкательных» тестировщиков, коим я сам когдато был. Здесь просто обычный замкнутый круг. Люди хоть с какимито мозгами восновном переходят в программисты, или какиенить буснес-аналитики, тупо потому что там больше платят. Отаеться зброд который, ничего кроме как потыкать в кнопочку по спеке и не могет. За что ему многа платить ? :-)

Если бы я бы был заказчиком я бы платил за результат, а не за процесс. Тестер должен в первую очередь стрелять. У нас в одесском Л работала девушка очень заметная, сейчас иммигрировала в НЗ, вот она находила кучу багов, которые очень влияли на перформенс проекта, вообщем то весь перформенс держался на ней, хотя она была и есть манки тестером (посмотрите кстати ролик манки вс автоматчики). Мои три орла, которые были в моей команде, получали вообщем то побольше ее, но они не нашли и 1% на троих от того, что нашла та девушка одна... Как то даже были неприятное разговоры с заказчиком, он находил баги в нашем коде через минуту после включения девайса. А в это время, мои орлы находили псевдо-баги на автоматизации. Уберите мануальщиков из команды и вы получите продукт, который будут оплевывать все кому не лень, включая и вас. Так почему им надо платить меньше, только потому что они на кнопки нажимают :), они работают и делают свою работу, вычищают перформенс продукта. И кстати, не так уж это и просто на кнопки правильно нажимать. Без определенного подхода все это будет впустую, за год ни одного бага не найдете. Вообщем то, в моей команде были несколько хороших разработчиков, которые выполняли работу тестера (манки) в нужном объеме и у них вообщем то проблем не было, были разработчики, которые писали прогу и отдавали ее без раздумий нашим трем орлам, и потом заказчик матерился и все такое... ну или та девушка находила и тогда ситуация сглаживалась.

Еще раз повторюсь, зп с мануальщиками вообщем то связана со спросом-предложением. Намного проще найти адекватного тестера, намного сложнее программера. ЗП у автоматчиков выше как дань моде на автоматизацию у наших компаний. Рейт у тестера и программера одинаковый на входе в Украину, проверьте или поверьте.

Все верно, только это вы должны не мне отвечать, а Богдану ниже по поводу автоматизации тестирования.

Не очень понял про трёх орлов. Они были автоматизаторы? Если автоматизаторы, то они не должны были находить кучу багов, а должны были автоматизировать уже разработанные тесты. А если она были тестировщиками, но всё время тратили на не нужную автоматизацию — то это проблема управления ими.

Из тестеров делаются норм ПМы.

А не по то му ли это, что потерять хорошего дева куда хуже чем хорошего КуА?

у них времени больше свободно базарить с клиентами — вот и назначают их ПМами

Из тестеров делаются норм ПМы.
 в унылом аутсорсе

Заглянув в бухгалтерские отчеты у заказчика, вы бы увидели, что и тестеру и программеру (одинакового ранга) платится одинаковый рейт, более того, заказчик вообщем то это и не скрывает, потому что (говорю за большую букву Л и ХБ) по ведомостям проходят такие позиции как Junior Engineer, Engineer, Senior Engineer (другими словами, тестеры и девы маркируются одинаково). Так что и тестеров и девелоперов ценят одинаково, по крайней мере со стороны заказчика. Разница может появиться уже на местном локальном рынке из-за того, что найти нормального тестера проще, чем такого же адекватного разработчика. Знаю по своей бывшей команде в Одессе, намного проще было закрыть позиции тестировщика, чем программера, последний раз с разработчиком был вообще мего фейк, искали 6 месяцев, из которых 4 заказчик мог платить рейт, а человека не было... вот такие вот пироги.

Патамушта их в принципе тупо больше, чем программистов.

Причин тому много.

Например, тестирование бывает разное. Термин существует один, а применяется по-разному у программистов и у непрограммистов. Соответственно и оплата бывает разной.

Например, термин «повар» общий, но бывают повара в жральне для дальнобойщиков, а бывают повара в Ritz или Aragawa — вообще разные уровни приготовления вроде бы обычной хавки.

Я, конечно, не уверен на все 100%, но может из-за того, что программист может заменить тестера, а тестер программиста — зачастую нет? По личному опыту: у нас тестеры просто, следуя тест кейсам, «проклацивают» функционал... Им вообще никаких знаний по программированию не надо в данном случае.

Как это не странно, либо программисты (если тест не стандартный), либо используют стандартные, которые применяются для данного типа тестирования и написанные и заапрувленные какой-то командой ранее (аля псевдостандартизация)

Как это не странно, либо программисты (если тест не стандартный),

Такое вообще не надо. Программист сам себя может проверить.

Тогда, канешна, платить не за что. Манки — они и есть манки, хоть тестировщики, хоть девелоперы.

Тот же, кто пишет функциональные (и нефункциональные) спеки.
В теории хорошая спека — половина кода и прямо готовый тест кейс.
Но это в теории. Потому что функциональные спеки обычно присылаются в виде куцего вордовского файла.

Потому что многие тестеры не программируют.

Тыкают в кнопки, пишут тест кейсы в ворде. То, что называется «Ручным тестированием».

За счет них средняя ЗП тестеров ниже, чем у программистов.

внезапно — тестируют :)

Логичнее было бы назвать их испытатели или дегустаторы.

Senior QA может получать и побольше джуниор-девелопера.

Senior QA может получать и побольше мидла-девелопера.

Не достаточно оскорбительно. Надо было:

Senior QA может получать и побольше джуниора-девелопера.

Как бы правдивость не нарушает и трололо-эффект больше. :)

«Не достаточно» пишется в данном случае слитно.

Мльо, дайте хтось тестера, вже 3 роки їх не бачив, впадло свої баги самому шукати ((

Потому что программисты одновременно работают и тестировщиками — на этапе, пока пишут свою программу и производят отладку кода. 99% процентов своих багов находят они же) Вот и получается — за две профессии и зарплата больше))

именно. Тестировщик должен получать столько, сколько бы программисту за тестирование, если бы тестировщиков вообще не было. Тоесть допустим программист в день получает 60.у.е. Допустим прогрммист заэстимейтил фичу на 4 дня. 3 дня он разрабатывает фичу а один день кликает и проверяет, что все работает с разными сцанариями. Тоесть 3 разработки 1 день тестирования. Так вот — тестировщик должен получить только за этот день, тоесть 60 у.е за 4 дня.

Вы все жжоте я смотрю! :)

Но почему? Может я немного прувеличил в примере. Но я не вижу економических причин что бы платить тестировщику зп большую чем прогаммисту.

Но я не вижу

Вот в этом и суть. Если вы не видите — это еще ничего не значит :)

Вариаций и нюансов очень много, но, естественно, как писали ниже — «среднее по больнице ЗП» у дэвелоперов выше, но далеко не всегда. QA QA-ю — рознь, как и дэвелопер дэвелоперу!

Ну если вас не затруднит приведите пару примеров, которые подтверждают, что тестер должен иметь большую компенсацию. Для меня очевидно, что тот кто создает продукт и функционал, за который будут платить, тот и должен получать больше. Может этот функционал будет сырой, но есть взаимодействие с кастомерами, хелпдески, эскаляции. И баги будут найдены и пофикшены. А тестировщик не может создать продукт. Так почему он должен получать больше?

что тестер должен иметь большую компенсацию.

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

По большому счету вы не так уж неправы — просто в описанной вами ситуации ПМ (если он, разумеется, пребывает в здравом уме) нанимает одного тестировщика на трех девелоперов и платит ему за те же три дня. В реальности, в предположении, что ПМ продолжает пребывать в здравом уме, он быстро соображает, что из трех дней тестировщик полтора дня курит бамбук (поскольку специализация и разделение труда увеличивают производительность), увеличивает соотношение до 1:5 и имеет профит, который, собсна, и является обоснованием для найма специально обученного тестировщика :))

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

Предположительно там же, где ПМы не в здравом уме... то есть не в объективной реальности.

Иногда кажется, что объективная реальность, — это где все поголовно бамбук курят, а не наоборот.

У нас с вами разная объективная реальность...

Объективная реальность не может быть разной :)

Однако ее характеристики могут изменяться в зависимости от места наблюдения.

Реальность (то, с чем личность соглашается) может быть разной, это безусловно.

Объективная реальность быть разной не может :)

Спасибо, Кэп. Однако же (поясняя по простому, по рабоче-крестьянски) в объективной реальности вокруг меня может быть +30 и пальмы, а вокруг вас, к примеру, −30 и айсберги.

Не находят программисты и 5% своих багов. Программист работает в описанном сценарии использования, для него важно, чтобы заработал именно этот сценарий. Что за пределами описанного юзкейса программиста не волнует совершенно. Он даже не представляет, что там может быть и как пользователь может поступить. Но все баги именно там. Это задача мануального тестирования — прогнать все возможные сценарии использования (даже откровенно идиотские) и показать программисту те, в которых его работа вылетает.

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

Че вы вот это все «обязан то, обязан се».
У нас например было совсем наоборот — программеры смотрели на глобальную картинку, где, кто с чем и почему взаимодействует, и даже где теоретические косяки могут вылезти. И передавали эту инфу мануальщикам. А они уже потом тупо по кнопочкам клацали.

Че вы вот это все «обязан то, обязан се».

Слово «должен» я употребил только один раз.

У нас например было совсем наоборот — программеры смотрели на глобальную картинку

Это даже теоретически невозможно. Не может программер реализовывать функционал, находясь за пределами этого функционала. Он всегда «в задаче», у него работа такая. Поэтому глобальную картину он может оценить только на чужом проекте.

Что за пределами описанного юзкейса программиста не волнует совершенно

Вот-вот, это просто самая боль! Откуда взялась эта идея, что программер обрабатывает только основной сценарий, и занимается альтернативными только когда его как нашкодившего котенка ткнут мордочкой, где нагадил?!

Откуда взялась эта идея, что программер обрабатывает только основной сценарий, и занимается альтернативными только когда его как нашкодившего котенка ткнут мордочкой, где нагадил?!

Из десятилетнего опыта работы программистом.

Вопрос скорее риторический. Я тоже это наблюдаю постоянно. Но во многих областях, напр. в системном программировании, в mission critical никакой QA в этой ситуации не спасает. Качество все же должно быть задачей программиста. Для себя ищу (и нахожу) области, в которых это имеет значение.

А качество работы программиста, вообще говоря, достаточно слабо коррелирует с количеством багов в программе. Согласно Глассу, 35% багов это отсутствие логических путей, 40% — это уникальное их сочетание. Эти вещи вообще никак от программиста не зависят. В первом случае он не может протестировать несуществующее (и автоматическими тестами это никак не ловится), во втором случае у него нет физической возможности (времени) для полноценного тестирования. То есть, по факту, программист отвественнен максимум за 25% багов в программе.

Согласно Глассу, 35% багов это отсутствие логических путей, 40% — это уникальное их сочетание

Где об этом почитать подробнее?

Взгляд программиста, имеющего опыт работы тестировщиком.

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

А ответ — потому что, чтобы протестировать, необходимо меньше принимать решений, меньше знать алгоритмов, паттернов, не надо думать о памяти, производительности, мультипоточности, совместимости браузеров, да и поддержка поддержка тест-сьютов дается легче поддержки кода, одним словом — думать приходится меньше. Да и разобраться в чужом тест-кейсе проще, чем в коде коллеги.

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

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

Ну а ТДД — инструмент программиста. Из вашего поста я понял, что вы считаете, что юнит тесты пишут тестировщики. Это не так. Прочитаете книгу Кента Бэка «Разработка через тестирование». Ну и, по моим наблюдениям, программисты, пишущие тесты, получают больше не пишущих, так что в чем-то вы правы.

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

и

Ну а ТДД — инструмент программиста. Из вашего поста я понял, что вы считаете, что юнит тесты пишут тестировщики. Это не так. Прочитаете книгу Кента Бэка «Разработка через тестирование».

Вот! Спасибо Вам за эти слова!

не надо думать о памяти, производительности, мультипоточности, совместимости браузеров

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

Ну а ТДД — инструмент программиста.

Опять унылое «write test first, eat doshirak next». Чушь все это, от багов не спасает.

По опыту самые страшные баги — по невнимательности. От этих — спасает.

Самые страшные баги, это которые от недостатка квалификации разработчика. От этих ничего не спасает, даже тестеры. :)

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

Звонит такой себе Виджай Кумар из QA в Индии и говорит: «Мы не знаем, как эту фигню тестировать. Я тут беседовал с Викторией Смит, нашим аналитиком, она тоже не знает. Но вы же девелоперы, вы же программили это все, уж вы то знаете, чего пользователи хотели»

потому-то без программиста ничего не будет, а без тестировщика — будет.

Вы реально считаете что если нельзя продлить аналогичную цепочку вверх и очень далеко и при этом многие «высшие» звенья в определенных случаях будут получать меньше определенных «низших» звеньев?

Извините, но вы какую-то глупость написали...

Все профессии нужны, все профессии важны © А выдергивая из цепочки звено, причем любое — вы её рвете ;)

а без тестировщика — будет.
Извините, но вы какую-то глупость написали...
А почему глупость?
Есть бизнес-требования, есть их реализация. Всякие там БДД и тд. Тестировщик как участник команды, вполне заменяется средненьким компом с ЦИ-сервером.
Факт в том что для средних и больше проектов, КуА могут давать много пользы не делают их необходимыми.
Или я что-то упускаю? Если да, то что именно?

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

Тестировщик как участник команды, вполне заменяется средненьким компом с ЦИ-сервером.

Почему до сих не заменили их тогда? Куда дешевле было-бы! :D

Почему до сих не заменили их тогда?

Кто сказал что не заменили? На небольших проектах довольно часто заменяют. На больших, проблема в том что покрытие тестами далеко от 100%, а спецификации не формализованы. Есть еще ряд нюансов, среди которых:

КуА могут давать много пользы

Речь была именно о необходимости, а не просто о пользе.

Куда дешевле было-бы!

А вот тут БАПМ. Делаем вывод что тестировщики дешевле чем средненький комп с ЦИ-сервером (это троллинг, если кто не заметил :) )

Какая чушь, простите :)

EPAM, Luxoft и GlobalLogic у вас должны курс лекций брать на тему «замены тестировщиков

средненьким компом с ЦИ-сервером

... а так же расскажите им что эти специалисты работают исключительно из-за «нюансов» :)

А вот тут БАПМ

А вот тут — фиг вам. Если бы заменили — было бы дешевле, да. А так — это лишь ваши фантазии и личная не приязнь к профессии (это факт, если кто не заметил) :)

EPAM, Luxoft и GlobalLogic у вас должны курс лекций брать на тему

А Циклум шо уже всех заменил? :)

А в общем им это и не выгодно, ибо с тестировщика маржа есть, а с ЦИ-сервера нет, разве шо там парнуху хостить.

Если бы заменили — было бы дешевле, да.

Еще раз: Заменяют и вполне благополучно. Процесс это не быстрый, так как нельзя заморозить разработку и полгода писать тесты.

и личная не приязнь к профессии (это факт

Не, не. Слабенько. Сразу на личности, ну шо дети.

... ну про ОЧЕНЬ ценное время программиста и про низкий порог входа в тестирование, я наверное отложу на завтра :)

А Циклум шо уже всех заменил? :)

Ciklum-у Ваша чушь не интересна, простите :)

Еще раз: Заменяют и вполне благополучно. Процесс это не быстрый, так как нельзя заморозить разработку и полгода писать тесты.

Ага, вполне успешно!

Не, не. Слабенько. Сразу на личности, ну шо дети.

Все мы в душЕ дети :)

ну про ОЧЕНЬ ценное время программиста и про низкий порог входа в тестирование, я наверное отложу на завтра :)

Отложите что вам угодно, мир и суть вещей от этого не изменится.

Ciklum-у Ваша чушь не интересна, простите :)

В Циклуме не используют ЦИ? Девелоперы не пишут тесты? Мо у вас еще и код на фтп хранят и без всяких там систем контроля версий? :)

В Циклуме не используют ЦИ? Девелоперы не пишут тесты? Мо у вас еще и код на фтп хранят и без всяких там систем контроля версий? :)

Ciklum-у Ваша чушь не интересна, простите :)

Не читайте между строк.

Боюсь, что заказчику трудно «продать» упомянутый «средненький комп с ЦИ-сервером». Зато тестировщиков можно продать вагон.

Кто сказал что не заменили? На небольших проектах довольно часто заменяют.

На небольших проектах и девелопмент часто джумлой заменяют...

На небольших проектах и девелопмент часто джумлой заменяют...

Нет.
На «не сложных» — заменяют. А я говорил о не больших, то есть о тех в которых ЕЩЕ нет много функционала. Тут основная проблема в том что если уже есть много кода не покрытого тестами, то покрывать его довольно напряжно.

А больших проектов (лет 5+ и релизов 10+) которые от самого начала, да по всяким ТДД и БДД их очень мало, я еще не видел.

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

крайне теоретическое представление о проектах, которые прям с самого начала по ТДД и БДД

Знаю про пару проектов до пары лет, утверждают шо у них нима тестировщиков.

И есть у меня сильное подозрение, как эта команда будет называться

Clover?

www.atlassian.com/...clover/overview

А теперь важный вопрос:
Так ли необходим выделенный человек (или тем более команда) для того, чтобы следить за тем бизнес-требования переведены в тесты/спеки?

Где та ниша которая делает КуА (отдельного человека, а не просто роль), не просто полезным, а необходимым для проекта?

Еще раз — необходимы на этой планете только сборщики риса, все остальное делается для удобства и упрощения жизни.

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

все остальное делается для удобства и упрощения жизни.

Ок.
Я хочу се инет-магазин забацать, шоб упростить продажи ... носков, например. Как это сделать без девелопера (человек который правит шаблоны для джаёомлы и человек который написал джомлу — девелоперы)? Ну или убийцу фейсбука?

Как убрать КуА, я вроде как предложил, а вот как выкинуть разработчика, пока не придумал.

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

Джумлу разрабатывал не «девелопер», а целая тима, в которой, подозреваю, без КуА не обошлось. И кстати, если считать настройку джумлы девелопментом, то куа вообще девелопят, рук не покладая. Это я вам со всей ответственностью, как человек, который джумл в жизни поперенастраивал пожалуй больше, чем куэил.

мост анжинерной работы прям до городу Парыжу забацать

Не залик. Возвращаемся к моему инет-магазинчику с носками. Какое отношение ваш мост к ниму имеет?

подозреваю, без КуА не обошлось.

Если даже отбросить слово «подозреваю», то КуА здесь это всего лишь особенность организации конкретного процесса 7-летней давности.

если считать настройку джумлы девелопментом

девелопментом в смысле производством. Допустим, мы считаем что навыки пользования каким-то специализированным ПО — это девелопмент.
То есть девелопер таки необходим.

А что в это время делает КуА?

Какое отношение ваш мост к ниму имеет?

Да примерно такое же, как сайт на три страницы и пять посетителей к профессиональному тестированию. Естественно, на проекте в 40 человекочасов (из них 10 на тестирование) тестирование не переломится и девелопер сделать. Или жену попросит мышой поклацать. Хотя... пилили мы тут давеча хомяк на сотню посетителей и забили на тестирование, так, сверху прощелкали... ох, и проблем огребли в итоге, мамадарагая!

навыки пользования каким-то специализированным ПО — это девелопмент.А что в это время делает КуА?

Очевидно же, что в этих странных пресуппозициях куа девелопит. Поскольку «имеет навыки пользования специализированным ПО» и даже им пользуется. Выглядит, правда, ваша концепция странновато...

как сайт на три страницы и пять посетителей к профессиональному тестированию.

Ок. Международный инет-магазинчик на 100500 страниц и тд.
Все сценарии описаны в спеках, которые написали БА.
Проверка выполняется ли спека происходит на ЦИ.

Для чего в таком процессе нужен КуА? (В ваших терминах: Зачем напрягать жену клацать мышкой?)

пилили мы тут давеча хомяк на сотню посетителей

Что такое хомяк?

Поскольку «имеет навыки пользования специализированным ПО» и даже им пользуется.

И что это за ПО, в контексте инет-магазинчика.

Надо таки добавить оговорку: ПО для производства инет-магазинчика.

Все сценарии описаны в спеках, которые написали БА.

А вокруг по радуге бегают розовые единороги. Почему бы тогда сразу не предположить, что девелоперы никогда не ошибаются? Тогда и ЦИ не понадобится.

Что такое хомяк?

Жаргонное пренебрежительное название для небольшой домашней страницы (от хоумпейдж)

И что это за ПО, в контексте инет-магазинчика.

Ну, например, административный раздел ЦМС, на которой крутится интернет-магазинчик. Там вообще-то настройка, администрирование и тестирование — почти близнецы-братья. Хотя я продолжаю не понимать, почему вы, собственно, уперлись в интернет-магазинчик — других задач не существует?

Ну, например, административный раздел ЦМС, на которой крутится интернет-магазинчик.

Человека который туда лазит, мы уже назвали девелопером.

других задач не существует?

Ну дак приведите задачу из сферы разработки ПО, где необходимы КуА?

А вокруг по радуге бегают розовые единороги.

То есть КуА нужны для того чтобы те или иный учасники команды могли забивать на свою работу и сидеть в фейсбуке вместо написания спек?

что девелоперы никогда не ошибаются?

Потому что в обратном случае будет плохо. И поэтому для того чтобы убедится что все седлано верно, это надо проверять. Проверка это процесс, который не всегда требует выделенного человека. И вот это «не всегда» и создает разницу между «необходим» и «полезен».

P.S. Какой-то унылый срач получаетсо. ТС не залик!

Угу, скушно тут, пойду я спать лучше. Пока вы true в false не переименовали по следам удачи с переопределениями понятий «девелопер» и «необходимость».

То есть КуА нужны для того чтобы те или иный учасники команды могли забивать на свою работу и сидеть в фейсбуке вместо написания спек?

Дай разцелую. В точку.

А теперь важный вопрос:

Так ли необходим выделенный человек (или тем более команда) для того, чтобы следить за тем бизнес-требования переведены в тесты/спеки?

Нет. Достаточно будет если программист будет качественно свою работу выполнять. Но как мы видим квалифицированых программистов не хватает. Поэтому в помощь неквалифицированным программистам нанимают тестировщиков.

в помощь неквалифицированным программистам нанимают тестировщиков

А в помощь неквалифицированным тестировщикам нанимают квалифицированных программистов, чтобы у первых было больше времени сидеть в фейзбуке :)

Не я не имею ввиду, цепочки. Понянтно что например сейлз или консультант может получать больше программиста, хотя он и не создает продукт. Говорится только о сравнении тестировщика и программиста. Я утверждаю что тестировщики должны получать меньше, так как прогрммист создает продукт. Вот не было фичи, а благодаря деятельности программиста она получилась. А тестировщик только тестирует, то что уже сделано. Имеется ввиду только мануальный тестировщик.

Все профессии нужны, все профессии важны
Это понятно, но не отменяет того факта, что почти всегда тестировщик получает и будет получать меньше программиста.

Как все запущено...

Да нормальная логика крепкого крестьянина-середнячка.

почти всегда тестировщик получает и будет получать меньше программиста.

Не говорите моему начальнику :)))

Если книжек почитать то можно увидеть следующее: тестировщик сообщает заказчику информацию о состоянии продукта. Этакий засланный казачек от заказчика

Мочить надо таких козлов!

(флейм, так флейм)

Переводя велеречивого Кузняка на русский — например, без электричества вы вообще свой код будете на бумажке при свечке писать, но чота у электриков зарплата пониже :))

офигенчик!

Если речь о Unit-тестах, то это скорее всего делает не тестировщик, а QE — Quality Engineer (в компании Skype во всяком случае их называют так).
В Украине чаще всего их пишут программисты, QA — куда реже, во всяком случае — на моем опыте так.
Мне кажется вы просто «путаете понятия», читайте — путаете разных специалистов...
Помимо указанного выше QE, есть QA (Quality Assurance), есть QC (Quality Control) — вот QC = тестировщик.

А еще есть AQA — Automation Quality Assurance ;) Но они далеко не всегда пишут Unit-тесты, скорее, — используют трете партийные тулы для минимизации временных затрат на manual testing.

А на счет «получают меньше» — каждый получает столько сколько он «стоит», я бы вообще не проводил тут параллелей. Все очень сильно зависит от многих факторов, а хорошие специалисты и профессионалы своего дела по качеству (QE, QC, QA, или Q"whatever letter") — получают хорошие деньги.

Мне кажется вы просто «путаете понятия», читайте — путаете разных специалистов...

Помимо указанного выше QE, есть QA (Quality Assurance), есть QC (Quality Control) — вот QC = тестировщик.

а я думал что
tester — занимается поиском дефектов
qc — оценка процесса разработки

qa — влияние на процесс разработки, с целью обеспечени качества.

Нет, tester = qc. Проверка, валидация, сообщение о дефектах — не более.

Однако все тестировщики именуются qa, бо так удобнее.

Вот понятия и размываются.

Почему тестировщики получают меньше?

смотря какие :) если обычные мануальщики-тыкальщики — то меньше, и естественно, стать таким тестером может практически кто угодно :)

А хорошие автоматизаторы (да и просто хорошие тестировщики) получают вполне достойную зп.

А хорошие

Чё-то нифига не понеслась.

Альберт Толоконников, вот не расстраивайтесь шас подтянутсо, как раз вечер :)

А хорошие автоматизаторы (да и просто хорошие тестировщики) получают вполне достойную зп.

а это сколько?

ну как обычно это зависит от тулов, используемого языка, способностей и опыта :)
скажите мне сколько получает «программист» и я скажу, сколько «тестировщик-автоматизатор»

Чё-то нифига не понеслась. Хорошо, попробуем по-другому.

Чё-то нифига не понеслась.

Патамуша Троллинг — это тяжелая работа требующая терпения и высоких профессиональных навыков.
Еще важный момент:

Тролль должен хоть немного разбираться в теме которую «набрасывает». Это для того чтобы направлять и подогревать срач. Очень важно чтобы его позиция (сам вброс) была достаточно аргументирована.

Хорошо, попробуем по-другому.

Пробуйте!

Патамуша Троллинг — это тяжелая работа требующая терпения и высоких профессиональных навыков.

Таки да. Вот почему дегустаторы вин и сомелье получают в разы больше давильщиков вина, а в программировании наоборот?

Вот почему дегустаторы вин и сомелье получают в разы больше давильщиков вина, а в программировании наоборот?

Не совсем понял связь.
Это вы сейчас про троллинг?

Или вы сравниваете программистов с давильщиками винограда, а тестировщиков с сомелье? Если да, то лучше бы раскрыть фразу:

а в программировании наоборот

Оскорбление получилось как-то не очень очевидным, а ввиду слабой темы оно должно задевать как можно больше народу.

Альберт, учитесь троллингу у Богдана

У Богдана не научишься, там ярко выраженный дар божий!

там ярко выраженный дар божий

Дар тут не причем. Главное упорный труд и тренировки!

Вместе с тем, мне кажется, что тестировщики ценятся ниже кодеров, во всяком случае по зарплате

Вам кажется.

Я думаю, что человек, который пишет тесты, по умолчанию, должен знать больше того кто пишет код

Дану? Он должен знать другое, просто другое, а не больше/меньше.

Кроме того, если тесты для MVC он ещё и пользовательский интерфейс должен понимать. Добавьте сюда интеграционные тесты и моки(?) из базы и мы получим архитектора.

Смешались в кучу кони, люди. ©

Вместе с тем, мне кажется, что тестировщики ценятся ниже кодеров

А вы сравнивайте КуА инженеров и Софтвар инженеров, а не абезянок которые набирают код и абезянок которые кликают мышкой.

А теперь заключительный аккорд:

«Ещё один узнал про TDD»

ТДД — это совсем про другое, а не про тестировщиков. Вы бы хоть определение прочитали, а не только расшифровку сокращения.

Подписаться на комментарии