В моём идеальном мире, QC - это процесс, которые обеспечивает ВСЯ команда для продукта. QA - это часть этого процесса, которую обеспечивает именно отдел тестирования.

В моём идеальном мире, QC - это процесс, которые обеспечивает ВСЯ команда для продукта. QA - это часть этого процесса, которую обеспечивает именно отдел тестирования.

Это как DevOps - не человек, а набор практик.

Это как DevOps - не человек, а набор практик.

вооооооот

Но есть DevOps инженер, который занимается поддержкой и внедрением этих практик.

Я про то же и говорю. Что QA и QC - это процессы.

QC это если ты пишешь условные e2e тесты и проверяешь, что продукт пригоден к использованию и соответствует формальным требованиям. QA – ты выстраиваешь процесс обеспечения качества, чтобы продуктом было пользоваться не больно

во всяком случае, в меру моего понимания

Но есть DevOps инженер, который занимается поддержкой и внедрением этих практик.

формально, девопсом может быть любой человек на проекте.

QC это если ты пишешь условные e2e тесты и проверяешь, что продукт пригоден к использованию и соответствует формальным требованиям. QA – ты выстраиваешь процесс обеспечения качества, чтобы продуктом было пользоваться не больно

Ну, вот первое - это миддл тестер.

Второе - вобще непонятно.

А где тут заказчик?

Блин, опять не тот чат.

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

Ну, вот первое - это миддл тестер.

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

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

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

формально, девопсом может быть любой человек на проекте.

И тестировать

есть тестеры с доступом к коду?

да

И код писать.

Чем отличается Сеньор КуА от Сеньор Тестера?

вроде этот, нет?

Ещё раньше.

ох, я не на тот вопрос триггернулся видимо :)

Качество обеспечивает не тестировщик, а команда.

ты про это?

ты про это?

ага

Там и ещё раньше было )

ну так я про то же пишу – не везде есть понятие команды)

Но это тоже пойдёт.

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

тебе не придется читать юнит-тесты, если у тебя нет доступа к коду

и вот это все

но при этом люди в этих процессах и сеньоры и лиды и фараоны тестирования :D

То есть, тестировщик - это QA без возможности влиять на процесс?

Я так понял?

в моем понимании – да

но понимание у всех свое

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

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

то я уже не QA?

тогда ты не можешь быть QA, потому что процесс поставить не можешь – он от тебя не зависит

ты можешь поставить часть процесса

по верификации конечного состояния продукта

А QC - что тогда?

вот по мне это и есть QC

Стоп.

в моей картине мира нет тестировщика как отдельной сущности

есть QC и QA

есть тестеры с доступом к коду?

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

есть тестеры с доступом к коду?

есть конечно, как еще работать-то?)

тестишь продукт, ищешь баги, девелоперы фиксят

QA - это если я и в код могу лезть и попросить программиста по другому писать код и выстроить процесс для всей компании? QC - это когда выстраивается процесс только внутри отдела тестирования. Доступа к коду нет. Возможности изменить процесс в компании нет. А синиор тестеры, миддл тестеры - это просто манки кликинг?

есть конечно, как еще работать-то?)

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

QA - это если я и в код могу лезть и попросить программиста по другому писать код и выстроить процесс для всей компании? QC - это когда выстраивается процесс только внутри отдела тестирования. Доступа к коду нет. Возможности изменить процесс в компании нет. А синиор тестеры, миддл тестеры - это просто манки кликинг?

ты пытаешь замапить процесс на грейды

мне кажется, что это 2 разных сущности,как соленое и квадратное

но это имхо

jrtq/

Jrtq/

Окей.

условно сеньор, миддл, джуниор – это степень владения компетенциями

а QA и QC это чуть разные компетенции

Тогда вопрос. Почему тогда ищут QA и QC в вакансиях?

Это же процесы, а не должности?

HR не знают разницы

Вопрос не к тебе, а в воздух, скорее.

ищут QA/QC инженеров как правило

но на самом деле ищут тестировщиков.

то есть инженера, который процесс поставит

ERROR: S client not available

да, потому что разницы не понимают, и она особо не важна

как говорил один товарищ - обозначение вида QA Tester означает то, что там не совсем разобрались что к чему.

они хотят чувака, который будет тестировать

и их можно понять

ага, а потом и возникают кривотолки, что тестировщик должен ОБЕСПЕЧИВАТЬ качество продукта.

обеспечивать качество 1 человек не может

ну, я об этом уже писал выше.

это из серии "давайте введем KPI на нелинейные процессы"

ага, а потом и возникают кривотолки, что тестировщик должен ОБЕСПЕЧИВАТЬ качество продукта.

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

И даже отдел из 10 тестеров, хоть из 100 не может.

если такое есть – надо бежать

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

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

может, под обеспечением качества подразумевается в некоторых компаниях "найти ВСЕ баги, а если не найдёт - он и виноват" :)

все так :)

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

Hah! Когда тебя начинают драть за то, что ты делать не должен - это становится резко важным.

может, под обеспечением качества подразумевается в некоторых компаниях "найти ВСЕ баги, а если не найдёт - он и виноват" :)

В точку!

Hah! Когда тебя начинают драть за то, что ты делать не должен - это становится резко важным.

формально есть должностная инструкция

просто есть куча тупых носорогов

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

которые не понимают, что за баги отвечают все – менеджеры, аналитики, девелоперы, тестировщики

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

которые не понимают, что за баги отвечают все – менеджеры, аналитики, девелоперы, тестировщики

Верно. И установить терминологию в данной ситуации == прикрыть задницу/ограничить круг ответственности

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

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

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

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

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

вполне нормально.

Поэтому когда ищут "Junior QA без опыта работы" у меня пердак раскаляется и паркуется где-то в районе орбиты Юпитера.

а потом ко мне на собес приходит QA Lead с опытом в полтора года

потому что по крутой внутренней системе грейдов он был целый лид

и тестировал веб, но не знает ни одного http кода ответа

а потом ко мне на собес приходит QA Lead с опытом в полтора года

приходили такие, да.