×

Профессия QA инженер

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

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

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

Сформировалось нескольно якобы профессиональных терминов, типа баг. Появилась якобы своя некая культура и даже пару приколов, связанных с багами, мол лови баги убегают. Бытует даже мнение, что тестировщик — это творческая работа, и что бы найти дейстивтельно неожиданные и скрытые баги, нужно действовать нестандартно. Может это и так но это выглядит просто как навная детская игра. Выдуманно множество всяких никому не нужных методов тестирования типа smoke testing или еще чего бредовее monkey testing.

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

Можно рассмотреть как бы профессиональный знания, которыми должен обладать тестировщик: такие как базовые знания технологий (джава, дотнет...), основ программирования, может некоторых языков, знание SQL.

Особым образом можно выделить знание так называемых методологий тестированиия и моделей разработки ПО. Все эти знания являются просто вырезками из других более ярковыраженных и более определенных профессий: программиста, администратора БД, сисадмина... Как таковых особых обласей знания, которые можно отнести как категории ’тестирование’ по сути нет, или они уж если попытаться придумать, то это будет с большой натяжкой. Допустим те же самые методологии тестирования, которыми мучают тестеров на собеседованиях, по сути никому не нужны, а существуют только для того , бы о них спрашивали на собеседованиях. Ведь нужен же просто внимательный, ответсвенный человек, который может скурпулезно прогнать тесты.
Я вполне допускаю существование комманд разработчиков, которые могут и сами тестирут свой продукт. Может в реальном мире ввиду отсутствия времени это и утопия, все же это вполне логично. Написал функционал, продумал как и что будеш тестировать внимательно прошелся по всему функционалу, понавыдумывал тесткейсов, понаходил баги, пофиксил.
Существует еще одно название професси тестировщика — QA инженер, тоесть инженер по обеспечению качества. Тоесть это люди с которых ,так сказать, "будут спрашивать«.Но опять же з качество несут ответственность все — и зубной врач (пойдете ли вы к врачу, который скажет, что он не несет ответственности за качество работы а нужно спровсить у Пети из 4 кабинета — его назначили ответственным:)).Ответственность за качество это просто обычная человеческая, добросовестность в выполнениии работы, которая не может быть характеристикой исключително как-то одно проффесси.

Почти всегда (по моим наблюдениям в 90 проценов случаев) сениор и мидл QA инженеры стремяться перейти на новый уровень, став программистами, тимлидами, консультантами, проджект менеджерами, автомейшн QA инженерами. И я считаю так и должно быть. Из тех же 10 что осталсись — 5 процентов просто люди которые себе работают и особо не паряться по этому поводу — есть хорошая работа и нормально. Остальные 5 процентов это просто лентяи, который отсидевшись лет 4 — 5 на проекте и получив так сказать сениора «за выслугу лет», бегают из одной конторы в другую, и пытаются найти оправдание своей «сениоровсти» выраженное в денежном эквиваленте, хотя понимают, что могут быть легко заменены много более дешевым мидлом или даже отвественным джуниором.

Мое мнение таково — профессия тестировщика почти ВСЕГДА должна восприниматься, как ступенька перед переходом в на более высокий уровень. И тестировщик, который позиционирует себя лиш как просто мануальный тестер, быстро достигнет своего потолка зарплаты, причем он будет ниже чем в других направлениях айти и почти непробиваемым.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Добрый день. правда что в автоматизации время роста от джуна до синьора в 2 раза бестрее чем у разработчиков?

Годно) Хотя вы QA инженеров так и не видели еще)

ОПРЕДЕЛЕНИЕ: QA инженер — этот тот человек, который препятствует превращению говнокода (который производится большинством программистов по их же мнению ))) ) в говнопродукт

Если QA настолько безполезны и у них завышенные зп, почему здравомыслящие люди (ПМ, Тим Лиды т.д.), многие из которых в прошлом были разработчиками, ищут специалистов-синьйоров с зп овер 1500$, а не берут джуников, которые готовы работать за еду, лишь бы получить какой-то опыт?

, ищут специалистов-синьйоров с зп овер 1500$
Что-то меня заставляет верить, что на 1500 они долго будут искать синьоров (:
Хотя, смотря конечно, куда этот «овэр» простирается.

Ну, да, девушка лет 50-и ведь тоже девушка «за 20»...

эмм... ну вот, первое резюме которое мне выдал головоохотник по запросу QA Engineer
hh.ru/...6206712?query=QA engineer

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

Во многих крупных американских компаниях нет такого явного деления между разработчиком и тестировщиком. Обычно это называется Software Engineer (SE). При этом заниматься он может чем попало :)

Это интерсный подход, т.к. по факту нужно тестирование, а не тестировщики.

есть QA команды, куда могут входить как ручные тестировщики, так и те, кто пишет автоматические тесты в различных системах на различных языках, и также DB аналитики, и прочие разновидности инженеров из мира ПО. вот они дружно сидят и ашурят куолити. :)

попоболь на ровном месте.
Пишите тесты сами и просите уволить qa.

Находите баг и просите уволить программиста

Такие топики будут возникать до тех пор, пока большинство тестеров (да и разработчиков) считает, что задача тестера искать баги. Но задача QA инженера — обеспечить планируемое качество ПО. Вот как только начнете задумываться над вопросом «как с минимальными затратами ресурсов обеспечить планируемое качество», тогда можете называться QA инженером.

QA инженера — обеспечить планируемое качество ПО
Все правильно, только вы много видели людей с тайтлом QA, которые действительно могут обеспечить требуемое качество? В частности построить процессы на разных этапах от анализа и формирования требований до финального развертывания и поддержки? Чтобы этим эффективно заниматься нужно опыта лет 20 и желательно в различных сферах. А у нас 3 года мышкой покликал — уже синьор КуА ))

КуА делают лягушки, а то, чем мы занимаемся, называется QA

Коментар порушує правила спільноти і видалений модераторами.

Как человек, который работал и QA Engineer (в том числе и с Automation) и программистом, хочу кое-что добавить. Я считаю — что и одна и другая профессия очень важны. И в принципе, друг без друга не могут. Ведь, что самое главное в конечном итоге? Ответ: выпустить качественный программный продукт. Очень удивительно читать про холи-вары тестировщик vs программист. Это как вечные разборки из серии что лучше — Linux / Win, Mercedes / BMW и тп. Лично на практике встречал очень интересные и сложные проблемы в тестировании: так что здесь есть куда расти... Программист безусловно должен проверять свой код — но обычно девелоперы так загружены, что оставляют проверки на потом... Да и к тому же — человеческий фактор: можешь хоть 100 раз смотреть на свое изделие и не заметишь очевидного дефекта. Плюс ко всему — люди разные: у кого-то лучше получается именно девелопить, а у другого человека есть здоровое чувство критики и, так сказать, чутье на слабые места. Поэтому мое мнение — лучше всегда работать дружной командой :). P.S. И пиво веселее вместе пить за успешный проект :)

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

Вы просто не шарите, не более того

Коментар порушує правила спільноти і видалений модераторами.

Класс! :)

James Bach с вами категорически несогласен

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

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

Позволю себе закончить,-

Почти всегда (по моим наблюдениям в 90 проценов случаев) сениор и мидл Software инженеры стремяться перейти на новый уровень, став архитекторами, тимлидами, консультантами. И я считаю так и должно быть. Из тех же 10 что осталсись — 5 процентов просто люди которые себе работают и особо не паряться по этому поводу — есть хорошая работа и нормально. Остальные 5 процентов это просто лентяи, который отсидевшись лет 4 — 5 на проекте и получив так сказать сениора «за выслугу лет», бегают из одной конторы в другую, и пытаются найти оправдание своей «сениоровсти» выраженное в денежном эквиваленте, хотя понимают, что могут быть легко заменены много более дешевым мидлом или даже отвественным джуниором.
Мое мнение таково — профессия разработчика почти ВСЕГДА должна восприниматься, как ступенька перед переходом в на более высокий уровень. И разработчик, который позиционирует себя лиш как просто coding monkey, быстро достигнет своего потолка зарплаты, причем он будет ниже чем в других направлениях айти и почти непробиваемым.

Мое мнение таково — профессия разработчика почти ВСЕГДА должна восприниматься, как ступенька перед переходом в на более высокий уровень.

Нет не всегда!

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

профессия разработчика почти ВСЕГДА должна восприниматься, как ступенька перед переходом в на более высокий уровень.

В этой профессии ВСЕГДА (капс Ваш), и безо всяких «почти», есть возможность становиться более ценным специалистом, не уходя в руководство или ещё какое извращение, но соединяя все виды деятельности от анализа и архитектурирования до кодинга и тестирования в самом себе.

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

И вас с днем смеха!

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

Я уже не говорю о том, что практическое программирование никогда не состоит в этом.
в чем же оно состоит? :-)

Ну и по поводу низкого низкого порога входа.
Ув программисты. Вы хоть почитайте вот тут jobs.dou.ua/...cies/?search=QA
чего хотят сейчас от тестировщиков.

Ув программисты. Вы хоть почитайте вот тут jobs.dou.ua/...cies/?search=QA
чего хотят сейчас от тестировщиков.
Ок. Достаем линейку :)
jobs.dou.ua/...vacancies/5792
• Strong knowledge of testing processes and methods;
• Experience in black-box testing of web applications 2+ years;
• Experience in test documentation design (test plan, test cases, checklists);
• Analytical skills, attention to details;
• Intermediate spoken & written English;
• Ability to work independently with minimal or no supervision.
jobs.dou.ua/...vacancies/5789
• 5 years’ experience with C# and .NET;
• Strong knowledge and practical experience with ASP.NET MVC;
• Good knowledge of MS SQL Server 2005/2008;
• Good knowledge of Entity Framework, LINQ to SQL, NHibernate or other ORM;
• Good knowledge of JavaScript and AJAX;
• High degree of self-education and initiative;
• Good written & spoken English (at least pre-intermediate level);
• Ability to communicate with clients to clarify requirements and create tasks for other developers;
• Ability to give estimate tasks and get tasks done according to own estimation;
• High degree of self-education, responsibility and initiative.
-------------
Еще интересная выборка:
jobs.dou.ua/...earch=junior QA
3 вакансии по запросу “junior QA”
jobs.dou.ua/...rch=junior Java
Нет вакансий по запросу “junior Java”
jobs.dou.ua/...search=junior C
4 вакансии по запросу “junior C#”
Просто возьмите и посчитайте количество пунктов в вакансиях на джуна и как они разделены между обязательно и хотелось бы.

• Strong knowledge of testing processes and methods;
• Experience in black-box testing of web applications 2+ years;
• Experience in test documentation design (test plan, test cases, checklists);
• Analytical skills, attention to details;
• Intermediate spoken & written English;
• Ability to work independently with minimal or no supervision.
На самом деле реально требуется:
attention to details;
и
Intermediate spoken & written English;

А чего мы ходим вокруг да около. Страна должна знать своих героев.
Ув. программисты, если у вас есть пара тройка завершённых крупных проектов.
И за время разработки и пост продакшена, на вас в багтрекере не было открыто ни одной баги — лайкните этот пост.
(все баги были найдены вами еще в процессе разработки доки, найдены юнит тестами и пофикшены до продакшена). А если еще и в продакшене не вылезло ни одной баги — то оставьте комментарий.
И статистика будет. И вам почет и признание.
;-)

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

Как чего? Будет список идеальных программистов.
Прямо.

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

Мне не интересно продолжать этот разговор.
За все время так и не отметился ни один идеальный программист.
За сим откланиваюсь. Смысла в дальнейшем переливании из пустого в порожнее не вижу.

А какая же суть темы?
(я больше коментировал не саму тему, а коментарии к теме)

Вижу что вы перешли с администрирования (причем с веб хостинга ) в QA. Немного странно и интересно почему сменили ?

Ничего странного. Вы когда то пробовали работать в три смены? Неделю с утра до 18, потом с 17 до 24, потом с 23 до 8 утра. Это были жесткие времена с зарплатой в 100++ уе.
Ооо те сто баксов это были совсем другие. Нынешние сто баксов в долю не падают тем.
Но всеравно в аутсорсе платили больше.
Да и от QA\QE я как то потихоньку отошел.

Почитал топик и коменты и вот не понял.
Это что программеры наезжают что тестеры не нужны? ЛОЛ.
Все уже пишут без багов? Ну просто сказка.
Правда правда? Совсем без багов даже в огромных системах? Где работает десяток команд и начинается интеграция? А еще если часть компонент разрабатывают third party конторы...
Ааааа, наверно жаба задавила что кто то получает столько же, а иногда и больше?
Ну что ж вы так. Разве приличные люди смотрят в чужой карман?
Вот какие все глупые. Тратят деньги на каких то тестеров.
Даже целый, как это назвать, аутстафинг тестеровщиков клиентам продают. Когда, например, команда разработки в США, а команда тестировщиков в Украине.... Вот деньги буржуям девать некуда. Нет что бы повысить уровень своих программистов и качество документации.
Понизить всем тестировщикам ЗП!!! до 150 баксов. А чем им больше платить? За что? За то что они могут разобраться в документации. За знание английского? За опыт работы в разных ОС?
Та ладно... они там кнопки давят просто.
И пофиг что никто не пойдет на такую ЗП. Пофиг что влетим с релизом. Пофиг что заказчик уйдет.
Ну и пофиг что контора уйдут из бизнеса.

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

