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

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

«Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений», Сэм Канер, Джек Фолк и Енг Кек Нгуен, Москва, ДиаСофт, 2001:

"Руководитель проекта (project manager, также называемый software development manager или producer) отвечает за качество программного продукта, планирование работ и составление бюджета разработки...

Проектировщики (designers) продукта может быть несколько и среди них следующие.

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

• Специалист по анализу предметной области (subject matter expert или software analyst) должен понимать, чего хотят пользователи и как это выразить в терминах, понятных программисту или другому разработчику.

• Специалист по анализу человеческого фактора, или специалист по эргономике (human factor analyst или ergonomist)...

• Программист пользовательского интерфейса (user interface programmer) специализируется на создании пользовательского интерфейса программы...

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

Представитель группы технической поддержки пользователей...

Технические писатели (writers) - это члены группы документирования...

Тестировщики...", 52-54 страницы.

«Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование», Рекс Блэк, Москва, Лори, 2006:

"К началу семинара по анализу видов ошибок и их влияния Кейт и Макс выпустили первую черновую версию спецификаций требований и было проведено ее обсуждение", 38 страница. Кейт Эрнандес - менеджер продукта. Макс дель Оро - вице-президент по маркетингу.

«Верификация программного обеспечения», Сергей Владимирович Синицын, Никита Юрьевич Налютин. МИФИ, Курс лекций, 2006, 16 страница:

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

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

Менеджер программы. Эта роль управляет коммуникациями и взаимоотношениями в проектной группе, является в некотором роде координатором, разрабатывает функциональные спецификации и управляет ими, ведет график проекта и отчитывается по состоянию проекта, инициирует принятие критичных для хода проекта решений. Менеджер программы имеет право изменять функциональные спецификации верхнего уровня, план-график проекта, распределение ресурсов по задачам. Часто на практике роль менеджера проекта и менеджера программы выполняет один человек.

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

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

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

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

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

Специалист по безопасности. Данный Специалист ответственен за весь спектр вопросов безопасности создаваемого продукта. Его работа начинается с участия в написании требований к продукту и заканчивается финальной стадией сертификации продукта.

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

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

«Основы инженерии качества программных систем», Филипп Андон, Галина Коваль, Татьяна Коротун, Екатерина Лаврищева, В. Суслов, Академпериодика, 2007. 20-22 страницы:

Роли специалистов в организационной структуре разработки. Роли на уровне организации:

• Группа технико-технологической поддержки
• Группа защиты информации
• Группа инженерии процесса (технологическая служба)

Независимая группа качества (SQA-группа).

• Планирование и выполнение действий по контролю и гарантированию соблюдения дисциплины создания программной продукции в проектах (организация проверок работ в контрольных точках проектов, определенных календарными планами).
• Контроль документов и продуктов ПО (определенных в календарных планах как результаты работ) в контрольных точках проектов на предмет соблюдения действующих стандартов и других нормативных документов, установленных в требованиях Заказчика.
• Беспристрастие, отчетность непосредственно перед руководителем организации.

Независимая группа верификации и валидации (V&V -группа)

• Выполнение функций верификации (по договоренности с группой SQA).
• Планирование и проведение независимого квалификационного тестирования интегрированных компонентов ПО или программных продуктов с целью определения их соответствия требованиям Заказчика.
• Координирование планов работ с менеджерами проектов относительно требований к тестовой среде, сроков и порядка передачи ПО на тестирование.
• Предоставление отчетов (результатов) тестирования менеджерам проектов для принятия мер по исправлению ПО
• Независимость от менеджеров проектов в части определения объемов и методов тестирования.
• Отчетность перед руководителем организации за соблюдение порядка тестирования и состояние разработанных программных продуктов.

Группа поддержки Заказчика

• Связь с Заказчиком по вопросам автоматизации деловых процессов.
• Поддержка процессов управления требованиями, обучения пользователей, сопровождения (или помощь в их выполнении на уровне отдельных проектов).

Роли специалистов в организационной структуре разработки. Роли на уровне проекта:

Руководитель проекта системы

• Полная финансовая ответственность за выполнение проектных соглашений перед Заказчиком.
• Управление разработкой составляющих создаваемой продукции – проектов ПО, КТС, средств защиты информации (если проект предусматривает создание системы «под ключ» с поставкой всех составляющих).
• Ответственность за действия соисполнителей проекта.

Системные аналитики

• Обследование условий и потребностей автоматизации деятельности организации-потребителя.
• Системный анализ требований потребителя и формирование концепции системы.
• Контроль обоснованности принимаемых проектных решений.

Группа качества проекта

• Контроль качества рабочих продуктов, произведенных процессами ЖЦ (на соответствие стандартам, методикам и т.п.).
• Подотчетность только руководителю проекта.
• Может отсутствовать, если на уровне организации действует независимая группа качества.

Группа V&V проекта

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

Менеджер проекта ПО

• Полная ответственность за все проектные решения и действия, связанные с разработкой ПО в проекте.
• Подбор и контроль ресурсов проекта (относительно ОПО), а также графика работ.
• В больших или распределенных (по соисполнителям) программных проектах может быть несколько менеджеров (по подсистемам или уровням проекта ПО).

