Постановка и достижение целей по качеству ПО при взаимодействии отдела тестирования компании-заказчика и подрядчиком.

2010-02-13T19:22:00.010+03:00

В общих чертах в начале ситуация была такой. Проект по разработке приложения уровня предприятия – система интеграции на базе решения Oracle Service Bus (бывшая BEA AquaLogic Service Bus). К моменту, когда я начал работать в данном проекте, был готов прототип и прошла пара итераций по наращиванию функциональности, подключению интегрируемых систем. О проектных процессах скажу кратко, что как у заказчика, так и у разработчиков это были процессы не на 5ом уровне CMMI.

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

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

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

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

Причина наличия дефекта в ПО поставленном в Банк	Всего
Дефект - BEA	5
Дефект в коде. Пропущено при тестировании подрядчиком	8
Дефект в коде. Тестировалось ОТ банка. Пропущено при тестировании из-за неполных требований к ПО	6
Дефект в коде. Тестировалось ОТ банка. Пропущено при тестировании, так как не учтены особенности архитектуры.	1
Дефект в коде. Тестирование подрядчиком не проводилось.	3
Дефект скриптов установки. Пропущено при тестировании подрядчиком.	4
Изменение продакшн поведения без согласования внесения изменений.	1
Не дефект. Использовались некорректные данные.	4
Не дефект. Конфигурационные проблемы на средах банка из-за ошибок администраторов банка.	5
Не дефект. Конфигурационные проблемы на средах банка по причине отсутсвия в поставке актуальной документации	7
Не согласование с банком варианта реализации изменений в требованиях.	2
Фактически это CR компенсирующий изменения внешней системы.	1
Фактически это CR компенсирующий изменения внешней системы.	1
Дефект в внешней системы.	1
Общий итог	49

Да, мы увидели, что проблемы не только в тестировании подрядчика. Но в тоже время стало очевидно, что в тестировании подрядчика есть большая проблема. В этот момент у меня возник вопрос, что значит «плохое тестироание»? Я увидел, что не понимаю, как определить хорошее тестирование. Первые попытки найти такое определение заключались в поиске «правильных» практик. Но целостной картины подходящей ко всем нюансам проекта никак не скалывалось. В этот же период я начал изучать стандарт ISO 9001 и это привело к решению, что критерии хорошего тестирования лежат за пределами самого тестирования, что такие критерии правильно формулировать исходя из ожидаемого результата от всего процесса разработки. То есть, тестирование «хорошее», если оно обеспечивает определенные аспекты в конечном результате.

Тогда я вместо формулировки «Проблема качества тестирования» описал наши затруднения так:

· Сдвиг сроков вывода приложения в прод.

· Наличие в поставляемой на приемочное тестирование системе критических дефектов.

Как было уже сказано выше, ISO 9001 предлагает формулировать цели по качеству в отношении конечного продукта. И исходя из наших конкретных проблем я определил их так:

· Отсутствие критических дефектов в системе поставляемой на приемочное тестирование.

· Не более одной пересборки во время приемочного тестирования.

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

Мы провели встречу, продолжительностью около 2 часов. Ниже Agenda встречи:

Agenda

1. Проанализировать причины основных проблем в данное время:
· Сдвиг сроков вывода в прод.
· Наличие в поставляемой системе критических дефектов.
  2. Утвердить цели в работе по повышению качества:
· Отсутствие критических дефектов в системе поставляемой на приемочное тестирование.
· Не более одной пересборки во время приемочного тестирования.
3. Определить необходимые изменения в организации и проведении тестирования для достижения целей по качеству. Для этого рассмотреть следующие вопросы:
a.      Планирование трудозатрат и сроков тестирования.
b.      Подход к тест дизайну. Структура тест кейсов. Формат тест кейсов.
c.      Представление результатов тестирования.
d.      Применение автоскриптов.
e.      Проведение тестирования в банке.

Что мы сделали в итоге

Планирование

1. Ввели практику составления скоупа релиза (более-менее его закрываем, хотя бывают случаи срочного добавления CR).
2. Ввели практику составления план-графика релиза.
3. Ввели фазу тестирования (и при необходимости отладки) на тестовых средах заказчика. То есть с реальными внешними системами, а не заглушками.
4. Ввели в план-графике контрольные точки по подготовке и согласованию тест-дизайна.

Структура ТС
1. В структуре ТС разделяем сценарий и данные для сценария.
2. Отказались от шаблона в InfoPath и перешли на шаблон в Word. В итоге ревью проводить проще, есть такая простая и замечательная вещь как трэкинг.

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

Тестирование
1. Написаны автоскипты для регрессионного тестирования.
2. Заключительная фаза тестирования подрядчиком проводится на тестовых средах заказчика

Мы проработали после этого два релиза. И результаты этих релизов таковы.

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

2. Вторая цель достигнута полностью.

Релиз 1.6
		Причина
Срок поставки билда на приемочное тестирование	задержка 1 день	Неготовность тестовой среды банка
Дефекты найденные на приемочном тестировании	2	Один пропущен подрядчиком. Второй из-за не полных требований
Количество пересборок	1	Имеющиеся дефекты

Релиз 1.7
		Причина
Срок поставки билда на приемочное тестирование	без задержки	Неготовность тестовой среды банка
Дефекты найденные на приемочном тестировании	2	Не полных требований
Количество пересборок	1	Имеющиеся дефекты

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

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

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

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

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

Тестирование глазами заказчика

Постановка и достижение целей по качеству ПО при взаимодействии отдела тестирования компании-заказчика и подрядчиком.

Agenda