И пофиг что никто не пойдет на такую ЗП.

Не пойдут? Китайцев набрать — они пойдут. :)

Точняк. И команду переводчиков с\на анг-рус-китай. Ведь мы экономим.
И это дешевле всяких тестеров. Ну и порог вхождения совсем низкий.

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

А что за порог вхождения нужен, чтобы по тэст-кейсам кнопки давить? Глаза, да 1 рука с указательным пальцем (чтобы кнопку давить) — вот и весь порог. :)

Можете привести данные по китайцам, стоящим в разы дешевле украинцев?

Бред. Вы видимо в Китае не были ниразу. Английский там, что среди молодежи, что среди людей постарше — никакой.

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

Судя по написанному, у вас просто ужасные тестировщики и QA-и, по крайней мере в разрезе оформения документов. Теперь ясно откуда такое мнение.

Уважающие себя тестировщики не оформляют тест-планы в Excel’e или еще хуже, в Word’e :)

не оформляют тест-планы в Excel’e или еще хуже, в Word’e :)
А в чём вы пишите тест план?

Простите, неправильно выразилась — тест кейсы конечно же))) Microsoft Test Manager

Как по мне, Excel более чем отлично подходит для менеджмента тест кейсов и всего что с ними связано, если, конечно, уметь им пользоваться :)

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

Т.е. когда ты приходишь в компанию, то тебе говорят «У нас пишут тест-кейсы и тест-планы в такой-то программе». Но, для каких-то своих целей (небольшая проверка, не входящая с область проекта) вы все равно будете использовать ту программу, котрая наиболее удобна для вас.

Я не говорил ни о «своих целях», ни о «целях» вообще.

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

а можно и не уметь,все равно подойдет)

Тут Ви помиляєтесь. Подивіться ютуб і все зрозумієте. Кожен вибирає що більше йому до душі.

Сформировалось нескольно якобы профессиональных терминов, типа баг. Появилась якобы своя некая культура и даже пару приколов, связанных с багами, мол лови баги убегают. Бытует даже мнение, что тестировщик — это творческая работа, и что бы найти дейстивтельно неожиданные и скрытые баги, нужно действовать нестандартно. Может это и так но это выглядит просто как навная детская игра. Выдуманно множество всяких никому не нужных методов тестирования типа smoke testing или еще чего бредовее monkey testing.

Если подставить вместо «тестировщик» — «врач» (а вместо «баг» — «болезнь»), то, по-моему, будет смешно...
Здоровому врач обычно не нужен.

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

Если подставить вместо «тестировщик» — «врач» (а вместо «баг» — «болезнь»), то, по-моему, будет смешно...
...

Это неверная аналогия. Верная аналогия — иная:

Болезнь = баг. Больной = здоровый чел, с багами. Врач = программист.

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

Где тут место тестера?

Когда у здорового чела появляются баги

Появляются баги от чего? От действий пользователя или качества продукта?

Это маловажно, отчего. Главное, что баги.

В Вашем примере программист сначала тестирует (диагностирует), а потом исправляет. А иначе как он будет знать, что лечить?
Тестером может быть и программист, и клиент (что может быть неприятно для программиста при наличии ошибок), а самое серьезное — это безжалостные тестеры-пользователи.

Где тут место тестера?

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

Там, где медицина не порушена, такие осмотры — штатное явление.

да ладно, чё вы... правильные QA всегда нужны. А те лиды, которые пренебрежительно передёргиваются, когда qa-джун говорит «здрасте» всей команде войдя в кабинет, просто имеет очень много свободного времени и отжимая работу qa-джуна, предпочитает самостоятельно продавливать все пимпалки, вторым монитором веся вконтактике или где похардкорнее ;)
Кстати, мне вот чёта сразу STALKER «Чистое Небо» вспомнился, точнее кол-во негатива вылитое на GSC в следствии отсутствия адекватного тестирования))

Статья, конечно же, бредовая.
Но как вброс — великолепная. Слог, стиль, оформление. Причем чисто теоретически повестись на нее могут все 100% QA\тестеров\кликеров\автоматизаторов. Ведь неявно упор идет на то, что порог входа в тестировщики существенно ниже, чем в программисты. И каждый тестер это помнит, помнит как он из бывшего студента-оболтуса\эникейщика стал Junior QA.
А тут бац — матерый тролль громогласным голосом вещает — «Мол, хоть и получаешь ты много килобаксов, но на деле ты йух простой»

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

Ну машина — єто уже наврерно автомтические тесты. Их тоже надо писать и саппортить. Иногда лучше уже иметь мануал тестеров.

Их тоже надо писать и саппортить.
Ого, открытие!
Иногда лучше уже иметь мануал тестеров.
Что значит лучше? Нормальный ГУИ-тест покрывает 99% Проблем с ГУИ, даже «поехавшую» верстку. Затраты на тестировщиков куда выше, при хорошем покрытии тестами.
А от если забили на тесты (юнит, интеграционные, ГУИ ...), то тогда да проще (но не лучше) держать КуА отдел. От только проблема, что с таким подходом, он будет разрастаться и негативно влиять на разработчиков, которые начнут думать «а КуА проверят».

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

бывает много багов на стыке разных фич, о которых программист и не подумает, когда юнит будет писать.
Читаем внимательно:
тесты (юнит, интеграционные, ГУИ ...)

Разнообразие всяких тестов вовсе не значит их 100% эфективность.

Разнообразие всяких тестов вовсе не значит их 100% эфективность.
Разнообразие всяких тестЕРОВ вовсе не значит их 100% эфективность.

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

Тут зависит от самого тестера.
Тут зависит от самого тестОВ. :)
Некачественные тесты не решают проблему, как и непрофессиональный КуА. Хорошие тесты решают, как и профессиональный КуА.
когда говорят тестер
Я тут использовал чисто для каламбура.
Банально попросить любого КуА рассказать основы теории надежности, большинство спросят «Че?».
Зато если спросить девелопера то это отличный детектор, пересiчний синьор вспомнит про машину тюринга, ребята попродвинутее еще и про лямбда исчиление, ботаны про еще и машину поста до кучи и классы сложности, математики помянут Маркова и комбинаторы.
Банально попросить любого КуА рассказать основы теории надежности
Ну я бы не считал теорию надежности бекграундом для софтваре инжиниринга и ,в частотности, для тестирования и КуА. Может я ошибаюсь, то теория надежности применима к устройствам, которые изнашиваются в процессе работы и меняю свои характеристики. А разве компьютерная программа может износиться? Разве может под действием например погоды кнопка ОК внезапно стать выполнять функции кнопки Cancel.
Может я ошибаюсь
Ошибаетесь.

Теория надежности, помимо перечисленного, отлично применяется к ПО. Другое дело, что никто этим не занимается.

теория надежности применима к устройствам, которые изнашиваются в процессе работы и меняю свои характеристики
Не только, просто обычно «преподают» ее именно в таком контексте, но СМО — это так же не только про телефоны ;)
Уточнение: я говорил про математическую теорию надежности.
Разве может под действием например погоды
Погоды/непогоды, а кривых ручек. Банально сколько из КуА ведут «рейтинг разработчиков» (как часто тот или иной человек допускает ошибки и какого приоритета). Как оценивают стабильность функционала? Такие вещи помогают, например, оптимизировать время на проверку. Если коммиты только от разработчиков с высоким рейтингом и в некритичный функционал — один тест-лист, если в кор и от людей с низким рейтингом — другой.
Ну я бы не считал теорию надежности бекграундом для софтваре инжиниринга и ,в частотности, для тестирования и КуА.
Для тестирования — скорее нет чем да. Для КуА — скорее да чем нет. Оценивать программу как последовательную систему. Или оценка вероятности отказа при изменении нагрузки (для всяких СааСов). Я не особо интересуюсь КуА, но из того что я слышал про оценку нагрузок — это «просто запустили джМетр и накинули на глазок Х%».
И тут более важна другая часть того что я написал (не то что вы скопировали), а именно:
большинство спросят «Че?».
Это как с алгоритмами сортировки или с О-нотацией, больше в сторону «науки КуА». Но как вы заметили рании все движется в сторону «КуА клубов».

Тоже считаю, что с тех. точки зрения тестирование проще в разы, чем программирование, но от этого работа тестировщика не становится менее нужной, и уровень тестировщика для каждой задачи свой. Только вот фиг там программер будет тестить настолько скрупулёзно, ему это быстро надоест ибо он скажет, что шёл то он на программиста и «создан он вовсе не для этого», а если и будет тестировать, то ему для таких задач надо выделять время, новый ф-нал разрабатываться не будет и всё-равно мы придём к тому, что нужна отдельная роль и возьмём тестировщика на проект. А что касается разных QA/Test Talks и прочего, то не думали ли вы о том, что тестировщики в массе своей более социальны, экстравертивны в отличие от более замкнутых программеров? В этом возможно и причина, а не в том чтоб специально в глазах программистов поднимать свою значимость. Ещё что касается именно чистого QA — видимо вам не попадался проект где без такой роли просто не обойтись.

Только вот фиг там программер будет тестить настолько скрупулёзно, ему это быстро надоест ибо он скажет, что шёл то он на программиста
Хм,
Много лет работаю с программистами, тестерами, QA, лидами, ПМ-ми и всё это время мне пока ещё удивительным образом везёт так как вижу я адекватных людей из всех представленных профессий/должностей, которые хорошо трудятся, знают своё дело и уважают людей вокруг себя
Вы уверены что все ваши окружающие таки уж “лапочки”, и что вы сами “уважаете людей вокруг себя” и совсем не заГанжовані (как говорил один киевский мэр)?
Я в жизни никогда не видел лучшего вида тестирования, чем сесть и внимательно по спецификации медленно покликать ту или иную фичу
Судя по всему вы по настоящему не работали в коммерческих проектах и понятия не имеете чем отличается качественная разработка продукта от формошлепства.

А как по Вашему надо тестировать функционал

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

Нифига ж себе, такое впечатление, что народ или вбрасывает или реально не понимают, зачем команда тестировщиков на проекте. Когда заказчик на рынок будет выводить свой новый кардиостимулятор он должен объяснять, что Егор Чумаков и компания «мамой клянутся», что всё сами протестировали, вот тест кейсики придуманные ими на салфетке, которые они сами прошли — дефектов нет, можно проходить аудит, сертификацию и продавать. Или наш дримлайнер очень надёжное судно, наш супер «девелопер» лично протестировал весь свой код, летайте не бойтесь. Примеров массу можно привести, когда за коммерческий проект с сотнями тысяч строками кода, в котором вы написали «очень качественно» пару тысяч, и который в итоге не работает как надо, никто платить не будет и ваш апломб никого не интересует. И ваше «бл* буду, всё работает» на словах никому не интересно. А если вы утверждаете, что на вашем проекте именно так, то это не пример как надо, а наоборот как не надо делать, но заказчику видимо и так подходит. А по поводу зп, что мол синьйор тестер должен получать не больше джуниор девелопера, то я вам на это скажу, что за тестирование того поделия, которое пишут порой наши новообразовавшиеся мидл джава девелоперы, синьйор тестер вполне имеет право заявить о куда большей сумме чем вы тут себе понапридумывали.

Ответ был предсказуем, но я вынужден вас расстроить — я не тестировщик)

Когда заказчик на рынок будет выводить свой новый кардиостимулятор он должен объяснять, что Егор Чумаков и компания «мамой клянутся», что всё сами протестировали, вот тест кейсики придуманные ими на салфетке,
Сразу видно человека который ваапшэ не в теме :)
1) Если он так не доверяет господину Чумакову, то почему он отдает проверять ему же его работу? КуА то обычно сидят в «соседней комнате».
2) Тест-кейсы — это херня, есть спецификация, которую вполне можно автоматизировать, есть такая штука БДД. Все тесты прогоняет машина, которая намного ответственнее чем «неудавшийся экономист» который думает куда поехать в отпуск.
3) Есть разные этапы и в случае с кардиостимулятором все совсем по другому ибо клинические исследования, проводят не группа абстрактных КуА, а собственно врачи. В наших же реалиях сомнительно что делая проект для какого-то инвест-банка набирают инвест-банкиров (которые вряд ли бы согласились работать за ЗП разработчика).

То есть по вашему менеджеры феерически тупят нанимая себе в команду тестеров?

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

