Большинство имеет отдел качества. Не в каждой это именно QA отдел, хоть и называется так. Я видел конторы в которых вообще нет тестировщиков и их обязанности принимают другие отделы. Мне, будучи сотрудником QA отдела, приходилось фиксы делать вместо разработчиков. Это все лирика. Да, в природе есть компании, в которых отдел QA — это QA. И даже есть в которых код ревью делают, все зависит от подхода. Важно понимать, что QA — занимается тестированием, просто по сравнению с QC у сотрудников больше полномочий и обязанностей. Ну я уж не буду пояснять, что внутри отдела тоже есть иерархия и обязанности могут быть разделены.
Я гляжу, что не все до конца понимают о чем говорят…
На самом деле есть русская версия ISO: www.iso.org/obp/ui/#iso:std:iso:9000:ed-3:v1:ru:term:3.2.11
Выдержки:
— 3.2.11
обеспечение качества
quality assurance
часть менеджмента качества (3.2.8), направленная на создание уверенности в том, что требования (3.1.2) к качеству будут выполнены
— 3.2.10
управление качеством
quality control
часть менеджмента качества (3.2.8), направленная на выполнение требований (3.1.2) к качеству
— 3.2.8
менеджмент качества
quality management
скоординированная деятельность по руководству и управлению организацией (3.3.1) применительно к качеству (3.1.1)
Примечание 1 к записи: Руководство и управление применительно к качеству обычно включает разработку политики в области качества (3.2.4) и целей в области качества (3.2.5), планирование качества (3.2.9), управление качеством (3.2.10), обеспечение качества (3.2.11) и улучшение качества (3.2.12).
Первое — определение процесса обеспечения качества, второе — процесс управления качеством. Все это является состовляющей менеджмента качества, также как и планирование и многое другое. Это не определение должности человека.
В большинстве компаний есть отдел качества, который занимается как раз Менеджментом этого самого качества. Т.е. те же самые люди, что настроили процесс, могут заниматься и тестированием. Может действительно отдельную статью об этом написать…
Согласен, но я бы это сформулировал так: общий подход — нужно логировать, но в любом правиле, есть исключения. В зависимости от ситуации, углы можно и срезать, главное результат.
Во всем нужна мера. Если человек зациклен на мелочах и не смотрит главного, то да, получит фигню. А если он смотрит главное и находит, что функционал отвечает требованиям, но пользователь не сможет с таким работать, то это мимо проходить нельзя.
Согласен, процессы могут быть разные, но такого рода обсуждения важно логировать, чтобы потом было на что ссылаться. Если все будет устно, потом могут концов и не найти.
Ситуации бывают разные, если тестировщик наталкивается на потенциальную проблему, он обязан о ней заявить, другое дело, что команда разработки может принять решение ее не исправлять. Когда дело дойдет до заказчика может быть уже слишком поздно. Стоит отметить, что и заказчика может не быть, например если разрабатывается коробочная версия продукта и от релиза зависит будут покупки или нет. А противоречий тут нет, т.к. речь идет о том, что тестировщик должен правильно расставлять приоритеты во время тестирования.
Спасибо за развернутый комментарий, я намерено не стал вдаваться в подробности о том, что такое Тестирование, QC и QA. Т.к. это тема обширная, которая годится для отдельной статьи. Я лишь указал, что QA в большинстве компаний так и зовут тестировщиками, хоть это и неправильно. И да, бывает и обратная ситуация, когда тестировщиков зовут QA.
Увольнение не всегда может быть хорошим вариантом. Можно попробовать обойтись без крайних мер, но придется запастись терпением. Любые свои замечание нужно будет оформлять в виде тикетов и доводить до команды о их существовании. Команда, в свою очередь, может принять решение ничего по ним не делать. В таком случае ответственность за проблемы после релиза будет уже не на тестировщике, а на тех кто принимал решение не исправлять проблему. После череды событий из разряда «Я же говорил...», команда невольно начнет прислушиваться.
Ну суть как раз в том, чтобы аналитик начал их писать :)
И я не спорю, что научить можно кого угодно и чему угодно, весь вопрос в сроках и целесообразности.
Получается вы рассматриваете BDD как упрощение написания кода, когда речь идет о том, чтобы писать тесты на понятном человеку, без опыта программирования, языке. Не каждый Бизнес Аналитик, сможет читать код и уж тем более писать на нем.
На самом деле есть русская версия ISO: www.iso.org/obp/ui/#iso:std:iso:9000:ed-3:v1:ru:term:3.2.11
Выдержки:
— 3.2.11
обеспечение качества
quality assurance
часть менеджмента качества (3.2.8), направленная на создание уверенности в том, что требования (3.1.2) к качеству будут выполнены
— 3.2.10
управление качеством
quality control
часть менеджмента качества (3.2.8), направленная на выполнение требований (3.1.2) к качеству
— 3.2.8
менеджмент качества
quality management
скоординированная деятельность по руководству и управлению организацией (3.3.1) применительно к качеству (3.1.1)
Примечание 1 к записи: Руководство и управление применительно к качеству обычно включает разработку политики в области качества (3.2.4) и целей в области качества (3.2.5), планирование качества (3.2.9), управление качеством (3.2.10), обеспечение качества (3.2.11) и улучшение качества (3.2.12).
Первое — определение процесса обеспечения качества, второе — процесс управления качеством. Все это является состовляющей менеджмента качества, также как и планирование и многое другое. Это не определение должности человека.
В большинстве компаний есть отдел качества, который занимается как раз Менеджментом этого самого качества. Т.е. те же самые люди, что настроили процесс, могут заниматься и тестированием. Может действительно отдельную статью об этом написать…
И я не спорю, что научить можно кого угодно и чему угодно, весь вопрос в сроках и целесообразности.