Quality assurance vs. Quality control

Если мяса с ножа
Ты не ел ни куска,
Если руки сложа
Наблюдал свысока,
...
Значит, в жизни ты был
Ни при чем, ни при чем!
В. Высоцкий, Баллада о книжных детях

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

Самый главный риск — потеря обратной связи. Ну не может человек, который занимается внедрением процессов, качественно внедрить процессы, ни разу не «работая в поле». Чудес не бывает — чужая точка зрения на качество внедрения процесса (который, к тому же, не приносит прямой бизнес-ценности) никогда не заменит свою собственную. Ну и просто с точки зрения обычной логики — нельзя целью работы ставить внедрение процесса, внедрять процесс надо всегда ради продукта или как минимум — с оглядкой на него. О каком разделении QA и QC может идти речь?

Второй риск — если у среднестатистического человека на ментальном пространстве бывшего СССР появляется возможность не заниматься работой над продуктом, а заниматься «внедрением» чего-либо — он с радостью этим займется. Ведь это великолепная возможность не отвечать непосредственно за сделанное своими руками — всегда есть возможность свалить вину на тех, кто непосредственно по процессу работает. Это нормальная среднестатистическая человеческая реакция :) Иными словами — вместо карьеры в разработке софта, начинает строиться карьера в корпоративном маневрировании.

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

С самыми важными рисками разобрались, остается вопрос — почему так? ИМХО, все такие шаблоны поведения и принятия решений говорят о том, что, несмотря на декларируемую повсеместную agile-зацию, директивное управление все-таки прочно сидит в мозгах как руководителей, так и исполнителей. Действительно, ну как же без штаба, пишущего уставы и годами не выезжающего дальше полигона с тепличными условиями? Как может какой-то лейтенант понимать больше о том, что происходит именно здесь и сейчас возле деревни Гадюкино, чем заслуженный полковник за 200 км от места событий? Как же можно поставить цель без четкого определения пути достижения этой цели со стороны руководителя?

Остается вопрос — что делать?

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

Если вы строите процессы с нуля — все современные отличные практики вам в руки: смешивайте QC и разработчиков, разбавляйте их QA, тасуйте QA между командами и т.д.

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

В заключение — не зря приведены саркастические примеры из военной области. Немецкая Auftragstaktik и её наследница Mission-type tactic давно подвели научное обоснование под инициативность среднего и младшего командного состава и их возможности влияния на уставы и тактику боевых действий. Как говорил один умный и богатый японец: «Бизнес — это война и все законы войны распространяются на искусство ведения бизнеса». А ИТ-шники упорно цепляются за прошлое — обидно :)

Теми: QA

Елена Петрова Business Development Manager в IT-tuning 23.11.2011 14:24

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

По поводу замечаний :

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

Оба докладчика работают тестировщиками, один из них, параллельно, выполняет quality assurance функции. Несколько раз в ходе дискуссии говорилось, что внедрять, улучшать и аудировать процесс может только эксперт в этом процессе. В зависимости от предмета аудита QA функцию могут выполнять либо специалисты в области тестирования, либо эксперт в разработке, либо менеджер проекта. Если для нас важно качество процесса тестирования (насколько хорошо и достаточно тестирование выполняет поставленную перед ним задачу в данном конкретном проекте или данной конкретной компании — если есть требования к процессу тестирования на уровне компании, конечно), то этот процесс должен внедрять, улучшать и аудитить специалист в Quality control области, то есть тестировщик.

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

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

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

Результаты аудита рассматриваются только вместе с метриками, показывающими насколько результат процесса отклоняется от поставленной цели. Вот несколько сценариев:

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

отсутствие у присутствующих понимания того, что это не могут быть независимые процессы

О каком разделении QA и QC может идти речь?

Речь о том, что для выполнения QA функции нужна специальная подготовка. У аудита есть свои правила. Среди них упомянутая «независимость».
Опять же, на встрече делался акцент на том, что «независимость» надо понимать следующим образом: аудит (не внедрение ) процесса должен проводить не тот человек, который выполняет определенный процесс в данном конкретном случае, но это должен быть однозначно эксперт в дисциплине, которая проверяется. Это позволяет достичь объективности, непредвзятости.

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

Все указанные риски несомненно актуальны, если проводить аудит бездумно («потому что надо проводить»), бесцельно.

Лично от себя. Спасибо Дмитрию, что он написал статью. Я бы тоже хотела высказаться по поводу этого мероприятия, но не знала где и как сделать это наиболее корректно :).
Меня, как представителя Quality Assurance, доклад тоже разочаровал, но по другим причинам. Он мне показался бесполезным, самые важные моменты не были освещены. Это было похоже на попытки внушить людям, что аудит им нужен, не делая акцент на том, почему он им нужен. Мне кажется, что причина в том, что докладчики (несмотря на указанный опыт работы) уже убеждены в полезности, еще не сильно опытны в понимании сути этой полезности, не могут убедительно ответить на вопросы.