То есть по вашему менеджеры феерически тупят нанимая себе в команду тестеров?
Некоторые тупят или идут на поводу у лени или низкого профессионализма разработчиков в их коммандах.
Некоторые совсем не тупят а даже наоборот. Ведь за все платит «заказчик», больше тушек больше денег в проект.
что есть люди которые не тратят года на изучение языков и на то как правильно программировать и получают столько же сколько и программисты!
Пусть даже больше. Проблема в другом: приходится контактировать со всем тем шлаком который не тратит года на развитие в своей профессиональной области (банально список шагов в джире делают не встроенными средствами, а пишут 1, 2, ...10050).

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

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

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

Из КуА единственный путь в Delivery Unit Manager

Наблюдаю постоянный поток из тестеров в программисты.

Наблюдаю постоянный поток из тестеров в программисты.
вполне логичная эволюция.
уровень требований растёт, а с ним порог вхождения.
Наблюдаю постоянный поток из тестеров в программисты.
вполне логичная эволюция.
А можете объяснить логику?
А можете объяснить логику?
возьмём один из кейсов: студент 5-го курса учится-учится на программера, но понимает, что даже джуном его не хотят брать, т.к. доучивать — это инвестировать.
если этот студент не страдает завышенным ЧСВ, то он вполне может зайти в контору (имхо, желательно в крупную) как тестер.
И ничего страшного, что в некоторых моментах он overqualified.
Постепенно он обнюхается, доучится и начнёт работать программером.
Не все перцы настолько круты, чтоб сразу со студенческой скамьи зайти в контору программистом, тем более сейчас, когда скоуп требований к соискателю растёт.
тудент 5-го курса учится-учится на программера, но понимает, что даже джуном его не хотят брать, т.к. доучивать — это инвестировать.

С нынешним дефицитом разработчиков (и в Украине тоже)? Очень маловероятно. :)

Если тестер хочет быть разработчиком, но продолжает сидеть в тестерах — это просто лень/удовлетворённость «синицей в руках».

С нынешним дефицитом разработчиков (и в Украине тоже)?
Дефицита джунов в Украине (по крайней мере) никогда и не было. Дефицит есть тру синьоров готовых работать за ЗП джуна.
зайти в контору (имхо, желательно в крупную) как тестер.
Постепенно он обнюхается, доучится и начнёт работать программером.
Вот этот логический переход я никогда не понимал. Начал работать тестером и перешел в программисты?
Если переход за счет «доучился», то при чем тут работа КуА? Равносильно: пошел работать дворником, доучился, стал программистом. (если есть обидчивые, то пошел работать программистом, доучился, стал продавать ПО)
тем более сейчас, когда скоуп требований к соискателю растёт.
Та ни капли. Скоуп все так же гигантский и надо просто найти тех кто его реально оценивают, а не будут требовать 100500 фреймворков от джуна.
-------------
Тут параллельно есть тема про отношение к КуА. Так вот такой подход, когда в КуА идет те кто «недостаточно крут, чтоб сразу со студенческой скамьи зайти в контору программистом» и при этом сидят на местах КуА и «доучиваются», как раз подстегивает негативное отношение к профессии.

это тот путь, который я прошел сам.
разумеется, он не оптимален.
навыки, полученные в QA мне выбрасывать не пришлось, это точно.

Нынешний дефицит кадров не означает простоту трудоустройства.
В гoвноконтору с дикой текучкой да, проще устроиться, особенно с дисконтом по з\п (который надолго))

«негативное отношение к профессии» это форма идиoтизма (инфа 100%)
вот почему:
в программировании отсчёт начинается с нуля.
нужно уметь с пониманием относиться к людям которые не имеют достаточного опыта или знаний. В нормальной команде это быстро проходит.

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

Врятли это все можно понюхать работая дворником.

очень полезно для мозгов
Можно кроссворды решать.
билд сервер; навык установки, апдейта и администрирования системы; работа с апликейшн (ну или веб) сервером.
Это не про КуА, а про админов.
А также ( в зависимости от работы, и если повезет) целая куча технических тем
А ничего что тот же СКЛ для КуА и разработчика отличается. Банально накуа КуА оптимизировать запросы?
Есть конечно же и мега-полезные навыки для программиста, такие как «ворд и эксель».
Из любой работы можно извлечь что-то полезное. Но вот я никак не вижу
вполне логичная эволюция.
Какая эволюция из параллельного рода занятий?
Врятли это все можно понюхать работая дворником.
Из того что вы привели, сухой остаток — ангельский и в некотором плане аджайл. Такое можно и работая дворником «понюхать». Это совсем не про эволюцию. Переход из КуА в программисты — это скорее революционное развитие, чем эволюционное.
Вот этот логический переход я никогда не понимал. Начал работать тестером и перешел в программисты?

Нормальный переход, если есть способности программиста, но нет опыта и, главное, собственно развитых навыков по представлению control flow.
Отработать оба на тестировании проще, чем в любой другой деятельности.

Engineering is the application of scientific, economic, social, and practical knowledge, in order to design, build, and maintain structures, machines, devices, systems, materials and processes.
А теперь внимание вопрос, какие же из QA инженеры, если они ничего не производят и не дизайнят? По моему engineer в названии должности это только для того чтобы красиво называться.
ничего не производят и не дизайнят
Ознакомьтесь с тем кто такие QA Engineer сначала, может поймете что они «производят и дизайнят».

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

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

может только клацать на Save в формах
Врятли это Junior и вообще QA/QC/Test Engineer. Это ближе к секретаршам, о которых писалось уже.

Это может сделать и BA, и Product Owner, и дизайнер, но инженером он не станет.

Если важно именно слово «инженер», то себя я скорее назову QA Specialist, хотя всё это лишь вымышленные ярлыки по сути своей, важна польза от работы. Бабушка, которая зарегистрировала клининговую фирму и сама моет полы в офисах, с одной стороны уборщица, а с другой директор. :)

важна польза от работы
И в чем польза от работы КуА, вот КуСи довольно полезны, а чем полезны КуА ?

Представь себе, я это читал, но не видел КуА в опенспейсе

Видели вы или нет, — как влияет на то чем занимаются люди определенной профессии? И причем тут опенспейс?

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

QC это часть работы QA и не более. Главная цель QA — не «найти проблемы», а их предупредить и минимизировать.

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

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

если они ничего не производят
Хаос производят, для меня идеальный КуА который может писать автотесты, а то они отказываются, и приходится девелопером писать
Хаос производят
Сильно

Кстите, еще один вопрос-вброс:
Почему программистов удивляет, а иногда откровенно бесит, если вакансия, к примеру, требует знание .Net и java + вспомогательной «пачки» языков?! — и плолне логично вы говорите что надо 2-3 специалиста чтобы покрыть стек технологий (хотя речь и там, и там о программировании), но при этом то, что программировать и тестировать должны разные люди — вызывает бурный протест?
Тестируйте за собой сами, пишите код без багов, покрывайте его автотестами и отвечайте за свою работу в полной мере! Тогда QA вымрет как таковой и очень быстро ;)

Бесит, кого? Это не программисты.

Косят под них, видимо :)

По мне, нормальный QA должен быть вовлечен во все этапы разработки проекта и знать как что устроено на ровне с TL, быть правой рукой и ему, и PM, и BA, и т.д.(смотря как команда сформирована). Я не подразумеваю то, что один «круче» другого, каждый выполняет свои функции. При этом уровень ответственности у QA на порядок может быть более высок чем у разработчиков. Предложите любому девелоперу взять на себя последнее слово перед апдейтом или выпуском нового продукта. Далеко не все согласятся сказать «Да, я ручаюсь, что все работает как надо, поехали!»

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

Вот-вот. У меня как раз так и получается, что эту ужасную фразу ждут от QA, и потом, когда где-то какая-то мелочь вылазит спрашивают также c QA, хотя накосячил то не он по сути. ТОПам все равно, что где и кто, нужно крайнего найти. А на окончательные тесты и фиксы багов перед выпуском, вместо запланированных пары дней к примеру, бывает отводится несколько часов, т.к. у заказчика всегда всё ASAP и URGENT. Таким образом и получается, что часто программисты не несут ответственности даже за тот кусок кода, что сами написали.

Тестировщики и QA инженеры нужны, но существует одна большая несправедливость: их зарплаты завышены как минимум вдвое. Синьор-тестеры не должен получать больше чем хорошие джуны-девелоперы. Ведь по сути они сами ничего творческого не делают, способны лишь тестировать программу, написанную другими людьми, по спецификации, написанной тоже другими людьми. Не шибко умная работа по книжке нажать на кнопку и оформить баг, если результат хоть немного отличается от ожидаемого. А джун-тестер так вообще почти ничем не отличается от любой офисной секретарши, не знаю за что им платят такие деньги со старта. Не знаешь как автоматизировать процесс, получай свои 2 тыс грн. Не знаешь поведения системы под нагрузкой, получай те же 2 тыс. грн. Не знаешь семейства протоколов tcp/ip — та же самая тебе цена. А у нас тестер покликал 2 года вручную юайные тесты, выучил две mysql-квери, и уже на тебе — синьор с зарплатой от 1к и выше. Не за те заслуги короче. проффесианалы.

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

"Синьор"-тестер это не тот,то по спецификации тестирует, а тот, кто сам тесты придумывает, а то и тестовые фреймворки строит. А Вы просто не разбираетесь в предмете.

"Синьор«-тестер это не тот,то по спецификации тестирует, а тот, кто сам тесты придумывает
Ой какая же сложная и нетривилаьная работа — написать тесты :)
Нажми — на кнопку «Save» — должно произойти то-то и то-то...
Мне кажеться писать тесты может уже писать джуниор QA, а ранить стажер.
Мне кажеться писать тесты может уже писать джуниор QA, а ранить стажер.

Да уж, «кажеться» здесь ключевое слово.

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

Да, часто сложная и нетривиальная. Хотя бы потому, что Вы в своём принципиальном высокомерии и невежестве забываете, что основное даже не «написать» тест, а понять, что именно надо (в первую очередь) тестировать и на какие случаи.

Команда процессора выполняет умножение чисел? Тестировать надо не только тривиальные 2*2, а, например, (-32768)*2 (если входные числа 16-битные).

Телефонный коммутатор? Ну-ка, как и на что проверять ситуацию, когда у установленного звонка сторона A пытается поставить звонок на парк, а сторона B в это же время пытается сделать трансфер? Описано ли это поведение в спецификации? Хороший тестер определит, что какая-то ситуация просто не описана, опишет её и предложит методы поведения при её наступлении.

Кнопка Save, говорите? А что будет, если её нажать дважды? А если дважды с очень коротким промежутком, за который страница системы ajax не успеет связаться с сервером? А если трижды? А если ввести противоречивые данные? А если быстро нажать назад и вперёд 10 раз подряд? А если задать в форме платёжки 500 миллиардов рублей? А если явно отправить данные, которые не могли пройти валидацию собственно кодом страницы? А как отреагирует сайт на введение логина типа pupkin’;delete from users; ?

Вышла новая версия документации? Ну-ка почитаем... Почему скриншоты от старой версии, если половина кнопок переехала? На каком языке фраза «жмякнуть на пимпочку»? Зачем выполнять работу X методом прохождения через цепочку из 7 экранов по 100 полей в каждом, если через средство Q это делается одним экраном на 9 полей, а работа X составляет ~55% действий пользователя? Кстати, а зачем форма 215 вообще нужна, если все данные уже размещены в предыдущих?

Стажёр «ранит» тесты по кругу? А зачем его грузить этим, если есть средства автоматизации? Кстати, написать докладную начальнику, что планируемый вебокнопонажимательный софт R непригоден для планируемого перехода на новую версию движка, а надо купить S, хотя он и на 500 баксов дороже.

Вот что такое работа хорошего тестера, причём я описал менее половины от того, что такой тестер делает. И я горжусь тем, что мне повезло работать с некоторыми такими. А Вы с Вашим уровнем понимания, действительно, можете только 8 часов в день жать кнопку Save.

Кнопка Save, говорите? А что будет, если её нажать дважды? А если дважды с очень коротким промежутком, за который страница системы ajax не успеет связаться с сервером? А если трижды? А если ввести противоречивые данные?
Вот они какие эти тестеры, завалит сервак и потом ходит полдня ничего не делает. И ведь главное, не репродюснет потом.
Вот они какие эти тестеры, завалит сервак и потом ходит полдня ничего не делает.

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

И ведь главное, не репродюснет потом.

И, конечно, именно он виноват в том, что программисты не умеют писать отладочные логи.

У нас это багом не считается, такое даже не имеешь права заводить. Вот какие степы писать в багрепорт?

Нормально. Коли сторінка ще не загрузилась, натиснути таку то кнопку.... і т.д. В більшості випадків таді ловляться на раз:)

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

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

