×Закрыть

Кого обсуждают? QA или QC?

Вот, недавно стал читателем данного форума и немного не понял тенденций развития современного тестирования... Согласно книге г-на Канера QA — это не тестировщик в его общественном понимании. Т.е. QA — это не тестер software, а больше надсмотрщик за соблюдением стандартов и процесса самой разработки, а также его оптимизации. Вопрос: почему же даже уже работающие тестеры воспринимают термин QA в качестве спеца, который ищет баги (software test engineer). Естественно, что в маленьких компаниях эта должность может совмещаться, но судя из комментов восприятие совсем другое. Почему?

👍НравитсяПонравилось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

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

Поэтому употреблять терминологию очень просто — для всех вообще мы QA, потому что это понятно, или test engineer / tester, но это реже, так как QA короче и понятнее. Всякие QC, QD и QE только путают, особенно QC, который еще HP Quality Center.
На доу нужно писать tester, чтобы доставить одному менеджеру по доставке единицы :) .

QC — только часть QA.
Применяют QA потому что привыкли, часто на самом деле ищут сугубо QC-инженеров.
Кстати, не все, SOftServe например честно пишет QC в вакансиях!

есть мнение (не мое), что QC никак не связано с QA )

Да, есть много разных мнений касательно очень большого количества вещей, только реальность не меняется ни от их количества, ни от содержания ;)

вот не поспоришь с Вами ), хорошо сказано

лично я, так для себя определяю эти понятия:

“QA and testing are similar because:

— Their common mission is to improve software

QA and testing are different because:

— QA improves software through process improvement

— Testing improves software through bug reduction

Although our Course is focused on testing, we’ll also look at many issues from the QA angle.

Why is process improvement so important? Because software development IS a process (more precisely: a set of processes), and thus software quality has its roots in two things:

1. How quality-oriented our software development process is

2. The mentality and actions of each participant in the software development process*

* The software development process is also called the software development life cycle — we’ll spend a lot of time talking about this.

This brings us to the important idea that testers and QA engineers alone cannot be responsible for software quality. You can be held responsible only for things that you FULLY control.

For example, if a spec has a bug, that bug can be incorporated into the test cases and the software code as a legitimate thing.

But what is so special about testers and QA engineers, then? Our mission is to be passionate advocates of constant quality improvement in any shape and form. While we cannot be in full control of software quality, it’s in our hands to go above and beyond promoting quality as a vital philosophy within a software company.” R. Savin (qatutor.com)

все непросто — реально эти два понятия смешаны, без testing невозможно QA, а современный testing по сути выполняет функции QA. Чтобы убедится можно посмотреть цели тестирования тут
www.istqb.org/...nish/16/15.html

Странно. Но все онлйн ресурсы в т.ч. и портнов говорят, что процесч тестирония никак не относится к qa

это вряд ли, приведите конкретный пример

простая логика подскажет что гарантия качества ( QA ) невозможна без контроля качества

Даже больше — совсем наоборот — у Портнова к примеру эти понятия идут в комплексе как и должно быть.

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

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

Теперь начинаю понимать Вашу точку зрения понемногу. Чтобы качес веннее тестировать, нужно улучшить сам процесс разработки или ттого же тестирония. Верно? Другими словамиответ на вопрос топика будет: современный тестер обьединяет в себе эти 2 понятия и тестероы называют себя qa engineer только из-за большей созвучности должности. Поправьте, если куда-то ушел в сторону.

в целом да — SQA Engineer занимается обеспечением качества программного продукта и для этого есть техники и валидации (QC) и верификации (QA) и это все нужно использовать в комплексе чтобы обеспечить качество продукта.

Позволю себе не согласится :)
Quality Assurance в чистом виде не предполагает вообще никакого тестирования !
Тоесть Вы не будете руками ничего проверять, запускать какие то программы, прогонять какие то тесты, билдить какие то фреймворки, в общем ничего из того что присуще и назначено для Software Testing Engineer, который в свою очередь уже отвечает за всю эту скажем так «грязную работу» !

В наш век смешивания обязанностей нет ничего удивительного что такого разделения в чистом виде почти не осталось, почти потому что на Западе еще остались QA в том виде в каком они изначально задумывались. Но у нас ввиду того что компания не будет тратить средства и время на двух людей QA и Test Engineer, чтобы выполнять несколько схожие функции, когда «у нас есть Галя» :) Это же очевидно!

Надеюсь Я понятно изложил мысль.

Хм. Вы меня вернули к началу, когда я только задалвопрос. Так, почему же тогда тестеры называют себя qa? Потому, что это лучше звучит, чем qc или тестер или же они не знают принципиальной разницы между ними?

