🏆 Рейтинг ІТ-работодателей 2019: уже собрано более 5000 анкет. Оцените свою компанию!
×Закрыть

QA как класс уходит в небытие?

Уже не первый раз встречаю инфо, что в разных местах постепенно отказываются от тестировщиков.

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

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

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

3. Попытка переложить часть тестирования на программиста, писать юнит, интегрейшин и прочие тесты. Автоматизация всегда дело хорошее, в сложных кейсах конечно.

4. Попытка убрать QA совсем с индустрии?

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

LinkedIn

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

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

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

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

Та не вимирають QA зовсім. У нас на кантору за останніх пів-року взяли більше QA, ніж програмістів.
А хитрожопі замовники завжди були.
Ті що хочуть, щоб програміст сам баги тестав і сам їх фіксав.
Це просто бідні, жадібні та хитрожопі замовники створюють міф про вимирання QA.

Ага, уходит.
В разделе «Работа», количество вакансий по направлениям:
QA — 526
Java — 336
PHP — 296
Project Manager — 186
...
Ruby — 68

Небытие говорите? :)

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

подскажите на курсах дают такую программу обучения на QA тестировщика реально потом работу найти если с нуля пойти на такие курсы:
Обзор IT бизнеса: технологии и термины;
Фазы процесса разработки программного обеспечения;
Методологии процесса разработки программного обеспечения;
Анализ существующих моделей и методов разработки;
Роль и место QA в процессе разработки программного обеспечения, тестирование и QA;
Введение в тестирование;
Цели и задачи тестировщика в команде;
Теория тестирования: Подход, технологии, уровни, процесс, компоненты;
Дефекты: типы и жизненный цикл дефектов;
Типы тестов. Организация тестов;
Тестирование сложных программных решений и комплексных систем;
Requirements, введение в bug tracking systems;
QA процесс: инициализация, цели, приоритеты, сроки, риски;
Usability. I18N/L10N. MLU;
Системы контроля версий: CVS, SVN, GIT, Mercurial;
Обзор методологии SCRUM;
Сертификация ISTQB;
Язык программирования Java. Переменные и типы данных. Логические операторы и операторы ветвления;
Введение в теорию баз данных. Запросы SELECT, INSERT, UPDATE, DELETE. Многотабличные базы данных;
Функции агрегирования и объединения;
Представления, хранимые процедуры, триггеры,пользовательские функции;
Автоматизация тестирования: цели, задачи, этапы, подходы к автоматизированному тестированию;
Введение в Web-технологии, структура HTML, форматирование текста с помощью HTML и CSS. XML, XPath и WebDriver;
Selenium Server. Создание framework для тестирования в Selenium;
Анализ продуктов для автоматизации тестирования, автоматизированное тестирование веб-сервисов и мобильных приложений;

и при этом обещают что я смогу по окончанию курсов:

Использовать инструменты тестирования ПО для мобильных и десктопных приложений, а также веб-проектов;
Применять основы веб-технологий, программирования, системного администрирования, а также поймете принципы работы с базами данных для их использования в автоматизированном тестировании;
Создавать тест-план. Работать с баг-трекерами;
Проводить автоматизированное тестирование с использованием различного программного обеспечения;
Понимать архитектуру и принципы использования Selenium. Создавать скрипты в Selenium для тестирования веб-страниц;
Разбираться в языке структурированных запросов SQL. Уметь создавать многотабличные запросы;
Выбирать оптимальные методы тестирования;
Понимать принципы работы подзапросов и функций агрегирования;
Производить нормализацию баз данных;
Использовать хранимые процедуры, триггеры, виды, пользовательские функции;
Использовать различные системы контроля версий;
Пройти интервью на должность QA-инженера;

www.portnov.com/2018 — пройди это. Это бесплатно. Полно людей после этого курса нашли работу.

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

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

С нуля ты претендуешь на позицию entry-level или trainee или internship — это все для тех, у кого нет вообще опыта.
Когда будет опыт от года и больше (часто указывают 2 года) — это уже позиция junior.

Цифры — это смотря какой город, смотря какая страна.
В Украине не брезгуют даже на минимальную зарплату брать новичков, особенно если город маленький.
Превентивный ответ на вопрос «Почему в небольших городах новичков берут на минимальную зарплату?»: А тебя много кто вообще рвется брать в IT? Нет? Желающие в очередь не становятся за тобой? Много фирм-кандидатов на тебя, как на работника, хотят тебя доучивать? Нет? Вот поэтому.

Если изучить все это — можешь сразу на Синьйора идти .... просто для того что-бы все это выучить надобно года 2-3 учить а не просто ходить на курсы ....

года 2-3 учить

Не учить, а практиковать.