Тестируйте сами, раз это так легко
Тестируем сами, зависимости нету, проект сложный. Если и нужно что автоматизировать есть же селениум, а ручные тестеры таки не нужны

Интересно, а селениум ребут заавтоматизирует? %))

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

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

Все это самопридумывание тестов обычно сводится к записи скрипта на джмитре через рекордер.

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

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

На питоне или руби. Только какое отношение это имеет к QA?

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

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

такие в девелоперы уходят, не задерживаются.

Значит, не смогли или не захотели заинтересовать. Программисту с мышлением тестера будет достаточно работы в QA.

А зачем им идти в девы? Им и так весьма уютненько. SQA это такой себе программист который пишет программки для тестирования программ написанных реальными крутыми девелоперами у которых в профиле большими буквами написано ДЕВЕЛОПЕР.
=)

их зарплаты завышены как минимум вдвое. Синьор-тестеры не должен получать больше чем хорошие джуны-девелоперы.
Размер (можете читать как «потолок») оплаты труда зависит от Value которое человек приносит на своей позиции, а не от того developer он, QA или аналитик.
А судя по тому что вы пишите ниже, вы вообще слабо представляете работу QA Engineer и кто они такие. Надеюсь в вашей рабочей практике появятся специалисты, которые изменят ваше мнение.

ЗЫ:
Кстати, почему эту работу, на которую по вашему ума не надо, не делают сами программисты? Почему вообще существует эта профессия, не подскажите? ;)

Размер (можете читать как «потолок») оплаты труда зависит от Value которое человек приносит на своей позиции, а не от того developer он, QA или аналитик.

Неа) Размер оплаты труда зависит прежде всего от соотношения спроса и предложения на рынке труда. Вот допустим средний синьор 10 лет назад получал 500 баксов, а сейчас 3500. Значит ли это что 10 лет назад в среднем синьор приносил в 7 раз меньше value?

Значит ли это что 10 лет назад в среднем синьор приносил в 7 раз меньше value?
Значит что за value которое он приносил 10 лет назат, ему готовы были платить максимум 500 или сколько там баксов.
Размер оплаты труда зависит прежде всего от соотношения спроса и предложения на рынке труда.
Доля правды в этом есть. Но спрос напрямую завивит от этого самого потенциального value. Это «внутренние войны компаний за кадры» на рынке Украины. Человеку всё равно не заплатят больше чем он может принести компании\клиенту, иначе такой человек не нужен.
Если будет переизбыток специалистов, профессионалы и мастера своего дела всё равно будут получать хорошо (потому что и value от них будет много), а посредственных специалистов будет 100500 на место за $3-$5/h (как в Индии, например), потому что один Senior+ заменит 10-20 посредственных, но этих Senior+ много не бывает.
Человеку всё равно не заплатят больше чем он может принести компании\клиенту, иначе такой человек не нужен.

Согласен.

Если будет переизбыток специалистов, профессионалы и мастера своего дела всё равно будут получать хорошо

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

Значит что за value которое он приносил 10 лет назат, ему готовы были платить максимум 500 или сколько там баксов.

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

Если вдруг резко упадет спрос
Вдруг и резко спрос на IT в мире не пропадёт. Не в ближайшие 10 лет. Он растёт из года в год и расти будет. Конечно, требования будут становится более высокими по мере того как растёт количество специалистов.
Украинский рынок же, из-за стремительного роста ЗП, может «насытиться» (то есть рост остановится), но даже при равных с западом\USA\Canada ЗП, наш человек всё равно будет дешевле (так как кроме ЗП нет огромного количесвтва других костов на специалиста), то есть — выгоднее.
Дальше — сложно прогнозировать что будет.
При худшем сценарии, — специалисты сами будут демпинговать ЗП (если предложение будет намного выше спроса), и тогда, конечно, если человек готов работать за $1000 (а не за $3000, хотя при такой ЗП он тоже выгоден), зачем ему платить больше? — Я же говорит о выше о:
Размер (можете читать как «потолок») оплаты труда
То есть, — о планке.
Вдруг и резко спрос на IT в мире не пропадёт.

Всякое бывает. К примеру, представьте себе ситуацию: одна северокорейская/китайская/российская ядерная бомба падает на силиконовую долину, а вторая за компанию на Нью-Йорк.

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

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

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

Всякое бывает. К примеру, представьте себе ситуацию: одна северокорейская/китайская/российская ядерная бомба падает на силиконовую долину, а вторая за компанию на Нью-Йорк.
Представил. Но вероятность очень низкая, давайте не вдаваться в варианты, вероятность которых стремится к 0.

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

пример мгновенного изменения спроса на синьоров.
Это пример мгновенного измнения вообще всего :) Я очень сомниваюсь что при ядерной зиме бумажки типа «доллара» как универсальный товар останутся. Будет всё оцениваться в автоматах, патронах, куртах и мешках картошки.
Значит что за value которое он приносил 10 лет назат, ему готовы были платить максимум 500 или сколько там баксов.
Не, это значит, что 10 лет назад были согласные работать за 500 баксов, а сейчас нет...

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

Обязательно, а вы эти «основы» наложите на Украину и зарплаты в IT сначале.
Раз вы согласны с постом автора и с тем что Senior QA должен (!) стоить как Junior Developer, то я вообще не понимаю к чему вы мне советуете что-либо, так как у вас своих проблем хватает, судя по всему.
А еще, объясните мне вашими:

основами ценобразования на рынке труда.
Почему Senior+ программист в Верховной Раде получет 5000 грн, а такого же уровня специалист в аутсорсовой или аустаффинговой компании $3000+, как и то что «вилка» ЗП в разных компаниях на одну и ту же позицию иногда отличается в разы, при одинаковом спросе на специалистов в один момент времени.
Почему Senior+ программист в Верховной Раде получет 5000 грн, а такого же уровня специалист в аутсорсовой или аустаффинговой компании $3000+, как и то что «вилка» ЗП в разных компаниях на одну и ту же позицию иногда отличается в разы, при одинаковом спросе на специалистов в один момент времени.
Потому, что компенсация и соответственно привлекательность работы никогда не ограничивается одним окладом.
Человек может выбрать работу в ВР, потому что лично для него:
а) это работа кажется более престижной
б) эта работа кажется более стабильной
в) это работа кажется более социально защищенной
и т.д. и т.п.

Я понимаю, как и тот факт, что в ВР он не приносит value, человек по сути не зарабатывает, так как ВР ничего не продает никак SaaS/PaaS, ни как Software. То есть человек = costs.
И никакие:

основы ценобразования на рынке труда.
тут не помогут.
Кстати, пример с ВР самый радикальный, второй же(про вилку ЗП на одну позицию в разных или даже в одной компании) — куда более часто встречаемый, что ответите на него?
Я понимаю, как и тот факт, что в ВР он не приносит value, человек по сути не зарабатывает, так как ВР ничего не продает никак SaaS/PaaS, ни как Software. То есть человек = costs.
facepalm :)
Скажите, а начальник отдела безопасности ЦРУ тоже не приносит value? ЦРУ ведь тоже, если я ничего не пропустил, не продает ни СааС ни ПааС ни другой аас :)
Старайтесь иногда думать шире рамок аутсорса ...
второй же(про вилку ЗП на одну позицию в разных или даже в одной компании) — куда более часто встречаемый, что ответите на него?
А что именно я должен ответить на него???
Скажите, а начальник отдела безопасности ЦРУ тоже не приносит value? ЦРУ ведь тоже, если я ничего не пропустил, не продает ни СааС ни ПааС ни другой аас :)
Старайтесь иногда думать шире рамок аутсорса ...
ВР и ЦРУ не одно и тоже, начальник безопасности и Senior Developer — тоже разные вещи. Старайтесь иногда не мешать кардинально разные вещи в одну кучу.
А что именно я должен ответить на него???
Не знаю,... я предполагал что-то вроде объяснения первопричин этого.
ВР и ЦРУ не одно и тоже, начальник безопасности и Senior Developer — тоже разные вещи.
В рамках той (давайте честно признаем) ерунды, которую вы написали — большой разницы нет. То, что синьор девелопер в ВР не приносит вэлью — это бред. Как раз вэлью он может там приносить поболе чем в Циклуме.

Ну то такое. Я (и не только я по ветке) пытаемся вам объяснить, что первична как раз ситуация на рынке труда, а именно соотношение между спросом и предложением.

То, что синьор девелопер в ВР не приносит вэлью — это бред.
Я бы не называл это ерундой. Он не приноси ВР value в виде прямых или даже косвенных $$$, он обеспечивает работу «внутреннего проекта», а это для ВР costs с ЗП из «бюджета», то есть — из своего кармана.
соотношение между спросом и предложением.
А я пытаюсь объяснить что не меньшее, а может, и куда большее, значение имеет кол-во value (чаще всего в прямых или косвенных $$$), которое конкретный человек может принести в специальности о спросе/предложении которой вы говорите.
Простой пример — футболисты. Почему крутые футболисты получают миллионы долларов в год? — Потому что они «раскручены» и приносят много value с проданых билетов, программах по ТВ, рекламы и так далее ;)
Есть вакансии и профессии в Украине, в которых на 1 потенциального кандидата куда больше вакансий чем, например, на middle whatever developer, но ЗП даже рядом с плюс/минус $2k не предполагается.
Он не приноси ВР value в виде прямых или даже косвенных $$$,
Ну вообще-то «формально» ВР и не должна приносить $$$ не прямо не косвенно :) Он помогает достичь цели (например, бесперебойной работы), а велью не всегда выражается в $$$, на вас опять груз аутсорса давит ;)
Простой пример — футболисты
Плохой пример — футболисты :) Прибыльных клубов раз-два и обчелся, там действуют немного другие законы. Одни действительно обеспокоены как что-то заработать, другим на все плевать ибо шейхи, которых мало интересуют футболки и билеты, разве что на них написано Fly Emirates ) Вообщем про футбол не надо, еще больше запутаемся :)

Давайте для простоты представим такую ситуацию:
У вас во дворе яма, в ней кусок золота (1 млн $$$).
Достать его очень просто, но сами вы не можете, нужно кого-то нанять. Упростим модель и уберем угрозы безопасности. Какую ЗП вы предложите для этой работы?

Ну вообще-то «формально» ВР и не должна приносить $$$ не прямо не косвенно :) Он помогает достичь цели (например, бесперебойной работы), а велью не всегда выражается в $$$, на вас опять груз аутсорса давит ;)
Какое value приносит программсит в ВР и почему ему не платячт больше 5000 грн?

Ваша «яма» мне не нравится еще больше футболистов. Мой пример жизненный и реальный, а твой — совершенно абстрактный.
Не нравятся футбольлисты, — возьми шоу-бизнес, любой.
Или еще проще, берём двух актёров. Один гениально играет в небольшом театре и получает гроши, а второй — хорошую ЗП за то что плохо играет роль третьего плана в посредственном фильме с большим (по украинским меркам) бюджетом или в каком-то «цирке дюсалей» стоит в масовке... почему? Потому что кассовые и DVD-сборы любого «посредсвенного» фильма или раскрученого цирка выше, чем value небольшого театра, работодатели это знают и могут предложить актёрам больше, зная что заработают в итоге.

Какое value приносит программсит в ВР и почему ему не платячт больше 5000 грн?
Потому что ЗП депутата не выше чем мидла.
Ваша «яма» мне не нравится еще больше футболистов. Мой пример жизненный и реальный, а твой — совершенно абстрактный.
Не нравится яма? Без проблем — у вас фирма, торгует тапочками, прибыль 1М в месяц. Нужен сисадмин держать сеть. Если его не будет и сеть упадет — все, швах, никаких продаж, никакой прибыли. Скока платим? ;)

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

