В теме 19 ответов, и 9 участников, последнее обновление сделано пользователем 
Надежда Тарасюк 12 г, 2 мес. назад.
-
Сообщения
-
Нет, в общем случае различие между QA И QC описано совершенно неверно. Это QA отвечает полностью за качество поставляемого решения в целом. А QC — это quality control, является более узкой специализацией. QC выполняет и QA, просто помимо QC, у QA есть еще большое поле деятельности. Если говорить совсем простым языком, то QC — это тестер. То есть это тот, кто контролирует работу программиста, а не качество самого продукта.
Да, в разных компаниях роли, которые выполняет QA, разнятся. Но в общем случае QA (простой, обычный QA) с заказчиком напрямую дело имеет очень редко. QA менеджер имеет, QA менеджер влияет на качество работы с заказчиком, конечно. Но так же влияет на него и менеджер программистов, я бы не стала выделять этоу функцию QA менеджера каким-то особым образом.
В чем пересекается QA и BA я уже писала. QA должен АНАЛИЗИРОВАТЬ то, что он проверяет. QC, в общем-то, этого делать не должен/не обучен.
Кстати, заметила новый странный тренд на рынке РБ. Стали появляться вакансии QA аналитиков cо списком обязанностей, которые, вообще-то, должен выполнять нормальный обычный QA. В силу того, что у нас QA называют всех, от кликеров и тестеров, до, собственно, настоящих квалифицированных QA, видимо, для обозначения классического скоупа работ последнего теперь будут использовать красивое слово аналитик
Главное — продать подороже 
Оставлю и я своё мнение.
1) г — Т.к. работаю на маленькой компании приходится быть и BA и QA, хотя в силу своей необразованности толком не знаю кто что должен делать, но у нас на фирме каждый работник "Швейцарский нож" (кстати очень понравилась аналогия). Я по долгу службы занимаюсь и написанием ТЗ и проверкой соответствия готового программного продукта тому же ТЗ и общением с заказчиками и т.д. Ещё успешно выполняю роль слесаря (если ручка двери раскрутится) и электрика (заменить лампочку или розетку починить). Скажите Вы мне кто я BA или QA?
2) а — Опять таки на своём примере считаю что совмещение данных ролей ведёт к более глубокой проверке функционала т.к. в наличии более глубокие знания и понимание специфики проектов.
Оставлю и я своё мнение.
1) г — Т.к. работаю на маленькой компании приходится быть и BA и QA, хотя в силу своей необразованности толком не знаю кто что должен делать, но у нас на фирме каждый работник "Швейцарский нож" (кстати очень понравилась аналогия). Я по долгу службы занимаюсь и написанием ТЗ и проверкой соответствия готового программного продукта тому же ТЗ и общением с заказчиками и т.д. Ещё успешно выполняю роль слесаря (если ручка двери раскрутится) и электрика (заменить лампочку или розетку починить). Скажите Вы мне кто я BA или QA? 2) а — Опять таки на своём примере считаю что совмещение данных ролей ведёт к более глубокой проверке функционала т.к. в наличии более глубокие знания и понимание специфики проектов.
Прокомментирую с вашего позволения:
1) т.к. BA и QA — это "роли", то вы просто играете обе роли. Если хотите аналогию, то это как в любой командной работе. Если хотите, пример из военной тематики. Есть танк и есть танкисты. Танкисты — это командир танка, наводчик оружия, механик водитель и заряжающий. Но ведь, в принципе, может получится так, что экипаж танка будет составлять не 4, а 3 или 2 человека. И что тогда? Правильно, один и тот же человек будет, например, и заряжающим, и наводчиком. Да, им наверняка будет сложнее, но чтобы выжить, им придется играть по несколько ролей. И да, чем лучше т.н. взаимозаменяемость (каждый может взять на себя любую роль), тем больше шансов у данного экипажа выжить.
2) совмещение ролей — это, как и всё в нашем мире, палка о двух концах. Один конец вы описали верно. А второй — это недостаточная специализация в каждой из ролей, как следствие — неглубокие знание, как следствие — невозможность решать действительно сложные задачи, требующие большого опыта и знаний именно в данном конкретном предмете. Здесь, у второго же конца находится уменьшение кол-ва времени, доступного на активности в каждой из ролей и тоже, как следствие, вероятно недостаточная проработка активностей каждой из ролей. Ну и опять же, здесь же у второго конца находится сложность переключения из одной роли в другую (ведь роли разные, цели и задачи у этих ролей тоже разные) и, как следствие, падение качества выполнения активностей одной из ролей.
Есть книжка очень интерсная:Agile Managment For software Engineering (David J.Anderson)
Там одним из ключевых моментов (почему-то в конце книге) является противоречие между использованием Специалистов и Генералистов.
И в конечном итоге в этом и видится основной спор между Agile и не Agile (так ли это судить не буду и свою точку зрения высказывать тоже).В конечном итоге предлагается решить этот вопрос через генералистов-специалистов. Типа каждый должен мочь выполнять любую роль, но при этом специлизируется на ряде каких-то областей. В детали в даваться не буду.
Но что-то в этом есть
Если еще больше обобщать затронутую тему, то можно упомянуть аналогию с ежом/лисой (http://leocasey.blogspot.com/2011/08/wi … gehog.html ).
Если кратко, то есть такая метафора — одни любят изучать многое и поверхностно, другие выбирают специализацию и изучают ее очень глубоко. Первых обычно называют лисами, вторых — ежами.
И вопрос в том, чтобы определить кто ты сейчас есть и кем надо быть, чтобы быть востребованным в профессиональной сфере. Обычно считается, что быть только лисой (знать и уметь всего по чуть-чуть) или только ежом (иметь очень глубокую экспертизу, но в одном/нескольких скиллах) недостаточно. Надо разумно сочетать в своей сфере характеристики обоих.
Вы должны авторизироваться для ответа в этой теме.