я всё больше и больше наблюдаю компаний в которых нет QA ребят совсем. Программеры:
1.Пилят код
2 Пилят тесты
4. частые деплои через CI/CD, постоянно прогоняя код через сотни и тысячи тестов, используя canary deployment.
5 А если что-то где то отвалилось — g0t0 #1
QA- это медленно и трудо затратно- автоматизации решение большинства проблем, ну и на пример крупных корпорации- пользователи потерпят или если сильно бунтовать будут- пофиксим.

Те що дозволено фейсбуку, не дозволено іншим. Якщо подумати, то єдина причина толерантності користувачів до фб якості, це база даних фб. Коли є монополія в такій ніші як соціальна мережа, то можна сильно не перейматися про відтік аудиторії, бо ж щоб відтік відьувся рішення має прийняти не одна людина, а як мінімум серйозна частка всього її оточення. Що є малоімовірним. Так і виходить, що люди на крючку у цієї корпорації. І якість фіч вже не така критична, коли ти тримаєш все життя людей на своїх серверах.

База даних — потужний тригер зацікавленості, але є ще активно пропагований міф, що начебто Фейса є соцпаспортом в онлайні. Начебто за Фейсою людину можна визначити, розписати та контролити з фулстековим прогнозом поведінки, яка задається алгоритмами мережі. Зруйнувати міф легко, я це прицільно тестила не один рік. Сама по собі соцмережа — дуже потужний інструмент просування, але політикани її віджали до задухи. Для них аудиторія Фейси — тупо електорат з бичачим світоглядом обивателя, що пасивно хаває будь-який силос, доки йому не сунуть попід носа червону ганчірку. Єдиний вихід з лайноти фейсбучого скотного двору — створити віртуальний коворкінг всередині мережі, так само тупо й безжально випилявши усе, що засирає простір міазмами швидкозасвоєного фаст-фуду.

Я ниче хорошего в тренде не вижу.

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

-В реале юнит тесты покрывают оч небольшой процент реальных функциональных кейсов. Девелоперы не умеют\не хотят тестировать, и некому это проверить.

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

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

Ну таке, повно легасі ентерпрайз проектів, де QA-їв вдвічі-втричі більше ніж девелоперів, тому що будь яка функціональність вимагає повного перетестування. А деякі з них навіть не мають юніт тестів, бо дуже легасі, tight coupling, а на переписування нема ані часу, ані грошей.
Ну і змушувати вручну тестувати девелоперів 1 — дорого, 2 — гірша якість тестування.

Я больше всего ору с того что вот причесать код нету денег, а вот двигать кнопку неделями и тестить ее неделями деньги у них есть :-) То ли и правда такие идиоты то ли пилят бабло просто.

Є проекти, які вже перейшли в стадію, коли ніхто вже не розуміє як ця махіна працює і не ризикують змінити щось більше ніж пара класів для свого функціоналу. Тому що тестів немає і цілі підсистеми можуть зламатись, а перевірити це зможуть лише мануальщики :)

что вот причесать код нету денег,
причесать код
причесать

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

Непогана ідея. І бажано вручну без автозаміни. Зайнятість на місяці, профіт очевидний.

QA не уходят и не уйдут — просто эволюционируют их задачи на проекте и требования к ним как к инженерам.
Сейчас QA (в мировом масштабе) это не самый простой способ «войти в айти».
Лет 8 — 10 назад достаточно было прочесть книгу Савина и уметь установить Виндовс — и тебя брали :).
Сейчас продукты стали намного сложнее. Одностраничные и статичные веб сайты со скудным набором функционала давно уже пропали. Все пилят «комбайны». Куча интеграции, CI\CD, эти ваши микросервисы, клауды и иже с ними.
Поэтому и требования к QA уже подтянулись к проектам.
Девелоперы могут и должны писать тесты. Как можно больше автотестов на разных уровнях.
Но, те же QA должны иметь возможность оценить на каком тестовом уровне у нас есть «проседание в кавередже», где потенциально могут быть риски и где нужно потестировать лучше и тщательнее. Это все — требует очень хорошего технического бекграунда у специалиста.

«Як це — бути QA-жінкою в ІТ?»

(sarcasm)все хотят DevQAOps(/sarcasm)

Та как бы сарказм тут лишний

QA як клас зникнуть тільки на тих проектах/продуктах/компаніях на/в яких Девелопери будуть працювати як девелопери я не писарі коду, нажаль це не стосується аутсорсу та малих компаній. Те що так може гугл/фейсбук/слак/спотіфай ще не показник, а лише приклад висококласної роботи. Як ми знаємо Олімпійськими чемпіонами не всі стають і мавпування чужих технік теж не зробить нових чемпіонів. Тому оці ідіотські заяви про відхід і зникнення тестування як класу спеціалістів сприймається із посмішкою та іронією :)

приклад висококласної роботи

Це тому фейсбук такий тормозний і глючний? А ще страшний.