Сергей, все зависит от ситуации или конкретного человека — Я думаю не стоит сильно заморачиваться по поводу тайтла!

Тут несколько вариантов на самом деле:
1 — люди не понимают разницы и называют себя одним названием вместо другого
2 — люди понимают разницу и называют себя одним названием вместо другого потому что это отвечает их обязанностям на данный момент
3 — люди понимают разницу и называют себя одним названием вместо другого потому что им так проще или им все равно или не принципиально, даже если они напрямую и не делают что то из того что должны
4 — люди никогда не слышали и не читали ничего о разных обязанностях и называют себя согласно той позиции в компании на которую их наняли — это уже проблема компании
5 — в наше время идет активное миксование обязанностей, или если хотите это рынок диктует какие то свои условия при которых люди начинают делать какие то специфичные задачи порой даже и не свойственные именно этой профессии, отсюда и появляется куда других новых тайтлов, например: Account Manager, Resource Manager, Content Manager, QA Analyst (тоже кстати интересный тайтл) — кто он Аналитик или QA?! И как тогда правильно называть: QA or BA ?

В общем как то так.

пы.сы. если не перечислил все новые тренды позиций то просто от нехватки времени :) Я думаю вы сможете добавить что то также в этот список.

Ok. Можно удалить все посты и оставить данный ответ т.к. он отвечает на все. Пусть каждый уже сам выбирает подходящий вариант

Главное понимать разницу и уметь ее объяснить.
Все остальное вторично.

SQA — есть подвид QA в сфере ПО и он включает тестирование как обязательный ключевой компонент, я у же говорил что без тестирования QA — чистая абстракция, мы же я думаю говорим о прикладных вещах, а на практике не существует способа выполнить цели QA БЕЗ тестирования.

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

Но в целом все верно.

я кажется понял в чем проблема) — Вы просто неправильно перевели термин QA — это не страховка качества, а гарантия качества или обеспечение качества.

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

да там просто два значения у слова Assurance

QA это не гарантия качества, а способы его обеспечения. 100% гарантию даже бог не даёт :)

да Бог дает 100% гарантию, он же Бог, а тестировщик дает только оценку рисков при тестировании

Совершенно верно говорят. QC не есть часть QA ни в каком виде.

QA и QC идут всегда в комплексе, по крайней мера это точно для SQA

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

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

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

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

здесь на мой взгляд неплохо объяснили — qawebmart.ru/...stirovanie-matreshka.html . Вообще смутно представляю, как можно разделять эти понятия.

Тема на самом деле стара как мир — Quality Assurance или Test Engineer ?!
Фактически в чистом виде Тест Инженеров уже не осталось НУ может быть на начальной стадии вхождения в эту профессию, чуть позже все так или иначе соприкасаются с процессом улучшения качества в целом, что также отражается на изменении должностных обязанностях и приближает онного к QA.

Фактически ситуация еще глубже чем Вы затронули — существуют даже три понятия:
— QA
— QA
— Software Testing
Быстрая ссылка на скорую руку blog.teamgrowth.net/...quality-control

Тоесть все Тестировщики которые начинают свою карьеру фактически занимаются чисто Тестированием, просто выполняя Тест Кейсы и дают заключение — работает или нет. Им не нужно (по крайней мере на начальной стадии) что то менять в процессе разработки в целом, вносить коррективы и прочее. Ну и соотвественно тайтлы меняются от (должны меняться и лет эдак 10 назад так и было): Junior Test Engineer, Middle Test Engineer, Senior Test Engineer.

Соответственно когда тот же Сеньор уже участвует в процессах улучшения качества в целом, меняя что то в процессе разработки и выполняя некоторые другие функции в его тайтле может появиться уже слово QA, например как: Senior QA Engineer or QA Team Lead or QA Manager.

По хорошему в настоящее время многие стали миксовать эти понятия и кому то проще писать название позиции сокращенно, отсюда и можно встретить вакансии Junior QA и так далее. Главное не это — а то чтобы люди которые работают и набирают людей — четко понимали кто же им нужен ! Даже БОЛЕЕ важно даже не это а то ЧТОБЫ человек который будет работать в данной отрасли четко понимал разницу и свое место в процессе!

Я думаю Я четко изложил мысль :)

пара ссылок на скорую руку:
— www.mosaicinc.com/...rmThisMonth.asp
— www.diffen.com/...Quality_Control

Сообщения не редактируются )))

А у меня редактируются )

Я как обычно нахожу баги которых никто не может найти )))))))
Это нормально и Я уже к этому привык ;)

Ну значит не зря Вы занимаете уже такую должность! :)

* ошибся малость — очепятка ))

— QA
— QC
— Software Testing

