Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 24
Был на работе митинг в начале этой недели.
Если что компания международная, не то чтоб прям большая, но и не совсем крохотный стартап уже, деньги есть.
И главное - занимаемся 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 разумеется ни коим образом их, наивных, не извиняет. Я ж вот видел, как я уже упоминал. Целый один раз.
Но статистика штука такая. Упорная. Способствует появлению предубеждений.
.
Бонус активного общения с нейросетями по работе - сразу видишь узнаваемый и привычный стиль во многих статьях на Хабре, как эта.
Работаю в 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? Профессия умирает? Или все преувеличивают?