1. Робим копію фейсбуку
2. Проплачуєм конференції де розказуєм що QA не потрібні і деви самі справляться
3. Чекаєм декілька нових білдів
4. ?????????
5. PROFIT

1 Первый пункт уже очень сложен, там много очень фичь
2 Как заставить 2ккк людей зарегистрироваться на новом фб?
3 После выполнения пункт 2, первый пункт может оказаться не выполненным, ну или счет за облако будет такой, что нули не влезут в экран или в сознание.

2. Сказать им что не будете собирать каждую крупицу данных о них

Сколько из тех 2 млрд парятся на эту тему?

Предполагаю что 5%. Или 25% если на злобу дня.

А как же тогда монетизировать? ;-)

Можно показывать им рекламу или продавать лиды на основе прсоональных данных продаванам ;-)

так тут предлагают не собирать данные о падаванах ) я на это отвечал ) а нет данных — нет таргетинга для рекламы )

А как же тогда монетизировать? ;-)

Для начала разберемся в терминологии. Test engineer (ТЕ) — инженер, который проверяет насколько правильно работает продукт. Т.е. констатирует факт: все хорошо или все плохо. QA — quality assurance — сотрудник, задача которого сделать так, чтобы требуемый уровень качества был достигнут. Работа и задачи у них, очевидно, весьма различные. Также как и инструменты. И даже подход к работе — TE реактивен, QA проактивен. Как правило, говоря «QA» в IT подразумевают как раз ТЕ. Все мысли ниже будут именно о TE.

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

ИМХО, где и какие тестировщики полезны:
1. Когда автоматизация сложна и требует иного технологического стэка, чем разработка, а разработчики слишком ленивы, чтобы его осилить. Т.е. это высококлассный автоматизатор.
2. Узкоспециализированный профессионал, например, в тестировании высоконагруженных приложений, тестировании безопасности и т.д. Как правило с хорошим уровнем программирования или хотя бы скриптинга.
3. Когда у тестировщика очень правильный майндсет — способность креативно придумывать сценарии, которые находят ошибки. Это, к сожалению, очень редкий скилл. Такой может быть очень полезен даже если чисто мануальщик. В особенности на этапе тест-анализа.

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

Вывод: при правильной культуре разработки среднестатистический тестировщик не нужен.

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

 — Это тонко показывает что на проекте большие проблемы ..... и не с тестированием

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

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

Вывод: при правильной культуре разработки среднестатистический тестировщик не нужен

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

Даже в компаниях уровня FAANG, когда излишне полагаются на сознательность и ответственность разработчиков, мы видим казусы в виде недавних обновлений Windows 10 и iOS 13. Что уже говорить про отечественный аутсорс, в котором частенько на «галеру» подбирают любого, кто хоть как-то может писать код.

Как правило, говоря „QA” в IT подразумевают как раз ТЕ

Как интересно. Посмотрел первый в списке джоб дескрипшен. Так Ка ли это или по укаринским меркам не совсем КюА?

Lead efforts on improving Developer and Engineering team’s test coverage, release velocity and production health.
Collaborate across teams to on improve to quality and customer experience.
Work closely with Development teams in instrumenting their workflow to build a comprehensive picture of velocity, coverage and quality.
Be able to automate repeated tasks and build test coverage through existing or new infrastructure.
Write moderately complex code/scripts to test systems, implementing test harnesses and infrastructure as necessary.

Вы давно читали описание вакансий QA .... все это там есть (если не джуна ищут) иногда не надо:

Be able to automate repeated tasks and build test coverage through existing or new infrastructure.
Write moderately complex code/scripts to test systems

единственная разница

Френк, а Вы заметили, что все эти вакансии не имеют отношения к IT? Они либо о хардварной электронике либо вообще о механике.

Есть как минимум в Apple и Amazon.
Google — это не весь FAANG.

Есть как минимум в Apple

по ходу таки мінімум, судячи по останнім релізам

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

среднестатистический тестировщик

Это малпа-тестер в простом народе. К тестировщикам он отношения не имеет, кроме названия.

Но таких существенно больше половины. На вскидку процентов 80.

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

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

Танечка рассказывает подружке, как с Вовочкой в кино ходила:
— Нет, Сарочка, ты прикинь, всего-то потратился — 10 коп. на билет и 20 коп. на мороженое! А претензии-то предъявляет:
«Почему сиськи маленькие, почему жопа холодная!»

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

Ну пусть ноют, кому это мешает?

Не взлетит

Ну в смысле не взлетит.. те самые фанги уже лет 15 так рабоают...

в ФБ тестируют юзеры и корпоративные клиенты .... — они могут это себе позволить но это не значит что это Хорошо ))) Яркий пример есть пост типа Канвас (Инстант Ехп по новому) — Его НЕЛЬЗЯ удалить из пейдж менеджера и есть лимит на количество — как только хитнул лимит — усе либо не создаешь либо в результате долгой переписки с ФБ тебе просто повышают эти лимиты ....

