Comments 34
Был на работе митинг в начале этой недели.
Если что компания международная, не то чтоб прям большая, но и не совсем крохотный стартап уже, деньги есть.
И главное - занимаемся healthcare, так что и сертификации, и аудиты и разумеется разнообразное тестировение более чем положено.
И да, QA у нас нет. Планы тестирования есть, юнит-тесты есть, визуальную регрессию сейчас добавляем, e2e добавляем.
Но делаем это сами, ну и ручное тестирование тоже на инженерах, дизайнерах и немножко на менеджменте.
Ну и поднимаю я вопрос. А не завести ли нам товарищи QA? Хотя бы одного QA инженера, это же full time job. Пусть он (она) и сценарии пишет, и вручную всё мучает. И у нас время освободится.
И тут начинают выступать по очереди все. Включая CEO. И все говорят, ну в теории да, а в реальности чего-то не хочется. И все, ВСЕ, рассказывают ОДНУ И ТУ ЖЕ ИСТОРИЮ.
Все же с опытом, работали не в одной и чаще всего не в двух компаниях. В разных странах мира. У всех был отдел QA. И у всех он состоял (тут я просто цитирую) из абсолютно бестолковых идиотов. Которые не то что не помогали рабочему процессу. Они наоборот, мешали ему как могли. Задерживали тестирование и блокировали PR, фичи и релизы. Придирались к совершенным мелочам или абсолютно корректному поведению, но при этом пропускали жирнейшие баги. Никогда не опускались до таких мелочей как понимание того, как работает код, что нативные API нельзя заставить работать по-другому, даже если им очень хочется. Ну а уж писать собственно тесты - да вы что, снизойти до кода. Это пусть инженеры делают.
Ну собственно и результат, в последние годы процентах в 80 западных компаний старого доброго QA в классическом понимании уже просто нет. DevQA - и достаточно.
И никто потери особо не заметил.
Субъективно. У меня, например, совсем другой опыт: почти все QA были профессионалами своего дела.
Конечно субъективно. Но уж слишком статически значимо.
Ну и у нас, походу, QA в ближайшей перспективе так и не будет. Тоже.
А жаль, у меня тоже был опыт работы с совершенно отличной командой из Лейпцига (правда ещё в некоторых компаниях был и крайне отрицательный опыт, ну да ладно). Надеялся кого-нибудь из них переманить.
Сам QA и помойку в QA среде наблюдаю лет 6. Ни код подучить, ни копнуть в андроид поглубже, чтоб активити стартануть из терминала, ни что-то еще. Вкатунов много, кто думает, что QA это не про инжиниринг, а как на завод сходить, что в 9 к станку, в 18 от станка. И фирменное "я это не должен знать". Заманался от таких коллег и уже 7-ю компанию меняю. Теперь понятно, откуда ненависть к тестировщикам. Вот из-за такого смузи, где тестер ждет, что ему 5 человек будут бегать приносить персонально задачи. Самое досадное, что к тем, кто вроде рубит, такое же отношение уже по инерции. И вроде ты проявил себя, локализовав багло и даже найдя косяк в коде, глянув в исходники, а вроде тебя все равно за недочеловека держат и не поддерживают
Вы уж простите, но за державу обидно как-то. Я конечно свечку не держал, уже давно как "единственный тестировщик в команде", но неужели действительно такое везде и всюду?
я че, зря чтоли лезу в код, пытаюсь найти где ошибка в коде (когда время и нервы есть разумеется, не всегда, каюсь. а иногда моей компетенции банально не хватает), мучаюсь над новым для себя (уже не таким новым, но все таки да) докером и liquibase, пытаясь собрать вменяемый докер который развернет все данные на тестовом стенде (по аналогии с имеющимся докерами собирал)?
неужели в 2к26 все еще остались ребята, которые "о, чето не получилось, заведу багу" остались? обидно блин
И фирменное "я это не должен знать". Заманался от таких коллег и уже 7-ю компанию меняю
Похоже, дело не в коллегах. Должны знать то, что в должностных обязанностях. Если у тестировщика в них не указаны глубокие познания андроида, то это не его проблема. HR'у (будем считать что работодателю) он подошел.
Какой хороший наброс.
Жаль, что наброс.
ручное тестирование тоже на инженерах, дизайнерах и немножко на менеджменте
разрабы выкатили фичу, а потом остальные смотрят на ТЗ и идут перепроверять?
Главная цель тестирования не поиск багов, а проверка продукта на соответствие требованиям.
Если ваша фича работает не так, как прописано в тз, то проблема либо в вас, либо в тз, но точно не в тестировщике.
Смешные... Как будто никто из них не работал с говнокодерами, которые не удосуживались ни смоук тест своей фичи сделать перед выпуском, ни хоть немного понять бизнес-логику приложения, ни проанализировать место собственной фичи в архитектуре системы.
Плохих, некомпетентных работников везде хватает, хоть в QA, хоть в ВА, хоть в РМ, хоть в разработке. Как и отличных специалистов, профессионалов своего дела.
Ну да, конечно смешные. У каждого лет по 15 опыта, а у некоторых (как у меня) и по 30 с лишним.
И то что все они уж точно видели разное (по всему миру, кстати, у всех опыт жизни и работы в разных странах и разных секторах), но вот абсолютное большинство из них никогда не видело адекватного QA разумеется ни коим образом их, наивных, не извиняет. Я ж вот видел, как я уже упоминал. Целый один раз.
Но статистика штука такая. Упорная. Способствует появлению предубеждений.
.
бестолковых идиотов
Каких они нанимали, такие и были.
Ну нанимали в большинстве случаев не они сами. Нанимало руководство (и нанимало тех кого обычно и нанимают).
Единственное исключение походу это CEO - там была его предыдущая компания и он тоже нанял тех кого обычно нанимают, и хоть дело было уже много лет назад, его до сих пор трясёт. На следующей неделе встречаемся лично - распрошу его за рюмочкой про эту историю. Самому интересно.
А "тех кого обычно нанимают" - это кого? Потому что для кого-то "обычно" это только нажимать на кнопочки, а для кого-то это грамотные инженеры, разбирающиеся в своей области.
Ну и процессы все-таки выстраивают не рядовые qa. Поэтому ситуация когда "задерживали релиз" и "пропускали жирнейшие баги", это может быть про "релиз выкатили в четверг вечером, катимся в пятницу, надо все проверить". "Придирались к мелочам" - здесь опять таки дело в процессах, выпускать с минорными багами или нет решат менеджеры/лиды разработки а не тестеры. К " абсолютно корректному поведению " - проблема может быть в кривых требованиях или отсутствии нормальной коммуникации в команде.
"а для кого-то это грамотные инженеры, разбирающиеся в своей области" - как чисто статистически можно заметить, подобный опыт был только у меня. Да и то вероятно случайно получилось - изначально очень толковый девопс привёл очень толкового qa-инженера (со знанием медицинской специфики, что было крайне важно), а тот уже набрал себе грамотную команду.
Ну а так мы все знаем кто обычно в QA идёт. А когда люди не-технические набирают команду, они и набирают кого было. С соответствующим результатом.
В любом случае - задача у QA абсолютно та же самая что и у всех остальных команд. И у разработчиков, и у дизайнеров, и у девопсов и у менеджеров. Где надо помогать и делать свою работу, а где не надо - не мешать. И, к сожалению, очень часть по обоим пунктам QA на первом месте по невыполнению обоих этих пунктов. Опережая даже менеджмент (это очень трудно, но они стараются).
Вся эта культура отказа от QA и перехода на dev-QA - она не на ровном месте возникла.
А почему не-технические люди набирают QA? Могу понять если это в стартапах на ранних стадиях, но в каком-то развитом продукте это мне кажется довольно странным.
Ну хотя бы потому что "технические люди" вообще редко кого где набирают, и, будем честны, в большинстве случаев это правильно. Посадите программиста одного набирать других программистов - и он в лучшем случае будет проверять какую-нибудь хрень типа "обхода бинарного дерева" (тм), которую он сам последний раз лет 10 писал, да и то непонятно зачем. А в худшем будет выяснять, соответствуют ли взгляды нового потенциального коллеги на его любимые фреймворки и библиотеки его собственным взглядам. И не дай бог не соответствуют.
Опять же посади программиста QA нанимать - кого он наймёт?
Так что да, как везде и всегда. Нанимает менеджмент исходя из своих соображений.
Ну и если уж про "развитые продукты" и особенно про большие компании, и особенно про копорации, то там вообще чаще всего непонятно откуда взялись все эти люди которые с тобой сейчас работают. И учитывая что как правило для того чтобы тебя из корпорации уволили надо приложить просто титанические усилия (просто ничего не делать годами тут недостаточно), а толковых специалистов понемногу переманивают, те люди кто там остаются очень часто представляют из себя квинтессенцию всех законов питера и мерфи вместе взятых. Стартапы в этом плане всё-таки поадекватнее будут.
Ну хотя бы потому что "технические люди" вообще редко кого где набирают, и, будем честны, в большинстве случаев это правильно.
Ну так в норме нанимают лиды, имеющие и технические и менеджерские навыки. Если менеджеры без технических собесов будут нанимать инженеров, то понятно что большинство будут "кто попало" и та же проблема будет у всех других ролей, и dev и devops, а не только с QA.
То есть проблема в таком случае больше в нанимающем менеджменте, а не инженерах.
В корпорациях обычно идет бюрократизация и разложение из-за этого, и там состав команды и процессы могут сильно зависеть от конкретного проекта. Но если компания еще не слишком раздутая и не слишком попала под влияние эффективных менеджеров, то там может быть нормальная инженерная культура и много грамотных специалистов.
В теории всё так.
На практике - практически во всех компаниях QA - больное место. Вероятнее всего, конечно, из-за того, что требования к специалистам в этом секторе очень долго были крайне низкими. И в результате мы имеем то, что даже среди QA-инженеров с длинным резюме найти хороших крайне трудно (и очень часто их никто и не ищет, да).
Ну и да, нанимать должны и не лиды (это часто приводит к ещё большей деформации). Оптимальный найм - это коллективное решение, где должно учитываться очень много факторов и разных мнений.
Вполне верю, что во многих компаниях так как вы сказали, но не думаю что это повсеместно. Хотя конечно, ситуацию когда в одном месте сидят неграмотные, а в другом инженеры с опытом не могут по долгу найти работу, тоже вполне представляю.
Оптимальный найм это вообще большая редкость в наши дни. Даже просто адекватный найм - довольно редок.
Бонус активного общения с нейросетями по работе - сразу видишь узнаваемый и привычный стиль во многих статьях на Хабре, как эта.
Работаю в qa 9 лет, из них 8 в бигтехе. Последние годы тенденция к повышению “time-to-market” ведет к осознанному пренебрежению качеством. В куа из инженеров делают менджеров пишущих бесконечные кейсы по требованиям меняющимся каждые от нескольких часов до нескольких дней (и хорошо если половина изменений доходит до тестеров). Часть регрессов существует для галочки, а на часть красных тестов вешается формулировки о нестабильном окружении. Потому что нельзя задерживать релиз. «Бизнес не может ждать» сказал техдир плачущему лиду саппорта после просьбы не катить большой релиз во второй половине пятницы. У высшего руководства нет никакой ответственности за что либо. В моей конторе у одного проекта в продакшене висело более тысячи багов, и информирование через приоритет от внутренних сотрудников они преподнесли как очередную реформу и достижение. Вероятно кто-то даже за это премию получил. Бэкэенд перестали тестировать и переложили все на разработчиков. Откуда баги? Да в целом всем наплевать. Пользователям всегда можно просто сказать «нам очень жаль что так получилось, извините».
Честно говоря, я тоже замечаю эти изменения. Ручное тестирование никуда не делось, но требования к QA действительно выросли. Сейчас уже мало просто находить баги, важно понимать, как работает система, уметь автоматизировать и быть частью разработки. На мой взгляд, это скорее развитие профессии, чем её исчезновение. Кто готов учиться и адаптироваться без работы точно не останется.
Тоже того же мнения, что лучше тестировщику воспринимать изменения, связанные с ИИ как рост. Ну и сейчас всё чаще ищут qa с навыками автоматизации, чисто мануал вакансий стало заметно меньше, чем несколько лет назад
В QA 20 лет. И я хочу сказать, что если QA не может разговаривать на языке девелопера с девелопером и на языке менеджера с менеджером - такой Qa будет создавать только проблемы.
Ещё Qa это не только тестировщик. Это тот человек, который получив задачу должен досконально разобраться в ней, даже если спеки 0, получить все вводные от менеджера, донести это все до девелопера, а потом проверить и довести до прода.
К сожалению, очень много людей в этой сфере дискредитируют хороших специалистов
Итак, что из этой статьи понятно : за 6 лет автор так и не понял разницу между Контролем качества (qc) и Обеспечением качества (qa). Автор до сих пор считает что тестирование и есть QA, в чем его и главная ошибка, которая делает полностью бессмысленной данную статью. Тестирование, как и иные способы qc, конечно являются частью QA, но QA естественно строится на других целях, о чем написало много хабровчан. Инженеры QA - это вообще специалисты намного шире, чем просто тестировщики, так как их границы это не " что хотели то и получили", а " что получили - то и хотят клиенты в приделах разумного". Качество определяется потребительской оценкой. Всегда можно сдедать хорошо протестированный, но полностью некачественный продукт, и примеров тому очень много. В РФ к сожалению это принцип бигтеха: делаем чтоб работало, а потребители пусть гемороятся, танцуют с бубнами и тп. Пусть создатели чтобы выпустить багфикс - прохожят полный релизный цикл на 3 месяца дабы исправить пару опечаток в формах. И т.д. т т.п.
Проблема автора как ни странно решается достаточно быстро и не сложно с помощью 2 лекций, в которых рассказывается разница между qc и qa, рассказываются медоды qa, рассказываются примерная оценка ROI внедрения и результатов в краткосрочной и долгосрочной перспективе, путь сверху вниз на внедрение, и горячее желание на изменение.
А что касается классичечкого страха " сейчас от ручников откажутся " - это уже 25 лет витает в воздухе, а воз и ныне там. С точки зрения денег и qa, автоматизация все и вся не имеет смысла, как и тестирование постоянное всего и вся в целом. Как раз и задача QA - это оптимизация всех процессов в угоду качества продукта, а оптимальным в этом случае будет ручная проверка мелких фич при внедрении, автоматизация основных бизнес-процессов и игнорирование редко-изменяющегося и невостребонного функционала. Ну и конечно же работа с клиентами : робот или даже ИИ не может понять боль или идеи человека, и донести его боль создателям в нужном виде
Что с QA в 2026? Профессия умирает? Или все преувеличивают?