Я прекрасно понимаю такое состояние, потому что сама была в такой ситуации. Надеюсь, постепенно перерастаю :). Поэтому я бы построила доклад по-другому и сделала бы другие акценты, чтобы достичь заявленной цели.

Відповісти

Підтримати

Дмитрий Ефименко CTO в Portmone.com 23.11.2011 15:28

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

Спасибо за мнение и оппонирование.

Елена Петрова

Елена Петрова Business Development Manager в IT-tuning 23.11.2011 18:21

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

И вообще, интересно, а существуют ли компании, в которых действительно требуется и налажен quality assurance?
Мне кажется, что это может быть востребовано только в «продуктовых» компаниях, где руководство заинтересовано в скорости и качестве производства.

Дмитрий Ефименко

Дмитрий Ефименко CTO в Portmone.com 23.11.2011 19:10

С востребованностью только в продуктовых компаниях (и почему у вас кавычки? :)) - не согласен.
Продуктовые компании тоже занимаются оутсорсингом — кастомизация продукта под заказ и/или интеграция, например.
А оутсорсинговые занимаются продуктами — фреймворки, например.
В чем разница-то? Я видел немало примеров оутсорсинговых компаний, которые работают по принципам продуктовой.

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

Denys Kostin pm в GlobalLogic 22.11.2011 15:10

Извините,мне не понятно только одно: как связаны QA и QC?

Как QC, занимающийся контролем продукта, связан с обеспечением качества как процесса, которым занимаются другие люди? По-моему тут такая же связь как и между любыми людьми, работающими на одном проекте... Все собираются, беседуют, митингуют...

Тогда каждый тестировщик должен быть и тестировщиком и QA, и QC... Тогда какой Вы видете смысл в разделении этих профессий?

Ноаборот, отделение QC от всех остальных, я думаю, важно. Чтобы меньше дружили идеями, чтобы меньше глаз зашоривался.

Может тогда пусть 1 человек все делает? И пишет, и тестирует, и продает?

Дмитрий Ефименко CTO в Portmone.com 22.11.2011 15:53

Извините,мне не понятно только одно: как связаны QA и QC?
Как QC, занимающийся контролем продукта, связан с обеспечением качества как процесса, которым занимаются другие люди? По-моему тут такая же связь как и между любыми людьми, работающими на одном проекте... Все собираются, беседуют, митингуют...

По порядку... QC реализует процесс, разработанный QA и вполне способен дать обратную связь о этом процессе.

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

Как раз я и не вижу — мне это не нравится, у меня QA и QC объединены :) А тем, у кого такое разделение есть — я как раз настоятельно рекомендовал обратные связи поддерживать и «в поле выводить» QA хоть иногда :)

А цена «обратной петли» такого решения?

Фрилансеры так и делают, вы не поверите. В компаниях смысла нет — есть возможность разделить и снять сливки со специализации и полировке инструмента и мозгов без постоянного переключения между разнородными задачами. Но ничего, кроме пользы, +1 левел к компетенции не дает. Продать/разработать/... пусть и не смогут, но зато кухню превращения идеи в деньги и «почему так» будут понимать лучше и смогут помочь.

Denys Kostin

Denys Kostin pm в GlobalLogic 23.11.2011 16:19

Наверно, я как-то неправильно выразился. Я не знаю примеров на столько разделенных QA и QC, чтобы их нужно было объединять. Больше похоже на борьбу с какой-то ситуацией, которая где-то должна быть. А если ее нигде пока нет, то нужно всем напомнить, что и не должно быть... И акцентировать, что ее не должно быть не по логике здравого смысла, а по очень умному расчету.

Дмитрий Ефименко CTO в Portmone.com 23.11.2011 19:20

Ну, я вот столкнулся с таким разделением :) Почему и говорю, что там, где разделение есть — лучше не устраивать революции по объединению, а заняться нормальными обратными связями.

Ну а про здравый смысл... Я как бы основные риски привел. Недостаточно?

Denys Kostin pm в GlobalLogic 23.11.2011 20:00

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

Дмитрий Ефименко CTO в Portmone.com 24.11.2011 11:52

Денис, вы просто не поверите — такое разделение много где есть :) В явном и неявном виде. Как следствие — проблема поиска тестировщиков с эрудицией и компетенциями шире, чем ручное и автоматизированное тестирование :)

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 22.11.2011 12:37