Не нравятся футбольлисты, — возьми шоу-бизнес
Давайте я озвучу вбитую аутсорсом мыслю, которая так и сквозит в ваших постах:
Зарплата DEV/QA не может быть больше чем сума, которую за него платит заказчик. Еще вы эту сумму вы называете value. Наверное так. Только во-первых зп все равно будет исходя из рынка, а во вторых как например померять велью Delivery Unit Manager? За вас вроде заказчик не платит? Скока вам платить-то?Может без вас вообще гайки всему отделу легонькой промышленности, а может (если верить реалити_хакеру так вообще ничего не изменится)...
Потому что ЗП депутата не выше чем мидла.
Вы считаете депутат живёт на ЗП?
А программист в ВР?
Отож!
Без проблем — у вас фирма, торгует тапочками, прибыль 1М в месяц. Нужен сисадмин держать сеть. Если его не будет и сеть упадет — все, швах, никаких продаж, никакой прибыли. Скока платим? ;)
А как сеть держится сейчас, интересно, если всё работает и есть уже прибыль?
Зарплата DEV/QA не может быть больше чем сума, которую за него платит заказчик.
Больше? Хех, она даже 60% от этой суммы составлять не может ;)
Еще вы эту сумму вы называете value.
Не обязательно эта сумма — value. За меня например не платит ни один заказчик вообще, за некоторых членов моей команды тоже, за некоторых около 20-40% от их времени только. Мы приносим не прямое, а косвенное value и не только в своём Unit-е.
Но в итоге, конечно, это сводится к тому сколько в сумме после всех приседаний компания/команда/отдел приносит денег и сейчас, и в перспективе, если речь об аутсорсе или аутстаффе.
В продуктовых компаниях всё немного иначе.
Может без вас вообще гайки всему отделу легонькой промышленности, а может (если верить реалити_хакеру так вообще ничего не изменится)...
Уверен что «Людмила Прокофьевна» знает ответ на этот вопрос ;)
Вы считаете депутат живёт на ЗП?
А программист в ВР?
Отож!
бла-бла-бла... Вы спросили почему 5К — я ответил...
А как сеть держится сейчас, интересно, если всё равботает и есть уже прибыль?
Племяш Саня согласился поадминить пока не найдем! Быстрее решаем скока админу платить, мульены сгорят!!!
Мы приносим не прямое, а косвенное value и не только в своём Unit-е.
И конечно же кто-то провел детальное исследование и объективно оценил это value «не только в своем Unit-e», и уже исходя только из него вывел сколько должен получать уважаемый юнит менеджер. А не то чтобы посмотрел по рынку сколько получают подобные работники? ;))
бла-бла-бла... Вы спросили почему 5К — я ответил...
Вы мне сказали что депутат получает меньше мидла, а не почему программист в ВР получает 5к грн, а такой же в «лидерах рынка» — 24000 грн.
Племяш Саня согласился поадминить пока не найдем! Быстрее решаем скока админу платить, мульены сгорят!!!
Нисколько. У нас всё тащит племяш Саня, не вижу причин для паники :)
И конечно же кто-то провел детальное исследование и объективно оценил это value «не только в своем Unit-e», и уже исходя только из него вывел сколько должен получать уважаемый юнит менеджер. А не то чтобы посмотрел по рынку сколько получают подобные работники? ;))
Зачем проводить исследования? Результаты работы видны каждый месяц.
По рынку я могу стоить сколько угодно, хоть $10000. Но, как вы сами признали выше, платить мне больше чем я приношу мне не будут.
Кстати, посмотрите по рынку, сколько нынче получают «подобные работники»? — Мне, например, очень интересно :)

Я добавлю еще одну причину. Человек банально безинициативный и боящийся что-то менять в своей жизни.

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

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

Такое, конечно, встречается, но с людьми которым за 30, которые не попали в волну IT бум-а.
Но «новое поколение» мыслит совсем иначе, на 10-20% или +$200-$300 sing-on бонуса многие готовы менять работу.

так как у вас своих проблем хватает, судя по всему.
Тестировщику припекло?
Почему Senior+ программист в Верховной Раде получет 5000 грн,
Потому что бюджет.
Тестировщику припекло?
Ам, что? По-моему «припекает» мистеру Zholds-у и Вам, как человеку поддержавшему коммент лишенный и смысла, и логики.
Потому что бюджет.
А как же :
основами ценобразования на рынке труда.
А? Что с ними вдруг случилось?

Нет, припекло как раз вам, т.к. вы не желаете признать что без вашего брата мы вполне можем обойтись.


А? Что с ними вдруг случилось?
Скажем так, ВР это «державна установа» и она не конкурирует ни с кем, как и не является коммерческой организацией, поэтому к рынку она имеет отношение косвенное ( как организация ).
вы не желаете признать что без вашего брата мы вполне можем обойтись.
Я знаю что не можете, что мне тут признавать-то?
Да и вам никто не запрещает без QA-я обходиться, пробуйте, потом расскажите как прошло всё.
Скажем так, ВР это «державна установа» и она не конкурирует ни с кем, как и не является коммерческой организацией, поэтому к рынку она имеет отношение косвенное ( как организация ).
Подождите-ка. Рынок вакансий — это рынок вакансий.
Если у ВР есть вакансия программиста, — то она конкурирует с любой другой компанией, у которой есть аналогичная вакансия. А комерческая организация, или нет, берет она деньги народа из бюджета для своих нужд или зарабатывает сама, уже надцатый вопрос.
А комерческая организация, или нет, берет она деньги народа из бюджета для своих нужд или зарабатывает сама, уже надцатый вопрос.
Нет, не надцатый, т.к. если бюджет утвердили, то ему ну никак не повысят зарплату. Это же гос. организация, огромный и неповоротливый монстр, колосс.

То есть супер система ЗП основанная на спросе и предложении рынка, а так же:

основы ценобразования на рынке труда.
... внезапно перестали работать, как я понимаю, да? :)
... внезапно перестали работать, как я понимаю, да? :)
Ипполит, какой же вы... Ипполит...
Вы правда не понимаете, что зп 5К в ВР ни коим местом не рушит закона спроса и предложения или придуриваетесь?

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

Александр, ну блин, ну опять вы за старое... Сделайте милость, почитайте, что такое закон спроса и предложения. Просто чтобы каждый раз когда вы видите зп в 5К грн и 3K$ не кричать «Ага! Не работает!» :)
З.Ы. И все-таки она вертится :)

Я не начинал тему о «законе», ну да ладно:

Закон спроса и предложения — объективный экономический закон, устанавливающий зависимость объёмов спроса и предложения товаров на рынке от их цен. При прочих равных условиях, чем цена на товар ниже, тем больше на него платёжеспособный спрос (готовность покупать) и тем меньше предложение (готовность продавать). Обычно цена устанавливается в точке равновесия между предложением и спросом. Закон окончательно сформулирован в 1890 году Альфредом Маршаллом.
Кричу «Ага! Не работает!», потому что он не работает для IT-специалистов в Украине, если уже и называть их «товаром», что как-то не корректно, что-ли. Это скорее люди, которые предоставляют сервисы в виде разработки, тестирвоания и т.д.
ЗП регулируется шириной карманов клиентов, ценами на IT-специалистов в других странах (скорее — соотношением затрат к качеству в других странах) и value человека на конкретной позиции, а уже потом идут все эти «перегретые рынки», количество человек на одну вакансию и так далее.
А те кто работают на наш рынок (читайте — программисты в гос. и так далее, где нет бюджетов и Value) — как получали 1800-5000 грн так и будут получать, не смотря на перегретые рынки и соотношения предложения\спроса и «законы».
З.Ы. И все-таки она вертится :)
Верю :)
Кричу «Ага! Не работает!», потому что он не работает для IT-специалистов в Украине
facepalm 2...
Незнание (и непонимание) законов не освобождает от ответственности :)
Надоело... Скучно... Адью :)

Да без проблем, извините что не смог убедить вас в существовании очевидных вещей.

Кстати, почему эту работу, на которую по вашему ума не надо, не делают сами программисты?
Потому-что, время программиста ценее и дороже, что-бы тратить его на тестирование. То есть время затраченное программистом на тестирование можно использовать более рационально:
— потратить на разработку нового функционала;
— банально увеличить время на разработку какой-то фичи;
Хотя я знаю один проект, где программистам дают время специально на цикл тестирования — и они сами тестят.

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

Потому-что, время программиста ценее и дороже, что-бы тратить его на тестирование. То есть время затраченное программистом на тестирование можно использовать более рационально: ...
Я спросил почему вы сразу не пишите программы так, чтобы их не надо было кому-то проверять в принципе? Вы считаете что мир не справедлив, поработайте без QA-я, или наймите, кого вы там предлагали, секретарш и других ребят за 2000 грн и расскажите потом что у вас получилочь из этого.
Я, кстати, тоже считаю не справедливым что программисты, которые не в состоянии покрыть базовыми Unit-тестами свой код, или хотя бы банально проверить что они закомитилии и/или как смержили, а не «собралось и хорошо» и выдают в тестирование явный булшит, вообще имеют право работать как программисты и называться таковыми.
Хотя я знаю один проект, где программистам дают время специально на цикл тестирования — и они сами тестят.
Серьезно? И как успехи в проекте?
И в место того, что бы вложить время и деньги на улучшения качества спецификаций, историй и профессионализма программиста (в плане работы с эстимейтами и анализа функционала), часто нанимают толпу тестеров, что еще больше расслабляет, как аналитиков, так и программистов («если че, QA найдет:)» ).
Весь мир глуп, ГДЕ ВЫ БЫЛИ РАНЬШЕ?!
Я спросил почему вы сразу не пишите программы так, чтобы их не надо было кому-то проверять в принципе?
Ну понятно, что это невозможно).Так как
непокрытые кейсы спецификации
плюс непрофессонилзм программиста, плюс банальные ошибки программиста.
Вы считаете что мир не справедлив, поработайте без QA-я, или наймите, кого вы там предлагали, секретарш и других ребят за 2000 грн и расскажите потом что у вас получилочь из этого.
Ну секреташи прочитают одну-две книги по «теории тестирования», посетят какой-то QA-клуб и станут сениор QA с притензией на 2000 — 3000 $.
Я, кстати, тоже считаю не справедливым что программисты, которые не в состоянии покрыть базовыми Unit-тестами свой код, или хотя бы банально проверить что они закомитилии и/или как смержили, а не «собралось и хорошо» и выдают в тестирование явный булшит, вообще имеют право работать как программисты и называться таковыми
Полностью согласен. Это к вопросу о профессионализме программиста. Описаных вами случаев — масса. Как показывает практика професиональных программистов (не в плане знания алгоритмов,языков, а в плане отношения к работе, аккуратности, ответственности, тимворке, понимания процессов и текущих реалий продукта, над которым они работают) не так уж много и такого булшита хватает. Но (особенно в аутсорсе):
в место того, что бы вложить время и деньги на улучшения качества спецификаций, историй и профессионализма программиста
часто нанимают толпу тестеров
Опять же я считаю профессию QA или тестировщика важной и нужно, но просто все таки качество продукта или релиза или фичи к сожалению очень часто не зависит от количества нанятых QA или тестеров, а больше зависит от профессионализма программиста, аналитика, архитектора...
Ну секреташи прочитают одну-две книги по «теории тестирования», посетят какой-то QA-клуб и станут сениор QA с притензией на 2000 — 3000 $.
Есть примеры таких success stories? Поделитесь. И почему нельзя так?! -
«Ну секреташи прочитают одну-две книги по Джаве, посетят какой-то Джава-клуб и станут сениор Джава девелоперами с притензией на 2000 — 3000 $.»
качество продукта или релиза или фичи к сожалению очень часто не зависит от количества нанятых QA или тестеров, а больше зависит от профессионализма программиста, аналитика, архитектора...
Да, от QA зависит оценка качества продукта, так как профессиональные програмисты, аналитики и архитекторы по тем или иным причинам не могут делать эту работу.
Есть примеры таких success stories? Поделитесь.
Знаю точно один пример перехода секретарши в аутсорс компании в QA в этой же компании. Ну и есть примеры перехода из банковской сферы в QA.
И почему нельзя так?! -
"Ну секреташи прочитают одну-две книги по Джаве, посетят какой-то Джава-клуб и станут сениор Джава девелоперами с притензией на 2000 — 3000 $.
Думаю этого будет недостаточно
Знаю точно один пример перехода секретарши в аутсорс компании в QA в этой же компании. Ну и есть примеры перехода из банковской сферы в QA.
Ам, как это относится к:
прочитают одну-две книги по «теории тестирования», посетят какой-то QA-клуб и станут сениор QA с притензией на 2000 — 3000 $.
???
Думаю этого будет недостаточно
Почему вы думаете что для QA будет достаточно?
Почему вы думаете что для QA будет достаточно?
Потому что претензии на знание джава подразумевают намного более глубокие технические знания которые спрашивают на собеседовании.

Так аналитик выходит туда же. Зачем аналитик, программисты же не тупые чтобы самим требования уточнять?

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

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

Я сам в шоке, а США including Кремниевая Долина до сих пор платит за «рутинную и тупую» работу QA-ев плюс/минус такие же деньги как программистам, вот дураки! :D

Я сам в шоке, а США including Кремниевая Долина до сих пор платит за «рутинную и тупую» работу QA-ев плюс/минус такие же деньги как программистам, вот дураки!
тем не менее в фейсбуке, гугле и куче других прогресивных контор в долине стад QA нету.

