Три проблемы заказного тестирования и как их решить

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

Время и бюджет

Дано: команда просит дополнительное время на тестирование.

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

Позиция заказчика: возражает, утверждает: «Вы хотите раздуть бюджет!»

Почему заказчик может выдвигать такие возражения? У него уже появился опыт работы с предыдущими проектами, где:

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

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

Условия и договорённости

Дано: команда не планирует писать документацию по тестированию продукта.

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

Позиция заказчика: Им просто лень!

Почему заказчик может выдвигать такие возражения? У него уже появился опыт работы с предыдущими проектами, где:

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

Что можно сделать команде: объяснить заказчику необходимость тест-планов и стратегии тестирования, потребовать у заказчика ответственного за бизнес-область. Команде важно всегда документировать тестовые сценарии и предупреждать о рисках.

Требования и качество

Дано: команда утверждает, что все они — специалисты высокого класса и могут выполнить свою работу хорошо.

Позиция команды: для заказного тестирования конкретной области нужны отдельные специалисты, у нас нет сертификатов, зато есть опыт и навыки.

Позиция заказчика: утверждает, что команда — не более чем «высококлассные маускликеры», и просит предъявить сертификаты.

Почему заказчик может выдвигать такие возражения? У него уже появился опыт с предыдущими проектами, где:

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

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

Как найти контакт

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

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

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

Какие варианты решения я вижу:

• необходимо не только преодоление сложившихся (и продолжающих складываться) стереотипов, но прекращение их активного формирования;

Как? Да просто делать свою работу так, чтобы её результаты и качество были понятными и бесспорными.

• необходима координация усилий, прежде всего в части управления ожиданиями заказчика;

Как её достичь? У нас в Учебном центре, к примеру, есть тренинги по управлению ожиданиями заказчика. Это отдельная и большая тема в разрезе тестирования, и по сути это управление рисками.

• следует не воспитывать заказчика, а делать проекты, удовлетворяющие его разумным ожиданиям.

Только в этом случае стороны смогут начать двигаться навстречу друг другу и решать совместные задачи.