+1
Спасибо за мнение. Я полносьью с Вами согласен. Интересны другие мнения

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

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

Хотел написать длинный и емкий комментарий, но потом одумался. Скажу просто.
Нужно принять, простить, и жить дальше.

Пока окружающие ломают копья вокруг откровенной ерунды вы можете стать профессиональнее. Подумайте логически что для вас реально важно? Что у вас на бейджике написано или что вы реально умеете и сколько зарабатываете? В наших реалиях разницы нет, а за бугром не будут смотреть на местные лычки, хоть вы президентом тут были, будут спрашивать с пристрастием о ваших навыках! Мои скромные выводы: не обращайте внимания на лычки и не давайте снобизму других перекинуться на вас.

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

Первое предложение полностью соответствует моим текущим планам и действиям. Вот, только, если я работаю в єкономике, то она должна біть связана с деньгами, курсами, биржами. А если я работаю с тестами, то не понятно, кто я: QA или QC) Наверное, вопрос больше риторический, но для мыслеварилки сойдет

QA-Библией я бы скорее назвала стандарты ISTQB.

ересь! (нет, это всего лишь альтернативный Коран)

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

почему же даже уже работающие тестеры воспринимают термин QA в качестве спеца, который ищет баги (software test engineer).
1) ЧСВ. Вот многие программисты — это, по факту, кодеры (довольно часто быдлокодеры). Но вот «разработчик» или даже «софтвер инженер» звучит круче.
2) Аутсорс. «КуА» продать проще чем «манки кликера».
3) Рашн традишн. Просто так сложилось, скорее всего, на основе пунктов 1 и 2.
.
Т.е. QA — это не тестер software, а больше надсмотрщик за соблюдением стандартов и процесса самой разработки, а также его оптимизации.
Интересный момент: как правило вот этим занимается кто-то из разработчиков.
.
Если честно, то я бы не советовал заморачиваться на эту тему. До тех пор пока эго «манки кликера» не мешает вам (или вашему эго :) )
Интересный момент: как правило вот этим занимается кто-то из разработчиков.
ЭЭЭ, не совсем понял, как дев относиться непосредственно к оптимизации процесса разботки. Он же не может разрабатывать код и при этом думать о том, что нужно кофе-машину поставить в офисе, чтобы он и его коллеги не бегали через дорогу тем самым уделяя больше времени работе. Оптимизация процесса и сам процесс-это же разные вещи. Вот, я у себя делаю аналог работы PM и QA, а мои сотрудники уже делают QC и DeV. .. Или я что-то не так понял?
ЭЭЭ, не совсем понял, как дев относиться непосредственно к оптимизации процесса разботки
Все очень просто: разработчик (хороший профессиональный разработчик, а не говнокодер, этим то пох) первый кто чувствует боль от не оптимального процесса.
Нет системы контроля версий, нет бил сервера, нет скриптов обновления — не удобно вносить и проверять (в ручном режиме) свои изменения, а также разбирать/воспроизводить фейлы продакшена (чтобы что-то исправить, его сначала надо воспроизвести).
Нет юнит тестов, ЦИ и ГУИ-тестов — долгое время на проверку багов и много монотонной работы (пусть ЦИ-сервер кликает вместо вас).
Нет вообще никакого тестирование — это разработчику будут звонить в сб «иди и сделай что-то!!1АДЫН».
Вот, я у себя делаю аналог работы PM и QA, а мои сотрудники уже делают QC и DeV. .. Или я что-то не так понял?
Так и вижу как ПМ (проджект или чего веселее продукт менеджер) поднимает ЦИ-сервер или делает ревью кода :) Тим лид или какой-то тех. лид вполне может.
.
Суть проста:
Проблемы решает (эффективно) тот кому это надо, как правило это разработчик. А вот если разработчику оно нах не надо, то тут никакой КуА не поможет.

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

Проблемы решает тот.... кто должен их решать...
У вас никто ничего не занимал, поэтому вам никто ничего не должен :)
Тестирует тестировщик, создает архитектор, ПМ управляет, а что же делает QA?
Вы смешали роли и должности. Простой пример:
Я — разработчик. Я должен тестировать?

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

Ві должні проверять и качественно делать свою работу, а тестировать должен тестировщик.
Какой интересный поворот. А в чем разница между “проверять” и “тестировать”?

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

но также включает ряд других процессов.
Каких процессов? (Шас все сведется или к равенству понятий тестирование и проверка, или к равенству тестирования и КуА :) )

Я мало понимаю в тестировании и разработке, но не поддержу.
Разработчик тестирует. Positive testing, unit testing, даже GUI тестирует.
Ему же надо убедится, что то, что он напогромировал хоть как-то работает.

