Мне понравилось это выступление, но я увидел в нем некую незавершенность. Поэтому на следующей конференции SQA Days я выступил с докладом на тему «Как возникают ловушки заказного тестирования».
Спасение утопающих – дело рук самих утопающих.
И. Ильф, Е. Петров «12 стульев»
На конференции SQA Days одна из спикеров выступила с докладом на тему «Ловушки заказного тестирования».
Мне понравилось это выступление, но я увидел в нем некую незавершенность. Поэтому на следующей конференции SQA Days я выступил с докладом на тему «Как возникают ловушки заказного тестирования».
Но давайте по порядку.
Спикер выделила три стереотипа заказчика – жадность, лень и тупость (с).
Жадность
Команда тестирования просит дополнительное время на тестирование. Заказчик возражает, утверждает: «Вы хотите раздуть бюджет». При этом объяснения команды тестирования: увеличение объема тестируемого функционала, опоздания в разработке, нечеткие требования, большая плотность дефектов – не принимаются во внимание.
Спикер доклада объясняет это тем, что заказчику не хватает понимания ситуации, прозрачности процесса, уверенности в результате. И предлагает рассказать ему про риски, снижение качества, приоретизировать тестируемые области, определять критерии окончания тестирования и приемки.
Мне кажется, что заказчик имеет полное право выдвигать такие возражения, поскольку в предыдущих проектах:
-
Не показывались отдельно расходы на обеспечение качества (не только тестирование!)
-
Более эффективная разработка обусловила меньшие объемы затрат на тестирование
-
Затраты на тестирование не обеспечили приемлемое качество продукта (однако были значительными) из-за общей низкой процессной культуры
-
Были организованы тендеры, где одним из критериев отбора является обоснованная стоимость проекта
Лень
Команда тестирования не планирует писать документацию по тестированию продукта. Заказчик возражает, что им просто лень! При этом объяснения команды тестирования - мы не писали тест-план и тест-кейсы, потому что на это не было времени; мы этого не делали, потому что об этом не договаривались; мы не напишем отчет о тестировании, потому что активности не фиксировались; заказчик смотрел и согласился – не принимаются во внимание.
В докладе спикер объясняет это тем, что и в этом случае заказчику не хватает понимания ситуации, прозрачности процесса, уверенности в результате. И предлагает объяснять ему то, что тест-план и тестовую стратегию всегда надо писать и утверждать, следует выделять ответственного за бизнес-область со стороны заказчика, всегда записывать сценарии и предупреждать заказчика о рисках.
Мне кажется, что заказчик имеет полное право выдвигать такие возражения, поскольку в предыдущих проектах:
-
Отсутствие именно этих действий/артефактов привело к провалу проекта
-
Команда тестирования действительно ленилась и не оформляла обещанные результаты (например, планы тестирования), за которые было заплачено
-
Ни разу не была представлена объективная оценка качества проекта, не было возможности контролировать его ход
-
Были организованы тендеры, где одним из критериев отбора является обоснованная степень следования процессам заказчика
Тупость
Команда тестирования утверждает, что все они - специалисты высокого класса и могут выполнить свою работу хорошо. Заказчик утверждает, что команда – не более чем «высококлассные маускликеры», и просит показать сертификаты. При этом объяснения команды: для тестирования конкретной области нужны отдельные специалисты; у нас нет сертификатов, зато есть опыт и навыки – не принимаются во внимание.
Спикер опять аргументирует это тем, что заказчику не хватает понимания ситуации, прозрачности процесса, уверенности в результате. И предлагает объяснять ему про то, что необходимость создавать артефакты тестирования, объяснять важность ручного тестирования, иметь портфолио.
Мне кажется, что заказчик имеет полное право выдвигать такие возражения, поскольку в предыдущих проектах:
-
В проваленных проектах его тоже уверяли, что у них есть опыт и знания
-
Декларация опыта и знаний проектной команды не подтверждалась никакими артефактами (результатами успешно завершенных проектов)
-
Имеется опыт успешных проектов, выполненных квалифицированной командой;
-
Были организованы тендеры, где одним из критериев отбора является наличие подтвержденной квалификации команды проекта
Корни
Как мы уже поняли, для всех стереотипов спикер доклада отмечала, что заказчику не хватает понимания ситуации, прозрачности процесса и уверенности в результате.
Но давайте по порядку.
-
Понимания ситуации – а зачем заказчику ее понимать?
-
Прозрачность процесса – а зачем заказчику его видеть?
-
Уверенности в результате – у заказчика есть основания быть неуверенным
Даже сами названия стереотипов трактуются по-разному:
Жадность
-
Заказчик - Разумная экономия
-
Команда проекта - Прибыльность
Лень
-
Заказчик - Экономия усилий
-
Команда проекта - Экономия затрат
Тупость
-
Заказчик - Необходимость гарантий
-
Команда проекта - А почему бы и не получить сертификаты, подтверждающие имеющиеся опыт и знание
Таким образом:
-
Стереотипы в значительной степени сформированы самими проектными командами
-
Необходимо не преодоление сложившихся (и продолжающих складываться) стереотипов, но прекращение их активного формирования
-
Разные проектные команды пожинают «успехи» друг друга
-
Необходима координация усилий, прежде всего в части управления ожиданиями заказчика.
-
Следует не воспитывать заказчика, а делать проекты, удовлетворяющие его разумным ожиданиям
Остается только вопрос, как же избежать ловушек заказного тестирования? :)
А вы как думаете? Оставляйте свои комментарии.
Ваш гуру, Александр