Какую литературу почитать для ознакомления с QA?

Я имею представление, что это за роль, но конкретного определения не знаю.
Мне нравится узнавать что-то новое. Тем более что я больше смахую на QA, а не на обычного тестировщика (обладаю требуемыми качествами, но пока нет знаний). Я только начал знакомится с сферой ИТ, в часности с тестированием и обеспечением качества.

ЗЫ. То что я делаю очипятки -- то я не волшебник я только учусь.

Тем более что я больше смахую на QA, а не на обычного тестировщика (обладаю требуемыми качествами, но пока нет знаний). Я только начал знакомится с сферой ИТ, в часности с тестированием и обеспечением качества.

Я не уверен, что смог понять, что здесь сказано.

В QA в основном имеется два типа специалистов:
1) "Инженер по обеспечению качества". Его обязанности примерно соответствуют обязанностям обычной секретарши.
В основном он занимается перекладыванеием документов из одной папки в другую и проставлением галочек в своём реестре.
Если какой-то требуемый документ не найден, то он обязан написать об этом отчёт.
Часто на эту низкооплачиваемую должность назначают людей совсем без опыта (например, выпускников, только начинающих работать).
2) "QA менеджер" организует и направляет работу этих "Инженеров по обеспечению качества". Как правило это человек с достаточным опытом в области разработки программ.

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

Тем более что я больше смахую на QA, а не на обычного тестировщика (обладаю требуемыми качествами, но пока нет знаний). Я только начал знакомится с сферой ИТ, в часности с тестированием и обеспечением качества.

По вашим предыдущим вопросам видно, что не совсем.

1) "Инженер по обеспечению качества". Его обязанности примерно соответствуют обязанностям обычной секретарши.
В основном он занимается перекладыванеием документов из одной папки в другую и проставлением галочек в своём реестре.
Если какой-то требуемый документ не найден, то он обязан написать об этом отчёт.
Часто на эту низкооплачиваемую должность назначают людей совсем без опыта (например, выпускников, только начинающих работать).

Бр-р-р-р :) Вы сейчас о ком говорите? Можете привести англоязычное название роли о которой написали?

1) "Инженер по обеспечению качества". Его обязанности примерно соответствуют обязанностям обычной секретарши.
В основном он занимается перекладыванеием документов из одной папки в другую и проставлением галочек в своём реестре.
Если какой-то требуемый документ не найден, то он обязан написать об этом отчёт.
Часто на эту низкооплачиваемую должность назначают людей совсем без опыта (например, выпускников, только начинающих работать).

Бр-р-р-р :) Вы сейчас о ком говорите? Можете привести англоязычное название роли о которой написали?

"QA Analyst"?

В QA в основном имеется два типа специалистов:
1) "Инженер по обеспечению качества". Его обязанности примерно соответствуют обязанностям обычной секретарши.
В основном он занимается перекладыванеием документов из одной папки в другую и проставлением галочек в своём реестре.
Если какой-то требуемый документ не найден, то он обязан написать об этом отчёт.
Часто на эту низкооплачиваемую должность назначают людей совсем без опыта (например, выпускников, только начинающих работать).
2) "QA менеджер" организует и направляет работу этих "Инженеров по обеспечению качества". Как правило это человек с достаточным опытом в области разработки программ.

Если говорить о software quality engineer (SQE) и брать американское представление, то получаем:
"The Certified Software Quality Engineer understands software quality development and implementation, software inspection, testing, verification and validation; and implements software development and maintenance processes and methods"
И минимальные требования к роли: Minimum Expectations of a Software Quality Engineer
Я уже давал эту ссылку вначале.

Ну и кого теперь можно назвать "секретаршей"?

Если вы имели в виду простого Quality инженера, не из области софтваре - там возможно и подешевле люди работают. Хотя тоже сомневаюсь:)

Про Software Quality Manager скромно промолчим:-)

Если говорить о software quality engineer (SQE) и брать американское представление, то получаем:
"The Certified Software Quality Engineer understands software quality development and implementation, software inspection, testing, verification and validation; and implements software development and maintenance processes and methods"

