Архив метки: процессы

Тестировщики и техподдержка

Во многих компаниях тестировщики являются своебразоной «второй линией» техподдержки: помогают техсаппорту с решением особо сложных проблем клиентов.
Какие плюсы есть у подобной организации деятельности?

(пост — мое сообщение на форуме software-testing.ru)

Зачем вообще надо тестировщикам лезть к клиентам?
Во-первых, сообщения об ошибках. Они будут всегда, потому что продукта без багов нет. Задача тестировщика — из клиентского запроса вида «ваш продукт не работает!» сделать качественное сообщение об ошибке, а может даже и не одной. Плюс к этому нужно предложить вариант решения проблемы в данных обстоятельствах.
Во-вторых, жалобы на нестабильную (частый error 503, к примеру) или медленную работу, особенно важно это для веб-продуктов и серверных решений. Это не функциональные ошибки, но еле-еле шевелящийся сервер будет раздражать сильнее, чем неработающая фича, так как касается 100% клиентов.
В-третьих, это вопросы клиентов «А как сделать вот это и вот это?». Тут стоит подумать об оптимизации интерфейса — если клиенты не знают, как пользоваться вашим продуктом, то что-то в интерфейсе не так.
Если в продукте обнаружился баг, который мешает пользователю выполнить задачу, то тестировщику придется включить смекалку и проявить знание всех скрытых возможностей своего софта: клиенту надо предложить workaround, с помощью которого пользователь все же сможет делать то, что ему нужно, причем максимально удобно в данных обстоятельствах.
И конечно, клиенты придумывают сотни и тысячи нестандартных вариантов использования вашего продукта :) Такие use case-ы также могут указать не недостаточно протестированные участки.

Зачем тестировщики нужны команде техподдержки?
Тут можно вспомнить про правило 20/80 :)
Большинство писем однотипны, и для их ответа можно пользоваться даже готовыми шаблонами. Зато оставшиеся 20% писем пожирают 80% времени техподдержки и все время тестировщика, выделенное на поддержку техподдержки :)
Техсаппорт хорошо разбирается в продукте на уровне пользователя, знает все фичи-кнопки-чекбоксы-API, но есть случаи, когда знаний сотрудников техподдержки может не хватать. Это, например, проблемы, описываемые впервые — тестировщик по роду своей деятельности постоянно сталкивается с проблемами в продукте, поэтому он быстрее и точнее определит причину и сможет подсказать решение. Если проблема в продукте — то заводится баг, если проблема в окружении и в нашем продукте это никак не решить — то решение во всех подробностях объясняется техподдержке, и создается новый шаблон :)
Еще частый вопрос, с которым обращается техподдержка — а будет ли работать наш продукт вот с таким нестандартным окружением, взаимодействовать через этот протокол, дружить с параноидальным файрволом, а можно ли результаты работы вашего продукта загрузить на сайт, заембеддить в Flex application, распространять на DVD, загрузить на ютуб... Потребности (и фантазии людей в части совмещения несовместимого) крайне разнообразны, и весь этот «compatibility» testing также хорошо знаком тестировщикам.