Проектировщики

• Принятие и документирование проектных решений по архитектуре и функциям ПО. Согласование решений с менеджером проекта ПО.
• Соблюдение стандартов качества (обеспечение достижения характеристик качества).

Программисты

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

Группа управления конфигурацией

• Выполнение процесса конфигурационного управления версий ПО и рабочих продуктов проекта ПО.

Группа сопровождения

• Выполнение процесса сопровождения версий ПО и рабочих продуктов проекта ПО во время опытной эксплуатации и в течение установленного периода сопровождения.
• Обучение пользователей.
• Выполнение процесса решения проблем.
• Могут быть членами группы поддержки Заказчика.

Группа проекта локальной компьютерной сети) (далее - ЛКС)

• При разработке системы «под ключ» проектирование и монтаж ЛКС для установки в организации потребителя.
• Закупка и установка комплекса технический средств и общесистемного программного обеспечения, пусконаладочные работы и т.п.

«Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах», Роман Савин, Москва, Дело, 2007:

"Спецификация (или spec — читается "спек". Далее употребляется в мужском роде) — это детальное описание того, как должно работать программное обеспечение. Вот так, ни много ни мало", 20 страница.

"Ваше дело послать е-мейл продюсеру (продюсером в интернет-компании называют товарища, создающего спеки), чтобы тот внес текст, уже написанный программистом, в пункт 19.а.

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

"Вопрос: Кто генерирует идеи в действующей интернет-компании? Ответ: Как правило, это отдел маркетинга. Нередко идеи инициируются службой поддержки пользователей или новым контрактом, например, с компанией по процессингу кредитных карт (credit card processor).

В общем вариантов множество.

При разговоре о большой картине сводному персонажу, генерирующему идеи, будет присвоено имя Маркетолог. Как правило, идеи компонуются в MRD ("эм-ар-ди" — Marketing Requirements Document — документ о требованиях маркетинга, суть которого: "хотелось бы это иметь").

Затем

• менеджмент проворачивает MRDШКИ через жернова анализа, утверждения и приоритезации, а
• выжившие идеи передаются продюсерам, которые их полоскают, высушивают и гладят, чтобы получилась спецификация", 70 страница.

"Разработка дизайна продукта и создание спека. На основании идеи, утвержденной менеджментом, разрабатывается и документируется ее воплощение, которое называется дизайном продукта (product design) или, простыми словами, то, как та или иная часть нашего веб-сайта должна выглядеть и/или работать.

Концептуальная разница между идеей (продукта) и дизайном (продукта) заключается в том, что

• идея — это описание ЦЕЛИ, а
• дизайн — это описание ПУТИ к достижению этой цели.

Профессионально весь этот джаз осуществляется менеджерами продукта (PMs — Product Managers), которые также могут называться продюсерами (Producers) или дизайнерами продукта (Product Designer).

Результатом продюсерских усилий являются спеки, называемые также PRD (Product Requirements Document — документ о требованиях для продукта) или просто requirements (требования).

Самые эффективные продюсеры в интернет-компаниях — это профессионалы, имеющие бэкграунд в предмете, на котором они специализируются, и ненавязчивую техническую подготовку", 71 страница.

"Спеки имеют следующую очередность статусов:

1. Во время написания они имеют статус Черновик(Draft). Продюсер пишет спек.

2. После написания и до утверждения — Ожидание утверждения (Approval Pending). Спек написан, и назначается совещание (meeting) с программистами и тестировщиками по его обсуждению или же просто им посылается е-мейл с приложением.

3. После утверждения — Утверждено (Approved или Final). Если на митинге все закричали "Ура!" или получены положительные отзывы от всех реципиентов, утвержденный спек немедленно выкладывается на один из серверов в локальной сети, чтобы быть доступным любому лицу внутри компании, которому положено его видеть. Если же спек не принят, то все начинается с пункта 1", 76-77 страницы.

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

"Стандартный глоссарий терминов, используемых в тестировании программного обеспечения", версия 2.3 (от 9 июля 2014 года), International Software Testing Qualifications Board, ред. пер. Александр Александров:

"Ведущий специалист по тестированию (test leader): См. руководитель тестирования", 14 страница.

"Директор по тестированию (test director): Руководитель высшего звена, управляющий руководителями тестирования. См. также руководитель тестирования", 18 страница.

"Группа процесса тестирования (Test Process Group): Группа специалистов (по тестированию), которые содействуют определению, техническому обслуживанию и совершенствованию процессов тестирования, используемых в организации. [Согласно CMMI]", 17 страница.

"Руководитель тестирования (test manager): Человек, ответственный за управление ресурсами и работами по тестированию, а также за экспертизу тестового объекта. Направляет, контролирует, администрирует, планирует и регулирует экспертизу тестового объекта", 48 страница.

"Тестировщик (tester): Опытный специалист, принимающий участие в тестировании компонента или системы", 61 страница.

03.12.2017