Я, признаюсь, немного упростил описание обязанностей "Инженера по обеспечению качества".
Кроме этого, я использовал определение QA, как контроля процессов разработки. То есть, в моё определение QA тестирование не входит.

На практике, единственный способ контроля процесса, это проверка созданных документов. Причём, качество созданного документа, как правило, не проверяется, а проверяется, просто, был создан какой-либо документ или нет. Для такой проверки знание "development and implementation, software inspection, testing, verification and validation" не требуется.

В своём ответе я не использовал определения ASQ, QAI или SEI (я надеюсь, что Вы помните анекдот о слове из трёх букв, написаном на заборе), а использовал собственные наблюдения.

"QA Analyst"?

Да ну прям таки :) Вы взяли одну задачу - точнее аудит проектной документации - при этом просто свели аудит к проверке наличия того или иного артефакта (хотя это не аудит, а ревизия) и ограничили роль только этой активностью.

+ у меня большое сомнение, что QA Analyst (аналитик!) занимается проверкой, а не анализом.

"QA Analyst"?

Да ну прям таки :) ... у меня большое сомнение, что QA Analyst (аналитик!) занимается проверкой, а не анализом.

На самом деле, изучение различных артефактов доходящих до страны медведей с дальнего и ближнего запада, а также с юго-востока, навевает на мысли, что модели качества в IT работают только в воображении составителей всяких "презенташек". В этом свете, охотно верится в то, что QA Analyst-ы занимаются именно тем, что сказал Yury (и то не очень успешно).

+ у меня большое сомнение, что QA Analyst (аналитик!) занимается проверкой, а не анализом.

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

Так как "QA Analyst" не яаляется ни программистом, ни тестером, то сам он с кодом и программами не работает.

"Code review" проводят программисты, а результат оформляют в виде документа.
Тестированием занимаются тестеры, а результаты оформляют в виде другого документа.
Наличие этих документов и является признаком формального (документированного) процесса разработки.
Вот со всеми этими документами "QA Analyst" и работает.

Если этих документов нет, то этот процес не является формальным, и "QA Analyst" там делать нечего.
----------------------------
Хотя мне рассказывали о случае, когда за плечом у тестера стоял другой человек, который смотрел на то, что делал тестер, и проставлял галочки в своём реестре, чтобы было доказательтсво того, что этот тест был выполнен, и что были полученны именно те результаты.
----------------------------

Case, а как Вы себе этот "анализ" представляете?

Yury

В этом свете, охотно верится в то, что QA Analyst-ы занимаются именно тем, что сказал Yury (и то не очень успешно).

Остаётся только вам посочувствовать - значит у вас эти практики не работают, не применяются и рабочими вы банальные аудиты и их результаты никогда не видели так же как и живого QA? Так получается?

Наличие этих документов и является признаком формального (документированного) процесса разработки.
Вот со всеми этими документами  "QA Analyst" и работает.

[наводящий вопрос]
То есть если в компании XP/Agile и по процессу результаты этих процессных работ в артефакты могут не оформляться, то процесса нет и процессный менеджер (мне кажется, мы всё-таки о нём стали говорить, а не о QA аналитике) не нужен?

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

Не совсем так, а точнее не всегда так. Процесс может быть и без документов вовсе - сюрприз? Больше скажу и RUP который ругают за монументальность бывает для малых команд буквально для 2 человек. Бывает процесс без документов, бывает и формальный процесс без документов, бывает и процессный менеджер без документов и врядли кто-то скажет что рабочий процесс с повторяющимися результатами менее формален чем обвешанный документами.

Хотя мне рассказывали о случае, когда за плечом у тестера стоял другой человек, который смотрел на то, что делал тестер, и проставлял галочки в своём реестре, чтобы было доказательтсво того, что этот тест был выполнен, и что были полученны именно те результаты.

А какое отношение имеет проверка работы конкретного исполнителя к контролю выполнения процессов? Не смешивайте, это разные уровни.

Case, а как Вы себе этот "анализ" представляете?

Какой анализ-то? :) Вы пока назвали аналитика проверяющим и рассказали что он просто сверяет документы со списком.