Лучьше так или хуже это уже вопрос отдельный. Но если проект размером с ФБ на этом летает то это уже точно не

Не взлетит

Мы тоже на пользователях тестируем (не скажу что)

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

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

Завжди буде сапорт старих проектів.
Юніт тести має писати програміст.
Куа не вимирає.

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

Или просто рассказывают неопытным клиентам про всякие «бест практисис» и что без куа все ломается, и что их нужно минимум по 1 на 2 девелопера. Чем больше народа продали, тем больше профит.

так все CI,CD, во многом, только для тестов и нужны. успешный проход UI automation tests критерий запуска CD. насколько я понимаю, во всех нормальных компаниях пайпланы строят тестеры. их уровень должен был повыситься до написания автотестов и работы с серверами сборок. остальные тестеры видимо сидят в компаниях, которые не могут или не хотят вводить автотесты.

у нас так это и работает)

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

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

угу, я помню как QA тестили лендосы )) которые

условно несложного или некритичного

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

Роль «тестер» неустранима, от того, что ее выполняет кто то «NOT QA» суть не меняется.

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

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

эльфы только в сказках

исполнитель, после которого не нужен QA — слишком дорого для бизнеса )

Отож, понабирают добоеб...просто хороших парней, а потом подтирай за ними жеппы. :-)

жеппы

через «ё» звучит интэресней

Ловите ньюфага, он не подозревает о существовании фразы «жепь ебрило»!

Некоторые компании всех (и QA и девов и синьер и джуниоров) по одной цене клиенту продают. Может по этому клиенты и не хотят QA.

Клиенты и не хотят QA → программисты и фронты сами тестят → затраты времени растут, а цена та же.

Долго был сторонником политики «QA не нужны», но они, заразы, каждый раз доказывают обратное. QA + программист + тесты + continous delivery = success

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

А как Manual QA встраивается в CD pipeline?

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

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

Кнопочки жмут, ага, и нотификации есть.

А инструменты есть какие-то для этого. На чем строится пайплайн? Как интегрируются результаты ручных тестов в нее? Или я не по адресу?

Gitlab, jira, slack. Как это всё построить не влезет в комментарий на доу, если интересно — го в личку

Недостаток лички в том, что для остальных знание будет недоступно. Но я примерно предствил, изменение состояния фичи в jira вызывает какие-то хуки в gitlab. А c TeamCity это можно как-то интегрировать? Я глубоко не копал.

Хм, хорошая мысль, можно статью написать. Приглашаю поучаствовать пруфридером ;)

Буде цікаво прочитати Вашу статтю!

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

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

Таски-вопросы это жесть. Но хорошая новость в том, что не везде так

QA Хоронят уже лет 10 никак не похоронят .... другой вопрос что войти в IT через QA стало очень сложно — проще таки через Дева

Але ж чому стало настільки складніше?

Вариант 1: очень много вайтишников на 1 место даже джунов хотят видеть с годом работы минимум
Вариант 2: очень разные требования в зависимости от проекта которые выдвигаються к QA

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

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

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

На самом деле цель у обоих заработать денег)

робота робиться, гроші капають
профіт

1) Еще ни на одном из проектов нам не удалось покрыть весь фронтенд автоматическими тестами. Бэкенд — да, почти все покрыто юнит и интеграционными тестами. Фронтенд — нет, тестами покрыта только базовая функциональность (Selenium), но эти базовые тесты не ловят очень много вещей, которые легко увидит живой QA в разных браузерах. Вывод: поскольку проекты еще не покрыты автотестами на 100%, живые QA нужны.

2) Почему еще все не покрыли автотестами? Эти проекты не enterprise, а чаще всего стартапы, которым нужно активно релизить фичи. Они еще не настолько зрелые чтобы тратить время и деньги на automation QA на фултайм. От не-фултайм automation QA толку нет, мы пробовали — он пришел, тесты написал, но кто-то ж должен постоянно эти тесты дописывать и поддерживать? Поэтому automation QA если брать, то надолго. Это дорого. Стартапы считают что они лучше +1 девелопера возьмут или не очень дорогого мануального QA.

3) Есть проекты которые говорят «зачем нам QA? пусть девелоперы сами тестят» или «я протестирую сам (говорит заказчик)». Но это до первого серьезного бага на продакшене.

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

2. Вы путаете full-time и постоянный контракт. full-time — это полный рабочий день, а не 3 месяца.

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

Ручной QA или Automation QA?
Ручной — нужен только до тех пор, пока не смогли автоматизировать то что он делает.
Automation QA для меня всегда оставался под вопросом — почему его работу не делает разработчик? Но если уж пытаться обосновать его наличие — то в его задачи должны входить: deployment, bugs reproduction, integration tests (которые должны делаться вместе с разработчиком).

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

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