Как раз ошибки разработчику искать сложно и этого делать не надо.

Я так и написал. Иными стовамми программист проверяет ошибки в написанном сочинении со стороны ученика, а ротом учитель проверяет все остально и то, что уже проверенно ранее повторно.

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

... ошибки в написанном сочинении со стороны ученика...
Мой учитель зарлита (по факту философии :) ) говорил:
Если вы начинаете объяснять что-то используя аналогии — это уже первый признак того что вы плохо разбираетесь в теме.
Не знаю как у вас, но в моем опыте это утверждение срабатывало всегда.

Если использовать Вашу аналогию, то правильнее сказать что ученик (программист) пишет сочинение и проверяет, что оно работает (есть вступление и окончание, раскрыта основная мысль и т.д., но не ищет ошибки).
Потом учитель (тестер) проверяет уже то же самое + наличие ошибок (аналог negative testing), соотвествует ли основная мысь теме сочинения (аналог acceptance testing) и т.д.

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

Учитель тоже не все найдет. А если и все, то ученик не сможет их починить.
Мир несовершенен.

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

Оффтоп. Ушли уже далеко от темы

Интересный нюанс — у нас аутсорсер пишет тайтлы как tester, а с этого года как test engineer. А вот два больших заказчика (500+) пишут тайтлы (и нам и своим сотрудникам), один как QA, а другой как QE.
Так что у кого какие традиции это еще большой вопрос.

Так что у кого какие традиции это еще большой вопрос.
От как раз глобал был одним из локомотивов «продажы КуА» и сказок про то что любой «манки кликер» это «ценный КуА специалист» (где-то в районе 2008 года).

Интересно! А в Европе тоже таким же образом нивелируются стандарты и понятия тестирования или это только в СНГ?

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

Получается, что тестировщиком быть некруто, а быть qa — занудно т.к. выполняешь совсем другую роль, а на тебя думают, что ты bug-hunter?

Кстати, вот, Вы какие обязанности выполняете в компании: QA или QC?

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

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

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

Но ведь Вы не в курсе исходного «кода» процесса разработки. Зачем тогла QA?

Что вы имеете в виду? Я вижу процесс разработки и принимаю в нём участие. Мне знакомы проблемы на определённых этапах. Я могу что-то улучшить, обратив внимание на слабые места.

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

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

Но можно же сказать «Я — software test engineer» или «Я -QC». С другой стороны, если я, например, PM и ищу себепополнение команды, то никогда не возьму сотрудника, который не понимает принципиальной разницы между QA и QC

Возможно по-этому вы и не PM.
Знание различий лычек в тестировании, пожалуй, самое меньшее что должно беспокоить.

Это показывает отношение человека к делу, которое ему нравится. Если формально относимся к разным специальностя , то также будем и к работе относиться. К тати, если взять мою иерархию и иерархию должностей в ит, то в дпнный момент я выше, чем ПМ.

Это показывает отношение человека к делу, которое ему нравится.
Нічого це не показує. Людині може бути щиро пофіг на різницю між QA та QC. А iso9000 взагалі може бути з галузі буквосполучень, які прсто пишуть на коробках.

Поки інші вчитуються що ж це таке, людина може набивати досвід в технологіях та інструментах для тестування. І в результаті зможе взути будь-якого “QA Senoir’а” зі знаннями різниці між QA та QC.

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

Не спорю, но Вы вводите прочие условия в вопрос. Млжно сказать, что он звучит с приписко."при равном условии"

С другой стороны, если я, например, PM и ищу себепополнение команды, то никогда не возьму сотрудника, который не понимает принципиальной разницы между QA и QC
Ну... «ніколи» — це не зовсім «Ceteris paribus»:)

А взагалі за інших рівних умов можна й вибирати й по принципу «а вот цей ще і танцює».

З іншої сторони, я довгий час толком не вважав за програмістів людей, які скажем, ніколи не писали алгоритм Дейкстри чи не читали Кормена. Але реальність така, що ці знання потібні не так часто і люди й без них справляються зі своїми задачами і дуже навіть не погано. В результаті кожен знаходить своє місце, правда ціна питання різна.

Мне напоминает что-то другое. Экономист, который знает, как делать процес (манки клинер :-) ), но не знает к какой должности он относиться. Пока он набирает опыта у него будет просто оттачиваться автоматика. Как правило, из личного опыта подбора персонала такие люди никогда ничем не выделяются, не делают работу на 5+ и никогда нестановятся в кадровый резерв. Анналогичто, что будет все-равно Игорь ли Ваше имя или Пигорь или Вигорь. Зато Вы крутойй спец. Как то так

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