Я бы не был так категоричен.
Во-первых, стад «быдло-кодеров», например, там тоже нет, как и армии Джунов и багоделов. Но, многие проекты, как и вся Украина в своей большей части, еще явно не там где Гугл и Фейсбук.
Во-вторых, QA в гугле есть, то что его не много, не значит что он нужен. А значит что проще, лучше и выгоднее иметь 200 професиионалов, чем 5000 джуниоров.
www.linkedin.com/...,PC&redir=redir
и www.glassdoor.com/...79_D_KO7,18.htm
И получают эти люди очень не плохо.
В Facebook нет QA, но есть очень большой Load/Performance отдел (которых или нет вовсе в большинтсве проектах или 1-2 человека в лучшем случае), как и программистов, которые выполняют работу QA в том или ином виде. Многие вещи вообще тестирует армия реальных пользователей и «жалуется на баги» письмами :)
К нам приезжала делегация из Facebook в Сиклум недавно, рассказывали что у них и как устроено, в том числе и в плане контроля качества. Всё не так просто. Да и брать Фейсбук для примера, так скажем, не особо корректно.
Во многих других проектах и компаниях тоже нет QA-ев. А еще бывает что нет аналитиков, тех. райтеров, сейлов, ПМ-ов и суппорт ннженеров, но это не значит что они не нужны.

, как и армии Джунов
Та нет, гугл и фейсбук вполне хайрят толпы вчерашних студентов, думаешь они сразу синьёрами становятся?
значит что проще иметь 200 професиионалов чем 5000 джуниоров.
www.linkedin.com/...ainCountryName=
и www.glassdoor.com/...79_D_KO7,18.htm
Я посмотрел первую страницу с твоей линки, там только один товарищ из гугла, и тот engineer in test, это те которые вполне себе код пишут.
Во многих других проектах и компаниях тоже нет QA-ев. А еще бывает что нет аналитиков, тех. райтеров, сейлов, ПМ-ов и суппорт ннженеров, но это не значит что они не нужны.
Та нет, если прогресивные лидеры идут в каком то направлении, это нужно как минимум мотать на ус.
Та нет, гугл и фейсбук вполне хайрят толпы вчерашних студентов, думаешь они сразу синьёрами становятся?
Впервые слышу. Откуд аинфа что они хайрят вчерашних студентов толпами? Если и берут кого-то «зеленого», то явно кого-то уникального. Зотя, конечно, их revenue per employee теоретически позволяет им это делать. Но зачем?
Я посмотрел первую страницу с твоей линки, там только один товарищ из гугла, и тот engineer in test, это те которые вполне себе код пишут.
Ссылка нормально не делает, я вижу именно Software QA Engineer: screencast.com/t/uGvftGV8
И да, их не много.
Та нет, если прогресивные лидеры идут в каком то направлении, это нужно как минимум мотать на ус.
Мотать можно, только зачем? — если у нас и направление, и бизнес, и ниша — другие?!
Впервые слышу. Откуд аинфа что они хайрят вчерашних студентов толпами? Если и берут кого-то «зеленого», то явно кого-то уникального.
Ну вот у них на сайте даже страничка есть: www.google.com/...th-america.html
Зотя, конечно, их revenue per employee теоретически позволяет им это делать. Но зачем?
Потому что светлых умов на земле не так уж и много
сылка нормально не делает, я вижу именно Software QA Engineer: screencast.com/t/uGvftGV8
И да, их не много.
Я бы сказал очень немного, на первой странице сконцентрировались. Какая то флюктуация.
Мотать можно, только зачем? — если у нас и направление, и бизнес, и ниша — другие?!
Потому что есть конкурирующие пищевые цепочки, типа гугл/фейсбук с прогрессивными подходами, и быдлобанк->аутсорс с человекочасами и КУАями, все идет к тому что первая цепочка по тихоньку занимает вкусные места второй. Тебе конечно решать в какой из них ты окажешься.
вы вообще слабо представляете работу QA Engineer и кто они такие
Судя по его предыдущей теме dou.ua/...ums/topic/6664, он вообще слабо представляет любую работу. Просто обиженый на всех школьник любящий другим указывать кто сколько стоит и куда им идти.

Капают триглецириды вовсю из вас (
Деликатнеше нужно))

Есть бизнес идея. Разместить обьявление на работном сайте, нанять 20 бывших офисных секретарш, добавить джуниор-разработчика и продать их как команду сеньор тестировщиков в UBS или еще куда. Разницу в з/п в карман. Профит!

Ну не в ЮБС, а в ГЛ, но вроде ж все так и было? ;)

Для более живучести надо бы их разбавить синьерами. Хотя бы по одному на 5 секретарш.
Реально может сработать.
;-)

If you hate users — it means you develop something wrong, if you hate QAs — it means you do right things...

У нас вот как год выжили последнего QA, полет ровный и хороший. В селениуме тесты писать/генерить проще простого, функциональные/интеграционные/юнит тесты разного рода програмисты делать научены, экспериментальное тестирование позволяет выявить проблемы на самых ранних этапах.
Если команда не лапухи в инженерном плане, для веб аплилух QA на 90% можно автоматизировать.

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

Так расскажи мне, каие сценарии не может протестировать селениум или какие нибудь функционально-интеграционные тесты?

Расскажу, но шляпу Д’Артаньяна нужно кое-кому для начала снять ;)

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

Предлагаю вам поработать на нормальном проекте что бы понять, что такое QA.
Писать тесты на селениуме или юнит тесты для серверной части на каком-то скриптовом яызке (php\python etc) это уровень джуниора-миддла. Так-то да, 5 программеров могут действительно заменить одного джуна куа...)

А у вас КУА пишут юнит тесты? И чем таким магическим у вас занимается senior QA? У вас есть Delivery Unit Manager?

Если программисты умеют провайдить качественный код, предупреждать потенциальные проблемы сами, не создают багов, все покрыто необходимыми тестами (и на это есть и время, и люди) и все работает «как часы», то да — QA-и не нужны.
Например, в Facebook-е нет QA-ев, но есть целый Load/Performance отдел :)

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

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

Всё заивист от тонны факторов, выбранной методологии разработки, использования TDD/BDD подхода, Unit Tests, Automation (UI/Back-end) tests и так далее. Говорить что:

гораздо выгоднее(в плане времени, качества и людей) инвестировать в покрытие автоматическими тестами, т.к. они будут запускаться каждый час не прося кушать.
... как минимум не верно, потому что в каких-то случаях это так, в каких-то нет, а в каких-то просто невозможно покрыть большинство функционала автотестами (тем более «вообще весь»).
Есть и другие факторы: сроки, бюджет, ресурсы, другие проекты в бизнесе, приоритеты, gross margin...
Короче говоря, всё крайне индивидуально от проекта к проекту.
Всё заивист от тонны факторов, выбранной методологии разработки, использования TDD/BDD подхода, Unit Tests, Automation (UI/Back-end) tests и так далее.
Ну да, в моем подходе нужно писать «Unit Tests, Automation (UI/Back-end) tests и так далее»
я еще не встречал методологию ведения проекта в которую бы не умещались автоматические тесты
... как минимум не верно, потому что в каких-то случаях это так, в каких-то нет, а в каких-то просто невозможно покрыть большинство функционала автотестами (тем более «вообще весь»).
Я выше написал что речь про веб апликуху, и ее на 90% покрыть вполне можно
Есть и другие факторы: сроки, бюджет, ресурсы, другие проекты в бизнесе, приоритеты, gross margin...
Короче говоря, всё крайне индивидуально от проекта к проекту.
Да, ты прав, давно не касался аутсорса, когда спихнули заказчику проект кое-как и забыли.
я еще не встречал методологию ведения проекта в которую бы не умещались автоматические тесты
Серьезно? Их много. Быстрый ответ — любое ПО (например для людей с disabilities) которое использует разнообразные не стандарные hardware-дивайсы (чаще — собственного производства). Много тут не наавтоматизируешь, максимум работу API и дров. Так же продукты, где нельзя просчитать матрицу вариаций (точнее — можно, но равносильно покрытию отдельным тестом каждое из всех возможных вычислений калькулятора) — например, игры.
Далее — я не представляю как usability и user experience может сделать автотест, а для некоторых приложений это имеет критическое значение (ПО для детей, например, те же игры, etc.).
Я выше написал что речь про веб апликуху, и ее на 90% покрыть вполне можно
Возможно, но покрыть, например, игрушку вы не сможете как положено, с мобильными устройствами такая же история, симуляторы ОЧЕНЬ не всегда работают адекватно, особенно идеальные типа WP7. А если есть развитый multiplayer, так как кол-во вариаций и сценариев очень большое.
Ты слышал, наверное, о существовнии alpha open/close-beta стадий у продукта и UAT тестирвоания. Почему большие и крутые компании просто не взяли и не «автоматизировали всё» или 90%+? — Потому что это не всегда возможно и не на все вопросы даёт ответы.
Да, ты прав, давно не касался аутсорса, когда спихнули заказчику проект кое-как и забыли.
Я понятия не имею как в аутсорсе сейчас, честно говоря. Я говорил скорее об аутстаффе. Nevertheless, «карман» клиентов не резиновый. Они часто меняют приоритеты, у них бывают не сдвигаемые дедлайны (например, выставки), смена желаний и приоритетов под «новых инвесторов\будущих клиентов», вообще не желание тратить доп. деньги на автомейшен любого рода, так как взял junior-middle мануальщика-двух банально дешевле для него, и многое другое. Иногда клиенту просто доказать и объясняить что-либо сложно. Иногда он не понимает тех. языка, сложно понимает что такое «технический долг», что-то вроде «зачем мне чистый код покрытый тестами? Зачем мне автоматизация? Мне надо чтобы сразу писали хорошо!», например, и в таком роде. А так делать не всегда возможно, особенно если решение масштрабируемое и с требованиями, которые постоянно меняются.
Для коротких проектов, например, вообще нет смысла основательно подходить к процессу автоматизации каких-либо тестов, а иногда, подходить к нему вообще.

Резюмируя: автоматизация — это очень хорошо, когда она делает «жизнь» лучше, проще и эффективнее. Но возможна и нужна она не всегда, не во всём, и не во всех проектах.

Серьезно? Их много. Быстрый ответ — любое ПО (например для людей с disabilities) которое использует разнообразные не стандарные hardware-дивайсы (чаще — собственного производства).
Я писал про методологии ведения проектов, при чем здесь разнообразные девайсы?
Возможно, но покрыть, например, игрушку вы не сможете как положено
Почему это?
Ты слышал, наверное, о существовнии alpha open/close-beta стадий у продукта и UAT тестирвоания. Почему большие и крутые компании просто не взяли и не «автоматизировали всё» или 90%+? — Потому что это не всегда возможно и не на все вопросы даёт ответы.
Наверное потому что у них еще не внедрены правильные подходы автоматического тестирования, а они выбрасывают деньги на сотни тушек, которые при каждом изменении ручками тестируют сотни тесткейсов.
Мне надо чтобы сразу писали хорошо!«, например, и в таком роде.
Ну так правильно, в «писать сразу хорошо» обычно включают хорошее покрытие автоматическими тестами. Кто о них слышал конечно.
Я писал про методологии ведения проектов, при чем здесь разнообразные девайсы?
Да ни при чем. При любой методологии будет так с такого рода проектами. Я в таких участвовал.
Почему это?
Потому что очень много вариаций.
Наверное потому что у них еще не внедрены правильные подходы автоматического тестирования, а они выбрасывают деньги на сотни тушек, которые при каждом изменении ручками тестируют сотни тесткейсов.
Расскажите это, анпример, Blizzard или другой гейм студии серьезной. Уверен что там не идиоты работают. Про баланс, usability, user expectation и так далее — слышали? Автотестами это не померять.
Ну так правильно, в «писать сразу хорошо» обычно включают хорошее покрытие автоматическими тестами. Кто о них слышал конечно.
Покрытие автоматическими тестами (любого рода, в принципе, а то мы как-то абстракто тут говорим) — необходимое условие, но не достаточное.
Да ни при чем. При любой методологии будет так с такого рода проектами. Я в таких участвовал.
Расскажите это, анпример, Blizzard или другой гейм студии серьезной. Уверен что там не идиoты работают.
Все это так, но в твоем деливери юните КУА занимаются тестированием странных приборов и high end компьютерных игр?
Покрытие автоматическими тестами (любого рода, в принципе, а то мы как-то абстракто тут говорим) — необходимое условие, но не достаточное.
Ок, т.е. вы таки поставляете заказчику инфраструйтуру автоматического тестирования? Или у вас пишут не хорошо или не сразу?
Все это так, но в твоем деливери юните КУА занимаются тестированием странных приборов и high end компьютерных игр?
Первое нет, второе — от части да, бывают проекты-игры (мобильные, социальные). На моём юните QA не заканчивается ;)
Или у вас пишут не хорошо или не сразу?
У меня нет ни одного знакомого программиста который пишет код без багов (major+ уровня), так или иначе — лажают рано или поздно все.
вы таки поставляете заказчику инфраструйтуру автоматического тестирования?
У нас есть развёртывание своего тест-фреймворка на Selenium WebDriver + Sauce Labs, например, и покрытие тестами продукта который у клиента в разработке (или уже разработан, не важно), — как service и тогда тесты — его собственность, так скажем.
Когда же речь о разработке продукта у нас, то клиента не особо волнует как мы добьемся качества (его скорее важно сколько стоит и когда будет) и при delivery продукта мы не поставляет ему тесты (не считая тех что непосредственно в коде продукта).

