Тестировщик и техническая поддержка ( моя статья из журнала Tester's life Декабрь'12)

Не раз и не два каждая уважающая себя компания подумывала о том, как бы сделать самую хорошую и оперативную техническую поддержку пользователей.

Размышляя о методах, формулировках и других деталях, главным вопросом оставался один — КТО должен это делать? 

Ведь это должно быть эффективно и полезно как пользователям, так и компании.

Кастинг «МОДЕЛЕЙ»

Размышляя над кандидатурами, обычно рассматривают: 

• Community manager.

• Специально выдрессированная обезьянка.

• Немногим реже — программист.

• С некоторой долей вероятности попадает ПМ.

• И чаще всего — тестировщик...

У многих возникает вопрос праведного гнева —почему и тут тестировщик?

Причин может быть несколько:

• «Тестировщик — всезнайка» — он знает больше всех о самом продукте и о его уязвимостях.

• «Тестировщик — винтик-шпунтик» — оперативно среагирует на озвученную проблему.

• «Тестировщик — сыщик» — он примет меры,дабы исправить эту проблему в кратчайшие

сроки, или найдет того, кто это сделает.

• «Тестировщик — проводник» — может разобраться и объяснить пользователю на

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

Рассмотрим вариант «Community manager» (он же СМ):

• «СМ — робот» — как правило, он ничего не знает о самом продукте, только общие понятия.

• «СМ — ответственный» — узнав о проблеме, он о ней кому-то, наверное, сообщит. Кому — потом можно искать долго и нудно.

• «СМ — злобный буратинка» — он не поможет пользователю решить его проблему, если

проблема на стороне пользователя. А иногда, даже если и поможет, то все может обернуться

еще хуже и уж лучше б не помогал.

Следующий вариант «Программист»:

• «Программист — обычный» — знает продукт только в части своего кода.

• «Программист — иностранец» — он не умеет говорить на языке обычных людей о продукте.

Если и объяснит что-то, пользователь не поймет.

• «Программист — вредитель» — узнав о проблеме, он может исправить ее молча; может передать другому программисту; может отправить тестировщику; может решить, что это

не проблема, и т.д.

Остальные кандидаты — конструктор из характеристик СМ-а и программиста. Небольшой опрос показывает, что в российских и украинских компаниях, тестировщик сам занимается

технической поддержкой или находится в тесном сотрудничестве с ней.

Где это не так — можно только посочувствовать или поставить памятник. На выбор...

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

ТЕСТИРОВЩИК — ОН ЖЕ ТЕХНИЧЕСКАЯ ПОДДЕРЖКА

Для начала рассмотрим ситуацию, когда тестировщик работает сразу на два фронта: и программу тестирует, и с пользователями «поболтать» не забывает.

  Ложка дегтя

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

Первая — время.

Допустим, что его предусмотрели.

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

Кристаллики бывают:

• «Пользователи — незнайки» — сообщают не о проблеме, а о сферическом вакууме, который

является непонятно чем, и на понимание этого вы тратите и время, и нервы ресурсы.

• «Пользователи — скромняжки» — некорректно сообщают о проблеме, и вы вынуждены искать кучу вариантов, вытаскивать из них информацию всевозможными пытками методами (кнут, пряник, клещи и т.п.).

• «Пользователи — бедняжки» — сообщают о проблеме, которая находится явно не на вашей

стороне, и вы должны помочь этим милым и трогательным или озлобленным личностям с ней

разобраться.

• «Пользователи — тролли» — особый индивид- вредитель, который придумывает баги и честно сообщает вам о них, а вы возвращаетесь к трате нервов ресурсов и времени.

Список может пополняться и варьироваться, но это основа того, с чем вы можете столкнуться.

Бочка пользы

Казалось бы, да к черту такие танцы с бубном, на кой оно бедному тестеровщику, когда работы по горло! А полезно это может быть по нескольким причинам:

• Оперативная реакция — если пользователям что-то создает дискомфорт, они мгновенно

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

кратчайшие сроки.

• Баг-халява — нет таких программ, где не существует бага/уязвимости, которая приносит

пользователю радость и халяву, а тестировщику бессонную ночь и валерьянку. Будет здорово,

если о таком виде «жука-уникального-с-планеты-Халявного-Зла» сообщит честный

пользователь.

• Баги-собственники — привязываются аки верный питомец исключительно к своему

персональному пользователю-хозяину. Найти баг можно в тот момент, когда ваше созвездие

сменило галактику в 45-й день месяца, совпавшего с лунным затмением, которое

бывает раз в 130 лет и... И счастье, если его сдаст пользователь.

ТЕСТИРОВЩИК И ТЕХНИЧЕСКАЯ ПОДДЕРЖКА — ВМЕСТЕ НА ВЕК!

 

Допустим, все-таки есть «СМ-уникум», который знает продукт, может ответить и помочь пользователю, а всю полученную информацию передает вам лично.

Идеальная схема.

Или нет...?

мая твая не панимает

Главная проблема всех времен и народов — коммуникация, игра в испорченный телефон.

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

По порядку рассчитайсь!

1. Пользователь1.

2. СМ.

3. Тестировщик.

4. «Человек-исправлятор».

Допустим, Пользователь1 передает проблему СМ-у, тот — дальше по цепочке. До тестировщика дойдет наиболее полная информация, а к человеку-исправлятору попадет

уже локализованная проблема. Такую схему можно использовать только при условии, что пользователи идеальные, формулируют проблемы четко, а СМ не растеряется, когда вместо Пользователь1 — появится Пользователь 2, 5, 250, 1032, и т.д.

Усложним задачку, посадим вместо Пользователя1 — Скромняжку.

В этой схеме тестировщик будет переспрашивать, задавая дополнительные вопросы СМ-у,

СМ — скромняжке, скромняжка — ответит СМ-у, СМ... И все это с разным интервалом времени... Аааа, остановите этот замкнутый круг!!!

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

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

И сколько еще б не было подходов и схем, в каждой имеется своя уязвимость, своя бага, если хотите.

Что в сухом остатке?

Тестировщик = техподдержка — идеал для небольших и средних компаний. В больших возникнут проблемы, там лучше набирать уже специально обученных людей. Идеальной схемы не существует, и как бы мы ни пытались охватить все проблемы, каждому необходимо

собрать свой конструктор из подходов и методик. Ведь каждая компания и ее продукты уникальны, и вряд ли кто- то знает, что подходит именно вам.

Ну и помните, талантливый человек талантлив во всем, неважно, тестировщик он, программист, специально обученная личность, ПМ или community manager.