Зачем для integration tests разработчик

может, чтобы код написать по-человечески?

Automation QA не может написать код? Причем будет независимая реализация без подгонки для прохождения.

ага, он мне и network partition кейс сможет реализовать, и reload компонента, и генератор данных со случайными ошибками, и конечно же шарит в многопоточности, работал с Кафкой и знает приколы JVM.

какой хороший qa, такой qa разработчиком называется.

подгонки для прохождения

это как вы себе представляете? assert(1 == 1)? вы уверены что такое пройдет code review?

это как вы себе представляете? assert(1 == 1)?
вы уверены что такое пройдет code review?

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

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

Ага, уходит.
В разделе «Работа», количество вакансий по направлениям:
QA — 526
Java — 336
PHP — 296
Project Manager — 186
...
Ruby — 68

Небытие говорите? :)

просто платити тільки за знайдені баги і кількість халявщиків піде на спад
www.youtube.com/watch?v=zf0BpWj7fdc

І тоді всі шукатимуть поверхові баги і забють на глибинні. Вийде як з оплатою за кількість рядків програмного коду. Може не треба цьої совкової боротьби з туніядцями?

Ще краще — деви вступають в змову з тестом і додають прості баги які легко виправляти. А отриманий прибуток ділять.

Геніальний план. Прямо як у простого народа ТМ, коли зливають соляру у підприємства, чи продукти тирять.

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

А для чого заставляти девів писати тести якщо можна взяти стороннього AQA за 0.3-0.8 вартості і заодно щоб робив організаційні процеси, трохи BA і трохи манкі тестінг?

Нормальный aqa за 0.3-0.8 вартости ничего тебе писать на будет)
Закладывай 1-1.5 вартости сразу)

Те саме можна сказати і про девелоперів. Нормально — поняття розмите

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

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

Через рік він захоче 1500, а aqa не більше 1200

шот по галєрах не скажеш, повно мануал позицій

а в чем легкость входа через куа?
а по теме, в автоматизаторах смысла не вижу, тк сами же программисты могут авто тесты писать
куа обезьянки будут нужны всегда, тк имитируют реального пользователя, но их много не надо последнее время соотношение от 1 к 3 — 5

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

у них будут тесты которые «всегда работают» :-)))))

норм программист не подгоняет а покрывает
и это тоже относится к написанию кода

Хє-хє, человеческую лень никто не отменял )

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

ну как бы стандартный подход на галерах
сочуствую

Можно покрыть строчки кода и не проверить результат.
А mutation testing мало кто делает.
Много раз на проекте видел assertTrue(true) и assertTrue(false)...

Чтобы программисты писали автотесты, надо чтобы им кто-то тест-кейсы писал :)

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

Плюс в эстимейт тесты никто никада не закладывает.

Да ладно — «никто никогда» :)
У нас в шаблонах для оценок для этого специальные пункты в WBS предусмотрены

тільки на адекватних проектах з фічою має релізитись пачка інтеграційних і фанк-юай тестів
і тому зазвичай в команді де 5 девів 3 кюея.
про такі речі як тест дизайн, регрешн, ревю сценаріїв мовчу зовсім

ну обезьянки кодеры тоже не нужны могут стать:) искусственный интеллект и все такое;)

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

у QA не стоит задача разломать то, что написано кодом. это ошибочное мнение надцати людей)

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

а миф про порог входа:) дает тот самый уровень"спецов" на выходе.

хороший QA легко трансформируется в БА или РМ, причем много качественнее,чем тот же разраб на эти должности. а это уже не миф, а реальная статистика:)

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

Судя по тому ужасу, который творит Microsoft со своей виндой — да, уже или тестировщики не нужны бизнесу, или чёртовы пользователи со своими вечными претензиями.

Если бы только Майкрософт. Атлассиан, Фейсбук пошли дальше в этом деле. Количество багов и ухудшения юзабельности в последние годы говорит само за себя.

Где ужас. Они официально ее сворачивают.

Когда то работала разработчиком и сама тестила свой код, и тогда все так работали и так было «принято», и это был капец и ужас. Т.к. по сути у программиста и тестера совсем разные задачи. Думаю что QA уже не исчезнет.

для UI любого рода QA останутся нужны, потому что сейчас это дешевле.
для бекенда в самом широком смысле — ніт

поясню: для меня код
— не покрытый integration тестами на каждый важный кейс (reload любого из компонентов или недоступность, network failure, некорректные входящие данные, все бизнес-кейсы)
— не написанный на строготипизированном ЯП
— не использующий типизированный формат передачи данных с поддержкой эволюции схем (Avro, gRPC/protobuf) в случае если есть N сервисов
— без экспорта метрик VM и множества кастомных метрик
— без e2e/smoke тестов на реальных данных напротив уменьшенной копии prod env

это не код, а набор букв. и пусть PM выйдет в окно, но в продакшн это не попадет.

