Как заказчик определяет качество тестирования, и делает ли он это

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

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

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

P.S. Мои вопросы основаны на реальных вопросах, на которые мне приходится периодически отвечать моим заказчикам, особенно в начале сотрудничества, потом как-то эти вопросы перестают волновать :)
Но я пока свои варианты ответов придержу, потом поделюсь :)

-- как вы договариваетесь с заказчиком относительно оценки качества вашей работы (как он якобы будет оценивать)

Никак.

Формально: "надо вот тут протестировать..."

Материально: я в итоге передаю ему список проверок, которые только могу придумать - как технические моменты, так и какие-то замысловатые сценарии и их пересечения.

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

-- как заказчик определяет качество тестирования на самом деле

Хз.

Наверное, судит по количеству багов, негодяй :)

Интуитивно, наверное. Ясных цифровых метрик типа "процент покрытия чего-то чем-то" я еще не использовал - не приходилось.

-- делает ли он это вообще или "пока петух не клюнет..."

Тоже хз, не мое дело вообще.

как вы договариваетесь с заказчиком относительно оценки качества вашей работы (как он якобы будет оценивать)

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

Смотрит заказчик полученные документы или нет - бывает по-разному.

как заказчик определяет качество тестирования на самом деле

У многих крупных заказчиков есть свои ИТ-отделы, которые отвечают за приемку.
Часто бывает, что приемочное тестирование заказывают сторонней компании (я сама сейчас в таком проекте участвую).
Хотя бывает и так (особенно в гос.секторе), что программа никого не интересует. Деньги распилены, откаты получены. Заказчик не оценивает не только качество тестирования, но не пользуется программой вообще :)
Для маленьких программ заказчик чаще всего конечный пользователь, т.е. фактически он увидит лично качество тестирования.

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

выделенный отдел.

Расскажите,
-- как вы договариваетесь с заказчиком относительно оценки качества вашей работы (как он якобы будет оценивать),

у нас процедура стандартная: согласовывается методика на основании ТЗ. Мы по ней спеки пишем (детальные), согласовывается методика - более высокоуровневые тесты. После реализации и тестирования, к руководству прилагаются отчеты нашей группы со ссылками на пункты согласованной методики. Этого обычно достаточно.

-- как заказчик определяет качество тестирования на самом деле,

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

-- делает ли он это вообще или "пока петух не клюнет..."

делает, продукт слишком ответственный. Госзаказ.

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

Согласно договренности, они там сначала сами проходят по согласованной методике, но на своих стендах и мощностях, затем передают нам. У нас более профессиональная лаборатория и более изощренные способы изврата с трафиком, поэтому часто просто не верят, что их успешный тест у нас твердый Fail.

-- как вы договариваетесь с заказчиком относительно оценки качества вашей работы (как он якобы будет оценивать),

В нашем случае заказчик оценивает качество не тестирования, а продукта.
Устраиваем Live Meeting. О качестве тестирования скорее догавариваюсь/отчитываюсь вышестоющему начальству (по результатам ПСИ)

-- как заказчик определяет качество тестирования на самом деле,

Повторюсь, думаю, что заказчики оценивают работу в целом а не отдельно тестирования. На основании нескольких показателей:время, качество, деньги ...

-- делает ли он это вообще или "пока петух не клюнет..."

Делает. Обратная связь с заказчиками налажена через BT. А также на имя руководства приходят благодарные письма.
Отделом QA периодически производятся опросы заказчиков удовлетворенностью продуктами итд.

-- как вы договариваетесь с заказчиком относительно оценки качества вашей работы (как он якобы будет оценивать),

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

-- как заказчик определяет качество тестирования на самом деле,

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

-- делает ли он это вообще или "пока петух не клюнет..."

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

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

На одном из fixed-price проектов сейчас создаем так называемый Delivery Test Plan.

В свою очередь ссылающийся на:

- Installation guide
в который будет заложено часты по white-box тестированию:
- unit testing;
- integration testing;
- deployment;
);

- User manual
в виде use case-ов пользования системой для конечного бизнес пользователя

- Troubleshouting guide
что делать, при возникновении проблемы, во время установке или в юзабилити приложения

- Test Cases Matrix
показывает список тест кейсов для отдельных фич системы,
показывает какие тест кейсы автоматизированы

- Test Cases
в виде step-by-step сценариев


Так же будет создан документ Release Summary Test Report, в котором будет приведена статистика по user-stories и регрессии, то есть найденным багам за все время(спринты) разработки.

На выходе мы получаем документы которые отвечают на вопросы заказчика,

- что это за система?
- какие hardware/software нужны для ее установки и поддержки?
- как развернуть систему?
- как решаются самые частые проблемы при установке?
- что делать в случае конкретной проблемы ?
- как пользоваться системой конечному пользователю?
- как проверить отдельный функционал системы ?

- какие баги были найдены?
- какие баги остались не исправлены и перенесены на след. релиз?
- статистика по user-stories
- какие тест кейсы написаны?
- какие автоматизированы?
и т.д.

Что касается контроля качества на протяжении цикла разработки.
Изначально был создан тест план по IEEE шаблону, который мы использовали как гайд в нашем тестовом процессе.
Заказчику хотелось получить ответ на вопрос - "Будет ли система отвечать его нуждам?". Для этого были Demo, в конце спринтов и Release Test Report который минорно похож на Sprint Test Report, с уточнениями по спринту.

В конце все пришло к документу, который получил название Delivery Test Plan.

P.S. Быть может этот случай не отвечает на ваши вопросы, Алексей. Я так понимаю, вам хотелось бы получить примеры разницы между договоренностью и реальным исполнением, на что в постах выше ребята попытались ответить. Но этот пример, когда заказчик не понимает чего он хочет от тестирования, а лишь требует "рабочую систему".

P.S. Мои вопросы основаны на реальных вопросах, на которые мне приходится периодически отвечать моим заказчикам, особенно в начале сотрудничества, потом как-то эти вопросы перестают волновать :)
Но я пока свои варианты ответов придержу, потом поделюсь :)

Поделитесь опытом :)

P.S. Быть может этот случай не отвечает на ваши вопросы, Алексей. Я так понимаю, вам хотелось бы получить примеры разницы между договоренностью и реальным исполнением, на что в постах выше ребята попытались ответить. Но этот пример, когда заказчик не понимает чего он хочет от тестирования, а лишь требует "систему".

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

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

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