У нас эти команды не разделены. Разделять, ИМХО — глупо, а после искать пути решения проблем что ты (вы, другие) сам же создал — еще глупее. И как результат — целью становится совершенно не то что планировалось изначально, не говоря уже о временных затратах.

Но для мазохистов указанные солюшены подойдут :)

Дмитрий Ефименко CTO в Portmone.com 22.11.2011 12:50

у вас достаточно категоричная точка зрения, но не нужно обзываться :)

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

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

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

Alexander Kuznyak

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 22.11.2011 13:00

Я не обзываюсь, сорри если так показалось, просто мне кажется что это создание проблем самим себе, не более.
Занимаемся — но не «постоянно» и это приносит определенные результаты для глобального процесса :)

Рабингранат Кагор 22.11.2011 11:55

Для кого предназначена эта статья?

Для менеджеров, которые могут устраивать насильную ротацию и смешивание ролей в проекте?

Для тестировщиков, которые до измения процессов вообще не допущены?

Для тех QA, которые «обожрались» и не могу снизойти до народа, запутавшись в «корпоративном маневрировании»?

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

Оффтоп: правильно ли я сужу по вашей риторике «Как же без штаба, пишущего уставы и годами не выезжающего дальше полигона с тепличными условиями? Как может какой-то лейтенант понимать больше о том, что происходит именно здесь и сейчас возле деревни Гадюкино, чем заслуженный полковник за 200 км от места событий?» о том, что вы если уж не предпочитаете, то считаете более правильной окопную ~~правду~~ прозу лейтенантов versus генеральские мемуары о решениях, которые принимаются и распространяются на весь фронт одномоментно? Было такое течение в литературе семидесятых годов.

Дмитрий Ефименко CTO в Portmone.com 22.11.2011 12:31

Для тех, кто управляет рисками разработки ПО.

А что вы понимаете под насильственной ротацией и как вы представляете добровольную ротацию? Ротация — это практически всегда воздействие извне. Вопрос с осознании необходимости и обоснованности этой ротации в глазах «ротируемых».

В том числе. И для их руководителей.

Нет, для их коллег — этих вряд-ли прошибешь.

Несогласие с мнением большинства или огорчение в связи с непониманием очевидных (не только для меня) вещей — это разочарование в окружающих? Интересный маппинг :)

Нет, неправильно.

Есть вполне себе ненулевой риск наличия у исполнителя более актуальной информации, чем у руководителя. Это проблема любой распределенной системы при принятии решений. Типовая проблема иерархических организаций «подчинение неактуальному приказу и фэйл с вероятностью наказания vs. инициатива для эффективного решения».

Если вы приведете пару имен из упомянутого вами течения и мы посмотрим на их биографии, то вы поймете, что пример нерелевантен :) Цели «окопной правды» и управления риском отсутствия эффективной обратной связи при принятии решений отличаются чуть более чем совсем :)

Рабингранат Кагор

Gremlin 21.11.2011 20:51

годная тема.

Quality assurance и Quality control — суть разные процессы, первый направлен на процессы, второй — на продукт.

диалектическое единство и борьба, тудыевокачель.

C’est La IT

vasiliy chobitok 21.11.2011 15:29

Дополню Вас цитатой из Йордона:

«Однако, меня охватывает гораздо большее беспокойство, когда я вижу команды, которые предпринимают свой первый безнадёжный проект с решением (или, что более вероятно, с указанием, навязанным им блюстителями методологии), обязывающим их использовать формальные процессы, например, те, которые регламентируются SEI-CMM или ISO-9000. Формальные процессы — это великая вещь, если вы хорошо знаете, что делаете, и если вы уже использовали их прежде. Однако, реальность такова, что такие формальные процессы, как правило, ранее вообще не использовались в организации...»

К сожалению, у нас чаще всего качество процесса внедряется не с целью делать качественный продукт, а с целью прикрыть зад некоторым управленцам на случай, если продукт некачественный или вообще не получился — есть 100%-й отмаз: «смотрите, у нас всё по процессу, я тут никаким боком, а виноваты конкретно этот аналитик, конкретно этот кодер и конкретно два этих тестировщика...»

Дмитрий Ефименко CTO в Portmone.com 21.11.2011 15:40

Ай, молодца!
А я дополню Вас цитатами из Брэнсона:
«Формальности хороши лишь тогда, когда они упрощают жизнь, когда с их помощью люди лучше понимают, что им нужно делать»
и

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

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

Не, ну без героев в нашей жизни никак, но «заочная любовь по переписке» настораживает.

vasiliy chobitok

vasiliy chobitok 22.11.2011 17:46

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