есть ли здесь место для QA — это вопрос риторический.

и пусть PM выйдет в окно, но в продакшн это не попадет.

РМ скорее тебя выбросит в окно и наймет кого-нибудь более покладистого.

есть ли здесь место для QA — это вопрос риторический.

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

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

И кто же по вашему хорош то в принятии этих решений? Уж не КюЕй ли?

приходит такой qa-мануальщик ко всем этим сениорам и архитекторам и говорит — тут фиксим, тут не фиксим, а ну быренько кофе допили и компаем отсюда до сюда.

Если мы говорим не о юнит-тестах, не о качестве на уровне процедур и классов, а о высокоуровневых вещах на уровне фич, типа «при таких и таких условиях у нас ломается такая-то фича» — да, кьюэй. Вместе с ПМом.

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

Строго говоря, ПМ (проджект менеджер) не должен принимать такое решение, у него другие компетенции.
Должен — продакт менеджер/продакт оунер. На крайняк бизнес аналитик.
Но в реальности даже на серьезных проектах, приносящих большой доход, бизнес аналитика часто не бывает, как бы это абсурдно не звучало. А продакт менеджер занят/недоступен/слишком high-level человек.
И на некоторых проектах я именно как QA отвечал за беклог, выбор второстепенных фич и фиксов под конкретные релизы. Эти задачи гораздо ближе по специфике к QA чем к девелопменту, который более ориентирован на технические приоритеты, чем на бизнес и пользователей.

ПМ (проджект менеджер) не должен принимать такое решение, у него другие компетенции.
Должен — продакт менеджер/продакт оунер. На крайняк бизнес аналитик.

Какое блин такое решение он принимать должен — не должен?

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

Вы шутитте что ли? Ни БА ни ПО такого решения принять не могут в принципе. Редкий ПМ — может. Они просто в принципе не смогут ответить на вопрос «а что на самом деле вот эта вот красная строчечка означает». У Кю-ей и то шансов на это больше.

Речь идет о решении тратить ли время на фикс (не пятиминутный) упавшего теста или на задачи с business value. И я могу повторить свои слова — это по части продакта или БА. А по факту, иногда QA.

Если вопрос в приоритете чего-то там красного на дашборде — то это точно не к КЮ-А, если о том что этот покрасневший дашборд на самом деле значит — скорее всего тоже не к КЮ-А и даже не к менеждерам. Все ИМХО, в вашей локации может быть по другому

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

:facepalm

Та не вимирають QA зовсім. У нас на кантору за останніх пів-року взяли більше QA, ніж програмістів.
А хитрожопі замовники завжди були.
Ті що хочуть, щоб програміст сам баги тестав і сам їх фіксав.
Це просто бідні, жадібні та хитрожопі замовники створюють міф про вимирання QA.

Саме так. Євреї та інші азіяти — особливо злобні жлобні кастомери. Уникайте таких, бо будете працювати і за себе, і за тестерів.

В итоге платят 2жды — из за плохого продукта ....

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

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

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

и они далеко не всегда от такого в восторге.

Давно в восторге. Вот в этом дело, а в не том нужно тестирование или нет.

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

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

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

Я тут свой айфон боюсь обновлять до иОС13, а ты мне аж про телевизор

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

З монітором сильно дорожче і менше вибір. Якщо говорити про діагональ 40+.

Но матрицы в мониторах обычно сильно качественнее тех, что в телевизорах.

Напевне. Різні ж призначення. Монітор має норм картинку видавати на малій відстані а телевізор на великій. Монітор має бути максимально швидкий, телевізор ні. Як інвестиція то норм я б взяв монітор 40, але якщо чисто як тв то не бачу сенсу переплачувати. От тв без смарт тв щоб зекономити напевно норм. Якщо там щось не урізали ще.

Как показывает практика тестеры проверяют что соответствует требованием на большее 98 процентов не способны либо леньки, а это может и дев в тестах сделать если умеет их писать (98 процентов не умеют)

хороший пост. типа главврач пришел в палату и всем воткнули градусники, даже медсестре))

Никуда он не денется, тестирование это в первую очередь процессы, и вот чтобы это наладить нужен специалист по QA, а будет там мануальное, автоматическое, енд ту енд, или еще какое тестирование это уже от проекта зависит.

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

Выскажу свою точку зрения для обсуждения как вариант. Развитие инструментов программирования. Появление опыта и технологий разработки ПО. Формализация постановки задач и рост компьютерной грамотности как при составлении ТЗ приводят к тому что багов становится все меньше. Многие типы багов исчезли вообще как класс. Все это привело к тому, что даже первые версии с багами оказываются вполне готовыми для показать и отдать пользователю для домучать тему. Написать программу что б она подвисала и гробила систему уже надо потрудиться. В крайнем случае достаточно перегрузить прогу, что нельзя считать критическим багом..

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

