Как убедить заказчика?

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

1) дорого
2) а зачем и так столько багов?
3) Я И САМ ОТЛИЧНЫЙ ТЕСТЕР!!!!!!11111 (заказчик говорил)

По 2-му пункту: на тестирование версия программы ко мне попадает за день, или в день срока сдачи, поэтому не все найденные баги успевают пофиксить.
Как мне убедить заказчика оставить тестирование у нас?

Мое предложение. Просто предложение.

Не убедите. И не переубедите. Можете только сделать другие предложения о сотрудничестве.

Если "1) дорого", то можно предложить более дешевый вариант тестирования продукта. Частичное, по-требованию, только определенный вид тестирования, и тыды.

2) а зачем и так столько багов?
вопрос не понятен. Он именно так выразился? Он имел ввиду, что нынешнее тестирование его не устраивает потому, что все равно много багов?

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

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

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

Вроде бы, фиксить баги не дело тестировщиков.

3) Я И САМ ОТЛИЧНЫЙ ТЕСТЕР!!!!!!11111 (заказчик говорил)

И что, вы в этом сомневаетесь? :) Хотите похлопать его по голове книгами ISTQB, чтобы доказать обратное? Вполне возможно, что он сможет все протестировать лучше вас - у меня нет данных для потдверждения или для опровергательства этого суждения, поэтому я сужу свободно.

И вот вопрос поважнее остальных - у вас прозрачный процесс тестирования для заказчика?

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

Вроде бы, фиксить баги не дело тестировщиков.

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

И вот вопрос поважнее остальных - у вас прозрачный процесс тестирования для заказчика?

Да, список найденных багов открыты для него, у каждого выставлен приоритет и статус.

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

Понятно.

Заказчик не прав, но такие "думания" весьма распространены, и так вещи нужно прояснять и объяснять отдельно, лично. Это сложно, но возможно.

И вот вопрос поважнее остальных - у вас прозрачный процесс тестирования для заказчика?

Да, список найденных багов открыты для него, у каждого выставлен приоритет и статус.

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

Я утрирую, но все-таки.

Понту заказчику от списка этих багов, если в продукте все равно есть другие, а те, о которых уже известно, еще ни фига не пофиксены?! Поневоле занервничаешь, и решишь все сделать самостоятельно.

Если клиент нервничает (похоже на то), и принимает решение все делать самостоятельно - вы действительно в сложном положении, и однозначный ответ на ваш простой вопрос вряд ли найдется. Неоднозначных - множество.

Может быть, вам стоит обратиться напрямую к http://software-testing.ru/consulting ?

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

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