Ловушки заказного тестирования

Моё выступление на совместной конференции SEC(R) 2009 + SQA Days 7.
Про отношения :)

Ловушки заказного тестирования

View more presentations from jnechaeva.

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

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

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

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

Таким образом, получается, что все эти проблемы имеют две стороны: заказчик не понимает, почему, а аутсорсеры не понимают, как заказчик может не понимать.

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

СТЕРЕОТИП ПЕРВЫЙ: ЖАДНОСТЬ

«Жадные аутсорсеры пытаются раздуть бюджет» - «Жадный заказчик не хочет платить лишнее».

В каких случаях команда тестирования может сообщить, что необходимо дополнительное время на тестирование? Может, если действительно хочет раздуть бюджет, а может, если это время на тестирование действительно нужно. По каким-то внешним причинам не вложились в заявленные сроки: увеличился объем тестируемой функциональности, поздно закончилась разработка, долго выясняли требования, и т.п. Команда говорит: «Нужно ещё 3 дня на тестирование». Заказчик говорит: «Не нужно, продукт работает, я сам видел».

Прецедент создан, стереотип родился.

Что делать команде тестирования?

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

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

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

Что делать заказчику?

- Слушать объяснения команды тестирования.

- Заранее определять критерии окончания тестирования и приемки продукта.


СТЕРЕОТИП ВТОРОЙ: ЛЕНЬ

«Команда не создает формальную документацию» - «Заказчик требует отчетов, но не хочет за них отдельно платить».

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

Прецедент создан, стереотип родился.

Что делать команде тестирования?

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

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

- Если тестовая стратегия не предусматривает создание тест-кейсов и формального тестирования, то это не повод не фиксировать, что же, собственно, и как тестируется. Даже эксплорейтори тестирование предполагает запись сценариев, осуществленных в ходе тестирования. На этом нельзя экономить время. Потраченное сейчас на запись сценариев – воздастся вам позже при регресионном тестировании. И у команды всегда будет готов ответ на вопрос «А что и как вы тестировали?»

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

Что делать заказчику?

- Утверждать тест-план и тестовую стратегию. Не на глазок, а вдумчиво. Хорошая команда всегда объяснит, почему было принято решение идти именно этим путем, и почти всегда сможет предложить другой вариант, если первоначальный заказчика не устроит. Хорошая команда всегда объяснит, чем чревато ускорение либо отказ от части активностей.

Заказчик должен быть уверен, что он экономит свои деньги разумно.

СТЕРЕОТИП ТРЕТИЙ: ТУПОСТЬ

«Команда маускликеров» - «Покажите мне сертификаты».

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

Прецедент создан, стереотип родился.

Что делать команде тестирования?

- Создавать артефакты тестирования, показывающие всю мощь работы разума тестировщиков.

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

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

Что делать заказчику?
- Просить аргументацию выбора специалистов именно такого уровня квалификации.

- Настаивать на более высоком, если очень хочется и готовы платить, не воспрещается.


Именно тот факт, что эти проблемы не решаются, и создает те превратные стереотипы о «жадных аутсорсерах» и «неадекватных заказчиках». Заказчики и аутсорсеры должны вместе работать над их разрушением.

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



Ссылки для смеху:

[1] Glenn Livingston, «Outsourcing Sucks, Delegating Sucks, Unless… »

[2] Niyaz PK, «Why Outsourcing Sucks»