Как-то не заметно по продуктам.
Это какие баги исчезли?

Это когда ТЗ стало лучше? Как по мне только хуже.

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

Саме так, я про це і писав кілька разів.
І це журбинка, бо останні релізи iOS (13) і Catalin, це якась журбинка з забагованістю. А, здавалось би — Apple, бабла мало би бути нємєряно на тестерів, але усе одно їх недостатньо.

Що поробиш. Зір у людей невпинно покращується, потрібно додавати більше пікселів.

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

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

Все верно.

Только если этим самым, зашедшим на Early Access, твоя поделка не понравится — тебя вышвырнут с рынка, и придётся немало заплатить за рекламу чтобы туда вернуться.

Половина игрушек — пользователи сами

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

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

Создал новое лого новой компании и вперде.

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

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

Создал новое лого новой компании и вперде.

Ага все побегут играть в ММОРПГ от Вася Пупкин и Ко )

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

Небыло никакого разделения на этапы.

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

прижилось ТДД и парное программирование и QA и юнит тесты и интеграционные тесты

В штатах з 2016, змінив 2 продуктові компанії — працюю в третій на даний момент. В першій команду QA/QC скоротили (американський лід і команда індусів). На другому — з 3х тестувальників на момент коли покидав компанію залишилася лиш одна (українка доречі, місцевих розігнали а вона реально тягнула). На поточному проекті на штат з приблизно 50 інженерів — два QA/QC. Обидвоє можуть як ручне так і автоматизоване тестування — але основна їх цінність а проекті ІМНО — knowledge keepers.

Підсумую — тестування не зникне, але тестувальників стане менше. Принаймні такий тренд спостерігається на даний момент

то то я смотрю какое сильное падения качества програмных продуктов! эвано что — экономят мля ))))

Тестировщики никакого value не приносят, только постят баги, отвлекают девелоперов и мешают деплоить вовремя!

точно поэтому нужно начала уволить всех QA как дармоедов а потом и девелоперов как еще больших дармоедов которые не могут писать код без ошибок и лавочку закрыть )

Смотрел видео от бывшего тест лида в Майкрософт. Он сказал, что с 2016го его и команду сократили. Заменили на метрики. Говорит именно из-за этого винда стала хуже.

Замінили не на метрики а на реальних користувачів (гуглити Early Adoption Program чи щось в тому дусі). Але так — 10ка з того часу знатно просіла як в якості так і в репутації

как только программисты перестанут делать ошибки в коде так сразу QA перестанет существовать — тобишь никогда )

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

ха ха — как только программеры начнут писать код без ошибок — они будут получать всю свою ЗП ) А так я буду их штрафовать за каждый баг и в итоге когда же они будут получать всю свою ЗП ? Правильно — никогда ))) ЛОЛ Я их еще в долги загоню — будут за похлебку кодить и отрабатывать свой говнокод))))

Тогда уже будет лучше нанять искусственный интеллект, чтобы кодил. :)

Ну ты это, старайся. В идеале если их ещё и бить будут. Мне не жалко, программеры не мои. И не факт что вообще программеры, за похлёбку вы разве только выпускников ШАГа наберёте.

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

QA нужны на серьезных проектах, qc хоть manual хоть automated не особо нужны. В Украине почти никто не знает что такое qa

В Украине почти никто не знает что такое qa

 А что по вашему мнению QA?

Для начала это то кто умеет в гугл

QA слово-паразит, на всіх тестерів кажуть QA, хоча вони можуть бути QC(manual)

Внезапно, «A» в аббревиатуре QA — это совсем не про automation. Собственно, ещё более внезапно: QA — это далеко не только про тестирование. QA — это про обеспечение ожидаемого уровня качества на выходе, а тестирование — всего лишь один из инструментов (причем, скорее, измерительных).

Кому интересно — посмотрите, хотя бы, про модель Cost of Quality и что туда входит.

QA — это про обеспечение ожидаемого уровня качества на выходе

Скоріше про замірювання якості.

4. Попытка убрать QA совсем с индустрии?

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

на что я ответил что возможно это не самая лучшая идея, лучше сразу девелопером.

вполне возможно

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

Чет у вас программисты говнище какое-то получается

Ага, я к примеру. Или QA очень хорошие, так сразу не скажешь. Ещё как вариант — Вам не попадались пока хорошие QA

Как правило, наоборот. Продукт получается НЕкачественный. Но об этом знает потребитель — потому что только он может оценить качество. А что оценивает QA — науке это неизвестно.

QA делают постоянную напряженность, не дают программистам расслабиться

Как бутират

КМК пользователь субъективно оценивает удобство для себя, QA проверяет соответствие продукта требованиям.

Ещё бы соответствие требований между собой кто проверил :)

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

QA это паразитирующая прослойка для раздувания штата не более.

