Слава Панкратов в своей статье описал риски в тестировании ПО. В статье  можно увидеть изображение алгоритма работы с рисками.

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

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

    Так же следует помнить, что тест-план не привязан к плану проекта. Автор говорит, это именно проблема процесса тестирования, которая очень распространена. Планы тестирования и разработки уже жестко должны быть связаны на уровне единого плана проекта.

    Так же существует риск отсутствия стратегии тестирования либо неприемлемость группой разработки или заказчиком. А формально это не риск, а проблема, которая порождает риск, что стратегия тестирования не будет выполнена в той части задач, где пересекается с задачами разработки или не будет обеспечена ресурсами (зачастую именно проектным временем) и как результат всё равно не выполнена.

    Автор подчеркивает о риске увольнения ключевого или не очень ключевого сотрудника. И такой риск есть всегда.

    На ввод нового сотрудника, его обучение и вывод на «проектную мощность» требуется время — соответственно планы проседают, скорость падает, все нервничают.

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

    Так же существует риск игнорирования рисков – это один из рисков, который распространяется на все уровни управления рисками.

    Нежелание принимать во внимание тот факт, что риски есть, что процесс (даже самый налаженный, выверенный, формализованный и контролируемый) может давать сбои, обычно к конфликтам, к необходимости перепланировать в «пожарном режиме» (что обычно приводит к просчётам и ещё больше нарушает нормальный ритм работ) и как результат к провалам.

    В таких ситуациях Панкратов советует начать работать с рисками. В тестировании специфичных рисков немного. Большинство рисков проектного уровня и могут решаться совместными усилиями групп тестирования, разработки и управления проектом.