Спасибо за статью. Хорошо раскрыли и обосновали подход. Согласен в части разделения процесов и их нейминга. Но вот с точки зрения структуры и невозможности совмещения этих процессов в одном челоеке не согласен. У меня за время работы устаялось такое понимание: QA - проактивные действия по обеспечению качества QC - реактивные действия по обеспечению качества Считаю что QC не влияет на качетво, только если искуственно возвести границы вокруг этого процесса. Это равнозначно, если например сказать, что сдача медицинских анализов не влияет на здоровье. Да, напрямую не влияет, но влияет опосредованно. Но зачем об этом говорить? )). Баг-репорт найденный в процессе тестирования(QC) будет пофикшен и уверенность в качестве(QA) возрастет. По-этому, ничего плохого в части нейминга QA для современного эффективного тестировщика не вижу. Он действительно может заниматься, тест-дизайном, тест-аналитикой, ручным и авто тестированием и выдвигать предложения по оптимизации процессов по недопущению багов. Для тестировщика, который пока еще не выполняет проактивные действия по предотвращению багов - есть хорошая точка роста и горизонт новых возможностей в плане использования процесса QA. Ну и тут вопрос, можно ли одним процессом QA обойтись без без внутреннего QC? На мой взгляд нет. Просто процесс QC может размазываться по команде.
Спасибо за статью. А есть ли у вас информация по поводу интеграции с Кайтен.
Спасибо за статью. Хорошо раскрыли и обосновали подход. Согласен в части разделения процесов и их нейминга. Но вот с точки зрения структуры и невозможности совмещения этих процессов в одном челоеке не согласен.
У меня за время работы устаялось такое понимание:
QA - проактивные действия по обеспечению качества
QC - реактивные действия по обеспечению качества
Считаю что QC не влияет на качетво, только если искуственно возвести границы вокруг этого процесса. Это равнозначно, если например сказать, что сдача медицинских анализов не влияет на здоровье. Да, напрямую не влияет, но влияет опосредованно. Но зачем об этом говорить? )). Баг-репорт найденный в процессе тестирования(QC) будет пофикшен и уверенность в качестве(QA) возрастет.
По-этому, ничего плохого в части нейминга QA для современного эффективного тестировщика не вижу. Он действительно может заниматься, тест-дизайном, тест-аналитикой, ручным и авто тестированием и выдвигать предложения по оптимизации процессов по недопущению багов. Для тестировщика, который пока еще не выполняет проактивные действия по предотвращению багов - есть хорошая точка роста и горизонт новых возможностей в плане использования процесса QA.
Ну и тут вопрос, можно ли одним процессом QA обойтись без без внутреннего QC? На мой взгляд нет. Просто процесс QC может размазываться по команде.
Ооо, а это как? Можете чуть-чуть поподробнее?