Паразитирующие прослойки:
— QA это, когда прогер не хочет писать тесты и проверять свой код.
— Скрам мастер — когда в команде настолько плохо с мотивацией, что нужно нанимать шута.
— HR — когда нечем заманить кроме систой глупышки. Если есть норм рекрутер и тимлиды умеют общаться то HR не нужен.
— Евангелисты — то же что скрам мастер, только круче звучит.
— UI\UX — когда нет нормального аналитика и не налажена работа сплит тестов и дизайнер не понимает что он делает и зачем.

Developer это паразитирующая прослойка для раздувания штата не более.

Оставшиеся прослойки:
— developer — когда клиенту лениво считать результат вычисления программы на счётах/вести бизнес в тетради
— бухгалтерия — когда лень самому залезть в погонщеский сейф и взять свою зарплату
— уборщицы — все в офисе взаимозаменяемые, и сами могут подмести/вымыть полы
— продукт оунер — в вмысле? Мы же будем контрагентов вести в тетрадке
— маркетинг и продажники — мы настолько ох*ительны, что клиенты нам сами должны звонить, и кидать нам в лицо деньги
— охрана у входа галеры — скажи, ну ты вот в зал ходишь? Значит сможешь вышибать непрошенных гостей
— админы/девопс — мы работаем в тетрадке и на счетах, запомни уже! Не.нужны.

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

Разогнать — ага, щас. Удвоить кнута, галера пойдёт быстрее

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

Для начала, QA — это не тестировщик. Тестировщик — это QC.

QC — это тоже не тестировщик)

Automation QA нужны очень даже(опять же, можно судить по кол-ву вакансий и по зарплатной вилке)
А то заставлять чисто девов и код ху*чить, и тесты к нему писать, и доку на него писать это чет такое себе удовольствие

Потому что писать надо на английском, а уровень-то фейсом об тэйбл

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

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

Стремительно? Попробуй купить билет в Венскую оперу или в Берлинскую филармонию.

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

Это как с музеем Эрмитажем, да там очередь, потому что он один

2 недели назад был таки в Эрмитаже. Сообщаю — он там не один, там целая батарея музеев в округе и одних Эрмитажей 3.

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

А с распространением телевидения и кинематограф уйдет в небытие ©третий провидец.

Как кинематограф может уйти в небытие если по ТВ крутят кино о_О

Посмотрите на зарплаты — QA сейчас зарабатывает от $1000 — на уровне Джуниора!! Имхо, если растут зарплаты, значит спрос на QA только растет!

Джуну QA дают с порога тыс уе ?

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

III квартиль
$800
Junior QA согласно статистике dou

Ну типо это как бы энивей не 1к
И это 3 квартиль
Медиана имхо более показательна)

Джуниор QA — это 12-18 месяцев опыта, требования как к миддлу 5 лет назад и английский. И даже при таких раскладах 1к это выше среднего.

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

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

О каком QA речь? Если не мануал, он же по любому будет кодить. Считай будет «сразу девом». Но в мире микросервисов сомневаюсь, что это самый легкий путь :)

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

Особняком только девопсы держатся

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

Це біль. І напевно їм просто забити на якість, глибину знань. Хочуть і дешево і добре. Типовий мас маркет. Напевно вихід в мімікруванні під усе це, або пошук адекватної роботи з розділенням обовязків.

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

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

любой front-end разработчик может верстать по ходу дела.

Да хрен там все они умеют верстать, там такой кошмар порой получается, что страшно смотреть. Они приходят в отрасль — основы html+css схватили и сразу погнали на модно-стильно типа React и иже с ними.

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

jobs.dou.ua/...​ategory=QA&category2=Java

jobs.dou.ua/...​egory=QA&category2=Python

jobs.dou.ua/...​category2=Project Manager

После этих графиков тему можно закрывать

Отсюда нужно вычеркнуть тех, кто пишет код

прикольно отзывы на вакансии QA около 10, в США например сотни откликов на вакансию , лафа — рынок соискателей )

Даже для опыта меньше года не очень много откликов:
jobs.dou.ua/...​ends/?category=QA&exp=0-1

Странно что они вообще есть, учитывая что большинство вакансий в Украине — тупо спам, вообще не имеющий никакого отношения к реальности.

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

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

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

это только подтверждает, что открытые ворота для QA — самые широкие из вайтивайти

dou просто не показывает статистику по домена тестировщиков. А специализаций на самом деле много:
— web
— web + mobile
— embedded
— banking
— performance
— security
— automation по разным типам доменов

Верно. Разве что банкинг я бы не выделял — это уже к бизнес доменам. Не накладывает столь сильного ограничения.

Ты еще забыл про стеки автоматизаторов. Python/Java/Ruby/JavaScript + по паре фреймворков на каждый язык. Ну или как минимум разделить на web и mobile, там прям сильно разный подход к организации.

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