В геймдеве автоматизации тестирования нету. Гуглил на эту тему ради интереса. Юнит-тесты пишут. А так, сидит толпа мануальщиков с включенным фрапсом и скурпулезно прочесывают игру. Думаю, геймдевы на этом форуме подтвердят.

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

Ам, вы делали подобные проекты?

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

Так в чем проблемма-то?

Разработайте пожалуйста дивайс элумирующий ребёнка с ДЦП или человека с плохим зрением или слухом, который потестирует соотвестсвующее ПО и девайсы к нему.
Расскажете потом как получилось, сколько это стоило, каких сроков потребовало и на сколько эффективно работало.

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

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

Я не буду здесь доказывать, что я не верблюд.
Жду ответа на:

Так в чем проблемма-то?

ну я думаю, человек намекает на то, что вы тестировали достаточно простую так себе коробочку-черный ящик, его поведение (реакцию на стимулы) можно было достаточно просто описать с помощью обычной логики. Если взять такие примеры, как привел товарищ, то вы (на данном этапе развития) не сможете за н-лет кропотливой работы м-сотрудниками покрыть тестами вашу коробочку до состояния, чтобы конечный пользователь смог бы пользоваться коробочкой хотя бы минуту без замечаний с его стороны. Ничего личного именно вам, и вашим коллегам, просто это жизнь, кстати тоже чрезвычайно сложная штука и никакими автоматическими тестами ее не покрыть. Как итог, иногда живой реально приближенный пользователь сделает на порядок больше, чем работа НИИ с к-докторами наук ну или две-три такие компании как люкс и глобал. Так зачем платить больше. Тут человек выше уже за геймдев писал с его автоматизацией. Это лишь один пример, их тысячи. Мед электроника, которой вы занимались тоже сюда входит. Просто помпа ваша была достаточно просто описываемым объектом плюс более гумано это автоматизировать а не колоть себя водичкой, хотя знаю что кто-то из тестеров вообщем то и это делал у вас.

Программист и тестер — разные стили мышления и полностью их никогда не совместить.

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

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

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

Всем хочется, чтобы должности красиво звучали, проекты были интересными, а еще начальство замечало, а клиенты хвалили. QAE в данном плане не исключение.
Я руководитель проекта, довольного крупного, с изощренной логикой и нестандартными клиентами. К сожалению, когда горячо любимые Sales managers договаривались с клиентами о проекте. Как результат, имеем обязательства перед клиентами, не выполнить которые равносильно потери репутации в целой отрасли, с другой стороны руководство, недополучившее прибыль от команды (да, ресурсы выбила себе на проект не самые плохие :), хотя и начинали нелегко — два джуниора, сениор и вечный девелопер — более 4 лет девелопер). Поэтому проектом и его ходом всегда недовольны, при каждом удобном случае тыкают, что проект убыточный, а это составляет довольно таки сильное психологическое давление на всю команду в целом. Первым не выдержал ТЛ, слиняв с проекта. Далее — более. QA Lead требовала настойчиво, чтобы ее перевели на другой проект, ибо сил нет работать в такой обстановке. Оговорюсь, команда довольно часто работала по выходным, ибо в переговорах с клиентами последние всегда аппелировали к руководству, и мы шли им на уступки по объему работ. Как итог, не успевали — даты и ресурсы -то фиксированы.

Так вот мой QA Lead попросилась на крупный и перспективный проект в нашей компании. Как результат, на нее спихнули задачу по геренации отчетов в формате, требуемом клиентами. Из-за генерации отчетов она никогд ане успевает со своей основной деятельностью, к тому же ее текущее тест-руководство не сильно довольно ее прогрессом по причине неуспеваемости. А девушка толковая и «шарит» в автоматизации, так что предвзятость тут незаслуженная. Что касается профессии QA, могу добавить только такое: если есть проект, где можно внедрить quality assurance — отлично. Зачастую подобного не имеется, то есть по-настоящему крупных и интересных проектов нет. Все специалисты вынуждены заниматься рутиной, иногда с их основным профилем не имеющей ничего общего. Говорю, как человек, выполняющий роль аналитика, тестера и даже build engineer на проекте, а также одновременно являясь руководителем этого проекта. Что касатеся QA, прийдя в IT-отрасль была твердо уверена, что QA, аналитики и PM — это все неудавшиеся программисты. Извините, если обижаю чьи-то чувства. Однако понимание процесса разработки открыло глаза на все, что творится вокруг. Теперь мне кажется, что у каждого на проекте своя роль. Никто кроме него не сможет выполнять ее лучше. Это же касается QA. Никто не сможет со всей ответственностью заявить, что релиз не готов к сдаче из-за недолжного качества оного. Опять же как руководитель проекта, в этом вопросе я полагаюсь исключительно на QA.

ну бывает, воткнулись в плохое управление чуть более чем ненулевыми рисками.

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

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

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

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

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

В итоге когда предложения от других компаний начали (в финансовом плане) быть на 25-30% выше нынешней ЗП, это «перекупило» идеальный с точки зрения «удовольствия от работы» проект и народ разбежался.

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

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

Тесретами, возможно, больше берут девушек, но не QA-ями точно :)

угу, расскажите это Юле Нечаевой, например :) а также многим милым дамам на позициях QAE, Lead QAE, QD

Никто не говорит что такого нет, я говорю лишь о тенденции.

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

это хорошо! главное, чтоб было нескучно)

Дякую, хороший список забобон і хибних уявлень про професію.

Коментар порушує правила спільноти і видалений модераторами.

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

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

Разве что, могу посоветывать почитать больше о такой профессии как QA Engineer (не путать с Tester и QC), и пообщаться в живую с хорошими инженерами (QC, Junior-ы и task performer-ы из разряда pass-fail не в счет).
Возможно это изменит мировозрение автора.

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

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

Здесь я бы поспорил (я большую часть карьеры в ИТ работал именно без таких тимов). Во-первых на небольших проектах куда эффективнее когда разработчики сами друг друга тестируют -ибо они лучше всех знают «почему баги» (но да, раз в неделю-две им необходим «свежий взгляд», но он вполне реален, если проектом интересуются ПМ и/или заказчик), ну и полноценный тестер, даже тот что

из разряда pass-fail

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

Но, не исключено, что на небольших проектах те самые QA Engineer таки лишние (плюс неподъемные для бюджета), потому мне они не особо и встречались.

В общем, похоже автор статьи и вы имеете разные определения для данной професии :)

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

У моего заказчика, например, на 4 девелоперов приходится 2-3 тестера (в зависимости от проекта). И это далеко не предел — посмотрите на аэрокосмическую отрасль.

Поставил плюсик.

У нас правда соотношение чуть похуже: 1 к 3 примерно.

Максим, а где (кем я уже понял) вы работаете раз у вас большую часть карьеры нет QA Тeam-ов? И какого рода продукты вы делали? Почему-то мне в голову приходят только «обычные сайты» или вообще, «шаблонные» вещи основанные на допиленых фриварных движках с перерисованным дизайном. Если ошибаюсь, — поправте.

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

Необходимость этих людей, их команды и должности как таковой доказана ни одним годом работы и ни одной сотней серьезных компаний, а также ни одной сотней тысяч сделаных проектов и ни одним миллионом денежного профита полученного в результате работы даных товарищей! :)

Никто не отрицает что людям которые пишут «что-то на коленках», «халтурки» и прочие «не серьезные» вещи, а также тем кто не понимает чем, как и зачем на самом деле занимается QA инженер (если они с такими и не сталкивались, или путают это понятие c QC, чисто «тестировщик ПО» или «человек который проверяет работает ли кнопка» и т.д.), вполне может казаться что «они не нужны». Как и «Дизайнеры», как и «Технический суппорт», как и «Проджек Менеджер» как и «Бизнес Аналитик», как и кто угодно на самом деле, в этой теме уже писали про «врачей» и т.д. и крайне верно писали.

Видимо просто вы еще не сталкивались с проектами где они нужны или же Вам не попадались люди, которые бы занимались своей работой качественно. Но этот никак не значит что они не существуют и\или не востребованы. :)

ЗЫ:
Пока писал ответ, еще 1 мысль пришла в голову.
Не в первый раз замечаю что у многих программистов имеется такое вот мнение, что QA не нужен (или это «не работа» на самом деле и т.д.) и что они являются «низшей» по сравнению с программистами «кастой» в IT обществе и т.д. И знаете, на моем опыте, это люди которые в девелопенге максимум год, или работают давно но в мелких «стремных» компаниях где нет ни нормально поставленного рабочего процесса, ни даже понимания о последнем.
Каждый имеет право на мнение, могу дишь добавить — поработайте в бизнес проектах энтерпрайс уровня, в банкинге, в телекоме, в крупных компаниях типа Люкса или Глобала, или Циклума (где QA Lead-ы выполняют по совместительству фукцию PM-а на многих проектах) и тогда, уверен, вы измените отношение и к этим людям, и к их работе и, особенно, к их надобности! :)

Единсвенное что действительно правда — это зарплатный фактор (если смотреть грубо и в среднем и т.д.). Порог входа ниже, это правда, но начинает человек как QC Trainee (или intern), а для этой работы действительно кроме тех. образования, IT-ного мышления, хорошего англ. языка и желания учиться больше ничего не надо.
Действительно QA-и получают на 10-15% меньше денег чем программисты и имееют не столь обширные возможности в проф. росте, получению новых навыков и т.д.но тут опять же, все зависит от квалификации, компании, твоего желания и стремления к самообучению.
И Senior-ов и, тем более Lead-ов никому не дают по «выслуге лет» — это все сказки. Хотя может в какой-то гос структуре бытует и такая смешная политика, но это разве что из раздела юмора... Дают за скиллы и способности, не иначе. И зарплаты и «погоны».

Я точно не работал и не работаю с шаблонными вещами.

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

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

Кстати «большую часть карьеры не работал» и «не работал» вообще — это разные вещи.

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

Угадайте, нужен ли QA _team_ фирме из 10-20 человек, среди которых до 18,5 разработчиков, в среднем 3-4 на проект, проекты решают не самые сложные, но нужные заказчикам бизнес-задачи? Здесь в лучшем случае задействуют одного (максимум 2-х) тестеров, и этого с головой хватит.

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

К тому же я указал на _небольшие_ проекты. Я отнюдь не оппонировал вам в целом, но указал, в каких случаях целый тим отнюдь не необходим, или даже неподъемен для бюджета (могу дать и конкретику: с точки зрения больших компаний это «жадные» заказчики. Да, такие тоже есть, но кто-то на них тоже зарабатывает? :) ).

Повторюсь, я отнюдь не оппонирую вам и не поддерживаю автора статьи в его мыслях: вы с ним действительно (как вы справделиво и заметили) под термином QA Engineer понимаете разные вещи. И я не говорю, что QA и даже простые тестеры в принципе «не нужны». Я лишь указываю ниши, где без них с грехом пополам справляются, и где «тим» (а не 1 тестер на 3-4 проекта- и это (3-4 проекта) — все активы фирмы) просто может быть неподъемен.

Понял Вас.

Пожалуй, соглашусь частично. При ваших проектах, конечно, комманда не нужна, но 1 толковый QA вам нужен (даже если 1 для нескольких проектов). Если найдете хорошего специалиста, уверен, вы не 1 раз порадуетесь тому что он у вас таки есть :)

Спасибо, эта тенденция (нанять 1-2 QA) также прослеживается в небольших компаниях, в т.ч. и в той, где сейчас работаю.

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

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

Угадайте, нужен ли QA _team_ фирме из 10-20 человек, среди которых до 18,5 разработчиков, в среднем 3-4 на проект, проекты решают не самые сложные, но нужные заказчикам бизнес-задачи? Здесь в лучшем случае задействуют одного (максимум 2-х) тестеров, и этого с головой хватит.

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

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

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

И я не говорю, что QA и даже простые тестеры в принципе «не нужны». Я лишь указываю ниши, где без них с грехом пополам справляются, и где «тим» (а не 1 тестер на 3-4 проекта- и это (3-4 проекта) — все активы фирмы) просто может быть неподъемен

а вы не думали, что активы фирмы поднимаются как раз за счет более высокого качества и сроков исполнения обязательств, чему явно способствует грамотная команда QAE ? и если вы таки понимаете, что такое QAE и чем он отличается от QC — должны понимать, что кроме непосредственно тестирования у них много областей :)

колись думав приблизно так само. дякую вищим силам, які дали попрацювати із справжніми qa-інженерами (язик не повертається назвати їх тестерами). вони зробили гарне щеплення від дурних снобських уявлень

Что за QA который поленился даже проверить орфографию? Проверок развелось — на каждум углу, в браузере, в почте, в ворде — так нет, все равно. Вы и тестируете также? )

Меня затроллила фраза "

