Тестировщики и тех.поддержка: взаимовыгодное сотрудничество

Вопросам взаимодействия тестировщиков и технической поддержки уделяется гораздо меньше внимания , чем, например отношениям тестировщиков и разработчиков. Хотя, на мой взгляд, тут также довольно много разных тонкостей, психологических моментов, проблем , стереотипов  и всяческих там особенностей.
Сотрудники технической поддержки находятся на самом "острие" , ежедневно общаясь с заказчиком, мотаются по командировкам , где зачастую в стрессовых ситуациях вынуждены оперативно решать технические проблемы, прикрывая порой промахи остального коллектива, оставшегося в уютном оффисе. Саппортеры - первые, кто узнает о проблемах заказчиков, фильтрует всяческие ошибки настройки от реальных багов. Благодаря близости к "реальной эксплуатации" техподдержка обладает особо ценными знаниями о конфигурациях софта, о типичных действиях реальных пользователей, об реальных объемах баз данных и еще о многом таком, о чем тестировщики могут только догадываться. В общем, "сильные стороны" тех.поддержки очевидны. Переворачивая известный афоризм , можно  сказать , что "недостатки техподдержки являются продолжением их достоинств". Сотрудник тех.поддержки зачастую не знает досконально всех особенностей системы и не настолько глубоко в нее "погружен" как разработчик или тестировщик. Поэтому порой ему недостаточно знаний о системе, чтобы точно поставить "диагноз" той или иной проблеме и, тем более , выявить точную причину произошедшего сбоя.
Тестировщики же, наоборот  , зачастую "оторваны от реальности" , не обладая полным пониманием всех тонкостей и особенностей того, как именно используется софт " в бою".
Исходя из вышесказанного должно быть понятно, почему вопрос взаимодействия тестирования и тех.поддержки - довольно важен. Для менеджмента и руководителей этих подразделений важно не только решать всяческие шероховатости, конфликты , возможные взаимные производственные споры сторон, но и налаживать и отлаживать процесс обмена знаниями. Тестировщики должны быть более осведомлены о "реалиях" использования софта для того, чтобы само тестирование стало более адекватным и направленным на реальные, а не вымышленные или высосанные из пальца  сценарии и конфигурации. Сотрудники тех.поддержки должны быть более информированы об особенностях этого самого софта  , чтобы давать более точные  и оперативные рекомендации заказчикам.
Процесс обмена знаниями можно построить по-разному.
Я бы хотел поделиться собственным положительным опытом организации и участия в одном из вариантов подобного обмена.
А именно в некоей ротации.
Время от времени сотрудникам технической поддержки передаются задачи на регрессионное тестирование тех или иных частей системы. Почему именно регрессионное?  Потому что в этом случае саппортеру не надо выдумывать тесты, погружаться в теорию и практику тест-дизайна - он проверяет работоспособность по методикам тестирования , которые , к слову, после работы с ними техподдержки , становятся намного богаче и адекватнее.
В то же самое время тестировщикам время от времени поручается разбор кейсов от заказчика, в ходе которого ребята по-новому начинают смотреть на вроде бы уже досконально знакомую систему и наборы своих тестов. А также, что немаловажно - переоценивают свою меру ответственности за общий результат.
Вот такое вот взаимовыгодное сотрудничество.

Новый сотрудник

Я, как правило, с сожалением отношусь к тому, что люди время от времени покидают команду, но в то же время я люблю, когда в коллективе появляются новички.
Много всего положительного происходит вместе с этим. Незначительные минусы, связанные с необходимостью траты времени на обучение нового коллеги внутренним процедурам и ознакомлением с особенностями и тонкостями, с лихвой компенсируется тем, что свежий взгляд способного мыслить критически человека (а именно такие люди, как правило, успешно проходят собеседование) вскрывает такие изъяны, которые мы либо не замечали, либо почему-то мирились с ними:

1. Неточности во всевозможных HOWTO для новых сотрудников. Как правило не всегда хватает времени , чтобы держать подобные мануалы в полностью актуальном состоянии - поэтому при работе нового тестировщика с этими документами появляется неплохой шанс привести инструкции в соответствие реальному положению дел. В данном вопросе можно пойти на дополнительную хитрость: обеспечить новичка документом, заведомо содержащим изъян и понаблюдать за тем, как человек будет решать возникшую проблему, заметит ли он ее вообще? Немного по-иезуитски, но это позволяет лишний раз убедиться в правильности решения после собеседования.
2. Порция некритичных ошибок в тестируемом ПО Незашоренность взгляда,а также отсутствие груза важной и срочной работы у нового сотрудника позволяет ему замечать множество мелких ошибок и недочетов в тестируемом ПО. Как правило это незначительные ошибки в GUI, ошибки эргономики , пропущенные более опытными коллегами, а также порция замечаний и предложений по улучшению. Многое из всего, что "замечает" новый тестировщик в итоге не приводит к изменениям и улучшениям, но какой-то процент действительно полезных замечаний обеспечен в любом случае.
3. Ошибки в документации к ПО Не знаю как у других, но в число обязанностей моей команды входит и тестирование пользовательской документации к ПО. В силу разных причин пользовательская документация неизбежно начинает накапливать неточности, несоответствия с реальным поведением системы. И новый тестировщик, априори внимательно относясь к пользовательской документации (ведь зачастую именно по ней он знакомится с системой ), неизбежно натыкается на эти несоответствия , а также на отсутствие необходимых ему сведений. Это позволяет повысить качество этой самой документации.
4. Повторение - мать учения. Во время помощи новому коллеге часто приходится вспоминать некоторые аспекты функционирования тестируемого софта, пояснять и уточнять последовательности настройки, развертывания тестовых стендов и т.д. и т.п. - все это может показаться скучным, но иногда это позволяет вспоминать уже подзабытые ньюансы, освежая и закрепляя таким образом собственное знание системы.
5. Новые техники. Новый сотрудник, особенно опытный, может привнести с собой новые техники тестирования. Например, когда-то давно пришел к нам тестировщик, хорошо знакомый с техниками пентеста. Его знания и умения пошли на пользу и успешно дополнили уже имевшиеся на тот момент наборы тестов безопасности системы. Сотрудник уже давно перешел в другую компанию, но его опыт продолжает приносить нам пользу.

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