Это руководитель проекта пишет из организации, в которой ISO и CMMI какого-то уровня.

Такую ценную цитату даже специально занес в анналы: armor.kiev.ua/...дство_проектами

Sergiy Movchan (COTOHA) human manager 21.11.2011 14:05

но процессы-то и правда разные. у нас (да и у буржуев) почему-то принято тестировщиков обзывать QA-engineer. Хотя это не так в общем случае.

Вообще обеспечение качества процесс сквозной и всеобъемлющий и осуществлять его должны _все_ роли.

А вот контроль качества — процесс очень конкретный и осуществляет его чаше всего роль QC-инженера.

с остальным согласен. без «поля» ничего не будет.

Дмитрий Ефименко CTO в Portmone.com 21.11.2011 14:14

но процессы-то и правда разные.

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

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

Sergiy Movchan (COTOHA)

Sergiy Movchan (COTOHA) human manager 21.11.2011 15:50

процесс контроля качества имеет общую цель с процессом обеспечения качества?
или что-то в терминологии или я не согласен.

в общем случае процесс контроля может осуществляться например внешней командой (всякие аудиты и т.п.) и каким боком оно к обеспечению?

это обеспечение не может жить без контроля, а контроль без обеспечения легко.

или ты уже про совсем высокий уровень абстракции типа «надо заработать больше денег».

Дмитрий Ефименко CTO в Portmone.com 21.11.2011 16:47

что ты понимаешь под обеспечением и контролем относительно QA и QC ? потому что у тебя противоречие в:

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

так вот, если опираться на определения QA и QC, то QA напрямую влияет на воспроизводимость качества в целом (т.е. на вероятность воспроизводимости качества), а QC влияет на качественные характеристики конкретного товара/услуги в частности.
Если говорить TQM-ными терминами, то QA — это Quality Improvements, а QC — это Quality Assurance. Именно поэтому, ИМХО, принято называть тестировщиков (QC) совсем «не по определению» QAE ввиду доминирования идеологии TQM :)
И если следовать этой идеологии — ДВА МЕХАНИЗМА (QI & QA) позволяют удерживать и развивать бизнес, ибо у обоих механизмов одна цель — дать некую гарантию потребителю, но QI ещё и вешает перед потребителем морковку того, что качество будет поддерживаться и повышаться.

Вот что имелось ввиду под общностью целей.

Sergiy Movchan (COTOHA) human manager 21.11.2011 17:59

противоречия не вижу :)

и КуСи и КуА я беру не по ТыКуэМ, а по старинке:

контроль = простое тестирование = сверка реализации со спецификацией.

обеспечение = таки обеспечение повторимости достижения некоего минимального уровня качества.

с твоими определениями расходится только контроль — (по-моему) он не влияет на качественные хар-ки, а только их меряет.

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

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

Дмитрий Ефименко CTO в Portmone.com 21.11.2011 18:08

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

ну я свое мнение сказал, почему QC называют QA — доминанта TQM, в которой для QA переопределено понятие :) как по мне — хоть трижды заслуженным QA зовутся в резюме — казаки вон себе есаулов и георгия сами на шею вешают, чего ж тестировщикам нельзя? :)

Anton Naumov SSE в Just Techologies AS 22.11.2011 10:58

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

Дмитрий Ефименко CTO в Portmone.com 22.11.2011 11:21

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

Anton Naumov

Kateryna Nesmyelova Test Lead в PwC New Zealand 21.11.2011 13:19

По этому поводу есть хорошая и умная статья :) www.developsense.com/…rance-business

Как по мне, если ты просто супер-тестировщик, автоматизатор и супер-гуру во многих областях, то это вовсе не обозначает, что ты сможешь так же успешно заниматься Qality Assurance всего проекта.
Quality Assurance должны заниматься все, а специальный отдел, который существует в упомянутой в статье компании, должен работать в тесном сотрудничестве с теми людьми, которые, собственно, и составляют проект.

Уметь и научить(внедрить) - это разные вещи, всё же.

Дмитрий Ефименко CTO в Portmone.com 21.11.2011 13:38

Уметь и научить(внедрить) — это разные вещи, всё же.

Согласен, кто же спорит-то? Но внедрять что-то без обратной связи — это делать работу ради работы, нет? Тем более, в такой «бизнеснеценной» области как тестирование.

Как по мне, если ты просто супер-тестировщик, автоматизатор и супер-гуру во многих областях, то это вовсе не обозначает, что ты сможешь так же успешно заниматься Qality Assurance всего проекта.

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

И ещё вопрос — кто тогда по-вашему способен ставить процессы?

Kateryna Nesmyelova

Quality assurance vs. Quality control

29 коментарів

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

Новини