эллементы троллига

"

Уже где-то на форуме оставлял эту ссылку, но уж очень она к месту здесь. Первые минут 20-25 тест-директор Гугла в забавной форме рассказывает, зачем нужны тестеры.

http://www.utest.com/webinars/more-bang-your-testing-buck

Будь-яку роботу корисно сприймати як сходинку для переходу на більш високий рівень.

Почти всегда (по моим наблюдениям в 90 проценов случаев) сениор и мидл QA инженеры стремяться перейти на новый уровень, став программистами, тимлидами, консультантами, проджект менеджерами, автомейшн QA инженерами.

У нас в команде 4 мануал тестера. Все сеньоры. Почти все ведут тест-проекты. И никто не собирается «переходить на новый уровень» путем смены вида деятельности. Это если и новый уровень, то он более низкий. Начинаете с нуля или только основных навыков. И опять потратите годы, чтобы достичь «потолка зарплаты».

Ці 4 тестера-сеньйори на тому проекті де 3 девелопера?))

Проект не один, и девелоперов не 3. Откуда такие предположения..

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

Пост на ДОУ на такую общую тему, более связанную с вашим отношением к теме, нежели с фактической ситуацией, к результативному обсуждению не приведет. Тут или согласятся с вашим видением, или нет, а в целом тема не бог весть как важна для сообщества.

В смысле, почему это тема «неважна»? По-моему очень интересная тема. Может быть на форуме такие темы редко обсуждаются, ну так попробуем исправить.

Согласен :) Тестеров сейчас довольно много, но они меньше пишут на форуме (и соответственно меньше читают, ибо меньше контента для тестеров).

Думаю, это отчасти потому, не видно позиционирования ресурса на тестеров. Больше на девелоперство, фриланс, стартапинг.

Наверное, не нужно ресурс на тестировщиков позиционировать.

Это не движущая сила, даже если их много, в Киеве нет (и походу — не будет) коммьюнити тестировщиков.

PS automated-testing.info не в счет, там особое, не уличное тестирование.

Тестер говорит, что ресурса (и коммьюнити) для тестеров в Киеве нет, не будет, да и не нужно. Я правильно понял? :)

Безусловно.

Если бы у киевских тестировщиков БЫЛА необходимость сделать себе коммьюнити, оно уже давно существовало бы. А оно не существует.

Есть живое коммьюнити в Днепропетровске, есть почти незаметное коммьюнити в Харькове, есть автоматизаторы в Киеве, и всё. Гляньте на карту сообществ СНГ sqagroup.spb.ru/communities Повсюду малые группы, никаких толп, и даже в Москве есть только одно внятное сообщество, да и там нет постоянного угара, такого, «шоб всё кругом гудело».

Технически сделать ресурс можно даже на заборе или на бумажных листочках — тот же ЖЖ подойдет. Посещаемость его в первые месяцы будет высокой, стопудов (наблюдал такое неоднократно). Затем резко пойдет на спад, бо контент-генераторов в среде тестировщиков не будет. Существующие сообщества тестировщиков в ЖЖ мертвы.

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

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

А все почему? А всё потому, что тестировщики кучкуются по компаниям, а не по интересам :)

ДОУ хорош тем, что он общий, как рыночная площадь.

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

Возможно, тестеры не видят, что они часть аудитории ресурса?

Все они видят. Недавний подсчет зарплат сильно разволновал эту часть аудитории :)

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

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

Рунет в этом плане явно не развит, основная тематическая движуха происходит на форуме software-testing.ru

Народ обычно состоит из 90% читателей, 5% троллей, 1% пишущих, остальные наблюдают.

Была бы необходимость в постоянном написании статей или sharing ideas — весь портал software-testing.ru только под это и заточен...

На хабре иногда появляются всплески активности и статей со стороны тестировщиков, но обычно это предваряет крупные события в области, вроде уже ставшей суперской конференции SQA Days.

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

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

Есть www.utest.com/community — там фрилансеры в тестировании обсуждают вопросы фриланса в тестировании. СНГ-шный аналог fixber в этом плане двигается, но вяло.

Короче, вот уже почти обзорная статья :)

1) Она не резонансна. Это не «хочу Иммигрировать ИЗ страны, что для этого надо учить, неужели Java?!» ;)

2) Подача темы для обсуждения [непосредственно в этом треде] изначально неудачна. У парня усеченное видение ситуации, очень похоже на нытье в стиле «Аааа, меня побили негры в Гарлеме! Я вообще не понимаю, зачем в мире существуют негры, природа явно ошиблась на их счет!», а это не конструктив.

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

Еще непонятно, является ли это видение «со стороны», или он сам пострадал, будучи «сосланным в тестирование».

Понятно только то, что сейчас он видит (и ретранслирует) низкий уровень тестирования, с никакущим социальным статусом и никакими перспективами; он тянет за собой в эту картину ВСЕ возможные страхи и опасения, и преподносит это как итоговое «вот так оно всё и есть, жизнь на Марсе невозможна».

Да, совершенно невозможна. Марсиане никого переубеждать не будут :) Кесарю — кесарево, слесарю — слеварево...

Я не считаю, что пофессия тестера ненужная, напротив тестировщики конечно нужны и уважаю их труд. Никто не спорит. Просто опять же хочу повторится, что считаю профессию тестировщика изначално штучной и составной. Но в этом нет ничего плохого. Собственно на это и пытаюсь указать. Теннисист — играет в теннис, программист — пишет код. Тут все однозначно. А тестировщик — тестирует. Что значит тестировать или обеспечивать качество? Это абстрактное понятие. Невозможно тестировать. Это составной процесс, а не конкретное действие. Тестировщик может например:
1) общаться с кастомером, уточнять требования и тд и тп (ок согласен, но это просто комуникация, английский. И программисты, и ТЛи общаются с кастомером. Что тут уникльного для тестера?)
2) Разбираться с продуктом, уточнять архитектуру, специфику работы продукта (ок согласен. Нужны знания. Ну что тут такого, что присуще исключительно тестированию?)
3) Настраивать окружение для работы (ок. согласен. Опять же тут навыки сисадмина, админа БД.... ).
4) Писать автоматические тесты, скрипты. (ок согласен. Но это программирование, просто (иногда урезанное) программирование)
5) Более опытные QA инженеры управляют несколькими молодыми (ок. Но это не тестирование, а менеджмент или микроменеджмент...)

6) И самое главное — собственно выполнять тестирование, то есть реально работать с конкретным продуктом. Это именно,то,что нужно. А это просто мануальный тестинг. Вот он и нужен. И кто его больше сделает, этого самого мануального тестирования, тот даст лучшее качество. А поскольку, выполнение ручных тестов многим сениорм из-за лени и , уже поднадоело, то придумали новую фишку, типа ручной тестер — это малоквалифицированый новичок, а более опытный сениор — выполняет оценку требований и тд и тп., управляет работой. Хотя я считаю, что именно сениор должен быстрее и больше всех молча, сцепив зубы, выполнять мануальные тесты, покрывая как можно больше требований и тесткейсов (ну естественно расставив приоритеты). Потому — что, только и только ручные тесты дают качество. (Автомейшн тут не рассматривается). Вот именно, те люди, которые выполняют хорошо прочитали мануал к продукту, уточнили детали своих фич и сделали больше тестов, те и хорошие тестировщики. Ну первые 5 пунктов тоже важны.

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

И так далее...

Если вас просто «обидели» чем-то QA-и, еще не поздно признаться! ;)

ЗЫ:

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

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

нет, нет. Писать код != знать буквы).

(ну и что тут такого? Прочитать книжки и выучить технологии может любой!)

вот именно, что не любой.

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

Это метафора была как-бы, предполагалось что она будет понята. :)

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

Вот еще топик для размышления: www.developers.org.ua/...ums/topic/4043

Дело в том, что

а) вы пытаетесь осознать рамки действия тестировщиков, и ищете однозначность. А тестирование неоднозначно.

Основной ваш постулат — каждый должен заниматься своим делом,

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

.

Но тестирование — это процесс, которым занимаются все, просто в разных долях применимости.

Теннисист, например, может водить машину и работать таксистом — одно другому не мешает, он все равно остается спортсменом с ракеткой.

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

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

б) понятие QA-инженер ублюдочно и искусственно по своей сути.

Нет инженеров по контролю качества ПО. Тестировщики ПО есть, а инженеров по контролю качества ПО — нет и никогда не будет.

Например, по штатному расписания у меня в письмах должна быть автоподпись с указанием должности ’Senior QA engineer’, но я заменил ее на ’Software tester on [такая-то торговая] platform’.

Смещение заблуждений а + б приводит к тому, что в итоге вы неверно оцениваете ситуацию.

Это не укор и не приглашение к спору :)

б) понятие QA-инженер ублюдочно и искусственно по своей сути.

Нет инженеров по контролю качества ПО. Тестировщики ПО есть, а инженеров по контролю качества ПО — нет и никогда не будет.

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

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

Это абстрактное понятие. Невозможно тестировать.

Это написано совершенно по незнанию. Точно так же, как есть люди, которые не понимают, что такое программировать.

Тестирование на сегодняшний день — это полноценная айтишная дисциплина, со своей структурой, техниками, сертификациями.

Еще непонятно, является ли это видение «со стороны», или он сам пострадал, будучи «сосланным в тестирование».

Что значит пострадал? Да не страдал я). Работал QA инженером и нормально справлялся с задачами.

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

А что значит высокий уровень тестирования, объясните пожалуйста?

Что значит пострадал? Да не страдал я). Работал QA инженером и нормально справлялся с задачами.

из вашего поста этого не следует. уклон в QC явно просматривается

А что значит высокий уровень тестирования, объясните пожалуйста?

вы заявили, что работали QA инженером — это и есть более высокий уровень

40 комментов за два дня. не так уж и плохо.

Две третьих тестирования в каждом проекте одинаковы. (И возможных вылетающих багов).

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

На самом деле тут все очень сильно зависит от специфики проекта.
Есть проекты которые можно автоматизировать практически на 90%, а есть такие где и 15% будет крайне не простой задачей, точнее — не выгодной попросту.

Просто по сути мануальное тестирование как таковое отходит на «второй план» у более старших QA-ев, но это не обязательно за счет написания «кода во фреймворках».

Працюю в тестуванні більше 2 років і зрозумів:
1) для мануального тестування не потрібна вища освіта
2) для мануального тестування потрібно знати 3-4 видіи тестування у 80% випадків
3) для мануальщика знання java, c++, vbScript ... + для самого тестувальника, більше то не потрібно нікому
4) без SQL мануальщику можна прожити але це тільки обмежує scope тестування
5) всі співбесіди де є купа теоретичних питань bullshit, і нічого в людини не виявляє як і не дає проявитись кандидату
6) думаю, що тестувальників можна готувати за 1 міс інтенсиву або 2-3 місяці з легкому режимі після роботи

7) для даної спеціальності підходить будь-яка адекватна людина, більше особливих вимог не треба, так як решту можна навчитись по ходу роботи

більше особливих вимог не треба, так як решту можна навчитись по ходу роботи

Инглиш!

6) думаю, що тестувальників можна готувати за 1 міс інтенсиву або 2-3 місяці з легкому режимі після роботи

что и делает успешно компания SoftServe))

Бачите, тут взаємовиключне протирічння виходить. З однієї сторони, ті хто процюють в тестуванні кажуть як Ви (не вперше зустрічаюсь з таким), з іншого боку — вакансій типу QA trainee практично немає, а щоб потрапити на курси по тестуванню — вже треба продемонструвати хард-корні навики grc.ua/vacancies/7382619 , особливо як для гуманітаріїв. Хоча багато кажуть що в тестуванні багато гуманітаріїв.

Любой здравомыслящий чевлоек может без каких либо на выков сесть и составить план тестирования чего-либо

Это применимо ко всему вообще. И врачом такой человек стать может, и физиком, и программистом кстати. А вот стает ли. Мы даем на собеседованиях протестировать одно небольшое приложение. Есть люди, которые находят 2, 4, 10 багов. А есть такие, кто находит 40. И вот тут я бы еще раз послушал о здравомыслии и что вы под ним понимаете. Люди то все адекватные, опыт там, все дела. А результат разный.

Любой здравомыслящий чевлоек может без каких либо на выков сесть и составить план тестирования чего-либо

План тестирования:
1. Тестируем
2. Еще разок тестируем
3. goto 1

Тестировщики появились потому что:
1) Программисты не хотят проверять приложение/не проверяют приложение/плохо проверяют приложение/пишут код с ошибками/не пишут юнит тесты/пишут плохие юнит тесты/не используют ТДД и т.д.

2) Заказчики не хотят проверять/технически не компетентны в деталях/им дешевле или выгодней нанять тестировщиков

И не всё можно автоматизировать кстати. Так что мануальщики были есть и будут. Ничто просто так не появляется и не исчезает.

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