значит у вас эти практики не работают

Я в разное время для общего развития изучал документацию по СМК нескольких фирм, в которых работал (питаю слабость к таким документам). Сведения о качестве их (и многих подобных) продукции и услуг у меня тоже не из вторых рук. На основе этого опыта считаю, что в ИТ улучшением одних только процессов многого не добьёшься. Собственно, наблюдения за темпом и направлением эволюции процессных моделей, это косвенно подтверждают. Опять же непрекращающееся нытьё о том, что технические специалситы почему-то не хотят идти в подчинение "процессным менеджерам", сами по себе свидетельствуют о том, что менеджерам чего-то не хватает для достижения успеха. :)

Также, у меня сложилось стойкое впечатление что крупные ISV совсем не парятся по поводу развития и сертификации СМК своих подразделений по разработке и обслуживанию ПО, а предпочитают свои проблемы с качеством решать всё-таки инженерными изысканиями, хитрыми партнёрскими и лицензионными соглашениями, тенденциозными disclosure report-ами, и позитивной документацией. :) Попробуйте выборки из гугла [Oracle IBM Microsoft] + [QMS ISO 9000 9001]. Они тоже идиоты и ничего не понимают в качестве?

Поэтому вопрос к цитате: "у нас", это где имелось в виду? Это с понтами, что где-то у кого-то уже получилось, и теперь нас дураков надо научить, как правильно? :)

Вы взяли одну задачу - точнее аудит проектной документации - при этом просто свели аудит к проверке наличия того или иного артефакта (хотя это не аудит, а ревизия) и ограничили роль только этой активностью.

Case, я описал своё понимание того, чем, собственно, занимается "QA Analyst" (с небольшими упрощениями).

Из Ваших вопросов я понял, что Вы с моим пониманием не согласны.
А не могли бы Вы представить Ваше понимание того, чем занимается "Инженер по качеству"?

Теперь понял.

Немного общих фраз (пишу без воды, просто иначе будет совсем длинно):
Качество продукта зависит от качества процесса. Процесс вещь вполне измеряемая и управляемая. Для каждого процесса существует набор метрик и формальных признаков, по которым можно судить что процесс выполняется. Процесс как некое подмножество практик и рекомендаций Методологии, является эффективным только в случае успешной адаптации и постоянного поддержания в актуальном состоянии для условий конкретного проекта. Условия не константны, соотв. и Процесс не есть нечто высеченное в камне.

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

Активности Инженера по качеству включают работы направленные на выявление наиболее оптимального Процесса, работы по адаптации Процессных практик к реалиям Проекта, понимание какими инструментами можно измерять эффективность Процесса (набор метрик и мероприятий типа ревью, etc), контроль Метрик Процесса.

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

Простые идеи, которые я хотел бы донести: Наличие артефактов является одним из, но не единственным и не обязательным признаком работающего Процесса. Гибкие методологии не фокусируются на артефактах, к примеру - однако я бы не стал говорить, что ХР или Scrum от этого хуже и перестают быть методологиями в принципе. Просто в том же Scrum как я его понимаю, роль инженера по качеству смещена в зону отвественности Scrum-мастера: коллеги работающие в Scrum меня поправят если я промахнулся.

Я в разное время для общего развития изучал документацию по СМК нескольких фирм, в которых работал (питаю слабость к таким документам). Сведения о качестве их (и многих подобных) продукции и услуг у меня тоже не из вторых рук. На основе этого опыта считаю, что в ИТ улучшением одних только процессов многого не добьёшься.

Наличие документов регламентирующих СМК и качество продуктов никак не связано. Как говорил Ломоносов "А я знаю 1000 богатых людей, но богаче от этого не стал".

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

Поэтому вопрос к цитате: "у нас", это где имелось в виду? Это с понтами, что где-то у кого-то уже получилось, и теперь нас дураков надо научить, как правильно? :)

С вашей позицией вечно обиженного на меня "бюргера" я уже устал возиться (что в личной переписке, что в форуме) - понимайте слова как вам угодно, но не все в этом мире хотят вас уколоть или подначить :)

Вы достаточно странно асоциируете QMS ISO 9000 9001 с качеством и процессами - кто сказал что если не ISO то фигня? Любой процесс хороший если он работает. Что бы он работал нужны определённые активности - они не заканчиваются (впрочем и не начинаются) на словах "артефакт, документ, ISO". Если консультант, к примеру, оперирует только ими то он теоретик: им тоже найдётся применение, но не везде. У нас в последней проекте в течении 2 лет шла работа по построению наиболее удобного для нас и заказчика процесса - силами энтузиастов проектной команды. В итоге получилась солянка из RUP и гибких методологий. При этом могу сказать что никаких ISO рядом не было, но уверен что по многим аспектам эффективности процесса мы могли бы дать фору и проектам по которому компания получала свой СММ3.

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

Я извиняюсь, но чем-же занимается руководство этого проекта, если практически всё за него делает "Инженер по качеству"?

Я извиняюсь, но чем-же занимается руководство этого проекта, если практически всё за него делает "Инженер по качеству"?

Менеджер проекта это "время-деньги-удовлетворение заказчика". Или вы про кого-то ещё говорите?

Я извиняюсь, но чем-же занимается руководство этого проекта, если практически всё за него делает "Инженер по качеству"?

Менеджер проекта это "время-деньги-удовлетворение заказчика". Или вы про кого-то ещё говорите?

Да, руководитель это тот, кто контролирует бюджет и ресурсы.
Также это человек решает, кому что делать. Как сказал Гашек в "Похождениях бравого солдата Швейка":
"Солдаты без распоряжения офицера и пёрднуть даже не могут".

У Вас же:

Инженер по качеству - роль контроллирующая и обслуживающая Процесс.

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

В реальной жизни руководитель контроль за людьми и контроль за процессом из своих рук, как правило, не выпускает.
В этом случае, роль "Инженера по качеству" сводится к изучению текущего процесса и предоставлению рекоммендаций. Никаких прав вести переговоры и что-либо внедрять у него нет.

У Вас же:

Инженер по качеству - роль контроллирующая и обслуживающая Процесс.

Правильно - с чем вы не согласны?

Процесс это то КАК, а не то ЧТО делаеют люди. Задачи исполнителям в рамках выполнения инженерной задачи реализующей проект ставит технический руководитель. Обьём работ, стоимость, приоритетеы - руководитель проекта. Бывает что совмещают - ну и ладно. Задача процессного менеджера как роли, говорить и доказывать КАК надо делать чтобы было лучше и эффективнее.

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

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

В этом случае, роль "Инженера по качеству" сводится к изучению текущего процесса и предоставлению рекоммендаций. Никаких прав вести переговоры и что-либо внедрять у него нет.

Не совсем понятно что такое "в реальной жизни". Мы обсуждаем какой-то конкретный случай где есть руководитель который тянет всё (а по сути просто совмещает роль ПМ и процессный менеджер - сам себе злобный Буратино) или разбираемся по сути какие роли есть и что в них входит?

Ваша картинка - типичная для проектов/компани, где весь фокус на функционале к сроку любой ценой. Выше мы с вами говорили о том что входит в роль инженера по качеству (свелось к процессному менеджеру). На что хватает прав у менеджера вопрос ровно в том, какие задачи перед ним стоят в конкретном проектном окружении или рамках компании. Поэтому говорить про частный случай и делать вывод о том что входит в роль - ИМХО совсем не корректно. Хороший менеджер хорош именно потому, что занимается только тем что входит в его круг отвественности и делегирует всё что не входит. В круг задач ПМ-а входит "время-деньги-радость заказчика", управление процессом не входит и более того, сомневаюсь я что ПМ-ы хотя бы в 50% случаев это умеют - но вот обсепечить эти работы ресурсами и административной поддержкой они обязаны.

Предоставление рекомендаций - это результат обследования, в часности именно то что вы окрестили "посмотрел, нет документа и сделал отчёт". Внедрение - это обследование, предоставление рекомендаций, контроль за внедрением процессных изменений, адаптация-адаптация-адаптация.